Blocking IP Ranges

Discussion in 'LnS English Forum' started by daniel952, Mar 8, 2006.

Thread Status:
Not open for further replies.
  1. daniel952

    daniel952 Registered Member

    Joined:
    Jul 30, 2004
    Posts:
    71
    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?
     
  2. Kush

    Kush Registered Member

    Joined:
    Dec 10, 2004
    Posts:
    138
    Location:
    Montreal,Canada



    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 :)
     
  3. daniel952

    daniel952 Registered Member

    Joined:
    Jul 30, 2004
    Posts:
    71
    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.
     
  4. Kush

    Kush Registered Member

    Joined:
    Dec 10, 2004
    Posts:
    138
    Location:
    Montreal,Canada


    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!
     
  5. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    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.
     
  6. daniel952

    daniel952 Registered Member

    Joined:
    Jul 30, 2004
    Posts:
    71

    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.
     
  7. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    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.


     
  8. daniel952

    daniel952 Registered Member

    Joined:
    Jul 30, 2004
    Posts:
    71

    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?
     
  9. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    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?
     
  10. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    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… :)
     
  11. daniel952

    daniel952 Registered Member

    Joined:
    Jul 30, 2004
    Posts:
    71
    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!
     
  12. daniel952

    daniel952 Registered Member

    Joined:
    Jul 30, 2004
    Posts:
    71
    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.
     
Thread Status:
Not open for further replies.