comp.os.linux.networking

  • Thread starter Thread starter tiffini
  • Start date Start date
T

tiffini

Hi,

I have noticed some interesting traffic coming from one of my pc's and then to one of my pc's.
First a little background.
I have a befsr41 router with snmp :-) So I can log traffic going into my little network using wallwatcher and opmanager.

I have one XP machine I leave on a lot. I notice that it is sending UDP outbound from L-port 137 to R-port 137. Then in a relatively short amount of time I see an inbound request from a different IP to ports 1026 ,1027, and 1028 from a different IP that the 137 was sent from.
I have norton's running, and ad aware and spybot don't show anything.

The addresses seem to come from anywhere China, hong kong, even the US and Canada.


Any Ideas of what this is?







Log Snips:
-------------

alert_audit435.txt:20:54:06:542 ALERTAUDIT: Update: from Clear to Clear at Tue Dec 26 20:54:06 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @out UDP from 10.100.1.7:137 to 221.6.163.50:137
alert_audit435.txt- alert_audit435.txt-20:54:45:033 ALERTAUDIT: System Clear: Tue Dec 26 20:54:44 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @in UDP from 202.97.238.132:32957 to WANIP:1026
alert_audit435.txt- alert_audit435.txt-20:55:43:724 ALERTAUDIT: Update: from Clear to Clear at Tue Dec 26 20:55:43 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @in UDP from 24.64.159.205:19437 to WANIP:1027
alert_audit435.txt- alert_audit435.txt-20:55:43:836 ALERTAUDIT: System Clear: Tue Dec 26 20:55:43 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @in UDP from 24.64.159.205:19437 to WANIP:1028
alert_audit435.txt-
Log Snips:
-------------


alert_audit435.txt:22:01:00:913 ALERTAUDIT: System Clear: Tue Dec 26 22:01:00 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @out UDP from 10.100.1.7:137 to 24.64.19.74:137
alert_audit435.txt- alert_audit435.txt-22:01:42:516 ALERTAUDIT: Update: from Clear to Clear at Tue Dec 26 22:01:42 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @in UDP from 24.191.3.147:25931 to WANIP:1026
alert_audit435.txt- alert_audit435.txt-22:02:43:193 ALERTAUDIT: System Clear: Tue Dec 26 22:02:42 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @in UDP from 24.64.255.139:16957 to WANIP:1027
alert_audit435.txt- alert_audit435.txt-22:02:43:213 ALERTAUDIT: Update: from Clear to Clear at Tue Dec 26 22:02:43 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @in UDP from 24.64.255.139:16957 to WANIP:1028
alert_audit435.txt-
Log Snips:
-------------

alert_audit436.txt:22:36:32:840 ALERTAUDIT: Update: from Clear to Clear at Tue Dec 26 22:36:32 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @out UDP from 10.100.1.7:137 to 204.16.209.30:137
alert_audit436.txt- alert_audit436.txt-22:38:33:569 ALERTAUDIT: Update: from Clear to Clear at Tue Dec 26 22:38:33 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @in UDP from 24.64.252.244:10501 to WANIP:1026
alert_audit436.txt- alert_audit436.txt-22:38:33:686 ALERTAUDIT: System Clear: Tue Dec 26 22:38:33 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @in UDP from 24.64.252.244:10501 to WANIP:1027
alert_audit436.txt- alert_audit436.txt-22:38:33:694 ALERTAUDIT: Update: from Clear to Clear at Tue Dec 26 22:38:33 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @in UDP from 24.64.252.244:10501 to WANIP:1027
alert_audit436.txt- alert_audit436.txt-22:38:33:697 ALERTAUDIT: System Clear: Tue Dec 26 22:38:33 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @in UDP from 24.64.252.244:10501 to WANIP:1028
alert_audit436.txt-


Log Snips:
-------------

alert_audit436.txt:22:45:48:878 ALERTAUDIT: Update: from Clear to Clear at Tue Dec 26 22:45:48 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @out UDP from 10.100.1.7:137 to 24.64.5.208:137
alert_audit436.txt- alert_audit436.txt-22:51:51:654 ALERTAUDIT: System Clear: Tue Dec 26 22:51:51 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @in UDP from 204.16.208.76:37844 to WANIP:1026
alert_audit436.txt- alert_audit436.txt-22:51:51:661 ALERTAUDIT: Update: from Clear to Clear at Tue Dec 26 22:51:51 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @in UDP from 204.16.208.76:37844 to WANIP:1026
alert_audit436.txt- alert_audit436.txt-22:51:51:769 ALERTAUDIT: System Clear: Tue Dec 26 22:51:51 CST 2006. Alert: 10.100.1.1_TrapsFromRouter_trap : Traffic .1.3.6.1.4.1.3955.1.1.0: @in UDP from 204.16.208.76:37844 to WANIP:1027
alert_audit436.txt-
 
tiffini said:
Hi,

I have noticed some interesting traffic coming from one of my pc's and
then to one of my pc's.
First a little background.
I have a befsr41 router with snmp :-) So I can log traffic going into
my little network using wallwatcher and opmanager.

I have one XP machine I leave on a lot. I notice that it is sending UDP
outbound from L-port 137 to R-port 137. Then in a relatively short
amount of time I see an inbound request from a different IP to ports
1026 ,1027, and 1028 from a different IP that the 137 was sent from. I
have norton's running, and ad aware and spybot don't show anything.
The addresses seem to come from anywhere China, hong kong, even the US
and Canada.


Any Ideas of what this is?
Click to expand...

That machine should not be sending any outbound on 137, unless it's to
another Windows machine on the LAN.

If outbound on 137 is being sent to a WAN/IP from behind the router,
then you might have some trouble.

http://www.linklogger.com/UDP137.htm

You can use the tools in the link like Process Explorer and Active Ports
and look for yourself. PE can look inside a running process and show you
all the processes that are being hosted by the process, such as
malware being hosted by a legit process.


Long
http://www.windowsecurity.com/artic...d_Rootkit_Tools_in_a_Windows_Environment.html

Short
http://tinyurl.com/klw1


You should keep in mind that if the machine has been compromised can you
trust the machine after that.

http://www.microsoft.com/technet/community/columns/secmgmt/sm0504.mspx
 
This sounds similar to a "NetBios Echo", which you can prevent by
turning off "OK to use NetBIOS 137" on WallWatcher's LOGGING menu.

If you do that and the problem goes away, it probably was an Echo: if
that option's ON, then when WW does an rDNS lookup (convert URL to IP)
and your ISP's Nameserver can't resolve the IP, Windows automatically
send the request again, but this time, it sends it to the IP address
itself, asking for identification. It rarely gets a reply, but may
need a minute or so to time-out the request. More importantly, your
address has been sent to the remote IP, and if happens to be a hacker,
he now has confirmation of a valid address (yours). Since you're
behind two firewalls (the router's and your software firewall), your
computer's almost certainly safely protected, but it would be better to
not have your network sending out that information in the first place.

WallWatcher isn't sending your address to those remote sites, it's only
asking Windows to find the URL of an IP. However, there are two ways
to do that, and the NetBios (port 137) approach can result in
contacting the remote site. The other, more modern approach, makes the
request only through port 53, and those do not go to unknown remote
sites. That method is used when the "NetBIOS 137" option's turned off:
WW asks Windows to do the lookup, but in a way that won't use NetBIOS.
The advantages of the non-NetBIOS method are 1) it's more secure, and
2) it's generally faster when there's no answer. The drawback is that
the NetBIOS approach has a greater chance of finding the URL.

The original NetBIOS Echo situation usually received probes on port
137, rather than on 1026 or 1027. Either the hackers have gotten more
subtle or these 1026/1027 Inbounds are coincidental to the port 137
Outbounds. Personally, I'm not a great believer in that kind of
coincidence.

If you try turning that option off, please post your results here.
Thanks.

Dan Tseng (WallWatcher author)
 
From: "Dan Tseng" <[email protected]>

| This sounds similar to a "NetBios Echo", which you can prevent by
| turning off "OK to use NetBIOS 137" on WallWatcher's LOGGING menu.
|
| If you do that and the problem goes away, it probably was an Echo: if
| that option's ON, then when WW does an rDNS lookup (convert URL to IP)
| and your ISP's Nameserver can't resolve the IP, Windows automatically
| send the request again, but this time, it sends it to the IP address
| itself, asking for identification. It rarely gets a reply, but may
| need a minute or so to time-out the request. More importantly, your
| address has been sent to the remote IP, and if happens to be a hacker,
| he now has confirmation of a valid address (yours). Since you're
| behind two firewalls (the router's and your software firewall), your
| computer's almost certainly safely protected, but it would be better to
| not have your network sending out that information in the first place.
|
| WallWatcher isn't sending your address to those remote sites, it's only
| asking Windows to find the URL of an IP. However, there are two ways
| to do that, and the NetBios (port 137) approach can result in
| contacting the remote site. The other, more modern approach, makes the
| request only through port 53, and those do not go to unknown remote
| sites. That method is used when the "NetBIOS 137" option's turned off:
| WW asks Windows to do the lookup, but in a way that won't use NetBIOS.
| The advantages of the non-NetBIOS method are 1) it's more secure, and
| 2) it's generally faster when there's no answer. The drawback is that
| the NetBIOS approach has a greater chance of finding the URL.
|
| The original NetBIOS Echo situation usually received probes on port
| 137, rather than on 1026 or 1027. Either the hackers have gotten more
| subtle or these 1026/1027 Inbounds are coincidental to the port 137
| Outbounds. Personally, I'm not a great believer in that kind of
| coincidence.
|
| If you try turning that option off, please post your results here.
| Thanks.
|
| Dan Tseng (WallWatcher author)

Dan:

It is a pleasure to see you posting. I haven't communicated with you in quite a while.

All the best to you in the upcoming year.

{ A long time and proud user of WallWatcher in conjunction with a Linksys BEFSR81. }
 
Back
Top