BlitzenZeusBurnt Out Cynic Premium Member join:2000-01-13
|
ICMP Block all does not block all ICMPIn the exploit test: » www.pcflank.com/advanced.htm--1,[15/Mar/2002 17:02:15] Rule 'Block All other ICMP': Blocked: In ICMP [3] Destination Unreachable, 192.168.0.60->localhost, Owner: Tcpip Kernel Driver --1,[15/Mar/2002 17:02:15] Rule 'Block All other ICMP': Blocked: In ICMP [5] Redirect, 192.168.0.16->localhost, Owner: Tcpip Kernel Driver --1,[15/Mar/2002 17:02:15] Rule 'Block All other ICMP': Blocked: In ICMP [3] Destination Unreachable, 192.168.0.148->localhost, Owner: Tcpip Kernel Driver --1,[15/Mar/2002 17:02:15] Rule 'Block Inbound': Blocked: In ICMP , 192.168.0.177->localhost, Owner: Tcpip Kernel DriverMy current ICMP block all rule has every type selected, and the problem I see here is beside the fact they are spoofed packets, they don't have a correctly assigned number to be filtered by. I can reproduce this, and when you make a rule out of them they have no icmp type assigned to them so they can't effectively be filtered by the icmp rules. Last copy of my current rules: » blitzweb.home.att.net/xp ··· ules.gifAs you can see I had to activate my Block Inbound rule since I was getting prompted for these malformed icmp packets. |
actions · 2002-Mar-15 8:18 pm · (locked) |
stev32k Premium Member join:2000-04-27 Mobile, AL |
stev32k
Premium Member
2002-Mar-15 8:39 pm
Are you saying that a block ICMP (X) rule is needed for each type of ICMP? What about the default rule that is supposed to block anything that is not specifically allowed? Does this not apply to the ICMP protocol?
(Sorry for all the questions). |
actions · 2002-Mar-15 8:39 pm · (locked) |
Sunriser13 Premium Member join:2001-12-16 Umm... here? |
to BlitzenZeus
BlitzenZeus, I am nowhere near as good at this as you are, but this is what I did. Now, whether it did any good or not, I'll leave you to critique; but I did pass all the tests at PCFlank...perhaps an aberration? The "Null" rule shown following the "All" rule has nothing checked, and the "All" rule has everything checked. FWIW... |
actions · 2002-Mar-15 8:40 pm · (locked) |
|
to BlitzenZeus
BZ- Check the actual ICMP rule and see if Deny is actually checked. When I upgraded to 2.1.1 my Denies no longer had the Deny radio button selected. I didn't test whether it made a difference, so I don't know if that is the problem but I know there were reports of the Denies no longer having the radio button selected. |
actions · 2002-Mar-15 8:50 pm · (locked) |
stev32k Premium Member join:2000-04-27 Mobile, AL
|
to Sunriser13
Sunriser: I'm really confused about your "null" rule. If you have nothing checked, and you check deny what have you denied?
Maybe you should have nothing checked and check allow. That way you would allow nothing - [text was edited by author 2002-03-15 21:21:01] |
actions · 2002-Mar-15 9:15 pm · (locked) |
|
BlitzenZeusBurnt Out Cynic Premium Member join:2000-01-13 |
to Sunriser13
Thanks for the idea about checking nothing(null) It seems quite stupid they don't have a 'any' option for icmp. |
actions · 2002-Mar-15 9:17 pm · (locked) |
BlitzenZeus |
to Sunriser13
Sunriser13, your null rule didn't block anything as I suspected, but I had to try it out anyway. |
actions · 2002-Mar-15 9:25 pm · (locked) |
Sunriser13 Premium Member join:2001-12-16 Umm... here? |
to BlitzenZeus
Hey, y'all, I didn't say it made sense or anything...but I figured it couldn't hurt. My feeble attempts at deciphering the logs after the first test had given me this (not so) bright idea!! I guess I'll take it out now as utterly useless...LOL!!! |
actions · 2002-Mar-15 9:31 pm · (locked) |
gwionwild colonial boy
join:2000-12-28 Pittsburgh, PA |
to BlitzenZeus
Where you say block all... you have ALL types checked... and I mean "all," not just the ones you haven't allowed above it... rule order. You deny ALL types in the deny rule, bar none. If the prior rules allow it, it goes in. If it can't be allowed by the upper rules, it is marked for blocking. Remember, Tiny-Kerio logic... NOTHING is "passed" when a rule applies, the rule is used and processing STOPS. Dead and cold. If it does apply, nothing below it will interfere with it... it was already processed and dropped. If it doesn't, the next rule in sequence, etc., is compared until something applies. Since I can't see the checked types in your "block all" rule, I don't know what you have checked... it should be every single block in the type list, bar none. From what you're saying, this is being "passed" somehow to the end of the list... the prompt me slop bucket. The only way it should pass that far is no rule in the set applies. Tip: I have anti spoof rules in my own set... a spoofed nonroutable address would be dropped right at he top of my own rule set... ICMP or anything else... we've never discussed that concept, much, and they're borrowed from an old Unix firewall I have, but they serve a very useful purpose, once you reach "learned beginner - intermediate" status and want to experiment with some more advanced concepts... so, on this machine, a 192.168.(or any reserved IP) sourced packet not from a valid LAN machine would be killed before it even got looked at... with extreme prejudice. ANY protocol. The test system has the Kerio default settings "out of box," so I might look at this later on. But right now, I have to take a break. I'm getting pizza on my keyboard, first real meal I've eaten all day... hmmm... they could use more garlic in this sauce... oh, well... if you want a "perfect" one, you gotta toss it yourself! |
actions · 2002-Mar-15 10:03 pm · (locked) |
BlitzenZeusBurnt Out Cynic Premium Member join:2000-01-13 |
I already understand that i'm already permitting what I have allowed in the above rules, but my block all rule does have every type selected. You just click the 'select all' button, and it done. I even verified it when I made the rule the first time, and verified it after I had prompts for icmp. Its only these malformed packets with no icmp type that are getting through. So the issue here is its hitting the 'slop bucket' since its not conforming to the block all where you have to pick what you want to block, and we don't have a choice of "ANY" icmp type which would be a more reasonable choice. Rules to block packets from reserved ranges are a good idea I will just have to lookup all the ip ranges for privately assigned addresses, and start from there. Either way i'm going to submit this idea as a bug, and see if he will add an "ANY" checkbox for ICMP so this doesn't slip out anymore. |
actions · 2002-Mar-15 10:41 pm · (locked) |
gwionwild colonial boy
join:2000-12-28 Pittsburgh, PA
|
to BlitzenZeus
Well, Kerio trumps my router in all regards. If this is a flaw, I don't mind. Those weren't just ICMP's, that was a blend of malformed ICMP and protocol type 4 all with spoofed sourcings... and I sort of LIKE being notified on that stuff, personally... Got a lot of prompts from my deny ICMP and so forth rules, too, it was fast and furious... it was almost like opening a browser bomb, for me, in fact, because of all the alerts I have set... but really, this isn't of any concern to me. It's just a lot of good information to know about the firewall, but it's decidedly not a vulnerability of any kind; in a way, it's the precise opposite. The attacks are ICMP with no type or code, so they didn't match anything. Some were protocol 4 packets. This was a concerted, half decent attack. But the firewall passed. That's plenty, for me. No way in hell I'm allowing that stuff, on my worst day ... this is good to be aware of. But it is in no way a bug, in the real sense of the word... if anything, this firewall scores bonus points for detecting and prompting on "unknown packet types"... which probably slip through some versions of some firewalls. Good information point, but not a vulnerability, just FYI. It handles malformed ICMP by dropping it through, apparently... the scan was done before I finished denying. Those lil buggers timed out, anyhow, before they were even seen. Now, I have to take the IP forward off of my router... I trust DSLR... it's those other sods I worry about... PS- and with my anti-spoof rules active, alert disabled??? NOTHING - it was a spoofed 192.168 address; of course, the deny for that whole subnet took it out silently and thoroughly. By the way, blitzenZeus, look at the FAQ ruleset... they're there ... |
actions · 2002-Mar-15 11:51 pm · (locked) |
geico$ join:2002-02-26 Honolulu, HI
|
to BlitzenZeus
Funny i just checked my Deny rules & as TheWiseGuy mentioned & nothing in the Action part was checked. Those rules are still working though because when i get scanned it does show that they do get blocked correctly, thats a relief BlitzenZeus , I noticed that awhile back with the ICMP types also. Kerio only shows 40 ICMP types out of a possiable 255. It would be nice if they added all 255 of them so they would all show up in the ICMP rule & so you dont get just null. They do get blocked anyways & thats the most important thing. [text was edited by author 2002-03-15 23:56:51] |
actions · 2002-Mar-15 11:54 pm · (locked) |
BlitzenZeusBurnt Out Cynic Premium Member join:2000-01-13 |
Even though there are 255 types, only 40 types are assigned right now. |
actions · 2002-Mar-15 11:56 pm · (locked) |
gwionwild colonial boy
join:2000-12-28 Pittsburgh, PA
|
to BlitzenZeus
It would be nice if they had a block so you could put in the codes, if desired... now that, I would consider a one of a kind feature in this class... but, then again, I think Kerio/Tiny are already sporting several one of a kind features, in their class ... so, I figure we have a job here just getting comfortable with what we have. So, let's get to it ... it's a good firewall, as far as inbound protection. And it handles itself pretty well, not allowing the packets it can't clearly identify, either... and prompting when in doubt. PS- a trailing block any, for people satisfied with the completeness of their rulesets, would, no doubt, kill all those alerts... but... how often do you get to see the old pinball machine light up like this??? |
actions · 2002-Mar-16 12:07 am · (locked) |
geico$ join:2002-02-26 Honolulu, HI |
to BlitzenZeus
So BlitzenZeus its impossiable for anyone then to send anything over the 40? I guess im not very familar with these malformed packets & the way they work. Ill have to do some searches & see what i can learn |
actions · 2002-Mar-16 12:14 am · (locked) |
BlitzenZeusBurnt Out Cynic Premium Member join:2000-01-13 |
to gwion
Gwion, I'm still a AtGuard user at heart, and this is what I was used to... I miss my 'any' setting, and found it very useful since it didn't let this stuff past while marking it 'unknown icmp'. |
actions · 2002-Mar-16 12:40 am · (locked) |
|
Blitz, I went in and check all the protocols for ICMP, set it to block both directions.
Try that one and see what it does for you. |
actions · 2002-Mar-16 1:00 am · (locked) |
BlitzenZeusBurnt Out Cynic Premium Member join:2000-01-13 |
PLEASE read the previous comments, this was already covered. |
actions · 2002-Mar-16 1:08 am · (locked) |
|
Sorry. My bad.
But I have replicated the warnings you have in the previous posts. I'll keep up with the going ons while this problem tries to get resolved. |
actions · 2002-Mar-16 1:16 am · (locked) |
BlitzenZeusBurnt Out Cynic Premium Member join:2000-01-13 |
The only problem here is we can only block it automatically by using a 'any' protocol block rule, blocking the addresses they are coming/spoofed from, or use the 'Deny Unknown' security setting. We should not see this used against us unless they are trying to use exploits against our system, and that is why this probably hasn't been a big issue before. A simple "any" setting will fix |
actions · 2002-Mar-16 1:28 am · (locked) |
gwionwild colonial boy
join:2000-12-28 Pittsburgh, PA |
to BlitzenZeus
Not a problem.
Nothing is getting through.
It's merely not matching a malformed ICMP because there's no ICMP type match to "malformed". It's passing the protocol 4's and protocol 41's down because there's no "deny any" in the ruleset that covers them. The spoof rules, in mine, do. So would a trailing any. And the firewall denies whatever you don't click permit for. THERE IS NO BUG . NOTHING IS INHERENTLY INSECURE IN THIS BEHAVIOR WHATSOEVER, NADA... BUGGER ALL... ZIP! It's a great indformation post, but that's it. This isn't an insecurity. It leaves the alert up untl you acknowledge it so you can makke a rule. The packets time out before you can machine gun click through to the next retry on the same trick.
If this would be an issue on a certain system, use anti-spoofing rules and / or trail the rule set with block any, both ways, log and noalert. |
actions · 2002-Mar-16 1:48 am · (locked) |
BlitzenZeusBurnt Out Cynic Premium Member join:2000-01-13
|
Well I finally got around to adding those rules for the private ip ranges, and letting out the communications that use those port ranges before they are implicitly blocked. This is extreme overkill, but I think I will make this part of my future rulesets. Thanks Gwion I never said that they were not being dropped/blocked correctly, just not identified correctly to match a specific situation in a normal rule From my first message:"As you can see I had to activate my Block Inbound rule since I was getting prompted for these malformed icmp packets"The fact is unless you block where they were coming from, or blocked all protocols inbound at the end of your ruleset somehow you just have to deal with the pop-up. That's it... I just don't want to see the pop-up |
actions · 2002-Mar-16 2:09 am · (locked) |
gwionwild colonial boy
join:2000-12-28 Pittsburgh, PA |
to BlitzenZeus
By the way, thanks for the reminder. PC flank isn't a bad link to have around if you need a self scan - very thorough. If you can pass every single test here, you're probably in the 90th plus percintile of internet users for security level... they aren't your run of the mill FUD factory buy-our-firewall scan with "stupid java tricks." It really did toss some good stuff out... odds most of us will get hit by some of this stuff are slim. But it's nice to know you're prepared. |
actions · 2002-Mar-16 3:29 am · (locked) |
|
to BlitzenZeus
Does this work ? Protocol - Other Type 1 - Both
I can't test it since logging on my system seems to get messes up by ICS. |
actions · 2002-Mar-16 8:26 am · (locked) |
BlitzenZeusBurnt Out Cynic Premium Member join:2000-01-13 |
You have taken the approach I didn't even consider, and it does work! I'm replacing my block all rule with this as it actually does the job.... Thanks for the idea |
actions · 2002-Mar-16 9:37 am · (locked) |
|
Glad I could help, especially after my first post which was one of those where I say to myself later, come on, try to at least understand the question, before you answer a post. |
actions · 2002-Mar-16 9:43 am · (locked) |
Sunriser13 Premium Member join:2001-12-16 Umm... here?
|
to BlitzenZeus
Not trying to hijack here, but this does bring me to a question that never got answered in another post of mine. Is there a list somewhere of just what the protocol numbers are and what they do? My previous question had to do with IGMP (which I still don't completely understand), because Kerio's default rule on IGMP has number 2 listed with "Other". According to this list - » www.spirit.com/Resources ··· cmp.html , both 1 & 2 are "Unassigned" (as well as 7), so I am still not sure what they prevent or allow. I have just learned with this thread (Thanks, y'all! )that the "Other" setting can encompass ICMP as well, so I figure I need to learn how to use it. I'm sure the information is contained here somewhere - » www.landfield.com/rfcs/r ··· les.html - but I have no idea exactly what I'm looking for. Would you be so kind as to enlighten me? |
actions · 2002-Mar-16 10:35 am · (locked) |
BlitzenZeusBurnt Out Cynic Premium Member join:2000-01-13 |
This information will probably read like Greek, but normally you can't refer to a protocol by its number. » www.iana.org/assignments ··· -numbers |
actions · 2002-Mar-16 10:52 am · (locked) |
Sunriser13 Premium Member join:2001-12-16 Umm... here?
|
OK, so I was confused in my understanding of this to begin with. According to this, "Other, 2" IS IGMP. "Other, 1" IS ICMP. So for example, if I wished to block all TCP with this rule, I could technically do it with "Other, 6", although this is of course already provided for. (Am I getting it now?) Can each of these numbers be used in the "Other" rule? |
actions · 2002-Mar-16 11:05 am · (locked) |
BlitzenZeusBurnt Out Cynic Premium Member join:2000-01-13 |
Yes you could block all tcp with Other-6, or even UDP with Other-17. You just don't have any more control other than allow, or block to certain remote addresses.... |
actions · 2002-Mar-16 11:10 am · (locked) |