Showing posts with label packet. Show all posts
Showing posts with label packet. Show all posts

Thursday, December 11, 2008

Unix And Linux Factoids - Your Time To Live Is Gonna Come

Hey there,

Today we're going to start a new random thread of posts dealing with common commands and how they work. The meat of today's post is near the end, as the explanation, when I get around to it, is fairly simple and easy to both convey and understand. The majority of this page will be an introduction to this series of posts, with some philosophy mixed in (which may upset certain people) and a brief discourse on knowledge (what it means to have it and why it's probably the worst measure of a person you could ever use).

Farther down this post, we'll take a look at a common command, named traceroute (generally on Linux and Unix) or tracert (On Windows; I have idea about Mac ;) that makes up part of any sysadmin's network troubleshooting arsenal (hint: do a find for "traceroute" in your browser if you want to skip the preceding discourse!). Of course, not everyone knows how this command works (and we're talking about the very basics). That's nothing to be ashamed of, of course. Everything you know now, you learned at some point in your life (unless you're of that rare breed that emerges from the birth canal engaging adults in stimulating discussion of the experience ;). Before you learned it, you didn't know it. It's hard to fault someone for not knowing something they don't know already, even if your predisposition is to think that they should. For instance, if you were to approach someone on the street to ask them what time it was and they replied to you in an obscure Greek dialect (actually, any Greek, for me would be... Everyone knows where that lame joke was going ;), you wouldn't consider yourself stupid for not understanding them. If you'd taken the time to learn how to speak Greek, studied it until you became fluent and still had no idea what they were saying to you, I guess the situation could be awkward. Kind of like this introduction :)

The point I'm trying to make in the downward-trajectory of this introduction to these new factoid (or bits-of-interest) posts is that one should never become too socially intimidated, or otherwise societally fettered, that they just stop learning for fear of someone else finding out they didn't already know something. There is an old saying (which I'll paraphrase) which is about as true as true gets: The most agile-minded, clever and knowledgeable of us are those who are not afraid to ask for clarification or explanation when they don't understand. Keep a dictionary on hand when you're reading a book. There's no shame in understanding what you're reading. Dictionary's exist for a reason ;)

In my personal and professional life, I do my best to avoid highly intelligent individuals with extremely low self-esteem, as their company never seems to foster any sort of learning, sharing or growing. Better, still, I should hang out with folks who (regardless of their level of intelligence) are curious, interested, interesting and non-judgemental. It's been my experience that if you stay away from the "better" class of people, your life will be much more rewarding and enjoyable. The one thing that you must remember about people who look down at you is that they're, generally, consumed with the fear that you'll find out how much they, themselves, don't know or understand. Living life with one's guard constantly up is to, essentially, ensure one's own death (mentally, physically, spiritually; take your pick or go for option 4).

I've often found the above-mentioned argument the most decisive in shutting down, and casting aside, negative influences in my life. It bears repeating because it's so obvious and impenetrable: No matter who you are, you didn't know anything until you learned it. Everything, from your native tongue (essential in ensuring your survival and, possibly even more importantly, being able to ask where the bathroom is ;) to the principles of quantum physics, are all perfect examples of something you once didn't know of or understand. Again; no shame in that. People get an education (in schools, at the library or on the streets - all the same) for a reason. Just because someone you know can quote William Shakespeare (and does so at any and every opportunity) does not mean that you're any less capable because you aren't totally familiar with his work (William's, that is). I could write a book about this, but it would probably become self-parodying at some point. Here's a quick, and abbreviated, list of a few other ways you can spot folks who will suck the life out of you, and how to avoid them. Better yet, if you're a glass-half-full type, attempt to start a dialogue with them regarding the issue at hand - some folks only "seem" to be self-important and megalomaniacal. If you can reason with someone, you may end up enjoying a friendship with them that might have otherwise been lost. It's important to remember that immediately dismissing people who irritate you is exactly what irritates you about them in the first place:

1. If someone claims to "only read the best books" or "only dine at the finest restaurants," or other such snobbery, be sure to ask them who supplies them with their opinions? Having only read, or experienced, the best and the finest, they can't have possibly ever exposed themselves to anything lesser and, therefore, can't possibly argue the merits of the finer things with an ounce of credulity ;)

2. If someone treats the foreign help as if they're idiots because they don't speak English (or whatever your native language may be), be sure to find out exactly how well they speak that foreign tongue. If they're fluent in it, they may just be cruel, since they could converse with "the help" in that foreign language and avoid all the insults. If they can't speak the foreign language, they have no basis upon which to judge the other person's worth. For instance, I've known many Spanish, Polish, Russian, Hungarian, etc, people who know how to speak quite a bit more English than I can speak (or even pronounce correctly) in their language. When you think about it that way, it makes it harder to justify the false belief that the person who doesn't speak your language is any less intelligent than you. If anything, when it comes down to multilingual capability and capacity for communication, they've got you beat hands down. I can't speak a lick of Polish, but I've met plenty of first generation American's who can understand most of what I say to them and are able to communicate their ideas to me reasonably well.

3. If you're ever put in a position where you're made the object of public humiliation because of your lack of knowledge or understanding in a certain area (and your response should be as commensurately rude as the insult, unless you prefer to let other people perceive for themselves what kind of impotent ass would lower himself to spotlight your weak points while, inadvertantly, exposing his own mediocrity), be sure to appear to be congenial. Laugh it off and make a hayseed remark (something stereotypical of the type of rube you're being portrayed as). Then be sure to follow up with an impossible question for them to answer (back, again, to the fact that none of knows what we haven't already learned). When they can't, politely explain (simultaneously allowing them the opportunity to save face and you to be the better person). If you can't think of anything to say that will stump them, take possession of something they hold dear (the more pretensious, the better) and hold it ransom until they apologize to you. This move can backfire on you, but it's great if you're stepping in for someone who's actually intimidated or beside themselves over the embarrassment. Then you can hold onto the item until they apologize to the person they've insulted. That move may, occassionally, get you a phone number at the very least ;)

Anway, Traceroute. Here's how it works. Very simply and, hopefully, easy to understand. Future posts will be composed of more than one factoid, since, as you'll see, they're not very substantial, insofar as page length is concerned.

Traceroute works buy sending a bundle of packets (I believe the norm is 3) from your source to your destination. So if you were to invoke:

host # traceroute www.google.com

traceroute would begin sending out those packets to trace a route (listing all the hops - usually routers or firewalls - that it encounters along the way) from your machine to whatever IP address www.google.com resolves to. The method it uses to track every step of the way is ingenious in that it's very basic (As a side note, some versions use UDP, some use TCP, and most use the ICMP protocol - we're assuming ICMP for our example, although it doesn't really matter, since this is just "theory" ;).

The trick to how it operates is very basic. It has to do with the TTL (Time To Live) setting in the packets themselves. What it does is send out the first batch with a TTL of 1. Since every router the packets pass through decrements the TTL by one, the first "shout out" is reduced to zero at the first hop, which generates an ICMP timeout-exceeded condition, the connection is terminated and that information is received. Now, we have the information we want about the first router on the our path to www.google.com.

Again, the beauty in the simplicity of the theory continues to pay off until the end. The next batch of packets gets sent out with a TTL of 2, which means it will pass the first router and get to the second router on the road to www.google.com before its TTL is decremented to 0 and it's returned. Information is gathered in this manner (Every successive bundle of ICMP packets having a TTL one greater than the previous) until the endpoint is reached. And, at that point, you have a nice listing of the router-path your network traffic follows (at least for now ;) to get from your machine to Google's machine.

As a side note, almost all implemenations of traceroute default to making 30 attempts before they give up entirely and leave you with an incomplete route. I, generally, will just control-c out of the operation if I see more than one line of asterisks (* * *) as these indicate a timeout before the next bundle of packets gets sent out. One, possibly two, lines of these might be acceptable if you are aware of network latency issues that may be affecting the time it takes for the packets to get back to you, but, in my experience, this behaviour will generally continue until you reach the 30th round and usually indicates that you've just passed through a router or firewall that drops these sorts of requests or hit a dead end (modern security precautions leave this as a mystery for you to ponder over). Also, to include some of the confusing output you may see from time to time, if a bundle of packets goes through a router that doesn't respond, it may take an alternate route, which will still draw you a map to your destination, just not necessarily the "intended" one (from that particular router or firewall's perspective). Since IP routing doesn't guarantee that your packets will take the same path every single time you send them from one host to another, the information may be somewhat misleading. For the most part, though, it's correct, as the basic routing tables on most major hubs don't change quite as often as the one in your company data center might.

Hopefully, that explanation was succint enough, while still being informative. Since I write 5000 words if you ask me how I'm doing, it's hard for me to realistically guage the end-user experience ;)

Best wishes, and to your continually increasing store of knowledge. If you think you can't learn something (anything) you're probably selling yourself short. Your brain will only atrophy if you refuse to use it. Conversely, if you keep at it and continue to put forth the effort, someday even your own country's fiscal policies will make perfect sense to you ;)

, Mike




Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

Saturday, April 19, 2008

Snooping Through Email On Solaris

Good morning/afternoon/evening,

For this Saturday's post, I thought I'd put together another bash script on Solaris Unix using snoop. The last time we did this it was to grab cleartext logins and passwords. This time, I thought we'd look at email. SMTP, port 25, in particular.

Snooping through someone's physical mail (delivered to their home) would be a federal offense, but (to my knowledge) if you're a Unix or Linux administrator and have to analyze network traffic and interrogate packets at your place of work, there's almost no way you can avoid getting into other people's business. Most company's have an HR policy that your email is considered private and gaining access to another user's email, without their consent, is blah, blah, blah leading up to, and including termination. Of course, five minutes after said employee leaves the company, you're probably going to be called upon to provide just that sort of access (or the information gained by that access) to the same department that demanded you never ever do that sort of thing in the first place.

That being said, I'm pretty sure the law at this point is that a company can do whatever it wants with any data you create or use on their systems. If they need to, or want to, they can look at the email you send out and receive and where you go on the web, etc. I'm not sure why corporate America insists on assuring the average employee that their company-owned data is "personal and confidential" when all that email and web traffic has to be scanned by 15 security appliances before it can be allowed to enter or leave the company network? You can't block access to a website (even to, say, everyone in the company) without having to examine where every employee is going when they surf the web, etc. It probably makes for some yawn-inspiring legal battles ;)

Anyway, for the sake of today's argument, you're the root user (or someone with sufficient privilege to run snoop on Solaris Unix) and you're inspecting network traffic on an interface on a machine for a semi-legitimate reason.

If you need to check mail traffic, the simplest thing to do is snoop on port 25. This is the SMTP port and is used for sending and receiving email (you can also look at the POP and IMAP ports, but we'll wrap that into the everything's-pretty-much-all-the-same-when-you-get-right-down-to-it closing). You can get a good deal of information just running a straight-up snoop, like so:

host # snoop -o output_file port 25 <--- This snoop will use the default network interface, only capture traffic on port 25 and write the output to a file called "output_file."

The only problem you have is that, although it's readily clear who sent mail to whom, you can't see "what" they wrote. That's the stuff you want to see if you're going to be intercepting that information in real-time.

Note: In order to see the full contents of a packet, you don't need to use the "-v" flag. In fact, I'd strongly discourage it, since it pumps out about 50+ lines of IP stack layer information that you don't need for each and every packet!

If you want to see the full contents of the packets in snoop, just use the "-x" option and pass it the argument of an offset. "-x" gives you the entire packet, in both HEX and ASCII formats. You don't really need the HEX, since most humans read ASCII encoded text (like this) a lot more easily ;) A quick way to dump the HEX portion of each packet is to set the offset to 54 (for TCP traffic) and 42 (for UDP traffic). So, if you wanted to grab each packet and look at the ASCII contents only, you would type:

host # snoop -x 54 -o output_file port 25 <--- We're assuming TCP for the email transmission, although we'd capture any UDP packets that went to that port, also.

If you're ever snooping a protocol that doesn't fit the standards, or you forget these, you can almost always get the exact same effect (for TCP, UDP and any other protocol) by piping your output_file to awk when you're ready to read it, and just printing out the last field of every record, like so:

host # snoop -o output_file port 25
host # snoop -i output_file 2>&1 | awk '{ print $NF }'


The script we wrote for today doesn't take any arguments (but you should modify the snoop line if you want to specify a NIC with the "-d" option) and can be run simply, like this:

host # ./snoopmail.sh

And you'll get somewhat-ugly, but ultimately satisfying, results like this (yet another reason to never send a password via email):

..............To
...some.poor.guy
@xyz12345.com..S
ubject
Update 4....Hi
again....How are
ya,....Your new
password is bU
ggl3s....Please
do not share thi
s information wi
th any one!....T
hanks,.....Secur
ity..


Enjoy your Saturday, everyone :) Best wishes,


Creative Commons License


This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

#!/bin/bash

#
# snoopmail.sh
#
# 2008 - Mike Golvach - eggi@comcast.net
#
# Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
#

if [ $# -ne 1 ]
then
echo "Usage: $0 SnoopOutputFile"
echo "Please capture packets with the suggested"
echo "settings: snoop -o output port 25"
exit 1
fi

snoop_file=$1

if [ ! -f $snoop_file ]
then
echo "Cannot find snoop output file $snoop_file. Exiting..."
exit 1
fi

snoop -i $snoop_file -x 54|sed -n '/DATA/,/QUIT/p'|grep -v SMTP|awk -F":" '{print $2}'|cut -c41- -


, Mike