-
February 17th, 2003, 12:00 PM
#1
Junior Member
whats going on here?
1,[05/Dec/2002 07:08:04] Rule 'Packet to unopened port received': Blocked: In UDP, 10.251.111.42:4682->localhost:27015, Owner: no owner
1,[05/Dec/2002 07:08:04] Rule 'Packet to unopened port received': Blocked: In UDP, 10.251.111.42:4682->localhost:27016, Owner: no owner
1,[05/Dec/2002 07:08:04] Rule 'Packet to unopened port received': Blocked: In UDP, 10.251.111.42:4682->localhost:27017, Owner: no owner
1,[05/Dec/2002 07:08:04] Rule 'Packet to unopened port received': Blocked: In UDP, 10.251.111.42:4682->localhost:27018, Owner: no owner
1,[05/Dec/2002 07:08:04] Rule 'Packet to unopened port received': Blocked: In UDP, 10.251.111.42:4682->localhost:27019, Owner: no owner
1,[05/Dec/2002 07:08:04] Rule 'Packet to unopened port received': Blocked: In UDP, 10.251.111.42:4682->localhost:27020, Owner: no owner
1,[05/Dec/2002 07:08:04] Rule 'Packet to unopened port received': Blocked: In UDP, 10.251.111.42:4682->localhost:27021, Owner: no owner
1,[05/Dec/2002 07:08:04] Rule 'Packet to unopened port received': Blocked: In UDP, 10.251.111.42:4682->localhost:27022, Owner: no owner
1,[05/Dec/2002 07:08:04] Rule 'Packet to unopened port received': Blocked: In UDP, 10.251.111.42:4682->localhost:27023, Owner: no owner
1,[05/Dec/2002 07:08:04] Rule 'Packet to unopened port received': Blocked: In UDP, 10.251.111.42:4682->localhost:27024, Owner: no owner
1,[08/Dec/2002 16:44:25] Rule 'TCP ack packet attack': Blocked: In TCP, 10.251.111.42:139->localhost:1520, Owner: no owner
1,[08/Dec/2002 16:44:27] Rule 'TCP ack packet attack': Blocked: In TCP, 10.251.111.42:139->localhost:1520, Owner: no owner
1,[08/Dec/2002 16:44:29] Rule 'TCP ack packet attack': Blocked: In TCP, 10.251.111.42:139->localhost:1524, Owner: no owner
1,[08/Dec/2002 16:44:32] Rule 'TCP ack packet attack': Blocked: In TCP, 10.251.111.42:139->localhost:1524, Owner: no owner
1,[08/Dec/2002 16:44:33] Rule 'TCP ack packet attack': Blocked: In TCP, 10.251.111.42:139->localhost:1520, Owner: no owner
1,[08/Dec/2002 16:44:38] Rule 'TCP ack packet attack': Blocked: In TCP, 10.251.111.42:139->localhost:1524, Owner: no owner
1,[08/Dec/2002 16:44:25] Rule 'TCP ack packet attack': Blocked: In TCP, 10.251.111.42:139->localhost:1520, Owner: no owner
1,[08/Dec/2002 16:44:27] Rule 'TCP ack packet attack': Blocked: In TCP, 10.251.111.42:139->localhost:1520, Owner: no owner
1,[08/Dec/2002 16:44:29] Rule 'TCP ack packet attack': Blocked: In TCP, 10.251.111.42:139->localhost:1524, Owner: no owner
1,[08/Dec/2002 16:44:32] Rule 'TCP ack packet attack': Blocked: In TCP, 10.251.111.42:139->localhost:1524, Owner: no owner
just a "little" snip from firewall logs. whats going on?
this has been going on from late november. sender uses ports 139, 1035-1038, 1781-1785, 3773-3776, 4678 and 4682. might have missed other ports, but logs are _big_.
since net access goes through lan and nat, i understand that part of the snip could be just normal traffic. however, 10.251.111.42 is sending much more packets to my "comp farm" than any else. maybe in 1000x more than others total.
so, should i pick up a baseball bat or just sit tight?
-
February 17th, 2003, 02:13 PM
#2
Junior Member
Do you have a packet capture of this traffic you could post?
It's hard to tell what's going on based on your logs, however it's not a scan from the internet since the source IP is a reserved one. Which leaves your internal network So do any computers on your network use IPs in the 10.x.x.x range?.
Ferengi Rules of Acquisition:
Rule 59 Free advice is seldom cheap.
-
February 17th, 2003, 02:24 PM
#3
Junior Member
no packet capture yet. give me a link to good prog and it will appear soon.
net conn is shared 1mbps/1mbps dsl which uses 10.251.111.xxx range. my personal network uses 192.168.0.xxx range via proxy.
-
February 17th, 2003, 02:37 PM
#4
Two things do stand out about this log:
1. The 10.x.x.x subnet is a private subnet and therefore should not be routable across the public domain. It will be forwarded to it's destination because the routers do not look at the source address in their determination of what to do with the packet. OTOH, when a machine tries to reply the first router _should_ drop the packet as being non-routable. I see similar all the time at my border router and have had no joy trying to find out what it is. I have got as far as determining that the MAC address belongs to a Cisco router but the packet traffic itself is not something that a cisco would normally be sending out - (at least I don't think it should).
2. The very first destination port is 27015. That port is most commonly associated with Counterstrike or other Half-Life online games. Those games generally connect from 27105 up about another 10 ports and usually begin their connection attempt using UDP. Therefore, looking at the packets and their sequence in the first half the suystem is looking for a Half-Life type server. I believe the second half is looking for an ssh connection.
EDIT:
OK I see you posted....<s> If you are on the same subnet as this machine then it is local.... sorry for being obvious.... but it will therefore route within the network and the source is therefore seeing replies. It might just be a local kid trying to find Counterstrike/Half-Life servers on the LAN or more likely he has his own LAN game set up and it is "leaking" out onto the rest of the LAN.
/EDIT
Don\'t SYN us.... We\'ll SYN you.....
\"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides
-
February 17th, 2003, 05:20 PM
#5
Junior Member
A good analysis TS
The 10.x.x.x subnet is a private subnet and therefore should not be routable across the public domain. It will be forwarded to it's destination because the routers do not look at the source address in their determination of what to do with the packet.
True, which is the reason it can't be a "internet" scan since no replies from the target will get back to the sender (If they even reach the target in the first place).
. I have got as far as determining that the MAC address belongs to a Cisco router but the packet traffic itself is not something that a cisco would normally be sending out - (at least I don't think it should).
The MAC address will always be the next upstream network device. So all the packets coming in from that interface should have the same source MAC address. Have you ever looked at the TTLs of those packets? I would be interested in any other facts you have about them
Anyway,I agree with you that because of the sequential sequence of the dest. port numbers , it's a server of some type looking for an open port. But I always like to look at a packet capture just to make sure.
Andersen Windump is a good free "packet capture" program. A
Google search will lead you to where you can download the program.
Ferengi Rules of Acquisition:
Rule 59 Free advice is seldom cheap.
-
February 17th, 2003, 06:00 PM
#6
Originally posted here by obake_hakkaa
A good analysis TS
Thanks
True, which is the reason it can't be a "internet" scan since no replies from the target will get back to the sender (If they even reach the target in the first place).
I disagree. Under certain circumstances an attacker could have got a sniffer that ftp's logs out of the network onto the public network. Knowing the internal IP of that machine would allow the attacker to test ACL's on routers and firewalls without getting a direct reply.... He just sits back and waits for the logs to be sent to him.
The MAC address will always be the next upstream network device.
That's why i love this place..... I have never been aware of that.... In all my digging and reading it either never came up or the significance never reached into the depths of my brain..... Thank you.....
Have you ever looked at the TTLs of those packets? I would be interested in any other facts you have about them
I have..... there is nothing outstanding about them, the sources appear to vary if the TTL's are not crafted.... I don't worry because I'm not using the 10.x.x.x private subnet inside...<S>
Anyway,I agree with you that because of the sequential sequence of the dest. port numbers
That series is typical of Half-Life/Counterstrike..... I play rather more Counterstrike than I should probably admit to....<s>
Don\'t SYN us.... We\'ll SYN you.....
\"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides
-
February 17th, 2003, 09:43 PM
#7
Junior Member
Frame 1971 (243 bytes on wire, 243 bytes captured)
Arrival Time: Jan 17, 2003 22:16:58.503295000
Time delta from previous packet: 0.006787000 seconds
Time relative to first packet: 116.427336000 seconds
Frame Number: 1971
Packet Length: 243 bytes
Capture Length: 243 bytes
Ethernet II, Src: 00:e0:7d:b1:92:d2, Dst: ff:ff:ff:ff:ff:ff
Destination: ff:ff:ff:ff:ff:ff (Broadcast)
Source: 00:e0:7d:b1:92:d2 (Netronix_b1:92:d2)
Type: IP (0x0800)
Internet Protocol, Src Addr: 10.251.111.42 (10.251.111.42), Dst Addr: 10.251.111.255 (10.251.111.255)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 229
Identification: 0x1265
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (0x11)
Header checksum: 0x3284 (correct)
Source: 10.251.111.42 (10.251.111.42)
Destination: 10.251.111.255 (10.251.111.255)
User Datagram Protocol, Src Port: 138 (138), Dst Port: 138 (138)
Source port: 138 (138)
Destination port: 138 (138)
Length: 209
Checksum: 0x619b (correct)
NetBIOS Datagram Service
Message Type: Direct_group datagram (17)
More fragments follow: No
This is first fragment: Yes
Node Type: B node (0)
Datagram ID: 0x8176
Source IP: 10.251.111.42 (10.251.111.42)
Source Port: 138
Datagram length: 187 bytes
Packet offset: 0 bytes
Source name: SCARY<20> (Server service)
Destination name: WORKGROUP<1d> (Local Master Browser)
SMB (Server Message Block Protocol)
SMB Header
Server Component: SMB
SMB Command: Transaction (0x25)
Error Class: Success (0x00)
Reserved: 00
Error Code: No Error
Flags: 0x00
0... .... = Request/Response: Message is a request to the server
.0.. .... = Notify: Notify client only on open
..0. .... = Oplocks: OpLock not requested/granted
...0 .... = Canonicalized Pathnames: Pathnames are not canonicalized
.... 0... = Case Sensitivity: Path names are case sensitive
.... ..0. = Receive Buffer Posted: Receive buffer has not been posted
.... ...0 = Lock and Read: Lock&Read, Write&Unlock are not supported
Flags2: 0x0000
0... .... .... .... = Unicode Strings: Strings are ASCII
.0.. .... .... .... = Error Code Type: Error codes are DOS error codes
..0. .... .... .... = Execute-only Reads: Don't permit reads if execute-only
...0 .... .... .... = Dfs: Don't resolve pathnames with Dfs
.... 0... .... .... = Extended Security Negotiation: Extended security negotiation is not supported
.... .... .0.. .... = Long Names Used: Path names in request are not long file names
.... .... .... .0.. = Security Signatures: Security signatures are not supported
.... .... .... ..0. = Extended Attributes: Extended attributes are not supported
.... .... .... ...0 = Long Names Allowed: Long file names are not allowed in the response
Reserved: 000000000000000000000000
Tree ID: 0
Process ID: 0
User ID: 0
Multiplex ID: 0
Transaction Request (0x25)
Word Count (WCT): 17
Total Parameter Count: 0
Total Data Count: 33
Max Parameter Count: 0
Max Data Count: 0
Max Setup Count: 0
Reserved: 00
Flags: 0x0000
.... .... .... ..0. = One Way Transaction: Two way transaction
.... .... .... ...0 = Disconnect TID: Do NOT disconnect TID
Timeout: 1 second
Reserved: 0000
Parameter Count: 0
Parameter Offset: 0
Data Count: 33
Data Offset: 86
Setup Count: 3
Reserved: 00
Byte Count (BCC): 50
Transaction Name: \MAILSLOT\BROWSE
SMB MailSlot Protocol
Opcode: Write Mail Slot (1)
Priority: 0
Class: Unreliable & Broadcast (2)
Size: 50
Mailslot Name: \MAILSLOT\BROWSE
Microsoft Windows Browser Protocol
Command: Host Announcement (0x01)
Update Count: 0
Update Periodicity: 12 minutes
Host Name: SCARY
OS Major Version: 5
OS Minor Version: 1
Server Type: 0x00031003
.... .... .... .... .... .... .... ...1 = Workstation: This is a Workstation
.... .... .... .... .... .... .... ..1. = Server: This is a Server
.... .... .... .... .... .... .... .0.. = SQL: This is NOT an SQL server
.... .... .... .... .... .... .... 0... = Domain Controller: This is NOT a Domain Controller
.... .... .... .... .... .... ...0 .... = Backup Controller: This is NOT a Backup Controller
.... .... .... .... .... .... ..0. .... = Time Source: This is NOT a Time Source
.... .... .... .... .... .... .0.. .... = Apple: This is NOT an Apple host
.... .... .... .... .... .... 0... .... = Novell: This is NOT a Novell server
.... .... .... .... .... ...0 .... .... = Member: This is NOT a Domain Member server
.... .... .... .... .... ..0. .... .... = Print: This is NOT a Print Queue server
.... .... .... .... .... .0.. .... .... = Dialin: This is NOT a Dialin server
.... .... .... .... .... 0... .... .... = Xenix: This is NOT a Xenix server
.... .... .... .... ...1 .... .... .... = NT Workstation: This is an NT Workstation
.... .... .... .... ..0. .... .... .... = WfW: This is NOT a WfW host
.... .... .... .... 0... .... .... .... = NT Server: This is NOT an NT Server
.... .... .... ...1 .... .... .... .... = Potential Browser: This is a Potential Browser
.... .... .... ..1. .... .... .... .... = Backup Browser: This is a Backup Browser
.... .... .... .0.. .... .... .... .... = Master Browser: This is NOT a Master Browser
.... .... .... 0... .... .... .... .... = Domain Master Browser: This is NOT a Domain Master Browser
.... .... ...0 .... .... .... .... .... = OSF: This is NOT an OSF host
.... .... ..0. .... .... .... .... .... = VMS: This is NOT a VMS host
.... .... .0.. .... .... .... .... .... = Windows 95+: This is NOT a Windows 95 or above host
.0.. .... .... .... .... .... .... .... = Local: This is NOT a local list only request
0... .... .... .... .... .... .... .... = Domain Enum: This is NOT a Domain Enum request
Browser Protocol Major Version: 15
Browser Protocol Minor Version: 1
Signature: 0xaa55
Host Comment:
more will come if needed.
-
February 17th, 2003, 10:10 PM
#8
That looks like a standard packet attempting to discover a NetBios network. The address XXX.XXX.XXX.255 is always a broadcast address so that machines can perform discovery be it ARP or NetBios or whatever.
This also pretty much proves that the source is very close virtually. Routers are not _usually_ set to forward broadcasts so this is likely sitting on your local subnet. Furthermore, the source network device is made by netronix which, (using the info I just learned right here in this thread..... ), means that the last device to touch this packet was made by netronix. They only make NIC's and switches so it appears that no router has been involved. Also, the TTL is 128 and this is NetBios so this is a windows box, (also indicated by the name bing "scarey" and the workgroup being "workgroup"). Windows TTL's default to 128 while *nix boxes are usually 64 if memory serves which further indicates the box is close by.
Issue a tracert 10.251.111.42 I'm willing to bet it will "one hop"... ie. it's local.
If this is the case here's the scoop...<S> Someone has a completely unprotected Windows box right next door to you. With that in mind make sure you plug all your holes cos if nasty Mr. Cracker get's onto that box the first thing he will do is take a look at the neighborhood - which is YOU!!!!
Don\'t SYN us.... We\'ll SYN you.....
\"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides
-
February 17th, 2003, 10:35 PM
#9
Junior Member
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
|