Re: hardening checkpoints
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
it was very late at the time - i found a bug in webmin but debian fixed it
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
> i assume by domain server its not samba stuff since oyu mention
> a bigger checklist for your "proposed debianized security checklist"
will read in detail!
>> could people please supply any enhancements/corrections/deletions or
>> point to any resources which detail a better hardening checklist for
>> 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
> - 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
>> and could possibly put key executables on to CD-ROM and leave them in the
> 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
> 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 ...
> - 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
done - the email accounts are virtual accounts set up in courier.
> - use pop3s instead of regular pop
>> 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
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
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