TcpDump

Category:Sasecurity
back to http://scratchpad.wikia.com/wiki/Sasecurity
TableOfContents
should have been 'tcpdump'
> have you tried using
 
> tcpcump -i wlan0 tcp
 
> or
 
> tcpdump -i eth0 tcp
 
> on the node, to double check if the box is being flooded with traffic 
in some way?
 
Instead of leechtest, you can also try downloading, using a wireless 
client, one of the large MeshAP images from LW's site
http://www.mirror.ac.uk/mirror/live.locustworld.com/32mb-images/
They're large enough to give you speed indication.
>>Hi,
>>All we have a problem node, but not sure what happening. The node has 
2mb backhaul, runs fine most of the time.
This node has been great for over a year but of resent times it has 
become very slow. We have some repeater nodes running of this gateway node, 
which I can ssh in to from another GW, I can run speed tests via the slow 
node and get top speeds via the slow node. 
I can access the slow node's router at very fast speeds and ssh via 
remote gateway, but try to ssh to the slow node via its ethernet gateway 
feed and all comes to a stop.
The node is not loaded, I can see this from the router QOS graph etc, 
its something to do with the node. The temp is normal and volts, not sure 
what can be causing this.
Its 150ft up so we only want to go up once as its on a commercial 
site and we have to pay for site access, by the hour.
Could it be memory? 128 mb fitted. VIA-500 board, senao radio, Fans 
are plugged in.
---
Found out what is dragging the box down, we a user runs a VPN session 
(not to the box -outside vpn), it kills the mesh box, the qos on the router 
is doing its job but the mesh box seam to died under the a vpn connection, 
its fine with heavy web traffic VOIP and ftp, but VPN kills it! this is a 
pro node.
==============
=== sdfsdfsdf ===
ed about this, as Kenny knows. Although -I've- never 
gotten 
technical answers here (it's supposed to be quid pro quo Jon), I will 
say 
that your tcpdump is telling you this is SSH traffic, and so it's just 
your 
own. To exclude your own traffic, try:
tcpdump -qi {whatevertheinterfaceis} 'not port ssh'
Note that if you use -i any , captures will not be done in promiscuous 
mode, 
which means only traffic actually through the node will be reported. 
Use -q, 
to suppress that timestamp hash junk. The first thing to figure out is 
whether he's on wire or on radio for that node. 
Assuming that there is someone leeching, determining how he does it may 
take a 
detailed knowledge of NoCatSplash. However I suspect it's something 
simple, 
like maybe they hijacked the gateway or are simply bypassing the 
portal. 
Blocking the MAC won't work; MAC authentication is *no* security. 
Does the 
offending MAC belong to *anyone* in wiana? (spoofing) Certificates 
would be 
best.
Is directory indexing allowed on the node? IOW, if you remove the 
index.* 
file in a directory then surf there, will it list that directory's 
contents? 
It should give a "Directory Listing Denied", and if it doesn't, it's 
probably 
your problem; HUGE security hole. This is an option in the http 
server. I 
don't use LW, so don't know which server you're using, nor how to fix 
it.
Do you really have a second interface? If not, set it to ad-hoc and 
that will disappear. This looks like your ssh traffic though.. not p2p.
I don't see how someone can get on the network without a username, 
password, MAC authentication bypassing the captive portal. I've not 
personally used Meshtrak, but isn't it supposed to have many of the 
same features as LW Pro? If so, you should easily be able to determine 
who it is downloading p2p and shut that account down or change their 
method of access if it's been compromised.
One other suggestion: I would consider upgrading to Pro software for 
just the reason you are writing this message!
I had two access points on my network that were running OSS because 
they have only a couple of users and were fairly easy to watch after 
(and I like to experiment with OSS!). However, just last week I had two 
clients that had their M$ PC's hijacked by some mass-mailing email 
virus. Our mail server is actually located off the mesh, and it has 
Spam Assassin installed on it. Once our gateway IP was flagged as a 
spammer's IP, we were no longer able to send email out (on port 25) 
from our network (until we shut them down) since our own server was off 
the mesh! Fortunately I was able to track down the infected PC both 
times very easily because both were on MeshAP's running Pro software. 
Wiana flagged them as having several megs of traffic on port 25 and one 
guy sent 1,000,000 packets out on port 25 - which made him very easy to 
spot! Having this capability made me realize the importance of running 
Pro software on all of my nodes as this would have been very difficult 
to track down on OSS on a busy network and since then I've upgraded 
those two.
> Using Meshtrak (www.meshtrak.com) I was able to see that one person 
> not authorized on my wiana realm has downloaded a gigabit of stuff 
> which looks like p2p.
>
> I see on the wiana topographical map that I have an interface 
> 10.11.15.20. I commented on this earlier and have seen it for quite 
> some time. You all said this was due to the second interface being 
set 
> to infrastructure mode. However, after doing a tcpdump, it seems that 
> someone has exploited this interface. Here is some tcpdump output.
> 
----------------------------------------------------------------------- 
> ----------------------
> 21:52:32.200301 1.34.49.152.ssh > 10.11.15.20.2349: P 
49953:50129(176) 
> ack 48 win 9792 <nop,nop,timestamp 229946872 230252555> (DF) [tos 
> 0x10]
> 21:52:32.200311 1.34.49.152.ssh > 10.11.15.20.2349: P 
50129:50305(176) 
> ack 48 win 9792 <nop,nop,timestamp 229946873 230252556> (DF) [tos 
> 0x10]
> 21:52:32.200322 1.34.49.152.ssh > 10.11.15.20.2349: P 
50305:50481(176) 
> ack 48 win 9792 <nop,nop,timestamp 229946874 230252557> (DF) [tos 
> 0x10]
> 21:52:32.203115 1.34.49.152.ssh > 10.11.15.20.2349: P 
50481:51105(624) 
> ack 48 win 9792 <nop,nop,timestamp 229946875 230252557> (DF) [tos 
> 0x10]
> 21:52:32.204135 1.34.49.152.ssh > 10.11.15.20.2349: P 
51105:51297(192) 
> ack 48 win 9792 <nop,nop,timestamp 229946875 230252557> (DF) [tos 
> 0x10]
> 21:52:32.204852 1.34.49.152.ssh > 10.11.15.20.2349: P 
51297:51489(192) 
> ack 48 win 9792 <nop,nop,timestamp 229946875 230252557> (DF) [tos 
> 0x10]
> 21:52:32.205572 1.34.49.152.ssh > 10.11.15.20.2349: P 
51489:51681(192) 
> ack 48 win 9792 <nop,nop,timestamp 229946875 230252557> (DF) [tos 
> 0x10]
> 21:52:32.206287 1.34.49.152.ssh > 10.11.15.20.2349: P 
51681:51873(192) 
> ack 48 win 9792 <nop,nop,timestamp 229946875 230252557> (DF) [tos 
> 0x10]
> 21:52:32.207035 1.34.49.152.ssh > 10.11.15.20.2349: P 
51873:52065(192) 
> ack 48 win 9792 <nop,nop,timestamp 229946875 230252557> (DF) [tos 
> 0x10]
> 21:52:32.207763 1.34.49.152.ssh > 10.11.15.20.2349: P 
52065:52257(192) 
> ack 48 win 9792 <nop,nop,timestamp 229946875 230252557> (DF) [tos 
> 0x10]
> 21:52:32.208483 1.34.49.152.ssh > 10.11.15.20.2349: P 
52257:52449(192) 
> ack 48 win 9792 <nop,nop,timestamp 229946875 230252557> (DF) [tos 
> 0x10]
I dont know how they would be able to get through either. But I am 
getting logs from them on meshtrak and see their IP show up on wiana. 
Someone living near the node I see the traffic on had emailed me just 
prior to the "illegal" activity requesting an account. I hadn't heard 
back from them so I assume they got their internet. ;)
Right now I have just added an iptables rule to DENY their mac address. 
We'll see if this solves any problems.
I have determined the mac address but they dont have an account on 
wiana. This is what is confusing me.
Meshtrak is free right now, LW Pro costs money. That is my primary 
motivation for using it, and I'm the developer ;).
> Do you really have a second interface? If not, set it to ad-hoc and 
> that will disappear. This looks like your ssh traffic though.. not 
p2p.
>
> I don't see how someone can get on the network without a username, 
> password, MAC authentication bypassing the captive portal. I've not 
> personally used Meshtrak, but isn't it supposed to have many of the 
> same features as LW Pro? If so, you should easily be able to 
> determine who it is downloading p2p and shut that account down or 
> change their method of access if it's been compromised.
>
> One other suggestion: I would consider upgrading to Pro software for 
> just the reason you are writing this message!
>
> I had two access points on my network that were running OSS because 
> they have only a couple of users and were fairly easy to watch after 
> (and I like to experiment with OSS!). However, just last week I had 
> two clients that had their M$ PC's hijacked by some mass-mailing 
> email virus. Our mail server is actually located off the mesh, and 
it 
> has Spam Assassin installed on it. Once our gateway IP was flagged 
as 
> a spammer's IP, we were no longer able to send email out (on port 
> 25) from our network (until we shut them down) since our own server 
> was off the mesh! Fortunately I was able to track down the infected 
> PC both times very easily because both were on MeshAP's running Pro 
> software. Wiana flagged them as having several megs of traffic on 
> port 25 and one guy sent 1,000,000 packets out on port 25 - which 
> made him very easy to spot! Having this capability made me realize 
> the importance of running Pro software on all of my nodes as this 
> would have been very difficult to track down on OSS on a busy 
network 
> and since then I've upgraded those two.
>> Using Meshtrak (www.meshtrak.com) I was able to see that one person 
>> not authorized on my wiana realm has downloaded a gigabit of stuff 
>> which looks like p2p.
>>
>> I see on the wiana topographical map that I have an interface 
>> 10.11.15.20. I commented on this earlier and have seen it for quite 
>> some time. You all said this was due to the second interface being 
>> set to infrastructure mode. However, after doing a tcpdump, it 
seems 
>> that someone has exploited this interface. Here is some tcpdump 
output.
>> 
----------------------------------------------------------------------- 
>> ----------------------
>> 21:52:32.200301 1.34.49.152.ssh > 10.11.15.20.2349: P 
>> 49953:50129(176) ack 48 win 9792 <nop,nop,timestamp 229946872 
>> 230252555> (DF) [tos 0x10]
>> 21:52:32.200311 1.34.49.152.ssh > 10.11.15.20.2349: P 
>> 50129:50305(176) ack 48 win 9792 <nop,nop,timestamp 229946873 
>> 230252556> (DF) [tos 0x10]
>> 21:52:32.200322 1.34.49.152.ssh > 10.11.15.20.2349: P 
>> 50305:50481(176) ack 48 win 9792 <nop,nop,timestamp 229946874 
>> 230252557> (DF) [tos 0x10]
>> 21:52:32.203115 1.34.49.152.ssh > 10.11.15.20.2349: P 
>> 50481:51105(624) ack 48 win 9792 <nop,nop,timestamp 229946875 
>> 230252557> (DF) [tos 0x10]
>> 21:52:32.204135 1.34.49.152.ssh > 10.11.15.20.2349: P 
>> 51105:51297(192) ack 48 win 9792 <nop,nop,timestamp 229946875 
>> 230252557> (DF) [tos 0x10]
>> 21:52:32.204852 1.34.49.152.ssh > 10.11.15.20.2349: P 
>> 51297:51489(192) ack 48 win 9792 <nop,nop,timestamp 229946875 
>> 230252557> (DF) [tos 0x10]
>> 21:52:32.205572 1.34.49.152.ssh > 10.11.15.20.2349: P 
>> 51489:51681(192) ack 48 win 9792 <nop,nop,timestamp 229946875 
>> 230252557> (DF) [tos 0x10]
>> 21:52:32.206287 1.34.49.152.ssh > 10.11.15.20.2349: P 
>> 51681:51873(192) ack 48 win 9792 <nop,nop,timestamp 229946875 
>> 230252557> (DF) [tos 0x10]
>> 21:52:32.207035 1.34.49.152.ssh > 10.11.15.20.2349: P 
>> 51873:52065(192) ack 48 win 9792 <nop,nop,timestamp 229946875 
>> 230252557> (DF) [tos 0x10]
>> 21:52:32.207763 1.34.49.152.ssh > 10.11.15.20.2349: P 
>> 52065:52257(192) ack 48 win 9792 <nop,nop,timestamp 229946875 
>> 230252557> (DF) [tos 0x10]
>> 21:52:32.208483 1.34.49.152.ssh > 10.11.15.20.2349: P 
>> 52257:52449(192) ack 48 win 9792 <nop,nop,timestamp 229946875 
>> 230252557> (DF) [tos 0x10]
>>