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. > 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? > 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! Marco -- The Family Guide to Digital Freedom: http://digifreedom.net