how-to block ads
|
|
Share Topic
 |
 |
|
|
|
TheWiseGuyDog And ButterflyPremium,MVM
join:2002-07-04
Yonkers, NY
kudos:1 Reviews:
 ·Optimum Online
| reply to KachiWachi
Re: Westell 2200 Firewall Rule Explanation Needed said by KachiWachi:
Am I correct in the fact that since all ICMP protocols are being dropped inbound with that rule, that I should get no response from a ping?
Yes, Ping is simply an ICMP type 8 from the sender and ICMP type 0 for the reply. So if the drop protocol icmp was active you wouldn't respond to a Ping.
The problem is what do they mean by
said by help:
done Specifies that the filtering engine should stop checking any subsequent rules should this rule match. This action provides a mechanism to optimize the decision tree implemented by the filtering engine.
and
quote:
Once the packet filter engine finds a match for a rule it will note the filter action to be taken (pass or drop) and continue to compare the following rules with the given packet unless otherwise instructed (see the description of the done action in section 3.2.1.2.3).
What happens in a case such as this is not really stated. The action is noted but unless there is a done the engine keeps looking but what happens when it finds another rule? All it says is that Done will optimize the decision making tree. I'm not sure that means that if it finds another rule it will substitute the new setting. The Ping test seems to indicate that it won't but the question becomes why does it continue down the tree. It can be very hard to know exactly what will happen without fully testing a firewall when they don't explicitly state exactly how the rules are evaluated.
Unfortunately the documentation is not written properly to allow a user to easily understand how the firewall works, take the ALL statement. quote:
all Specifies all packets. If the all condition is specified in a rule, all other conditions are ignored.
Does this mean once an All is hit, no other conditions below it apply. Does it mean no conditions above it apply, if a done has not been encountered? Maybe what the done is for is to allow a filter rule of ALL at the bottom and allow other statements above to still be used. Without full testing it is hard to be sure.
--
Dog and Butterfly | |
| OK...I was playing this morning with the "Custom" setting.
As for background color (Severity):
4 is Red.
3 is Orange.
2 is Yellow.
1 is Light Yellow.
0 is Clear (No color).
For the Inbound Rule set, I moved the "Rules, pass all" to the end. For clarity, I added a new Rule Name "Protocol" for the three protocol rules. AddressDrop remained the same (though I added an extra "s").
On the Outbound side, I moved the Rule name "Rules" to above the "pass all" statement, and created a new name "DropNetBIOS" for that statement.
At GRC, I just ran a single port test. GRC said I still responded to the ping test, but the firewall log shows this :
Log Time Intfc Dir Sv Rule Alert
--------------------------------------------------------------------------
1 10:23:44 mirror0 IN 4 Protocol ICMP Message To WAN IP
IP Packet Header:
Src Addr : 204.1.226.228 Dest Addr: 151.199.xxx.xxx
ICMP Packet Header:
Type: 0 (Echo Reply) Code: 137
So it recognized the new Rule Name  , but it did not seem to stop the ping  . Perhaps TheWiseGuy is right in saying that pass all does just that, no matter where it is located.
I'm going to add a done after the ping now and see what happens.
--
CPU - DFI 586IPVG, Cyrix MII 433, K6-2/+ 450, i430VX, 128MB EDO.
BIOS patched by BiosMan.
VOL (ex-BA) 768/128, Westell 2200. | |
| OK...when I added the "done" to the ICMP statement, the ping was stealthed.
Just for fun, I moved the "pass all" to the beginning. The ping was still stealthed.
So this seems to indicate that the "done" does override the "all" command.
(Light bulb goes off!!) I just realized that the idea here was to just get the ping message into the log, but to allow it to pass...hence Low Security. It was written that way to let you know you were pinged, hence the alert text "ICPM Message"!!
So now what would be the proper place for the "pass all"...if it is even needed...beginning, or end? I'm thinking at the end, just comparing it to the other rule sets, and following the strategy that IF [statment], then "done", ELSE "pass all".
As for the port 53, again...why the "to" and "from" statements, and what is the drop address IP 0.0.0.0 for?
--
CPU - DFI 586IPVG, Cyrix MII 433, K6-2/+ 450, i430VX, 128MB EDO.
BIOS patched by BiosMan.
VOL (ex-BA) 768/128, Westell 2200. | | |
|
| Hmmm...no reply...
I will wait a bit more, then move on to the Medium Rules, which Westell says should be the default setting, though VOL has this set to none. | |
TheWiseGuyDog And ButterflyPremium,MVM
join:2002-07-04
Yonkers, NY
kudos:1 Reviews:
·Optimum Online
| reply to KachiWachi
said by KachiWachi:
Just for fun, I moved the "pass all" to the beginning. The ping was still stealthed.
So it doesn't seem to matter where the "pass all" is in relationship to the done, since the done seems to overrule all.
quote:
(Light bulb goes off!!) I just realized that the idea here was to just get the ping message into the log, but to allow it to pass...hence Low Security. It was written that way to let you know you were pinged, hence the alert text "ICPM Message"!!
Good observation, makes sense to me.
quote:
As for the port 53, again...why the "to" and "from" statements, and what is the drop address IP 0.0.0.0 for?
Port 53 is DNS. Hard-wiring DNS IN from port 53 in case someone changes things makes sense. DNS IN to port 53 would only be if you were running a DNS server. I don't know the logic behind this one.
0.0.0.0 is the IP that a PC would use when it first comes on line to get an IP via DHCP. I don't know if VOL uses DHCP, if it did this would prevent you from seeing other users DHCP broadcasts if they were passed downstream. I'm not sure of any other reasons why it might be there.
--
Dog and Butterfly | |
| OK...
I've been experimenting, but I will hold off on going into that for one more post.
My question for port 53 was why both a "to" and "from" statement in the "Inbound" rule set. Wouldn't one be meant for the "Outbound" rule set (the "to" statement?), which is what you seem to indicate? Currently, I only see "from" statements in the log (I modified the current statement to make a log entry for each, where it did not display one before). And what did you mean by "someone changes things"?
For 0.0.0.0, I believe that VOL uses DHCP, because if I log out/turn off the modem, I get a new address on the next login/powerup. So you are saying that the 0.0.0.0 is broadcast out, then VOL sends back a DHCP address for me to use. I guess I could write a rule to display that in the log (pass from addr 0.0.0.0), but as that rule stands now, I don't see a message coming up in the log anyway, so I'm not sure what is going on with that. Maybe VOL blocks this at VOL, and the modem just comes with this statement as default (it is in all 3 rule sets).
Might this 0.0.0.0 be passed on if you connect another computer in an internal network? After all, this thing is also a router, so with a switch behind it, you could add more computers and create a "home network"...
--
CPU - DFI 586IPVG, Cyrix MII 433, K6-2/+ 450, i430VX, 128MB EDO.
BIOS patched by BiosMan.
VOL (ex-BA) 768/128, Westell 2200. | |
TheWiseGuyDog And ButterflyPremium,MVM
join:2002-07-04
Yonkers, NY
kudos:1 Reviews:
·Optimum Online
1 edit | said by KachiWachi:
OK...
I've been experimenting, but I will hold off on going into that for one more post.
My question for port 53 was why both a "to" and "from" statement in the "Inbound" rule set. Wouldn't one be meant for the "Outbound" rule set (the "to" statement?), which is what you seem to indicate? Currently, I only see "from" statements in the log (I modified the current statement to make a log entry for each, where it did not display one before). And what did you mean by "someone changes things"?
Ok Inbound from port 53 would look at the the port on the computer that sent the packet(the Source Port). You see these in the logs because you send Outbound packets to Port 53 on the DNS server, anytime you resolve a url to an IP. The DNS server then replies with an Inbound packet from Port 53 with the IP that corresponds to that url.
Inbound To port 53 would be sent from another computer but the firewall would look at the port it was intended for on your computer (the Destination port). So it would be Port 53 on your computer but the packet would still be inbound. So you use TO for the Destination Port of a packet and a FROM for the Source port of a packet.
If you think of TO as the Destination Port and From as the Source Port of each packet it will help you understand it for the outbound rules. There the From port is on your computer and the TO port is on the destination computer, this is the exact opposite of the Inbound directions.
By changing things I mean if you commented out the Pass All rule, you would have changed things.
quote:
For 0.0.0.0, I believe that VOL uses DHCP, because if I log out/turn off the modem, I get a new address on the next login/powerup. So you are saying that the 0.0.0.0 is broadcast out, then VOL sends back a DHCP address for me to use. I guess I could write a rule to display that in the log (pass from addr 0.0.0.0), but as that rule stands now, I don't see a message coming up in the log anyway, so I'm not sure what is going on with that. Maybe VOL blocks this at VOL, and the modem just comes with this statement as default (it is in all 3 rule sets).
Might this 0.0.0.0 be passed on if you connect another computer in an internal network? After all, this thing is also a router, so with a switch behind it, you could add more computers and create a "home network"...
If your VOL is DHCP and the Westell is acting as a router what occurs is that the Westell, when initially connecting, won't have an IP and will send a packet outbound with a source address of 0.0.0.0 to the broadcast address of 255.255.255.255. The reply to you, will come from an IP address of a DHCP server. Now technically what a broadcast means is that a packet is being sent to all addresses on the subnet but the verizon gateway probably should not pass these Broadcasts back Downstream to all the routers on the Subnet since it should probably act as a DHCP relay. If it did send the packets back downstream then you would see packets with a source address of 0.0.0.0 and see DHCP discovery packets from all the other users on the subnet, in addition to your own routers DHCP discovery that would be passed back downstream. So you really shouldn't see packets Inbound with a source address of 0.0.0.0, if you did they would have initially been Outbound packets from your router or other usres on your subnet.
If you added a computer it would do DHCP by sending outbound packets to 255.255.255.255 and the routers DHCP server would reply so there should still be no Inbound packets from 0.0.0.0 coming from the Internet. The router also would not forward the outbound packets to the Internet.
--
Dog and Butterfly | |
| OK...
I get the To/From Destination/Source thing . So it appears that unless I'm running a DNS server (why would I do that?), I should never see a "to port 53" show up in my logs, so that rule essentially is meaningless.
Same goes for the "drop address 0.0.0.0".
-- I'm wondering if other firewalls have similar default rules or not...just to compare with what Westell is doing.
OK...moving on now... 
What I did next was to substitute the Level 2 Rules for my Inbound "screening", leaving the Level 1 Outbound Rules in place. The only thing I did was to add alert messages to the statements that had none, color coordinated them so they would stand out in the log, and added some extra "Rule Names" to differentiate the steps better in the log.
title [ Security Level 2 IN rules ]
begin
TTLDrop
drop match 3 8 { 01:FE } >> alert 4 [TTL of 0 or 1]
AddressDrop
drop from addr 0.0.0.0 >> done, alert 4 [0.0.0.0 Source IP Address]
PassUDP
pass protocol udp, to port 53 >> done, alert 2 [Pass to port 53]
pass protocol udp, from port 53 >> done, alert 1 [Pass from port 53]
ICMPDrop
pass icmp-type reply >> done, alert 3 [Pass ICMP Type 0]
pass icmp-type unreachable >> done, alert 3 [Pass ICMP Type 3]
pass icmp-type exceeded >> done, alert 3 [Pass ICMP Type 11]
drop protocol icmp >> done, alert 4 [Invalid ICMP Type]
Rules
pass all
Doing so adds the TTLDrop ("message only" as there is no done) in the logfile (which was previously discussed briefly), and adds the four ICMP rules.
I think I understand this to be that I should be able to receive 3 responses from a ping that I send out (Types 0, 3, and 11 as previously discussed briefly), but to drop all other types. This seems to allow me to become "stealth" on the Internet (I can't be pinged, or rather I don't respond to that attempt).
I've only seen the ICMP "alert 4" message in my logfile so far, but not the other three. Nor have I seen the TTLDrop and AddressDrop messages either.
On a side note I see this in the log a lot -
IN 0 PRIOR_DropToWANUDP UDP WAN Traffic to WAN IP
Inbound rule, Severity zero, Rule "PRIOR_DropToWANUDP", with the message "UDP WAN Traffic to WAN IP".
What does this mean, and where is this rule set?? Is this coming from the NAT part of the Westell??
--
CPU - DFI 586IPVG, Cyrix MII 433, K6-2/+ 450, i430VX, 128MB EDO.
BIOS patched by BiosMan.
VOL (ex-BA) 768/128, Westell 2200. | |
TheWiseGuyDog And ButterflyPremium,MVM
join:2002-07-04
Yonkers, NY
kudos:1 Reviews:
·Optimum Online
| said by KachiWachi:
I think I understand this to be that I should be able to receive 3 responses from a ping that I send out (Types 0, 3, and 11 as previously discussed briefly), but to drop all other types. This seems to allow me to become "stealth" on the Internet (I can't be pinged, or rather I don't respond to that attempt).
Type 0 Inbound - allows you to ping someone else.
Type 11 Inbound - allows you to run tracert correctly.
Type 3 Inbound - allows you to receive an error message if a packet you sent can not reach its destination
quote:
IN 0 PRIOR_DropToWANUDP UDP WAN Traffic to WAN IP
Inbound rule, Severity zero, Rule "PRIOR_DropToWANUDP", with the message "UDP WAN Traffic to WAN IP".
What does this mean, and where is this rule set?? Is this coming from the NAT part of the Westell??
Sorry I don't know.
--
Dog and Butterfly | |
| OK...
Just to complete the Inbound Rule Sets, Level 3 (High Security)...
Adds a done to the TTLDrop statement. I'm guessing the addition of the done will not allow my machine to respond with the ICMP Type 11 (Time Expired), which would allow the sending machine to know my IP address. (Without the done, it will respond, but also let me know it did by placing the message in the log file.)
AddresDrop remains the same as in Level 2, but only allows UDP "from port 53". (It removes the "to port 53" statement, which we thought was questionable anyway...)
Next comes a "drop all", which I assume drops all other packets.
Refining that comes in the next section, PassService, which allows only Mail, News, Web, FTP, and IPSEC (11 specific ports).
Once there are no more comments here, I will move onto the Outbound Rule Sets 2 and 3, since these seem to affect how I communicate with the world more than the Inbound Rules do...as far as IM programs, etc...
Thanks again TheWiseGuy for continuing to reply to this thread.
--
CPU - DFI 586IPVG, Cyrix MII 433, K6-2/+ 450, i430VX, 128MB EDO.
BIOS patched by BiosMan.
VOL (ex-BA) 768/128, Westell 2200. | |
TheWiseGuyDog And ButterflyPremium,MVM
join:2002-07-04
Yonkers, NY
kudos:1 Reviews:
·Optimum Online
| said by KachiWachi:
OK...
Just to complete the Inbound Rule Sets, Level 3 (High Security)...
Adds a done to the TTLDrop statement. I'm guessing the addition of the done will not allow my machine to respond with the ICMP Type 11 (Time Expired), which would allow the sending machine to know my IP address. (Without the done, it will respond, but also let me know it did by placing the message in the log file.)
You have it right, but from a technical standpoint I believe it is keeping the router from sending the ICMP type 11, if the packet actually reached your computer it would not need to send out the ICMP type 11 since it has reached its destination. The sending machine already knows your public router IP.
This brings up an interesting question, should the router send out a ICMP type 11 even if the TTL is 1 and it reduces it to zero, since it has already reached the IP specified as the destination IP in the packet. Yet the router needs to forward this packet into the private network and again technically it should not forward it with a TTL of zero. Some home routers don't decrease the TTL so maybe this is the reason they don't, to avoid this exact dilemma.
--
Dog and Butterfly | |
| Is there a way to test this?? | |
TheWiseGuyDog And ButterflyPremium,MVM
join:2002-07-04
Yonkers, NY
kudos:1 Reviews:
·Optimum Online
| You can test if the Westell reduces the TTL by doing a tracert outbound. If it the IP of the Westell (normally a private IP like 192.168.1.1) shows up in the tracert it decrements the TTL,(at least outbound) if it doesn't show up, the Westell doesn't decrement the TTL. You can try a tracert IN and also see what responses you get but you really can't learn much with that unless you have set up NAT to forward all packets to one machine. If you did set up NAT this way you might be able to run some tests, but I really would need to think this through completely as to how it would work.
--
Dog and Butterfly | |
|
