dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
15711
BlitzenZeus
Burnt Out Cynic
Premium Member
join:2000-01-13

BlitzenZeus

Premium Member

Example ICMP rules

Edit: Stev23k had a good idea about putting the icmp numbers in the rule name.

ICMP is not even necessary to use the net completely, but its up to you if you want to allow it. There are many security risks, but limiting what you accept will help if you do allow ICMP.

Now there are icmp floods, pings of death, spoofed packets, etc... A good firewall with Stateful Packet Inspection should only let through what your computer asked for unless its a packet that requires no verification. Not many personal firewalls even have SPI...

I have not had a problem with this stuff, but some servers do when used as a DOS attack.

If your going to allow ICMP you should allow:

Inbound:
3 Destination Unreachable (otherwise your connections might just hang instead of closing correctly.

Outbound:
3 Destination Unreachable (To your DNS servers ONLY, but optional)

To allow yourself to ping/trace others:

Inbound:
0 Echo Reply
3 Destination Unreachable
11 Time exceeded

Outbound:
8 Echo Request

To be pingable...

Inbound:
8 Echo Request

Outbound:
0 Echo Reply
-------------------

Now these are the bare minimum you need to except for these except icmp 3, but that will prevent some problems/headaches. You should block the rest of the icmp packets in, and out that you do not explicitly allow. You can make rules for only certain sites to be able to ping/trace you, and that will allow you to tighten your ruleset.

If you do not allow icmp 3 in, it could cause problems with your online games, and running pings/traces not to complete properly.

My rules:
[_] Permit Pings (disabled)
-- In: 8 (any site)

[x] Permit site x to ping me
-- In: 8 (www.com)

[x] Inbound ICMP
-- In: 0,3,11 (any site)

[x] Outbound ICMP
- Out: 0,8 (any site)

[x] Block all ICMP
-- In:all Out:all (any site)

[text was edited by author 2002-03-02 18:15:53]

stev32k
Premium Member
join:2000-04-27
Mobile, AL

stev32k

Premium Member

Click for full size
I'm glad you brought this up - I've been wondering if there should be any local or remote port designations. And is it important to add the deny rule right after the ICMP rules. I have not added the block ICMP rule - depending on the block all rule at the end to do that. Could this cause any problems?

gwion
wild colonial boy

join:2000-12-28
Pittsburgh, PA

gwion to BlitzenZeus

to BlitzenZeus
Ports aren't used by ICMP. You might want to be pingable or traceable, though, from some addresses and not others... The attacks mentioned are very real, but are mostly server-directed attacks. One big threat on a client machine would be a trojan starting one as a part of a DDoS from your machine. These are sort of up there with ARP poisoning and some of the more esoteric scanning techniques, in terms of frequency... however, especially f you have a server running, you may want to tighten, or separate for logging/individual activation and deactivation, the pretty basic, loose ended rules we tend to use on clients.

PS- the block all will be fine, if you provide the allows the way you want them. It will just stop the firewall prompting everytime you get an ICMP hit you don't have listed. Just remember, any "allow any" you put below the rule CAN'T allow ICMP, because of rule order... the ICMP's will already have been processed by the kill all. OOPs Ok, yeah, I see, a BLOCK ALL ALL. OK, that's entirely optional. I leave that open for discussion. The firewall defaults to dropping anything that makes it that far, anyway, if you don't answer the prompt.
BlitzenZeus
Burnt Out Cynic
Premium Member
join:2000-01-13

BlitzenZeus to stev32k

Premium Member

to stev32k
Contrary to what the FAQ says, I use the bare minimum you need to allow. I have not seen the need to allow icmp 11 outbound for any reason.

Now you could use a block everything rule in the end, but I don't so I keep separate block all rules for certain types of packets. I don't leave my block all rule enabled for tcp/udp since I do have rules that require my input every time they connect.
jbibe
Premium Member
join:2001-02-22

jbibe

Premium Member

I use three ICMP rules. Rule 1 allows inbound ICMP types 0, 3, and 11. Rule 2 allows outbound ICMP types 3 and 8. Rule 3 blocks all ICMP types inbound and outbound.
[text was edited by author 2002-03-02 18:26:15]

stev32k
Premium Member
join:2000-04-27
Mobile, AL

stev32k to BlitzenZeus

Premium Member

to BlitzenZeus
Thanks, I just removed ICMP type 11 from the outbound rule. I'm going by the theory that the fewer rules I have the fewer mistakes I can make (I hope).

gwion
wild colonial boy

join:2000-12-28
Pittsburgh, PA

gwion to BlitzenZeus

to BlitzenZeus
I like that approach. I may edit down those rules even more... 3 and 11 outbound are entirely unnecessary, really, for clean function. We only allow 'em in only (type 3) to support the Max MTU detection tweaks, and (11) to support traceroute; since WE are the machine that will back down MTU, and WE are the machine that is tracing route, we don't need to allow them out, really... thanks... duly noted... maybe we'll trim that FAQ a little more... of course, depending on situations, some servers may want to allow themselves to be tracerouted or pinged, sort of a fluid topic, there. But for an average client machine, probably best rule is minimum for what you need...

[ED: Done. The theme of the FAQ is basics, for right now, secure essentials for starting out. I restated that to allow 0,3,11 in and 8 out... This might make a good topic for FAQ inclusion, overall, in the "advanced" department. Well done.]
BlitzenZeus
Burnt Out Cynic
Premium Member
join:2000-01-13

BlitzenZeus

Premium Member

Yes these are meant for a client/home user. This was taken from my reply to another person, and modified a little bit so the information in this post would be hopefully easier to understand than the information in the FAQ.

stev32k
Premium Member
join:2000-04-27
Mobile, AL

stev32k to gwion

Premium Member

to gwion
I seem to need an outbound ICMP type 3. I had several occasions today where the browser hung up for a minute or two, and each time I received a notice that tiny had denied outbound ICMP type 3. Since allowing the type 3 outbound I haven't had the problem.
BlitzenZeus
Burnt Out Cynic
Premium Member
join:2000-01-13

BlitzenZeus

Premium Member

Then what you will need to do is make rules to allow this outbound to your dns servers only like in my first post, and that will take care of that problem.

gwion
wild colonial boy

join:2000-12-28
Pittsburgh, PA

gwion to BlitzenZeus

to BlitzenZeus
I'm going with that. I've had mixed results, myself, without allowing it. It sdoes seem to help. As with any rules, ICMP allows are a calculated risk. I have to balance, myself, betwen usability and security.

Excellent discussion. It's very important, with a rules based firewall, that you understand at least a little bit about protocols and ports... there's a handy table of ICMP types and codes at »www.spirit.com/Resources ··· cmp.html ; please note that Tiny nor Kerio yet address codes. Allowing a tye is an all or none operation. It would be nice if a feature were provided. The table, there, is a nice resource, and if you have a general idea of networking vocabulary, you can probably pick up an idea of what some of these types are all about, there.

Ideally, we would enable "type3, code4, both ways," if we could. We can't, so the closest we can get is to allow as much of the whole type as we have to to get things working smoothly...

stev32k
Premium Member
join:2000-04-27
Mobile, AL

stev32k

Premium Member

Click for full size
Okay - Here's the new rule set. I moved IE to the head of the class with DNS in second place. Browsing seems to be a tad faster that way. I've restricted outbound ICMP to the DNS servers(really my firewall/router). So far this set seems to be working just fine.
BlitzenZeus
Burnt Out Cynic
Premium Member
join:2000-01-13

BlitzenZeus

Premium Member

Look at your rules... Keep your normal two icmp rules, but just make the extra that only allows icmp 3 to your dns otherwise with your current configuration you will not be able to ping anything besides your router.

BTW, the order of your rules will not work here since ICMP rules are not application based.

If you want you can even use your Custom Address Group if your not using it for anything else. I have multiple dns servers I use so I was forced to do this:
»blitzweb.home.attbi.com/ ··· ules.gif

stev32k
Premium Member
join:2000-04-27
Mobile, AL

stev32k

Premium Member

Thanks for the advise. I set up a custom address group and added one ICMP allow rule for ICMP type 3 to that address only. I tried trace route and ping and they are both working as they should.

I feel really good about that rule set - thanks a lot.

gwion
wild colonial boy

join:2000-12-28
Pittsburgh, PA

gwion to BlitzenZeus

to BlitzenZeus
I'm curious, what would the most serious consequence of allowing ICMP type 3 really be for the average home user?

Smurf attacks are a dying breed. Most of the exploits are server directed, DoS type exploits. SANS has an interesting write up on ICMP at »rr.sans.org/threats/ICMP.php ... it includes a nice table, near the bottom, that summarizes the vulnerabilities.

I always have trouble with this one, myself. Hard call. I certainly don't allow anything I have no reason to allow. I'll be following along

stev32k
Premium Member
join:2000-04-27
Mobile, AL

stev32k to BlitzenZeus

Premium Member

to BlitzenZeus
Okay - guess I'm really confused. The order of the rules I have now are:

allow outgoing ICMP type 8 - any address
allow incoming ICMP type 0, 3, 11 - any address
allow outgoing ICMP type 3 - custom address (my router)

Is this wrong?
BlitzenZeus
Burnt Out Cynic
Premium Member
join:2000-01-13

BlitzenZeus to gwion

Premium Member

to gwion
Floods only tie up our resources, but there is one that could be a problem with icmp 3, type 5... "Man in the Middle Attack"

If you don't allow icmp 3 in you can't ping/trace correctly, it will cause problems with online games, and mtu detection....

It is a tough call, but how often is this really used? The better question is how do we know its not already being used?

Your right, until we have control over the type of packet it is to the point where we can block icmp 3(5), its a possible hole for abuse.
BlitzenZeus

BlitzenZeus to stev32k

Premium Member

to stev32k
No you commented that you put your IE rule higher than the icmp rules, but that didn't make a difference in how icmp was processed

gwion
wild colonial boy

join:2000-12-28
Pittsburgh, PA

gwion to BlitzenZeus

to BlitzenZeus
Steve, your rules should work fine. Long as there's nothing to block ICMP above them, or that would allow it wholesale to some particular place (an allow any type rule would do that; in a complimentary way, a deny any rule would stop the allowed types, placed above them. I allow "any type" for my LAN, for example... but nothng else... above pretty much everything. That's a trust decision, but, as a rule, you would be shy about allow "any" from an internet source, in my book. If you need a special protocol or more ICMP for a certain site or mask, better to create an exception rule for that IP or range...

The short answer, it looks alright.

Generally, I put a rule deny all ICMP under the allows, myself. It's the equivilent of "drop this junk and don't bug me." I don't personally need to be prompted that an unallowed ICMP was killed. If I have problems, I can enable logging on the deny and see what it's catching...

BlitzenZeus... well said... who knows?
JPM89141
join:2002-01-03

JPM89141 to BlitzenZeus

Member

to BlitzenZeus
"Your right, until we have control over the type of packet it is to the point where we can block icmp 3(5), its a possible hole for abuse."

I believe Look 'n' Stop allows this type of control over ICMP.
BlitzenZeus
Burnt Out Cynic
Premium Member
join:2000-01-13

BlitzenZeus

Premium Member

It has been proven that the current icmp block all rules don't block all icmp packets, and TheWiseGuy had a great idea!

IP Protocol 1 is ICMP so if we block it, we successfully block it completely

So officailly you can change your Block All ICMP rule to:
protocol: other
(a empty box will apppear to the right of that)
Box: 1

gwion
wild colonial boy

join:2000-12-28
Pittsburgh, PA

gwion to BlitzenZeus

to BlitzenZeus
That's a good, informative post, BlitzenZeus... great idea. Yes, I hadn't considered that one, but if the popups generated by malformed ICMP packets bother you, and you don't want to kill them wholesale, selecting the protocol by number should do the trick. Good work. We'll keep that handy ... a quick, easy behavior modification... I have a feeling this group will be writing a few great rules, as we progress - and that's a very good start. Yes, I've wanted to get into discussing proto blocking, and this is a good, simple starting point to demonstrate the concept. If you "block all icmp by type," malformed ICMP isn't a valid type, so you have no rule blocking it. It spills over and prompts. If the prompt is undesirable, to you, then a rule like this should do the trick. An any rule will also work, but that would prevent anything from prompting, so here's the beginning of a more granular set of filters to get the prompts before they pop up...

BUT- can we all please stop phrasing it this way? That's my only very minor but real problem, here. This isn't a bug. It just shows that ICMP is per type blocking, not per protocol blocking. Thanks, BlitzenZeus for demonstrating per protocol blocking for ICMP. In per type, if the match is not to the types selected (that is, a malformed or null ICMP packet), it becomes an unknown packet, far as the rule is concerned. It's just one way that the processing can be handled. It isn't a "bug" or (by any means) a vulnerability... it still prompts... it's entirely simple to understand. There's no "malformed" packet type in the list. Therfore, no match. An any rule will match it, as will a rule like this. If no rule matches, it doesn't get in. It prompts, like any other unknown packet. This is potentially confusing, for some people. It's just the way Kerio cjhose to implement the matching procedure. It actually provides MORE, not less granularity in your configuration, if you think it out entirely... I personally think that malformeds are a good thing to log and alert on "separately", becaus they don't belong, normally, and deserve special attention, if you suddenly start getting them... it's just one way of implementing rules parsing. Other rules based firewalls may implement other ways... but this is equally valid... NOT a vulnerability or bug... and that is precisely what it sounds like, in this phrasaelogy, intended or not, to a less articulate or advanced user... Frankly, it's what it sounded like to me, on first blush. It's simply an implementation. Nothing's getting "through". At all.

... oops, and thanks, Wiseguy, too... don't want to leave you out! good job.
BlitzenZeus
Burnt Out Cynic
Premium Member
join:2000-01-13

BlitzenZeus

Premium Member

UPDATE: Stanislav Kolar has updated the icmp options to finally include an 'all' option!

So you don't need the other-1 setting, but just the 'all' setting in your ICMP Block rule now

michlin
join:2000-11-18
Georgetown, MA

michlin to stev32k

Member

to stev32k
Stev32K,

I'm curious why you would allow incoming with Internet Explorer. That's dangerous! Allowing outbound only is sufficient for the "three way handshake".
Sentinel
Premium Member
join:2001-02-07
Florida

Sentinel to BlitzenZeus

Premium Member

to BlitzenZeus
I tried blocking all ICMP. I have a block all and log rule at the end of my rule set to see if anything is trying to get out and I am blocking it somehow. I did get a lot of ICMP type 3 out logged. Now I have only 1 ICMP rule. I allow ICMP type 3 outbound. All else is blocked by my block all rule.
BlitzenZeus
Burnt Out Cynic
Premium Member
join:2000-01-13

BlitzenZeus

Premium Member

As previously noted in my first comment, allow these to your DNS ONLY, and if you have read your logs you will see that they are only being sent to your DNS servers.

You don't have to let them outbound, its safe to block them, and sometimes these are caused by software problems. Using a modified hosts file, or ad-blocking software can cause false messages to be sent at times.

If you have a problem with seeing them blocked in your logs, but want to keep them blocked, just make a rule to block them that won't log them...

stev32k
Premium Member
join:2000-04-27
Mobile, AL

stev32k to michlin

Premium Member

to michlin
michlin: you're right I changed the rule to allow outbound only.
Sentinel
Premium Member
join:2001-02-07
Florida

Sentinel to BlitzenZeus

Premium Member

to BlitzenZeus
Hmm. Sounds good blitz. I never thought ot that. I do use a hosts file and Proxomitron so these outbound ICMP is probably false. Guess I'll just drop them quietly.