Am I being flooded?

Comodo Internet Security - CIS Firewall Help - CIS
#1

Screenshots:

And then the logs:

Neither of those IPs listed in logs belong to me. Not internal, nor public IP.
I am not behind a personal router (only ISP’s) and I have my own public IP. I reside in heavily populated network zone (basically every customer of my ISP is part of it, but broadcasting on this network is off).

My ports are stealthed, tests show no open ports.

My internet connection has been a bit slow lately, is it related?

Thank you for assistance.

#2

Hi Spark,

Based on the Firewall logging your ISP uses private ip space to give to the customers and uses NAT translation somewhere in their cloud.

If you take a look at the ranges you’ll see that there are hosts on the
192.168.136.x range broadcasting to 192.168.137.255
192.168.138.x range broadcasting to 192.168.139.255
192.168.176.x range broadcasting to 192.168.177.255

Suggesting it uses a /23 or 255.255.254.0 subnet on the ranges.

Ports 137 and 138 UDP are windows noise (NBname/NBdatagram) which windows uses to build up a list of “network neighborhood” computers.

I suggest creating drop rules for those on the Global Rules of the Firewall policy (Advanced, Network Security Policy, 2nd tab Global).

Add, Block, UDP, IN source any destination any src port any dst port range 137 - 138.
If you are not having multiple computers on a local network.

That leaves us with a broadcast on port 5678 that could refer to “Remote Replication Agent” software.
Can you check to see if you have this running on your system, also try this:

Open a command-box and type

netstat -an

Check the output for something like this:
UDP 0.0.0.0:5678 :

#3

Hello Ronny,

I have added the global rule like you said.
You are right, the subnet mask on this network is 255.255.254.0

The result of netstat -an does not show any connection that is listening on 5678 port.

This is the updated log (the red indicates my internal IP).

Still looks like there is a lot going on.

#4

Having just taken a real quick eyeball look at your latest log, some of this traffic does not make sense for Internet traffic going thru an ISP router.

Destination traffic to 255.255.255.255 is a LAN segment only address. It doesn’t route at all, unless the ISP routers are horribly configured.

One of the log entries is a multicast ping to “all hosts” (224.0.0.1). That does not route across the Internet either. ISP’s won’t touch that kind of traffic load.

The log entries suggest that you’ve got another machine in-house, and it’s sending out some really strange packets. UDP packets are very easy to forge, but routing packets like that is another problem entirely.

How many machines do you have? And how are they connected?

#5

Hello Spark,

The top one is a probe for your Windows RPC daemon, that should be blocked, so that’s correct.
The next is a Multicast request for 224.0.0.1 All host group request you can safely block incoming IGMP traffic global.

For the 255.255.255.255 broadcasts you could make a block rule like Block, In, UDP, src any dst single ip 255.255.255.255 src port any dst port any.

The packet from 60.222.x.y is known as messenger spam, if you would have this port open you will continue to receive windows popup alerts, mostly with text like “you pc is slow, get our registry cleaner at… websitexyz”.
So that’s a correct block on unwanted traffic.

There are still a few broadcasts left to the subnet your on, you could put them all in blockrules like
Block, In, UDP, src any dst 192.168.137.255, src port any, dst port any.
Block, In, UDP, src any dst 192.168.138.255, src port any, dst port any.
Block, In, UDP, src any dst 192.168.177.255, src port any, dst port any.

Only leaves an ICMP Ping request ICMP type 8 code 0 to the multicast “all hosts” 224.0.0.1, you should make a specific rule to drop this
Block, In, ICMP, src any, dst 224.0.0.1, IMCP Details Any.

That should leave most of the normal broadcast noise out of your firewall logging.

Grue, i think he’s a some sort of cable/local lan switch, we have those over here also, but our providers don’t use private ip space on them.

#6
For the 255.255.255.255 broadcasts you could make a block rule like Block, In, UDP, src any dst single ip 255.255.255.255 src port any dst port any.

DHCP? There needs to be an opening for ports 67 and 68, or DHCP will ■■■■.

#7

Oeps, your right if he uses DHCP there should be allow rules for it yes.
On the global rules make it the top rule, Allow, In/Out, UDP, src any, dst any, scr port range 67 - 68, dst port range 67 - 68.

#8

I updated the rules, the logs are still kinda noisy.
Yes, this is a cable connection and there is no other computer in the house. I live in the apartment building so it might be neighbors.

Which IP addresses must I exclude from block list if I want to block every single IP from my lan? I am guessing dns, subnet, what else, or is it not a good idea?

#9

Well it’s not needed because it’s already blocked, only if you don’t want to let it clutter you firewall logging you could apply specific block rules to “filter” them from the block/log rule.

Could you post an other screenshot from what’s left now ? see if there is still “noise” or if it are real probes/attacks etc.