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-adminat_private > 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
This archive was generated by hypermail 2b30 : Wed Feb 20 2002 - 15:48:25 PST