Re: hardening checkpoints
> 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.
but after the initial connection doesn't the server then wait for the data
connection on a port in a range above 1065?
> 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.
fair point
>
> 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...
i'm beginning to think that i should force the users away from FTP!
>
> 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.
this is ok to do in cgi scripts due to cgi-wrap being relatively easy to
install - however, i've never even heard of doing this for PHP.
>
> 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.
>
will check this out
>> 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...
>
very interesting - will need to be looked into.
> [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.
>
thanks again - very useful
when i've finished the daily monitoring script i'll post it up in case it is
useful to anyone else.
kev
Reply to: