[SWLUG] Possible SSH Attack

[Dave Cridland]

On Fri Jul 15 09:00:57 2011, Jon Reynolds wrote:
>  As for the pop side of things, I'm afraid my understanding of the  
> mail
>  server is lacking a little. I kind of blindly fumbled my way  
> through
>  setting it up following an online tutorial and it works, but  
> that's as
>  far as my knowledge goes really.
> 
> 
I wouldn't trust Courier as far as I could throw it.

In any case:

1) Switch to Dovecot. I think it'll work off the same mailbox format,  
and Timo's a nice guy. He'll be amused that I keep recommending his  
server given I work for a company selling one.

2) Do not use system accounts for service access.

3) Do not use system accounts for service access.

4) Do not use - have we got there yet?

For one thing, if you hook your IMAP server's authentication into  
your system authentication, via PAM, you're restricting the types of  
authentication you can use, so your mail client will always send your  
password in the clear.

For another, brute-forcing POP or IMAP is cheaper than brute-forcing  
SSH, and if they recover that password they've then got system access.

Most mail clients seem to support CRAM-MD5 - which isn't secure  
enough to consider running without TLS anymore, but does make it  
harder to be subjected to spoofing or brute-force attacks.

Most mail servers support DIGEST-MD5, which is a bit better, and some  
support SCRAM-SHA1-PLUS, which does magic known as "channel binding",  
and is better yet.

Channel binding is proving that the TLS channel you're talking over  
extends from you to the thing that's asking you to authenticate,  
without anybody else in between.


>  I access my mail via IMAP on my phone, roundcube via a browser or  
> mutt
>  directly in an ssh session. I 'think' I don't need POP3 but how to
>  configure this to help my security problem is still a bit beyond  
> me.
> 
> 
All those support IMAP.

Just turn it off, or firewall it off. If things don't work anymore...


>  I did think I had followed a tutorial to set up  my mail as SLS  
> but it
>  didn't seem to work, at least when I tried my credntials in my mail
>  client as SLS(or TLS not sure the diff) it wouldn't work, put in
>  credentials as just plain login and it worked, so I have left it at
>  that...again naively thinking, who would want to get into my  
> system, I
>  have nothing of interest. Seems I was wrong!

Mail clients typically have two modes of operation for encryption,  
and for some bizarre reason insist on making the user make the  
choice. This is blindingly stupid, but what can you do? For maximal  
confusion, they use the wrong terminology usually, and so you have to  
guess what they might mean.

"IMAP" - a mail protocol, running on port 143.

"IMAPS" - Same protocol, with immediate and unconditional encryption  
negotiation, on a diffrerent port.

"SSL" - one of three close relatives, this is an old protocol  
providing encryption, developed by Netscape (remember them?) and  
loosely based on X.500/X.400 strongly authenticated binds. You  
typically see SSLv3 in the wild on older sites. SSLv2 is considered  
harmful.

"TLS" - an IETF standard, in three varieties which are *very* close  
in form, which is the modern standard protocol for encryption.  
Virtually anything that claims to be doing SSL is really doing TLS.

"StartTLS" - an extension (now part of the core) of IMAP, which  
allows a pre-negotiated switch to TLS on the same port. Most other  
application protocols also have this (ACAP, POP3, LDAP, etc).

Assuming you have provided your mailserver with a keypair (an X.509  
certificate and a private key, sometimes bundles together as a  
PKCS#12 file), then StartTLS should just work. If your mail client  
offers you a "TLS" option as well as an "SSL" option, it probably  
means "StartTLS" - the SSL option will do IMAPS, and as I said  
before, probably negotiate TLS anyway. A "TLS if possible" also means  
StartTLS - usually.

Some clever mail clients may even spot the STARTTLS extension and  
automatically negotiate it - which is what they're meant to do.

Some stupid ones will connect quite happily to an IMAP server without  
concern if it doesn't offer TLS, but then complain bitterly if it  
does and they can't validate the certificate. You can make the client  
validate the certificate by creating your own CA, or using someone  
elses - if you don't, then the encryption is - technically speaking -  
worthless - unless you're using Channel Binding, which'll give you  
roughly similar effects.

HTH,

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade