On 7/21/07, M. Fioretti [EMAIL PROTECTED] wrote:
On Fri, Jul 20, 2007 15:12:34 PM -0600, Stephen John Smoogen
([EMAIL PROTECTED]) wrote:
My first point is going over the long list
http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf and figuring out
what meets the local environment.
- set up only ssh2 on a non standard port
Depending on the environment, I have found that this is not a useful
tool. The problems I have encountered is that it just turns off some
of the attacks.
I agree, but I have noticed in the past, and read in several places,
that it's not security through obscurity: its main usefulness would
not as much extra security as saving a bit of bandwidth and server
load from automated attacks with off the shelf scripts.
denyhosts or fail2ban also can help that. THe main issues I had was
that I had automated scans against SSH on other ports. Not as many as
I did with SSH on 22... but they do show up... the attacks seem to be
based on the principle that a lot of backdoors are hacked ssh servers
running at a high port with usually a poor password. So some
hack-teams are just looking for existing backdoors and pounding away
at them until they figure out which 'default' backdoor it is.
But if the target is considered worthwhile it does nothing as a slow
nmap will point out that SSH is running on another port.
of course, but that's why I listed it together with SPA
[Oh I will put ssh on the telnet port as no one would explain
that.. and that way I can use a 5 letter password.]
long passwords are another item on the list.
Other issues are that it can flag other security tools that might be
used in an environment looking for non-standard traffic.
sorry, I am not sure I understand this. Care to elaborate?
At several places I have worked, our snort/etc servers would look for
SSH on high ports due to the backdoor problem listed above. A lot of
the intrustion prevention tools will auto-block that as bad traffic
also. We spent a couple of days dealing with a client who kept saying
SSH wasnt working.. and it was due to his providers IPS blocking stuff
at 22122 as SSH was only to occur at 22.
I do not know enough about this to answer, but its name does not imbue
trust in me :). [E.G. I would believe more in a 3-5 packet approach.
Query, ReverseQuery, Answer-To-RQuery, Authorization]
Is this scheme documented anywhere?
- set up itables (what would the safest iptables script to do all and
only the services listed above?
I think that if security is essential, then one should know iptables
first.. then use a script.
Me too, but it's a chicken-and-egg situation. iptables and ssl are
among the worst documented areas of what a learning sysadmin should
learn. I have NO trouble to study iptables, but doing it with a
tutorial or man page on one side, and a working, _recent_ script (some
of the most readable docs I've found are relatively old) would be much
more efficient. Hence my request of sharing iptables commands working
today.
Not knowing iptables and relying on a script usually ends up with
lots of email to some firewall list about why I cant talk to my
remote server anymore.
Of course, I wouldn't run such a script, or any new tool suggested in
this discussion, before being sure to understand what each line and
option does.
Any further feedback is welcome!
Will try to send some iptables stuff later this week.
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. The Merchant of Venice
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
