Security Incidents mailing list archives
Re: SNMP Scans 02/17/02
From: Dan Terhesiu <dante () astral ro>
Date: Tue, 19 Feb 2002 10:12:43 +0200
On Sun, Feb 17, 2002 at 10:23:09PM -0600, Peter Johnson wrote:
Just saw this in my portscan log (via snort) and decided to share with the community so we can figure out who is scanning with what tools and for what purpose(investigative or malicious).
I've seen almost the same pattern with some differencies though: variable source port same destination address TCP instead of UDP Samples: Feb 15 11:23:50 x kernel: Packet log: input DENY eth1 PROTO=17 212.93.140.25:4539 x.x.x.x:161 L=117 S=0x00 I=50744 F=0x0000 T=57 (#2) Feb 15 11:23:52 x kernel: Packet log: input DENY eth1 PROTO=17 212.93.140.25:4539 x.x.x.x:161 L=117 S=0x00 I=50752 F=0x0000 T=57 (#2) Feb 15 11:23:54 x kernel: Packet log: input DENY eth1 PROTO=17 212.93.140.25:4539 x.x.x.x:161 L=117 S=0x00 I=50757 F=0x0000 T=57 (#2) Feb 15 11:23:56 x kernel: Packet log: input DENY eth1 PROTO=17 212.93.140.25:4539 x.x.x.x:161 L=117 S=0x00 I=50762 F=0x0000 T=57 (#2) ... Feb 16 02:13:41 x kernel: Packet log: input DENY eth1 PROTO=17 212.93.140.25:1032 x.x.x.x:161 L=117 S=0x00 I=7005 F=0x0000 T=57 (#2) Feb 16 02:13:43 x kernel: Packet log: input DENY eth1 PROTO=17 212.93.140.25:1032 x.x.x.x:161 L=117 S=0x00 I=7020 F=0x0000 T=57 (#2) Feb 16 02:13:45 x kernel: Packet log: input DENY eth1 PROTO=17 212.93.140.25:1032 x.x.x.x:161 L=117 S=0x00 I=7035 F=0x0000 T=57 (#2) Feb 16 02:13:47 x kernel: Packet log: input DENY eth1 PROTO=17 212.93.140.25:1032 x.x.x.x:161 L=117 S=0x00 I=7044 F=0x0000 T=57 (#2) ... Feb 19 09:46:22 x kernel: Packet log: input DENY eth1 PROTO=17 212.93.140.25:4186 x.x.x.x:161 L=117 S=0x00 I=34692 F=0x0000 T=57 (#1) Feb 19 09:46:24 x kernel: Packet log: input DENY eth1 PROTO=17 212.93.140.25:4186 x.x.x.x:161 L=117 S=0x00 I=34695 F=0x0000 T=57 (#1) Feb 19 09:46:26 x kernel: Packet log: input DENY eth1 PROTO=17 212.93.140.25:4186 x.x.x.x:161 L=117 S=0x00 I=34699 F=0x0000 T=57 (#1) Feb 19 09:46:28 x kernel: Packet log: input DENY eth1 PROTO=17 212.93.140.25:4186 x.x.x.x:161 L=117 S=0x00 I=34701 F=0x0000 T=57 (#1)
From what I've seen, it starts counting from 1032, reach 4996 as source port, and then start again with 1032.
Seems like they scan my 5 IP block 3 times Feb 17 20:21:06 67.113.159.146:1504 -> X.X.X.50:161 UDP Feb 17 20:21:06 67.113.159.146:1504 -> X.X.X.52:161 UDP Feb 17 20:21:06 67.113.159.146:1504 -> X.X.X.53:161 UDP Feb 17 20:21:06 67.113.159.146:1504 -> X.X.X.54:161 UDP Feb 17 20:21:06 67.113.159.146:1504 -> X.X.X.55:161 UDP Feb 17 20:21:11 67.113.159.146:1504 -> X.X.X.51:161 UDP Feb 17 20:21:11 67.113.159.146:1504 -> X.X.X.50:161 UDP Feb 17 20:21:11 67.113.159.146:1504 -> X.X.X.55:161 UDP Feb 17 20:21:11 67.113.159.146:1504 -> X.X.X.54:161 UDP Feb 17 20:21:11 67.113.159.146:1504 -> X.X.X.52:161 UDP Feb 17 20:21:16 67.113.159.146:1504 -> X.X.X.53:161 UDP Feb 17 20:21:16 67.113.159.146:1504 -> X.X.X.54:161 UDP Feb 17 20:21:16 67.113.159.146:1504 -> X.X.X.55:161 UDP Feb 17 20:21:16 67.113.159.146:1504 -> X.X.X.50:161 UDP Feb 17 20:21:16 67.113.159.146:1504 -> X.X.X.51:161 UDP Feb 17 20:21:16 67.113.159.146:1504 -> X.X.X.52:161 UDP ======================================================= I have some generic snmp rules to catch all SNMP scans/probes. Here is a sample packet that got [**] SNMP/udp public access [**] 02/17-20:21:06.412571 0:A0:C5:E5:F6:93 -> 0:10:5A:F:34:B1 type:0x800 len:0x61 67.113.159.146:1504 -> X.X.X.50:161 UDP TTL:114 TOS:0x0 ID:55265 IpLen:20 DgmLen:83 Len: 63 30 35 02 01 00 04 06 70 75 62 6C 69 63 A1 28 02 05.....public.(. 04 3C 69 F1 B9 02 01 00 02 01 00 30 1A 30 0B 06 .<i........0.0.. 07 2B 06 01 02 01 01 02 05 00 30 0B 06 07 2B 06 .+........0...+. 01 02 01 01 01 05 00 ....... Every packet looks exactly the same. Wonder if this is the SANS snmp scanning tool? ====================================================================== Name: adsl-67-113-159-146.dsl.sntc01.pacbell.net Address: 67.113.159.146 George S Granados (NETBLK-SBC-06711315914429) San Francisco, Ca 94104 US Netname: SBC-06711315914429 Netblock: 67.113.159.144 - 67.113.159.151 Coordinator: Pacific Bell Internet (PIA2-ORG-ARIN) ip-admin () PBI NET 888-212-5411 Seems like ol pacbell gives info on who they give IP blocks to! ;) Do you think we should be reporting snmp scans to ISPs or just a waste of time?
In my case, it was: two e-mails, phone call ending with promisses. What can I tell you: 16757 entries only for this address. The same ISP has another address which defeated the first one: 48708 entries (this one dealing with scans, etc.). So I guess it depends mainly on the ISP to solve your problem. I don't even know what to do anymore: the packets continues to reach our network even when I write this e-mail. Do you have any suggestion about handling the problem in the proprer manner? PS. Sorry for my bad English
================================================================== Peter -- Peter E. Johnson Securityflaw http://www.securityflaw.com ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
-- Dan Terhesiu Network Administrator ASTRAL TELECOM ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
Current thread:
- SNMP Scans 02/17/02 Peter Johnson (Feb 18)
- Re: SNMP Scans 02/17/02 Security Coordinator (Feb 20)
- Re: SNMP Scans 02/17/02 Valdis . Kletnieks (Feb 22)
- RE: SNMP Scans 02/17/02 Tyrannis Von Nettesheim (Feb 22)
- Re: SNMP Scans 02/17/02 Eric Brandwine (Feb 22)
- Re: SNMP Scans 02/17/02 Dan Terhesiu (Feb 20)
- Re: SNMP Scans 02/17/02 Peter Johnson (Feb 20)
- <Possible follow-ups>
- RE: SNMP Scans 02/17/02 Dmitri Smirnov (Feb 23)
- Re: SNMP Scans 02/17/02 Eric Brandwine (Feb 24)
- Re: SNMP Scans 02/17/02 Security Coordinator (Feb 20)