Alvin Oga wrote: > > > On Thu, 15 Dec 2005, kevin bailey wrote: > >> was recently rootkitted on a debian machine because i'd left an obscure >> service running. > > if you know how they got in .. i assume oyu have since fixed it
my guess it was the miniserv.pl run by webmin - it had a security problem which does not seem to have been address by debian. (oh that reminds me - i must sent a bug report in now) - but i can't find it now :o( it was very late at the time - i found a bug in webmin but debian fixed it in 2003. another possibility was zope - it had had soem of its files altered. maybe now i'll not be sure now someine got in - at the time i was more concerned with moving everything to another server. > > if you do not know how they got in ... > - time to change security policy big time to prevent the next time > and/or risk losing more data next time > definitely - the first machine was a try out machine - and i'd installed loads of stuff on it. now i have two machines - one ready to take over from the first - with far fewer services running. >> now i've generally relied on debian issuing security patches but i >> thought i should be more proactive RE security. > > good bet in most cases .. but if the machine is put(used) in "insecure > mode", all the effort into putting out patches will not help > >> here's my proposed checklist to carry out for securing a domain server - >> i.e. one which mainly deals with serving websites and email for virtual >> domains. > > i assume by domain server its not samba stuff since oyu mention > website/emails > > a bigger checklist for your "proposed debianized security checklist" > > http://www.debian.org/doc/manuals/securing-debian-howto/ > will read in detail! >> could people please supply any enhancements/corrections/deletions or >> point to any resources which detail a better hardening checklist for >> debian. >> >> 1. before attaching server to network install and configure tripwire. > > personally, tripwire teaches people to ignore security emails > that the server had been hacked since you will more than likely > ignore the gazillion emails it generates of every change to the system > - turning off the checks is also counter productive that oyu don't > see the real hacked/changed files > > use other methods to find changed files or files that not supposed to > exists > - update your security database after EACH critical change > > - if you ignore things in /tmp or /usr/tmp or /var/tmp, that's > where you'll find the cracker hiding too > noted >> and could possibly put key executables on to CD-ROM and leave them in the >> server. > > good idea to put a WHOLE copy elsehwere so you have a way to > double check against a non-hacked ( offline ) machine > a second machine is set up ready to take over. > if it's cdrw drive.. the rw cdrom can be changed :-) > >> 2. firewall >> >> not i'm not sure about the need for a firewall > > how good are your defenses ?? and recovery proceedures if they get in > > - easiest scenario ... assume the cracker/hacker is in your routers and > firewalls and now do what you can to protect your machines and data > >> - i may need to access the server over ssh from anywhere. > > bad idea... what you can do .. the cracker can also do from "anywhere" > > at least, lock down incoming ssh from certain ip# > vi hosts.deny > ALL : ALL > > vi hosts.allow > sshd: your.own.machine.com > would like to do this - but i also need to be able to access the server from my laptop which connects over 3G - i.e. different IP address every time. but your right - maybe i should set it up as you say most of the time and open up access for only the time i am away. >> also, to run FTP doesn't the server need to be able to open up a varying >> number of ports. > > once a legal connection is made, other ports can be opened > >> BTW - FTP *has* to be available - many of the users only know how to use >> FTP. > > too generic .... > > if they are using ftp, they can easily use "secure ftp" isntead and > never know the difference other than possibly use a different and > secure ftp > - if they like cmmandline ftp ... they won't notice much > difference with sftp > > - if they like gui for ftp ... > http://www.linux-sec.net/SSH/client.gwif.html#SFTP > - use winscp or filezilla or ?? i'm being convinced that forcing the use of SFTP is the way to go > if they need FTP gui's > > ftp login/password should be different than their email login/passwd > they are different. >> currently - i see no compelling need to set up a firewall - especially >> since if i get it wrong i could lose access to the machine. > > you've been rooted/cracked... > - would a firewall have prevented it ?? ... maybe .. maybe not .. > >> 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. > > and how do you turn off "un-needed services" :-) > > ------- > > you left off email ... > > make sure email logins and pwd is NOT the same as the ssh > login/pwd > done - the email accounts are virtual accounts set up in courier. > - use pop3s instead of regular pop > done > ------- > >> 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 . > > bad idea ... there is zero reason why you will need to use a > pc at an internet cafe ( or any place where oyu did not install the sw ) > that is most likely filled with trojans waiting for you to tell them > your ip#, login and paswds > now been made aware of this i'll not be using internet cafes again!!!! at least it gives me an excuse to get either an ibook or a nokia 770 >> certainly check the strength of the existing passwords. > > run your favorite passwd crackers... it'd probably find 1/2 of your > passwds of your users > - if the passwd cracker found it .. the crackers know it too > i tend to use gpw or pwgen to create all passwords - so they shouldn't be too bad. but running the password checkers has to be done as you say. >> 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. > > those will teach you to ignore "security alerts" that it didnt > find anything > >> run snort to check for attacks. > > if you have the time to "watch" and what do you do when you're > sleeping and/or if you have 100 or 1,000 machines > >> get script to run and check status of server every day. > > most crackers will need about 5min - 15min to breakin and cover up > > too late if you check the status "every day" > > ---- > > lot's of other fun stuff ... that can take a day or a week to > harden the servers ... than how long more to "test it's hardened " > > c ya > alvin > > thanks for your points. i'm a programmer by training but finding that clients need reliable managed servers. so i'm trying to do two jobs at the same time - set up and manage servers - and write code to pay the bills! debian has really helped so far - my original server ran for 4 years before it was hacked - and that was with me installing loads of stuff and not really doing much RE security. hopefully i can be more proactive now and keep on top of the security issues better!!! thanks again, kev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
