A Server for my work (I'm in a little deep here)

[Impotence]

Also, I can argue that even a signed cert won't protect most users from a MITM attack, since they will usually blindly click "OK" anyway.

It won't protect the users, but it will protect me from the users if it does happen :P(and i have explained why it is important not to just click yes!)

But I digress... even a self-signed certificate is useful for the important thing: securing the connection with encryption.

Surely if a MITM is possible its not any better than clear text?

I Suppose the deciding factor is if i can convince my work to pay for a signed certificate, and do so on a yearly basis (How long do certificates last?)... how much is this going to cost overall?

[OT]
Verisign are impossible, i cant even find out how much they want for a certificate!
[/OT]

UPDATE: There is no way in hell that i'm going to manage to convince my work to shell out £525 for a 3 year certificate (Verisign), Its just not going to happen... They must be making an absolute fortune!

 

[Anti-Trend]

Surely if a MITM is possible its not any better than clear text?

I said it was possible, not plausible. For a MITM to work, you have to be expecting the connection to happen, you have to be physically in-line with the connection, and you have to be ready to spoof the target host and target client. Very methodical, and requires some resources in the right place at the right time. Just to compromise a misconfigured router or firewall and sniff for clear-text passwords however is a lot more feasible, since you just have to capture everything and parse through it later.

But back on the MITM topic once again, when you connect to a normal, unencrypted web page, how do you know for sure it's the real host? Gut feeling? ;) MITM is a very effective attack if you can pull it off, but it's not easy to do in most cases.

 

[Impotence]

I have had a slight brainwave, I'm dumping proftpd for SFTP (and FileZilla on the windows clients, if its ever needed... this is only a backup for samba!)

This will also make it stupidly easy to migrate machines from winbloze to K/Ubuntu if i ever get the OK :D

 

[Anti-Trend]

I ended up doing essentially the same thing on my own servers. I used to have secure WebDAV access and FTP w/TLS, but it seemed the less savvy users had problems no matter which mediums they chose, and it's not a great idea to allow so many services to address the same issue anyway. SFTP and a tiny bit of training seems to do the job quite well. Of course, SSH/SFTP is much more transparent on Linux than in Windows. For instance, in Konqueror you can put in an SFTP URL straight into your address bar and browse it like a local directory tree. Or even better, you can use the FUSE filesystem to mount your SFTP connection as a local directory. In Windows they'll have to use FileZilla (or maybe PuTTY, WinSCP, etc), but even that's not bad. They could do worse than having a decent, open-source FTP client like FileZilla.

Oh, and here's a tip for you. For users that won't need shell access, you can remove BASH (or whatever shell you give by default) from their account in /etc/passwd and give them the SFTP binary for their shell instead, like so:

#Before hardening
someuser:x:1028:1028:Some User:/home/someuser:/bin/bash
#After hardening
someuser:x:1028:1028:Some User:/home/someuser:/usr/libexec/openssh/sftp-server

This will prevent them from ever getting shell access, even if they have SFTP access. Also, with the use of DenyHosts, you can harden SSH/SFTP quite well against brute-force password cracks.

 

[Impotence]

Sweet, I had thought that i was going to have to give users shell access to use SFTP... but I'm glad i was wrong, so i can still ban all users except me from shell :D

 

[Anti-Trend]

Sweet, I had thought that i was going to have to give users shell access to use SFTP... but I'm glad i was wrong, so i can still ban all users except me from shell :D

Yep, and that's the right approach, too: give users the least amount of access necessary that still allows them to do their job unhindered. A good sysadmin works it out so things are easy and efficient for the users, *and* secure, easy to manage, and all the other things we like. In that respect, your server will be better configured than the IT infrastructure at my work by worlds. :)

 

[Impotence]

Right... passwords!

There is very little point in me securing this server to the best of my ability if my boss uses a simple password (as i believe that they want access to all files on the machine, there not getting shell tho ;)) so i need to write up a guide for staff to follow (and that i can enforce!). All i have come up with so far is:

1. Passwords MUST NOT be dictionary words.
2. Passwords MUST be over 8 characters.
3. Passwords MUST contain numbers or symbols.
4. Passwords MUST be changed every ???? weeks/months

While i don't want to become the local BOFH, i do want to enforce good passwords but not make it too 'hard' on the users so they write them down... how often should a password be changed?

I don't think it will be necessary to lock user accounts (until i unlock them) if they get there password wrong X times, i think it might be a good idea to lock accounts for 1 minute every time they get there password wrong after getting it wrong 5 times within 10 minutes! or some variant, ether way it would make a brute force attack (or even a dictionary attack) next to impossible while at the same time it shouldn't affect users too much (if at all)... how would i go about implementing this?

 

[Anti-Trend]

1. Passwords MUST NOT be dictionary words.
2. Passwords MUST be over 8 characters.
3. Passwords MUST contain numbers or symbols.
4. Passwords MUST be changed every ???? weeks/months

This all sounds very reasonable. However, some minimal user training may be in order. I'd introduce the users to a few easy ways to satisfy your criteria, such as 1337 and passphrases, whichever makes more sense to each individual. That way, they're less likely to have problems implementing your guidelines or think you too draconian.

While i don't want to become the local BOFH, i do want to enforce good passwords but not make it too 'hard' on the users so they write them down... how often should a password be changed?

You're absolutely right that if you rotate passwords too rapidly, users will become frustrated and confused, or worse, end up sticking their passwords to things via post-it notes. As to exactly what policy to implement here, you're in a much better position to decide, being aware of the political climate of your workplace as well as the sensitivity of the data you will be protecting. I'd say that the more sensitive the data, the more frequent the password cycles. Conversely, less sensitive data doesn't really merit rapid password cycling, since it will cause more problems than it solves. Politically, even if your data is pretty sensitive in nature, your boss may trump you on that front. These are all things you must weigh carefully, but I'd say as a general rule you should cycle your passwords no quicker than 2 months and and no longer than 6. Also, user accounts should be locked and/or password changed immediately once they've left employ, even if the data is left around for a while.

I don't think it will be necessary to lock user accounts (until i unlock them) if they get there password wrong X times, i think it might be a good idea to lock accounts for 1 minute every time they get there password wrong after getting it wrong 5 times within 10 minutes! or some variant, ether way it would make a brute force attack (or even a dictionary attack) next to impossible while at the same time it shouldn't affect users too much (if at all)... how would i go about implementing this?

You can set these policies and enforce them with PAM, built right into modern Linux and UNIX systems. It's actually quite easy to implement once you have an idea of what you want to do, see the PAM-Linux docs for more info: The Linux-PAM System Administrators' Guide - anti-trend.homelinux.org

Also, I've mentioned this already but you can use DenyHosts to further harden SSH against DOS and strong-arm cracking attempts from only certain networks (e.g. public ones), whitelisting others (e.g. private networks). It is a simple script which uses your system's TCPWrapper facility to automatically deny hosts for a predetermined amount of time based on abuse patterns, then report this data to you. I highly recommend it if you'll be exposing SSH for public usage -- in a rainstorm of scripted SSH attacks, DenyHosts is a sturdy umbrella.

 

[Anti-Trend]

One other thing to note: if you ever are able to move to Linux on the desktop (or simply wind up with a myriad of Linux servers), take a good long look at Puppet.