On 7/21/07, M. Fioretti <mfioretti at mclink.it> wrote: > On Fri, Jul 20, 2007 15:12:34 PM -0600, Stephen John Smoogen > (smooge at gmail.com) 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"