Dan Terhesiu wrote: > 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) can you tell if it automated or just someone poking around? > 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? Not really, senting admins emails and phone calls is all you can really do. If its a DOS situtation, you can try to get your upstream provider to null route the address, but for simple port scans you'll just have to deal with it. Most likely port 161 scans will become as common as port 111,53,21 and the more recent port 22. We just gotta keep our eye out for automated worms which could be extremely dangerous to the stability of the internet. Not all admins will patch their equipment, and hardware based systems will be slow to update their firmware. Hopefully admins will be responsible and disable/block and patch their systems, but if the past can fortell the future they won't. Atleast SNMP isn't a common Home User service like IIS web servers, enterprise networks with poor firewalls and poor router ACLs will have to worry if they don't learn how to 1st disable SNMP on all devices not needed 2nd Block/Filter SNMP ports at primiter routers/firewalls 3rd patch all devices needing SNMP and configure it with strict secure guidelines(see vendor advisorys) Good Resource(s) http://www.cert.org/tech_tips/snmp_faq.html http://www.faqs.org/faqs/snmp-faq/part1/ http://www.faqs.org/faqs/snmp-faq/part2/ > PS. Sorry for my bad English Its actually pretty good, prolly better than mine! ;) 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
This archive was generated by hypermail 2b30 : Wed Feb 20 2002 - 14:46:23 PST