Log in

No account? Create an account



« previous entry | next entry »
4th Jul 2005 | 10:32

We've just taken the third step towards eliminating insecure access to our servers.

When I was an undergraduate, Hermes was too overloaded to be able to cope with crypto, so all access (except for the sysadmins) was via cleartext protocols with exposed passwords. This has not been a problem for many years now, but because of inertia we have continued to allow insecure logins and a very large proportion of users are still using them.

Last summer I introduced secure authenticated message submission, in order to provide better support for roaming users. Since that point we have had secure versions of all protocols. At the start of term a couple of months ago, we gave notice that insecure protocols would be gradually disabled. I added pre- and post-login banners on the Telnet and FTP services warning of this, which probably had little effect because users don't read banners. I also changed the webmail login: in the past insecure logins were accompanied by a small warning which was not effective; I changed it so that users were forced to click through to the insecure login form and I made the warning more prominent. This had an immediate effect, reducing insecure logins by 80%.

This morning we've disabled Telnet and FTP completely, so terminal logins and file transfers must be performed using ssh and sftp. I've also changed webmail so that the insecure front page is redirected to the secure version, and insecure logins are forbidden.

The final stage is going to be a very long slog to gradually get all IMAP and POP users switched to secure configurations, by disabling insecure access for groups of users in stages. We expect this to take at least a year...

| Leave a comment |

Comments {7}

(Deleted comment)

from: kaet
date: 4th Jul 2005 11:41 (UTC)

I'm trying to think when my default reaction changed from telnetting to ssh-ing. Relatively recently, I think (compared to must people we know), perhaps four or five years ago. I'm sure I still type "telnet hermes", though, by default, :). Not that I do any more, I guess, now I can redirect cam mail via jackdaw (which I only found out by accident the other day). Hermes is still very useful for fingering, though. Does it use jackdaw, or its own database? Being able to type finger bloggs@hermes.cam.ac.uk is more convenient, anyway, :).

Reply | Thread

Tony Finch

from: fanf
date: 4th Jul 2005 11:55 (UTC)

The Hermes user database has a very large intersection with valid @cam email addresses, but there are @cam addresses which are not valid @hermes addresses (e.g. CUS users, mole users), and there are valid @hermes addresses which are not valid @cam addresses (mostly shared accounts). What is more, there are separate @cam and @hermes redirection mechanisms which do not have to agree with each other.

All the user admin databases are managed by Jackdaw, and the systems (Hermes, Raven, CUS, PWF, etc.) typically run a job each day to resynchronize their databases with Jackdaw's authoritative view of the world. This usually involves lots of Heath Robinson duct-tape and string.

Reply | Parent | Thread

from: kaet
date: 4th Jul 2005 12:20 (UTC)

It's usually a good way to find out crsid's for the initial search. At CARET (and some other places I've worked with) we don't use CRSIDs much, and it's hard to find out what they are when they're actually needed. It's changing now, though, now raven is becoming ubiquitous, at least everyone seems to know their own crsid's these days, :).

Reply | Parent | Thread


from: crazyscot
date: 4th Jul 2005 12:39 (UTC)

Ahh, now, I remember when the unofficial ssh access started, back when I were a lad ... *puts on flat cap*

Reply | Thread


from: techiebloke
date: 17th Jul 2005 18:26 (UTC)

Do you know the clients that are typically used?

I _think_ that most modern clients cope with IMAP servers which say:
mike@guylian:~$  telnet localhost imap
Escape character is '^]'.

which is a handy way of encouraging the clients to say "starttls" without any effort on your or - more importantly - the users part. If there are combinations of clinets + host os which are a pain for you to test, poke me: I have some reasonable client test resource available. (x86 is much easier than PPC because I *heart* vmware)

A useful first step might be to make the imap server require TLS if $clientip !~ /$camacuk/ (IYSWIM) - that'd certainly get you the most security bang for your helpdesk buck.

Reply | Thread

Tony Finch


from: fanf
date: 25th Jul 2005 11:20 (UTC)

Unfortunately this doesn't work with our planned per-user restrictions - doing the insecure lockout this way has to be per IP address. It is probably worth investigating, though. I will cause it to be discussed...

Reply | Parent | Thread