On Fri, Jul 20, 2007 15:12:34 PM -0600, Stephen John Smoogen (smooge@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