Different IPs Connect To Same Port #

Hi
I have a Netgear firewall and periodically (once a month) I find that there are a number of different IP addresses trying to connect to a single port. I don't think it's a denial of service attack because there just aren't that many IPs trying to connect.

My interenet connection did stop working 3 times the last time this happen. I feel fairly confident I don't have a virus, but who knows for sure.

They seem to come in groups every 20 to 40 minutes. Below is one of the groups. Also the Destination port number doesn't change and is usually something like port 500xx. This one just so happens to be Zabbix but I don't think it really matters.

Code:

Mon, 2013-06-XX 22:25:32 - TCP packet - Source: 105.225.127.XX - Destination: XX.XX.34.201 - [Access Policy not found, dropping packet Src 57082 Dst 10051 from WAN]
Mon, 2013-06-XX 22:04:26 - UDP packet - Source: 94.210.140.XX - Destination: XX.XX.34.201 -  [Access Policy not found, dropping packet Src 53481 Dst 10051 from WAN]
Mon, 2013-06-XX 22:04:28 - UDP packet - Source: 78.168.228.XX - Destination: XX.XX.34.201 -   [Access Policy not found, dropping packet Src 17527 Dst 10051 from WAN]
Mon, 2013-06-XX 22:00:55 - UDP packet - Source: 89.243.6.XX - Destination: XX.XX.34.201 -    [Access Policy not found, dropping packet Src 10000 Dst 10051 from WAN]
Mon, 2013-06-XX 19:41:15 - UDP packet - Source: 186.126.63.XX - Destination: XX.XX.34.201 -   [Access Policy not found, dropping packet Src 37218 Dst 10051 from WAN]
Mon, 2013-06-XX 19:04:30 - UDP packet - Source: 103.16.14.XX - Destination: XX.XX.34.201 - [Access Policy not found, dropping packet Src 3807 Dst 10051 from WAN]
Mon, 2013-06-XX 19:04:46 - UDP packet - Source: 203.98.117.XX - Destination: XX.XX.34.201 - [Access Policy not found, dropping packet Src 22411 Dst 10051 from WAN]
Mon, 2013-06-XX 19:10:17 - UDP packet - Source: 120.62.20.XX - Destination: XX.XX.34.201 - [Access Policy not found, dropping packet Src 46398 Dst 10051 from WAN]
Mon, 2013-06-XX 19:19:04 - UDP packet - Source: 177.132.18.XX - Destination: XX.XX.34.201 - [Access Policy not found, dropping packet Src 60235 Dst 10051 from WAN]
Mon, 2013-06-XX 19:20:40 - UDP packet - Source: 174.113.214.XX - Destination: XX.XX.34.201 - [Access Policy not found, dropping packet Src 31690 Dst 10051 from WAN]
Mon, 2013-06-XX 19:27:28 - TCP packet - Source: 41.182.65.XX - Destination: XX.XX.34.201 - [Access Policy not found, dropping packet Src 62201 Dst 10051 from WAN]
Mon, 2013-06-XX 19:27:31 - TCP packet - Source: 41.182.65.XX - Destination: XX.XX.34.201 - [Access Policy not found, dropping packet Src 62201 Dst 10051 from WAN]
Mon, 2013-06-XX 19:27:37 - TCP packet - Source: 41.182.65.XX - Destination: XX.XX.34.201 - [Access Policy not found, dropping packet Src 62201 Dst 10051 from WAN]
Mon, 2013-06-XX 19:29:15 - UDP packet - Source: 182.185.47.XX - Destination: XX.XX.34.201 - [Access Policy not found, dropping packet Src 10000 Dst 10051 from WAN]

 

Did you check out those IP addresses? The first one is from South Africa, the second from the Netherlands, and the third from Turkey. They also appear to be ISP providers.

You sure your not part of a botnet?

 

While I would agree that it is very hard to guess what's exactly going on behind these log entries without having a wider perspective, I do wonder what exactly makes you go that way? What frickin botnet and how did you come to this conclusion?

What's actually worse than giving no reply to the OP is posting FUD around.

If the DHCP server dynamically assignes IP addresses then you may occassionally see late packets from a session when your current IP address was used by someone else.

There are many types of DoS attacks, here we are looking at possible application layer ones (TCP/UDP). These attacks are performed against services that are listening and replying to incoming connections, usually found on servers. The idea is to disrupt the service by sending massive fake requests and causing it to reply to them (attempting to establish connection with each) thus overloading and being unable to serve legal requests.
There is no point in DoSing a closed stack this way as all packets will simply be blocked (or dropped, depending on how the firewall's been set) by the firewall (as your logs show) or by the stack itself in accordance with corresponding RFCs.

I seriously doubt the cause of disruption has anything to do with the log you posted. It may be related in a sense that when the connection reestablishes the DHCP gives you an IP that's been previously used for (example) P2P, so that's why you see the blocked packets you did not request. But this is all mainly guesswork, as I said without wider perspective it's very hard to tell. By "wider perspective" I am mainly referring to how your ISP operates.

You can know for sure very easily, by running multiple scanners such as MBAM, SAS, Himan and such. It won't hurt a bit.

 

Since I got nailed on giving a flipant answer, here's what I would in this situation.

First, check your Netgear router firewall settings and ensure the setting to "steath" all ports is on. If the firewall has a setting for statefull inspection, make sure that is also turned on. Then go to one of the web sites like Shields Up or PcFlack and run a scan to verify that your router ports are indeed in a stealth status. If a few ports are found to be in a non-stealth status, check if those are the ports your have been getting hammered on. If those ports are not closed but in an open status, then there is an issue with your router that you will have to address.

If for some reason you cannot hide those ports, then check your ICMP settings on the router. Make sure that echo reply is not set on by default. Your ISP may require that echo reply be set on due to that fact that it pings your router periodically to determine connectivity status.