> > I suggest you set up host based firewalling, where iptables limits > incoming/forwarding/outgoing traffic to whatever services you are > running. This is especially important if your running a webserver and > allow user cgi uploads, or cgi's with vulnerabilities are already > installed. For example, I had cacti from debian stable installed on a > monitor server at one point that got hacked by a script kiddie well > before the security patch was released. I have also had web users > install vulnerable cgi's that kiddies use to install programs that > launch DOS attacks on other networks, which in turn caused my network to > get DDOSed in retaliation (I am guessing really). Anyways on a > multi-user web server it difficult to track down the vulnerable cgi > unless you run the cgi's as the account owner (as apposed to all running > as www-data), and the conversion to suexec or cgiwrap is nontrivial
good point - i installed cg-wrap before and found it was ok to install on debian. this should be there as a matter of course. > (although I recommend it highly as you can also get cpu/mem limits with > cgiwrap), so for me blocking new or unrelated outbound connections was > the easiest. Now this does not protect me really from root exploits > since it is obvious they can get in the door, but for now I am checking > my binaries regularly as well as keeping my kernel up to date. > Occasionally I see denied outbound connections to strange port numbers > in my logs, most of them look like they are from evil scripts trying to > call home. > > It would be really nice if iptables could tell me what user it was that > was trying to open the connection (I know I can setup a rule to match a > user, but wouldn't this create a lot of overhead to have one rule for > each user on my system? (I have a lot)). > > Here is the guide I used for creating my firewall rules, I also read up > a bit on netfilter/iptables and tested it on a local system before > installing it on my servers. > > http://www.sun.com/blueprints/1103/817-4403.pdf > i'll check it out >> also, surely the most important set is next - which is >> >> 3. make sure only required services are accepting incoming requests. >> >> so, use something like nmap to test for open ports on a remote machine. >> make sure only required services are running. >> >> 4. enhance authentication >> >> maybe set up ssh access by authorised keys only - but again this has a >> problem when i need to log in to the server from a putty session on a PC >> in an internet cafe . >> >> certainly check the strength of the existing passwords. >> >> 5. ongoing security >> >> sign up to email lists to monitor security issues RE the services used. >> >> get server to run chkrootkit regularly and email results. >> >> run snort to check for attacks. >> >> get script to run and check status of server every day. >> >> >> any comments gratefully received, >> >> kevin >> >> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
