James G. Sack (jim) wrote:
Ralph Shumaker wrote:
Some time ago, I picked up a command line formula to listen for arp
sniffers. I just modified the formula because I am getting traffic when
I think there should be none.
Here's the formula and results:
# tcpdump -l -n | head -100 | awk '{ print $3 $4 $5 }' | sort | uniq -c
| sort -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
1 24.64.110.160.17850>68.183.me.me.1027:
1 24.64.110.160.17850>68.183.me.me.1028:
1 24.64.110.160.17850>68.183.me.me.cap:
1 24.64.132.160.24834>68.183.me.me.1027:
1 24.64.132.160.24834>68.183.me.me.1028:
1 24.64.132.160.24834>68.183.me.me.cap:
1 64.73.32.134.ntp>68.183.me.me.ntp:
1 66.51.205.100.domain>68.183.me.me.34899:
1 66.51.205.100.domain>68.183.me.me.42504:
1 66.51.205.100.domain>68.183.me.me.42864:
1 66.51.205.100.domain>68.183.me.me.56411:
1 66.51.206.100.domain>68.183.me.me.35097:
1 68.183.me.me.34899>66.51.205.100.domain:
1 68.183.me.me.35097>66.51.206.100.domain:
1 68.183.me.me.42504>66.51.205.100.domain:
1 68.183.me.me.42864>66.51.205.100.domain:
1 68.183.me.me.49685>66.51.205.100.domain:
1 68.183.me.me.56411>66.51.205.100.domain:
1 68.183.me.me.ntp>64.73.32.134.ntp:
2 68.183.171.148.panasas>68.183.me.me.microsoft-ds:
2 68.183.me.me>68.183.171.148:
2 68.183.me.me.ntp>69.36.240.252.ntp:
2 69.36.240.252.ntp>68.183.me.me.ntp:
3 64.233.187.136.http>68.183.me.me.37573:
3 68.183.me.me>24.64.110.160:
3 68.183.me.me>24.64.132.160:
4 68.183.me.me.37573>64.233.187.136.http:
15 66.163.181.169.mmcc>68.183.me.me.59671:
15 66.163.181.170.mmcc>68.183.me.me.34149:
15 68.183.me.me.34149>66.163.181.170.mmcc:
15 68.183.me.me.59671>66.163.181.169.mmcc:
101 packets captured
101 packets received by filter
0 packets dropped by kernel
I'm not concerned about the ntp stuff. But what's all the other stuff?
(Especially, why is there a "68.183.me.me.microsoft-ds"?)
I'm going to repeat the process, but for 1000 lines.
The ports 1027, 1028 and 1026(=cap) as well as 445(-microsoft-ds) all
seem to me to be traffic that _should be_ filtered out by the packet
filtering firewall in your DSL modem. I think it's all MS oriented, and
I would say it's a defect that your modem does not allow you to drop
those incoming packets. Maybe there's some other place deep in the admin
interface to keep those from coming through?
I don't know about that. I still cannot access it since disabling those
services. I don't know why, unless those were services being supplied
by the DSL modem to *my* computer. Got any ideas how to get back in?
Is this where I should call dslextreme?
Here's some other things you may find interesting:
dig -x 24.64.110.160
(etc for other IPs)
Interesting. So dig gives you info about an IP.
or you could leave off the -n, perhaps on "playback" via -r -- see below
tcpdump -nw tcpdump.save -c 10000
tcpdump -nr tcpdump.save | awk '{ print $3 $4 $5 }' | sort | uniq -c
I'm going to play with that. I think I will drop the "-c 10000" and
just run "tcpdump -nw tcpdumped" when I walk away from the computer, and
just hit [Ctrl]+C upon returning.
I like the idea of dumping to file with "-n" and playing back without
it. That way, name lookups won't occur during the dump recording, only
during playback.
The rationale for saving stuff is that if curious you can go back and
look at the same data again (for, say whether you replied, or for
timestamps or protocol).
Especially useful for playing back with different filters to see
different things. I was already doing that but using grep for
reviewing. I like your idea. I'm going to play around with that.
The saved (binary) data from '-w file' is read back with '-r file'.
tcpdump -nr tcpdump.save | less
I'm curious to peek at the binary. May not mean much to me, but still
curious.
or, if you like wireshark, possibly better is
wireshark -nr tcpdump.save
No manual entry for wireshark
Hmmm
http://en.wikipedia.org/wiki/Image:Wireshark_screenshot.png
Oh, now *that* looks kewl! It's like my tcpdump formula, but in
progress of accumulation.
But you used it as a command line. Is that preferable?
Oh, this is interesting (I wonder if it's actually down or has something
to do with the services that were disabled in my DSL modem which locked
me out of it since I haven't even tried yum since then):
(Creating this prompt on Sat Aug 16 at 10:33:24.)
# yum info wireshark
Loading "fastestmirror" plugin
Loading mirror speeds from cached hostfile
* updates: mirror.stanford.edu
Could not retrieve mirrorlist
http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=i386
error was
[Errno 14] HTTP Error 503: Service Temporarily Unavailable
Error: Cannot find a valid baseurl for repo: fedora
(Creating this prompt on Sat Aug 16 at 10:35:05.)
# yum update
Loading "fastestmirror" plugin
Loading mirror speeds from cached hostfile
Could not retrieve mirrorlist
http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f8&arch=i386
error was
[Errno 14] HTTP Error 503: Service Temporarily Unavailable
removing mirrorlist with no valid mirrors:
//var/cache/yum/updates/mirrorlist.txt
Error: Cannot find a valid baseurl for repo: updates
(Creating this prompt on Sat Aug 16 at 10:36:30.)
#
There's not much you can (easily/safely/reasonably) do about unsolicited
probes -- those _are_ (typically) the bad guys. Seeing the stats and
sources is mildly interesting.
OK, if I understand correctly, there's no harm in letting my computer
respond to port probes as long as I have no vulnerable services running?
Would there be any harm in having my computer drop all port probes
except for services I want running (like ntp)? Would that even do any
good, as in less visible being less vulnerable (like camouflage, like a
white moth on white tree bark)? If scans of a certain port, say 1026,
on sequential IP addresses is done to merely identify IP addresses that
answer back, wouldn't it be better to *not* answer back? Is that what
iptables is? (man iptables Description doesn't answer this for me, tho,
it probably would if I understood it better).
Or should I set up a secure honey pot for them to waste their time on?
Maybe make it look like a juicy whendoze machine that only answers back
something akin to "error reading drive C:". :))
Sometimes it's interesting to look at arp queries to get a feel for what
is going on in your ISP segment -- Hmmm, I guess(?) this is interesting
with cable, but not (or shouldn't be) with DSL. Perhaps someone more
knowledgeable will correct me. For someone just tuning in, Ralph's DSL
modem is doing packet filtering, but (I believe) running in bridging
mode (giving him a public IP) so arp (if any) should be visible to his host.
I believe that is correct.
And regarding arp queries on my DSL, this formula:
# tcpdump -l -n | head -100 | awk '{ print $NF }' | sort | uniq -c | sort -n
always gave me only two lines (adding up to 100): my own IP
(68.183.me.me) and the 68.183.me.1 equivalent. So, yeah, pretty
uninteresting.
If you play much with tcpdump, the filters start becoming pretty
interesting. The syntax is a bit(!) fussy, but one can at least find and
save some favorite recipes. There are examples in the man page and the
keyword list
tcpdump examples
is a pretty good search query.
These filters:
host 68.183.me.me
or
! host 68.183.me.me
and perhaps
src host 68.183.me.me
might be useful.
Thanks for the tip.
--
I don't see any use in spelling a word right, and never did. I mean I
don't see any use in having a uniform and arbitrary way of spelling
words. We might as well make all our clothes alike and cook all dishes
alike.
--Mark Twain
--
KPLUG-List@kernel-panic.org
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
