On Fri, 11 Oct 2002, Doug Hite wrote: > Thanks for the quick response Jeff. Yes, it is very much a sequential > thing - I don't know what a scan would look like from the logs, but if I > had to guess what it would look like, this would be it. Here is a very > brief snippit - > > Oct 11 06:56:02 isdnfirewall kernel: Packet log: remote DENY eth0 PROTO=6 >216.224.239.106:61694 209.251.232.18:135 L=44 S=0x00 I=12220 F=0x4000 T=107 SYN (#9) > Oct 11 06:56:26 isdnfirewall kernel: Packet log: remote DENY eth0 PROTO=6 >216.224.239.106:61697 209.251.232.19:135 L=44 S=0x00 I=12476 F=0x4000 T=107 SYN (#9) > Oct 11 06:56:29 isdnfirewall kernel: Packet log: remote DENY eth0 PROTO=6 >216.224.239.106:61697 209.251.232.19:135 L=44 S=0x00 I=12732 F=0x4000 T=107 SYN (#9) > Oct 11 06:56:35 isdnfirewall kernel: Packet log: remote DENY eth0 PROTO=6 >216.224.239.106:61697 209.251.232.19:135 L=44 S=0x00 I=12988 F=0x4000 T=107 SYN (#9)
No, this is just the server repeatedly trying to access rpc on your machine. This smells of sysadmin error on the source machine, or on a computer inside your network trying to get that machine to answer back through RPC. A real scan doesn't pound on the same door (port 135) over and over. It would try 136 a few times, then 137 a few times, and would probably quit after awhile (they would have easier fishing elsewhere). > The rule appears to have stopped this dead. My logs can > breath easier for awhile. Thanks again. > > Does anyone have any other procedures that they do > when in this situation ? I certainly will save this rule in my > personal LEAF documents folder if it happens again. I repeat, look at your masqueraded connections going through the router to confirm that you are not prompting this behavior inadvertently. Some "useful program" may be doing this, or a phone-home worm or virus could be calling for this connection. If you aren't causing it, then it is sysadmin error on the other end and you could send an email to a responsible person at that location asking them to look into it. You can use "whois" or "dig" to find out that the source ip reverse maps to wencpa.com, and surfing to http://wencpa.com brings you to a website that lists [EMAIL PROTECTED] as the contact. Maybe not a sysadmin type, but s/he should know who to route your query to. Be careful doing this... confirm that you are not prompting this torrent of connection attempts, and stick to the facts. In some cases the behavior has a commonly known cause that you can mention as a possibility, but in this case you probably don't have much basis for saying more than "your server is continually trying to connect to my system on port 135". It isn't really denial-of-service material at the packet rates you show, but it won't go away until someone fixes the cause. --------------------------------------------------------------------------- Jeff Newmiller The ..... ..... Go Live... DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/Batteries O.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --------------------------------------------------------------------------- ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
