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
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
Reply to: