May 2007 Archives

Anton Chuvakin

AddThis Social Bookmark Button

Following the new tradition of posting a security tip of the week (mentioned here, here ; SANS jumped in as well), I decided to follow along. One of the bloggers called it “pay it forward” to the community.

So, Anton Security Tip of the Day #10: Email Tracking Through Logs

Email tracking - oh, need I say more? :-) A nightmare for privacy fans - an “evil” weapon of lawyers and HR. Email tracking raises concerns that vary from a severe inability to do it all the way to having too much ability to do it. In this tip, we will focus on the following scenario: your boss says she just sent you an email; you never received it. What’s the story?

First we need to search our Sendmail server logs (this is that case where searching logs is appropriate) for the email address of the sender (unfortunately, we rarely can search the logs of the remote mail server which sent - or didn’t send! - the message in question). One thing to note before we start searching is to limit the time frame to the one close to the reported problem (let’s say to the same day).

So, we search for messages containing from=boss@examples.com (since we want the sender address) at January 11 (if you just search for boss@examples.com, the volume of unrelated results will be much higher) and find something like this:

Jan 11 11:45:49 ns1 sendmail[28022]: j0BGjkc28022: from=boss@example.com, size=376597, class=0, nrcpts=1, msgid=Pine.LNX.4.61.0501111145450.17081@boss.example.com, proto=SMTP, daemon=MTA, relay=esafe1.example.com[10.211.15.69] (may be forged)

Is this our message (we are not quite sure since we don’t see a recipient)? Why isn’t it here?! What do we do next? Well, this is where things get a little ugly (for those unfamiliar with Sendmail logs).

Next, we need to search the logs for this “mysterious” string “j0BGjkc28022” from the previous log record and find this:

Jan 11 11:46:00 ns1 sendmail[28025]: j0BGjkc28022: to=employee@example.com, delay=00:00:14, xdelay=00:00:11, mailer=local, pri=405901, dsn=2.0.0, stat=Sent

So, it looks like our mailserver have indeed sent the message, but what happened to it afterwards? Where did it go next? Given that “employee” has a mail account on the example.com system, most likely the message went into his mail spool (something like /var/spool/mail folder)

Next? If the employee uses local shell access to a mail server and Pine or other similar mail client to read mail (really unlikely, but possible - mostly at University systems), we need to see whether it exists in user’s local mail folders, such his /home/username/Mail folder or something similar.

But what if the employee uses POP3 or IMAP to read mail? In this case, we have more logs to go through … However, most POP3 server logs will not help us determine the fate of a specific message, but just to confirm that the user checked and/or downloaded mail. We will leave POP3 log fun for the next tip…

So, in today’s basic tip we covered one simple scenario of email tracking through logs.

Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Security Tips of the Day.

Brian K. Jones

AddThis Social Bookmark Button

I work in academia. I’m a sysadmin. However, I took a rather non-traditional route to sysadmin-hood. The very brief version of the story goes like this:

I started as a lowly database reporting geek. I found that I liked databases, and the database guys took me under their wing and made a DBA out of me. Then I went to work for Sybase and became a full-blown data snob. However, on various client sites I found that the people I inevitably needed to interact with to get my work done were the sysadmins.

As time went on I gained their trust and they started giving me more privileges on the machines where the database servers were running. It was a great help, and I was able to spread my sysadmin wings in an environment quite close to what would be called “production”.

After about a year of Perl scripting on the database end and for the sysadmin tasks I needed to perform, I decided that what I really wanted to do was build out these huge end-to-end systems. I wanted to do everything. I wanted to much with network gear, environmental monitors, power distribution, UNIX, databases, LDAP, Apache, and whatever else I could get my hands on. My next job was for a consulting firm that put me through tons of systems training, and I was on my way.

When I wasn’t at work, I was reading books about Linux and UNIX (I think I read all of the ones available at that time, actually), pounding the Linux forums, and setting up services on Linux boxes I had set up at home. I could rattle off ipchains rulesets in my sleep, recite Apache rewrite rules verbatim, quote error strings and tell you what they meant and how long you had before your disk just completely failed. I could set up quad-boot machines, run Linux on old SPARCs, and I had already written code to handle most of the basic admin tasks, as well as some basic monitoring.

In short, I was determined. I had given up any notion of a life, hacked day and night, read Phrack, 2600, the llama book, bat book and more, grokked perl, php, sed, awk, tr, ed, vi, ksh and bash, and had gotten myself ready to sit for the SCSA, SCNA, CCNA, and CheckPoint certifications after working in IT, mostly in database administration and development, for about 3 years.

I still felt like a flaming idiot. Heck, there are plenty of occasions where I feel pretty dopy now! Luckily, my sponge-like brain has shown no signs of becoming saturated.

My main goals now boil down to doing my best to fight specialization. I don’t want to stop coding Python, or doing database development, or maintaining LDAP servers, or building beowulf clusters, or maintaining VMWare servers. Aside from these goals, I also try to share as much of the knowledge I have with others who might be where I was 10 years ago by putting it here, or on my blog, or on my Linux admin site, or other sites, or on IRC, or the forums, or in magazine articles, or in slide presentations for LUGs. Oh - I once put some of my knowledge in a book, too!

What I want to know now, though, is this: How did you get here? Did you major in CS and choose systems work? Did you do something non-technical and became your company’s all ’round IT guy? Did you fight your way out of the phone support farm? Let me know! Share your story!

Anton Chuvakin

AddThis Social Bookmark Button

Imagine you bought something.

  • You rely on it with your business, with your very livelihood. Sometimes even with your life.
  • There is no warranty whatsoever on what you bought.
  • And you don’t know what’s inside the box.
  • Also, you cannot look inside the box, in fact, it is illegal.
  • You might not have have heard about the seller before and you have no particular reason to trust him.

Are you totally and irreversibly mad? How can you do it?! If you are not mad, aren’t you criminally negligent? Or just very, very, very stupid.

However, we all are. We all bought software at least once in our lives …

This blurb is inspired by some discussions I had at CONFidence 2007 Conference (where I presented on “Log Forensics” in front of about 180 people). Another related fun thought I picked there is that the most scary cyber-criminal of the future is not a spammer, a scammer, a phisher or a pharmer, and not even a good ole “cracker” - it is an unethical software engineer, who changes the code slightly to introduce a weakness (or a full-blown backdoor or a logic bomb) and later uses or sells this knowledge. In light of the above characteristics of software purchases, think billions stolen in one shot, think ruined companies, think stock market manipulation, think direct physical damage (and, yes, real cyberterror), etc. We do live in interesting times …

Technorati tags: , , ,