APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Who's been reading my email?


2013/07/02

Disclaimer: this is one of those "there must be a better way" things. Maybe there really isn't, but in either case I thought I'd write it up because the idea might be useful to you in some other context.

A Kerio Connect customer wrote to me asking this:

We would like to know if there is a way we can check to see if one of our Kerio email accounts has been compromised?

When our manager logs into his account some of his email's have been opened/read.

Is there any way check to if his mail has been opened at a certain location by IP-address?

The answer, unfortunately, most of the time, is "No".


The missing IP

There are times when IP addresses are recorded. If you send any email while logged into an account, your IP is recorded in thd "mail" log. If you delete or move any email, that will be recorded in the "operations" log.

In the unusual case where your IP address changes during a session, that will be recorded in the "security" log.

[17/Jun/2013 15:43:58] Client for Web
session(id=95a3232f5307f408a9a24f04ea6dc064e9a783f657b79d0d7;
[email protected])changed IP address: created for
IP=68.15.37.85, secure=yes, new connection from 
IP=174.23.88.15, secure=yes
 

Unless extended debugging has been turned on in the "debug" log, there is nothing that records your IP if you just log in, read some email and log out.

Surprisingly, some of the extended debugging that you would think might record the IP, do not. Turning on Authentication, for example, doesn't help:

[28/Jun/2013 13:50:48][16742] {auth} Authenticating user
[email protected]..
[28/Jun/2013 13:50:48][16742] {auth} User
[email protected] successfully authenticated.
[28/Jun/2013 13:50:48][16742] {auth} SessionManager:
creating session for user [email protected]..
[28/Jun/2013 13:50:48][16742] {auth} SessionManager:
successfully created session for user [email protected]
 

Connection logging will record the IP:

[28/Jun/2013 12:38:54][12868] {conn} Established
secure server connection from 174.23.88.15:53495 to
96.126.98.231:443 using TLSv1/SSLv3 with cipher AES256-SHA,
id 0xb0c97808
[28/Jun/2013 12:38:54][4677] {conn} Established
secure server connection from 174.23.88.15:53496 to
96.126.98.231:443 using TLSv1/SSLv3 with cipher AES256-SHA,
id 0xb0c97808
[28/Jun/2013 12:38:55][11721] {conn} Established
secure server connection from 174.23.88.15:53497 to
96.126.98.231:443 using TLSv1/SSLv3 with cipher AES256-SHA,
id 0xaf5a92e0
[28/Jun/2013 12:38:55][12874] {conn} Established
secure server connection from 174.23.88.15:53498 to
96.126.98.231:443 using TLSv1/SSLv3 with cipher AES256-SHA,
id 0xaea608a8
 

Combining those two gives us a record:

Combining Connections and Authentication

But it's very noisy:

[28/Jun/2013 17:52:37][11721] {conn} SSL debug:
id 0xaf52a038 SSL handshake started: before/accept
initialization
[28/Jun/2013 17:52:37][19329] {conn} SSL debug:
id 0xaf33c328 SSL handshake started: before/accept
initialization
(60 {conn} lines deleted)
[28/Jun/2013 17:52:37][19329] {conn} SSL debug: id
0xaf33c328 SSL_accept:SSLv3 flush data
[28/Jun/2013 17:52:37][19329] {conn} SSL debug: id
0xaf33c328 SSL handshake done: SSL negotiation finished
successfully
[28/Jun/2013 17:52:37][19329] {conn} Established
secure server connection from 174.23.88.15:21011 to
96.126.98.231:443 using TLSv1/SSLv3 with cipher AES256-SHA,
id 0xaea3aeb0
[28/Jun/2013 17:52:37][24347] {conn} SSL debug: id
0xaf51f1d8 SSL_accept:SSLv3 read client key exchange A
[28/Jun/2013 17:52:37][24347] {conn} SSL debug: id
0xaf51f1d8 SSL_accept:SSLv3 read finished A
[28/Jun/2013 17:52:37][24347] {conn} SSL debug: id
0xaf51f1d8 SSL_accept:SSLv3 write change cipher spec A
[28/Jun/2013 17:52:37][24347] {conn} SSL debug: id
0xaf51f1d8 SSL_accept:SSLv3 write finished A
(60 {conn} lines deleted)
[28/Jun/2013 17:52:47][19329] {auth} Authenticating user
[email protected]..
[28/Jun/2013 17:52:47][19329] {auth} User
[email protected] successfully authenticated.
[28/Jun/2013 17:52:47][19329] {auth} SessionManager:
creating session for user [email protected]..
[28/Jun/2013 17:52:47][19329] {auth} SessionManager:
successfully created session for user [email protected]
[28/Jun/2013 17:52:47][19329] {conn} SSL debug: id
0xb0c9e850 SSL3 alert write:warning:close notify
[28/Jun/2013 17:52:47][19329] {conn} Closing socket 65
(360 {conn} lines deleted)
 

On a busy server, there would be a lot of intermingled connections and it could be very difficult to determine who logged in from where.

Slightly less noisy, but suffering from the same uncertainty, is to only turn on Authentication and use tcpdump to record connections:

(Debug log)
[28/Jun/2013 18:17:37][21950] {auth} Authenticating user
[email protected]..
[28/Jun/2013 18:17:37][21950] {auth} User
[email protected] successfully authenticated.
[28/Jun/2013 18:17:37][21950] {auth} SessionManager:
creating session for user [email protected]..
[28/Jun/2013 18:17:37][21950] {auth} SessionManager:
successfully created session for user [email protected]
(tcp dump)
tcpdump "(tcp port 443 or tcp port 143 or tcp port 993) and tcp[13] == 2"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:17:37.454568 IP
pool-174.23.88.15.bstnma.fios.verizon.net.56402 >
www.aplawrence.com.https: Flags [S], seq 3157418091,
win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val
986188687 ecr 0,sackOK,eol], length 0
18:17:37.819622 IP
pool-174.23.88.15.bstnma.fios.verizon.net.56403 >
www.aplawrence.com.https: Flags [S], seq 2196966916,
win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val
986189046 ecr 0,sackOK,eol], length 0
18:17:38.747108 IP
pool-174.23.88.15.bstnma.fios.verizon.net.56404 >
www.aplawrence.com.https: Flags [S], seq 1481710430,
win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val
986189964 ecr 0,sackOK,eol], length 0
18:17:38.762135 IP
pool-174.23.88.15.bstnma.fios.verizon.net.56405 >
www.aplawrence.com.https: Flags [S], seq 868054077,
win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val
986189978 ecr 0,sackOK,eol], length 0
 

That "and tcp[13] == 2" is what curtails the tcpdump to only initial connections, so we do have far less chatter, but again, on a busy server we might not be sure what login belonged to what IP.

So, the answer is that we just might not be able to find out.

I did suggest a few things, though, the most obvious being to change the boss's password. Another, perhaps less obvious item would be to set his or her profile to only allow whatever client(s) they actually use. If they only use Outlook, disallow Webmail and so on. That's not going to stop snooping directly, but it might make it harder. The log record denying access might also show who has been doing this

28/Jun/2013 18:32:06] HTTP/WebMail: User
[email protected] - login denied: Access Policy rule
'Users with no WebMail from Internet' used. Attempt from
IP address 174.23.88.15.
 

If that's not an IP address that the boss uses, there's your culprit.

In a situation that demanded immediate action, we might temporarily forward all of that email to a new account. In that situation, any logins to the old account would be suspect.



Got something to add? Send me email.





(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Who's been reading my email?


1 comment



Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Anthony Lawrence







Tue Jul 2 16:32:50 2013: 12203   DaveGillam

gravatar


Another potential option--after changing passwords--would be to create a web link coded to that recipient's address, then add a filtering policy to append all email going to that person with an href to that coded file. Most contemporary mail clients will hit the URL in the href when previewing the email, effectively recording the client's IP in the web log. Since the web file is coded to the monitored recipient's address, a simple grep of the web log for that code will return all the IPs that have accessed the monitored inbox.



------------------------
Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





We are stuck with technology when what we really want is just stuff that works. (Douglas Adams)

I always knew that one day Smalltalk would replace Java. I just didn't know it would be called Ruby. (Kent Beck)












This post tagged: