On 7/21/07, M. Fioretti <mfioretti@xxxxxxxxx> wrote:
On Fri, Jul 20, 2007 15:12:34 PM -0600, Stephen John Smoogen (smooge@xxxxxxxxx) 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@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
