Re: hardening checkpoints
kevin bailey wrote:
2. firewall
not i'm not sure about the need for a firewall - i may need to access the
server over ssh from anywhere. also, to run FTP doesn't the server need to
be able to open up a varying number of ports.
You can limit your FTP server to listen for data connections on a
specific port only (eg, ftp-data, or 20). Then you only have to allow
connections to ports 20 and 21. This takes care of passive mode users;
active mode involves the FTP server connecting back to the users for
data transfer, and so relies on the users' own firewall policies
permitting the connections.
You could also set up SSL/TLS so that the users whose clients support it
recieve the benefits of an encrypted session.
BTW - FTP *has* to be available - many of the users only know how to use
FTP.
In that case it would be best to secure the machine assuming that the
user accounts have already been compromised. :) Can the users upload PHP
scripts? In that case anyone sniffing passwords from your FTP sessions
can run their code on your system...
You could configure Apache to run each user's scripts as the user in
question, rather than www-data. This is rather difficult to do however,
and perhaps impossible to do in a way that doesn't suck.
Keep on top of any privilige escalation bugs in the kernel since these
will allow the hypothetical attacker to take over the system entirely.
The stock Debian kernels recieved a security update yesterday... it was
a long time in coming but I believe the only issues in the stock kernels
have been fairly uninteresting DOS attacks anyway.
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 .
An alternative to public key authentication is to make use of a one-time
password system. There are packages for OPIE in Debian, which challenges
you with a string of text that you enter into your OPIE calculator (you
can get dedicated calculators, or software to run on a PDA or mobile
phone) along with a secret password. The calculator gives you the
response which you use to log in to the server.
A more low-tech solution is OTPW[0]. You simply print out 25 or so
pregenerated passwords into a bit of paper (write the system's SSH host
key on the back if you don't remember it). To log in, concatenate a
secret 'prefix password' with the next password on the list.
In both cases, the paper/calculator is useless to an attacker without
knowledge of both your password and the particular host to which it applies.
Until all public access PCs have some kind of standardised smart card
reader that we can use for our SSH private keys and PGP keys, one-time
password systems are probably more secure if you must use untrusted
public terminals. Consider that a PC that you plug your usb disk into
may have been configured to make a copy of anything it finds for itself,
either by the crooked owner of an Internet cafe, or a user who is mining
the computers for interesting passwords and other data...
[0] http://www.cl.cam.ac.uk/~mgk25/otpw.html
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.
run snort to check for attacks.
get script to run and check status of server every day.
Logwatch or logcheck can help with this. An alternative approach is to
configure syslog to log everything of ERROR priority or higher to a
file, eg /var/log/important. Then put an entry such as the following
into /etc/crontab:
@hourly root logtail /var/log/important | mail -e -s "Important log
events on $HOSTNAME" root
Another good one is:
@daily apt-get -qq update && apt-get -qq --dry-run upgrade | mail -e -s
"Upgradable packages on $HOSTNAME" root
Also check out /etc/security/limits.conf; it will allow you to set up
resource limits for your users. See getrlimit(2) and the administrator's
guide from the libpam-doc package.
--
Sam Morris
http://robots.org.uk/
PGP key id 5EA01078
3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078
Reply to: