> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
