For ssh I highly recommend disabling password login, use only key pairs, this will really help improve your security with SSH, another thing you can do is monitor SSH logs, you will find that at times there will be someone trying to loging using a dictionary of users, you can easily create a script that checks for failed logins, count them and ban the IP in your firewall with iptables, there is also some pre-made scripts for this too. Generally only open ports for services that you really need to have exposed to the WAN (Internet). 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. > 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 _______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
