Re: being hacked? - hatches/hardening
On Tue, 3 Feb 2004, Adam Aube wrote:
> On Sunday 01 February 2004 07:34 pm, @(none) wrote:
> > Any other packages recommended for battening down the hatches?
>
> - AIDE or Tripwire will maintain a list of checksums of binary files and
> libraries - so you can tell if anything's changed
>
> - Snort can detect some attempts to hack your box over the network (though
> it requires tuning to be useful)
>
> - You should also see the Securing Debian Manual
>
> http://www.debian.org/doc/user-manuals#securing
how much time/$$$ do you want to spend "battening things down"
- an hour, a day, a week ..
- it's eazy to spend a week to hardening your "one" servers
and than repeat for additional machines
my "security policy"
- create a security policy
- figure out why you need security or "don't care"
- figure out what you lose if the cracker has root access
to one or more of your servers
- figure out your security weak points
c ya
alvin
#
# http://www.Linux-Sec.net .... more links and "hardening" howtos
#
common security problems ..
- bad hardware .. ( bad fan, bad memory, bad disks, bad cables.. )
- bad/missing door locks
-
- easieast way for the cracker to get your "proprietory data"
- take/steal your PC or laptops )
- sniff you at starbucks, b/n, work
- sniff your passwds at the colo
- things you don't want to do/use ...
- disallow telnet ...... use ssh instead
- disallow ftp ......... use sftp instead
- disallow pop3/imap ... use secure pop3, secure imap
- disallow dhcp ........ use static ip# instead
- disallow root logins . login as user, than su - root
- disallow wep wireless .... use ipsec/ssh/ssl instead
- consider these to have inherited sniffers and trojans
- use "wired connections ... NOT wirelesss"
- disallow vpn from peoples homes
- consider these to have inherited sniffers and trojans
- disallow insecure laptops from your internal network
- consider these to have inherited sniffers and trojans
- disallow traffic from outside web traffice to come in ...
- inside servers goes out to get the new web db updates
- do NOT put login based services on "hands-off" servers
- dns, firewall does NOT need user accts
- web servers should be separate from mail servers
- secure pop servers should be considered insecure
- things to do ...
- use different login ID and different passwds
ssh login, email addy, ppp login, vpn login, ..
- apply all patches to your test server ...
than apply the tested patches to your "production server"
- create daily, weekly, monthly, quarterly full backups
- create daily, weekly, monthly, quarterly incremental
backups that span 2 or 3 full backups
- use rotate each backup to other disks/servers...
- play with firewalls if you like ...
- log everything .... on all machines ...
- but reading/scanning log files is a waste of time
until you have to double check what tripped the IDS
- each machine should consider all other machines hostile
- users should have to type their pass phrase to get
intot he server from known hosts w/ ssh keys
- setup ids, that does NOT give you any false positives
( each "alarm" you get are real ...
- learn from other peoples "security" mistakes
and if it applies to your similar "insecure practices"
.. on and on and on ... for days, weeks... months ...
and in actuality ... "security" is 24x7x365 ...
gazillion more rules .... and pizzallion more variations of why
one way is better than another ... ( just depends on you and
your time and your $$$$ and your risk/willingness to lose data )
Reply to: