[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hardening checkpoints




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

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
 
> 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/

> 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

> 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

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

>  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 ?? if they need FTP gui's

ftp login/password should be different than their email login/passwd

> 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

	- 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

> 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

> 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



Reply to: