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:
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 | |
|
