Blocking IP Ranges

Does anyone know if it's wise to block IP ranges in LooknStop?
Is there merit in blocking the IANA IP range 239.0-255.255.255.255 be blocked on a non-networked computer?
What are ranges that should likely be blocked for security reasons, for instance by geography, hack/spam/virus attempts etc?

 

Hello Daniel,


No reason to add these ranges and there are so many firewall spam IP's and IANA ranges you would run out of room in Internet filtering sooner or later and these rules below protects you from anything bad coming in.

+TCP : Block incoming connections

Also

+Invalid UDP packet

And a few others rules are protecting you from bad packets.


So there is really no need,but you can add them if you like.

Also if you want to stop IANA from connecting eveytime you boot-up go to GRC.COM and download this free program called unpnp (Universal Plug & Play) and that will stop a sever in Del Ray Ca.(IANA), from connecting at start-up.

Good Luck

 

Thank Kush.
I do have the Phant0m v6 ruleset. What does blocking the Invalid UDP packet accomplish? Does anyone know? I do remember seeing the rule when Phant0m rulset is loaded, but it blocks my A/V, so it's usually unloaded.

 

It stops malformed packets from reaching your computer and anything that is not a normal protocol.


You said you unchecked this rule? That's a very good way to get hacked and fast! What is your AV.? Never delete rules that are active,you now have killed your security on LnS.


I would put back the invalid UPD rule A.S.A.P.!!!! and tell us what your AV. you are using? So we can help you set it up without deleting Phant0m's rule-set.

I use Phant0m's rule-set also it is very secure,but not when you start deleting rules then your running into trouble and fast!

 

Hi daniel952, Hey Kush

daniel952, Kush is absolutely right, that port, port 0 is invalid / reserved port and should NOT be used (says so in an RFC article), TCP & UDP packets should not contain port 0 for a source OR destination ports.

As Kush said, would be interesting to know what AV product uses this port, because it shouldn’t and to-do so is bad security practices.

 

I never delete rules, but what I did do is change back to "Enhanced Ruleset" when updating A/V. Searched the rules, but missed the entry before posting here. The Invalid UDP Packet rule is there in the Phant0m Ruleset.

Thanks for the explaination and acknowledgement.

 

Recently I had contacted Frederic regarding Ingress Filters and several rules that I have in my Private copy of the Look ‘n’ Stop Ruleset (Phant0m``s GOLDEN PLUS Look ‘n’ Stop Ruleset), we’ might’ see a small Plug-In or something in the hopefully near future for the several Ingress Filters to be in a possibly small listbox instead of Ingress Filter per rule via ‘Rule Edition’.

These should be blocked by the software Firewall, and hopefully Look ‘n’ Stop will offer conveniences to this aspect.

 

Phant0m,

Thanks for the acknowledgement. My A/V does not use port 0. The block rule for "Invalid UDP Packets" was what brought port 0 into the discussion.
My only question is whether to block these UDP packets both inbound and outbound. Inbound is specified in the rule, but would it hurt bloking also outbound?

 

Hi daniel952

I’m confused, how does your AV get blocked? Normally this shouldn’t be an issue for AV systems to-do updates, can you locate and copy couple of those AV blocking lines from the Look ‘n’ Stop Logfile?

 

It is nice to have Ingress Filters in place in the firewall, one it stops many types of malformed, invalid, scan packets, and useless traffics. This stuff I see often and throughout the days, and if I’m not mistaken, running pcFlank Stealth Scan with all those exploits types applied I think all will be blocked simply by the Ingress Filters alone…

…

You should not make modifications to any of the current rules in the ruleset, there are reasons for everything…

 

Actually the rules would have worked just fine if I hadn't modified the flags from the original ruleset. The modified ruleset caused it to trigger the "Block all other packets" rule. I modified it to test the browser, but never changed it back to default. Port 80 and 53 iis where the A/V updated, and it works with the default.

Thanks for the info!

 

Not trying to be difficult, and I apologize for the A/V thing. Just want a better understanding of why only the inbound is blocked on the 'invalid UDP packet' rule. Why not the outbound as well? I have noticed that the port being blocked is port 0. Would it not be possible for a seemingly innocent or popular software to use such a sneaky way outbound for malicious purposes?

I now understand the reasoning behind your statement above as seen by the modification that I made blocking packets needed to allow my updates.