how-to block ads
|
|
Uniqs:
15121 |
Share Topic
 |
 |
|
|
|
| Westell 2200 Firewall Rule Explanation Needed I'm trying to understand the default Firewall Rules for my VOL/Westell 2200.
Below are the Inbound and Outbound Rules provided for Low(1), Medium(2), and High(3) Security. This is exactly how they are written...I did not parse them to make them more readable (I don't think that matters to the "decision engine", though I understand that order does).
I can see that as you go up in security level, more conditions need to be met for traffic to pass, both in and out. I do not understand TTLDrop. It also seems they have added command "names", but for some they did not specify a parameter before they added the next "name". I get the general idea, but I think some of the code was written "sloppy" in that some items seem out of order (does that matter...IE:"Rules" item?).
Could someone go over them in more detail and explain what is going on? The Westell manual and help file really do not explain things very well. Thanks.
Inbound Rules
title [ Security Level 1 IN rules ]
begin
Rules
pass all
AddresDrop
drop from addr 0.0.0.0 >> done, alert 4 [ 0.0.0.0 Source IP Address]
pass protocol udp, to port 53 >> done
pass protocol udp, from port 53 >> done
drop protocol icmp >> alert 4 [ICMP Message To WAN IP]
end
title [ Security Level 2 IN rules ]
begin
TTLDrop
drop match 3 8 { 01:FE } >> alert 4 [TTL of 0 or 1]
AddresDrop
drop from addr 0.0.0.0 >> done, alert 4 [ 0.0.0.0 Source IP Address]
pass protocol udp, to port 53 >> done
pass protocol udp, from port 53 >> done
pass icmp-type reply >> done
pass icmp-type unreachable >> done
pass icmp-type exceeded >> done
drop protocol icmp >> done, alert 4 [ Invalid ICMP Type ]
Rules
pass all
end
title [ Security Level 3 IN rules ]
begin
TTLDrop
drop match 3 8 { 01:FE } >> done, alert 4 [TTL of 0 or 1]
AddresDrop
drop from addr 0.0.0.0 >> done, alert 4 [ 0.0.0.0 Source IP Address]
pass protocol udp, from port 53 >> done
drop all
PassService
pass from port 80
pass to port 80
pass from port 20
pass to port 20
pass from port 21
pass from port 110
pass from port 119
pass from port 143
pass from port 220
pass from port 25
pass from port 443
pass from port 500
pass protocol 50
end
Outbound Rules
title [ Security Level 1 OUT rules ]
begin
Rules
drop to port >= 135, to port > done, alert 4 [Dropping NETBIOS Traffic]
pass all
end
title [ Security Level Medium OUT rules ]
begin
# Protocol Match conditions
DropAddr
PassPacket
pass to port 80 >> done
pass from port 80 >> done
pass protocol udp, to port 53 >> done
pass to port 20 >> done
pass from port 20 >> done
pass to port 21 >> done
pass to port 110 >> done
pass to port 119 >> done
pass to port 143 >> done
pass to port 220 >> done
pass to port 25 >> done
pass to port 443 >> done
pass to port 500 >> done
pass protocol 50 >> done
# Failed to match
DropPacket
drop to port >= 135, to port > done, alert 4 [Dropping NETBIOS Traffic]
drop all >> alert 1 [ Packet to be dropped unless Service enabled ]
end
title [ Security Level High OUT rules ]
begin
# Protocol Match conditions
DropAddr
PassPacket
pass to port 80 >> done
pass from port 80 >> done
pass protocol udp, to port 53 >> done
pass to port 20 >> done
pass from port 20 >> done
pass to port 21 >> done
pass to port 110 >> done
pass to port 119 >> done
pass to port 143 >> done
pass to port 220 >> done
pass to port 25 >> done
pass to port 443 >> done
pass to port 500 >> done
pass protocol 50 >> done
# Failed to match
DropPacket
drop all >> done, alert 4 [Unsupported High Application]
end
--
CPU - DFI 586IPVG, Cyrix MII 433, K6-2/+ 450, i430VX, 128MB EDO.
BIOS patched by BiosMan.
VOL (ex-BA) 768/128, Westell 2200. | |
 gwionwild colonial boyPremium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1 | This is interesting. I'm not familiar with this packet filter, because I haven't seen the new Westells, but the syntax looks a lot like IPFilter or IPchains at a quick glance. I wonder, can anyone give a few details on what, exactly, the firewall component on the Westell is based on? I'm genuinely curious. I didn't realize it was as comprehensive or configurable as this seems to imply... if it is, we might want to discuss this in some detail, since a lot of users (it's Verizon's "standard issue" modem) will have this on their gateways... I'll take a closer look, a little later... if this really is similar to IPF, I have several old rulesets we could analogize and extrapolate and try adapting... 
--
Semper Eadem
"The seas shall rise up in the twinkling of an eye, and the dust of the ancients shall be restored. The winds shall fight together with a dreadful blast, and their sound shall reach the stars." | |
1 edit | Besides those three, there is also a "None" setting with no rules present (basically pass everything), and a "Custom" setting for which you can write whatever you want and save.
Right now I use "Low", since I haven't been able to get things to work at the "Medium" setting, which is Westell's default, but not VOL's (theirs is "None"). I have no ports forwarded, as it doesn't seem to matter for what I am doing at present...though if I do forward them, the grc.com test does show them as "closed" and not "stealth".
What I don't understand is how to open ports from the "inside" to allow certain programs to work. I'm guessing that I would have to write a "custom" firewall profile for that...correct??
Here are some things from their FAQ -
What services are allowed for each security level in the Firewall?
High - This security level only allows basic Internet functionality. Only Mail, News, Web, FTP, and IPSEC are allowed. No other traffic is allowed. Another restriction of high security is that it can't be modified by NAT configuration options. With High security, you are guaranteed to only pass the previously mentioned traffic.
Medium - This security level only allows basic Internet functionality by default. Like High security, Medium security allows customization through NAT configuration, so you can enable the traffic that you want to pass.
Low - The Low security setting will allow all traffic except for known attacks. With Low security, your Router is visible by other computers on the Internet.
Custom - Custom is a very advanced configuration option that allows you to edit the firewall configuration directly. Only the most expert users should attempt this.
Does changing the security level of the Firewall change the level of security of what the outside world or Internet can see?
No, the security level only affects the outbound traffic from within your own LAN. The Service Configuration (port forwarding) is what affects inbound traffic from outside your LAN (the Internet).
What is port forwarding?
It forwards a service through the router to a computer on the LAN. This allow users outside your LAN to access specific computers on your internal network. Typically ports need to be opened for games or special applications such as VPN.
Can the ports be configured on this router?
Yes. The individual ports can be configured for specific services. (i.e. Telnet, FTP, gaming).
What is the Service Configuration menu needed for?
The Service Configuration menu is used to open ports (port forwarding). This will allow inbound unsolicited services (from the Internet) such as Telnet, Webserver, NetMeeting and other programs that require ports to be opened, through the router.
How is a Service or Port added for my specific program?
* Select your NAT profile. If you don't need different NAT profiles setup then choose the Default profile for your account.
* From the Service drop-down menu, select your desired service that want to enable to work through your router.
* Click Enable and OK. This will add the specified service to your list of available that will work through your router.
* Repeat this process until all services or ports are entered that you wish to use.
What if the service I want to add isn't in the list of available services?
* Click the Advanced Configuration link under the Services drop-down menu and choose Custom Service.
* Choose "Port Forwarding Ranges of Ports" and click Next.
* Type the name of the service you want to add; i.e., NetMeeting, PcAnywhere, etc.
* Enter the IP address for the PC that you wish to use the specific service on that is located on your LAN or network.
* Enter the range of ports that you wish to use.
* Select TCP or UDP for the protocol. Your program manufacturer will determine this.
* Click the Next button and the new custom service will show up in your service list.
| |
2 edits | Here is the Help file that the 2200 provides (please excuse the formatting) -
Packet Filtering Firewall User Manual
File/Buffer Format
The RDL file or buffer format is divided into two sections. The
first portion of the file defines any number of keys and associated
values. The second portion contains the filtering rule
definitions.
Key Definition Section
A key definition consists of the key followed by the associated
value. A value is actually a character string. The string is
delimited by the open and close square brackets. An example of a
keyword definition would look like the following.
title [ High security RDL file ] The packet filter engine does not use keys. They are intended to
provide information associated with the file. The user interface
treats the key definition and value pairs as standard text.
Rules Section
The rules section of the RDL file or buffer is delimited by the
begin an end keywords. The rules listed between these
delimiters are parsed and converted to a decision tree data
structure used by the packet filter engine. The rules listed are
implemented sequentially as listed in the RDL source. 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).
Rule Names
RDL rules may be given names. The packet logging facility and the
user interface uses these rule names. A name applies to all rules
following its declaration in the Rules Section until another name is
declared or the end statement. An identifier (one or more
alphanumeric characters beginning with an alpha character) on a line
by itself declares a new name for the following rule(s).
RDL Comments
Comments begin with the # character. The parser ignores
all characters following the comment character to the end of the
line.
RDL Command Syntax
An RDL command consists of a filter keyword followed by a
condition expression optionally followed by one or more action
keywords.
Filter Condition [, Condition2, ] [
>> Action, Action2, ] The filter keyword specifies if the packet will be passed or
dropped. The condition defines the portion of the packet and the bit
string to which it will be compared. The action keyword may specify
additional action(s) to be taken.
Filter Keywords
The RDL filter token may be either passed or dropped.
pass Specifies that the matching
packet is to be passed onto the associated interface or the SENS
MUX.
drop Specifies that the matching
packet will not be forwarded to the associated interface or the
SENS MUX. Condition Keywords
The condition expression determines if the rule is a match for
the given packet.
all Specifies all packets. If the all
condition is specified in a rule, all other conditions are
ignored.
match layer offset
{bit-string[:mask]} Specifies one or
more explicit bit strings and offsets into the layer header to
compare. This keyword is followed by three parameters. The first
numeric parameter is the header layer, valid values include 2
though 4 (Ethernet = 2, ip = 3, tcp/udp/icmp/igmp = 4). The second
numeric parameter is the offset into the packet to begin the
comparison. T and the third third parameter, is the representation
of the bit string and comparision bit maskitself. The bit stringIt
is delimited with the open and close curly braces ({}). A colon
delimits the bit string and mask. If no mask is provided, a mask
value of all ones is assumed. Each byte of the bit string and mask
is represented by a two character hexadecimal number and is
separated by white space from the previous byte
representation.
from | to [addr ip-addr/:mask] | [port port_n
|port >= port_n | port >= port_n]
Specifies particular fields (IP address or
TCP/UDP port number) of the IP header. The from keyword
designates the source fields, and the to keyword designates
the destination fields. One or more "A" descriptors of the
fields and their its contents then follows the keyword. A list of
descriptors is to be separated by colon(s). These field
descriptors include addr (IP address), mask (network mask), and
port (TCP or UDP port number).
addr Specifies the source or
destination IP address field and comparison mask. This keyword
is followed by a IP address in dotted-decimal notation and mask
separated by a forward slash. The mask is a number from 1 to 32
and it signifies how many bits of the IP address are compared.
If no mask is provided, a mask value of 32 is assumed.
port Specifies the source or
destination UDP/TCP port number. This keyword is followed by the
16 bit port number represented hexadecimal or decimal format.
Using the >= or >= operators allows for matching on ranges
of ports. protocol tcp | udp | icmp | igmp |
value Specifies the value of the
protocol field found in the IP header. It is followed by a
parameter that specifies the protocol value. There are built in
keywords for the TCP, UDP, ICMP, and IGMP protocols. If a
different protocol value is required, it may be represented by a
decimal or hexadecimal value between 0 and 255.
tcp Specifies the TCP protocol.
udp Specifies the UDP protocol.
icmp Specifies the ICMP protocol.
igmp Specifies the IGMP
protocol. flags urg | ::ack | :: psh | ::rst | ::syn | ::fin
Specifies some combination of the flag bits
found in the TCP header. The parameters following the keyword
should be represented in a colon delimited list.
igmp-type query |
report Specifies the IGMP packet type
found in the IGMP header. The report type checks for both
version 1 and version 2 type codes. No check is made by the parser
to verify that the IGMP protocol is specified. So it is up to the
user to include the protocol igmp condition in a rule using
the igmp-type condition.
icmp-type request |
reply Specifies the ICMP packet type
found in the ICMP header. No check is made by the parser to verify
that the ICMP protocol is specified. So it is up to the user to
include the protocol icmp condition in a rule using the
icmp-type condition. Action keywords
Specifies any further action to be taken upon a match between the
rule condition and the packet content.
log level Specifies
that the contents of any matching packet header should be recorded
in the log table. The level parameter is a mechanism to
indicate the source of the log entry. This value rule name is
stored with each log entry resulting from this rule. The log may
subsequently be searched or sorted by this valuee rule name. Log
entries appear in the table with a default severity of 0. The
level value is represented by a decimal or hexadecimal
value between 0 and 255.
alert severity [Alert
text] Specifies that the contents of any
matching packet header should be recorded oin the log table with
the corresponding severity value and text explanation. Severity is
a decimal number between 0 and 4. The alert text is delimited by
bracketsBrackets delimit the alert text.
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.
state Specifies that the TCP/ICMP/IGMP
session (particularly the sequence number in the case of TCP and
the packet type and source/destination addresses and ports in the
case of ICMP and IGMP) associated with this packet will be added
to the state table maintained by the filtering engine. As long as
that session remains in the state table all packets associated
with that session are passed without comparing them to the rules
decision tree. The filtering enginestate table logic maintains the
state of the session with successive packets and closes or times
it out (removes it from the state table) whenever
appropriate. --
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 | reply to KachiWachi
said by KachiWachi:
I do not understand TTLDrop.
The TTLDrop is designed to drop packets that have a Time To Live of 0 or 1. The syntax says
drop match 3 8 { 01:FE } >> alert 4 [TTL of 0 or 1]
from the documentation, the firewall will look into the packets and start in the IP layer (this is specified by the 3 after match), the first byte in the IP layer would have an offset of 0, so the second parameter which is 8 for the offset into the IP layer, would be the 9th byte in the IP layer. This is the byte where the TTL is placed in an IP layer. The TTL indicates how many hops a packet can go before it should be not be forwarded to the next hop. Each hop should decease the TTL by 1 before forwarding the packet.
The first value in curly braces is the value to be matched, the second is a mask which is used to create a range of values. The mask, assuming it is set up correctly to filter for 0 and 1, I believe is used by looking at the binary representations of the bit-string (in this case 1) and the binary representation of the Mask. If the bit of the mask is 1 then you look at that bit, in both the bit-string and the value in the packet, to see if they match, if the bit of the mask is 0, you don't look at that to see if they match. Since all the bits in FE are 1 except the last bit, and the bit string is all zeros except for the last bit, to match, all the bits would need to be zero except the last, which could be 0 or 1.
--
Dog and Butterfly | |
| Thanks TheWiseGuy for your insight on one aspect of this issue...
I still don't know what the purpose of TTL is though... | |
TheWiseGuyDog And ButterflyPremium,MVM
join:2002-07-04
Yonkers, NY
kudos:1 Reviews:
·Optimum Online
| TTL is used to make sure that packets don't keep bouncing around the Internet forever, and to inform the sending machine that the packets it sent did not arrive at its destination. You can set TTL to different values but it defaults in many windows versions to 32. Each router that forwards the packet should decrease the TTL by one until it reaches 0. When it it reduced from 1 to 0 by a router, that router should return an ICMP type 11 Time Expired telling the sending machine that the packet couldn't reach its destination.
--
Dog and Butterfly | |
| OK...got that now TheWiseGuy.
drop match 3 8 { 01:FE } >> alert 4 [TTL of 0 or 1]
So this rule then will just put an "alert 4" ( [TTL of 0 or 1] in red color if I'm not mistaken) message in my firewall log, telling me that the sent packet did not reach its destination...that simple?
I wonder why this statement isn't present in the "Low" setting then, since it seems that this is just an informational thing... | |
TheWiseGuyDog And ButterflyPremium,MVM
join:2002-07-04
Yonkers, NY
kudos:1 Reviews:
·Optimum Online
| .
If you receive an ICMP type 11 it would mean that a packet did not reach its destination.
This is for Inbound packets, so what it means the firewall drops a packet when it has a TTL of 1 or 0 and prevents an ICMP type 11 from being sent.
I'm not going to get into a discussion of the pros and cons of an Individual host sending or suppressing ICMP error codes, for a full discussion of possible ICMP misuse see
»www.sans.org/resources/idfaq/icmp_misuse.php
--
Dog and Butterfly | |
| OK TheWiseGuy...
I can see this then as a Second Level "security" item, since no ICMP response would be sent. At Level One (Low setting), the 2200 would then send one, which could be interpreted as "less secure".
It is interesting to note that the displayed alert message for the following Inbound rules is different. I wonder why this would be so?
Low - drop protocol icmp >> alert 4 [ICMP Message To WAN IP]
Medium - drop protocol icmp >> done, alert 4 [ Invalid ICMP Type ]
High - none, but uses drop all
Any more insight on the rest of the rules in effect?? | |
TheWiseGuyDog And ButterflyPremium,MVM
join:2002-07-04
Yonkers, NY
kudos:1 Reviews:
·Optimum Online
| Since I've never seen this syntax before I'm not 100% sure of this analysis but here is what I see.
The reason the labels are different is because the 2 rule sets do different things.
Level 1 drops all ICMP Inbound. Therefore the Alert is "ICMP Message To WAN IP"
Level 2 allows ICMP types 0,3,11 Inbound. The Alert makes sense since it allows some ICMP types and denies other types. "Invalid ICMP Type"
The level 1 rule does not make sense for Low security. The level 2 rules make sense for Medium security since they allow error messages to be passed to your computer. Low security should at least allow these also. Allowing "pass icmp-type reply" (ICMP type 0) would make sense if Level 2 outbound allowed ICMP type 8 which it doesn't seem to do. With ICMP type 8 allowed OUT and ICMP type 0 allowed IN, it would enable you to run Ping and tracert. Without ICMP type 8 OUT, allowing ICMP type 0 IN does not make sense.
IMO you were right when you said the rules were sloppy.
--
Dog and Butterfly | | |
|
| Interesting again...
I'm going to try a little explaining myself...I hope someone will comment on if they think I'm right or not. I will do one "Security Setting" at a time, then wait for comment.
Well, two this time... 
Definitions -
Outbound - packets leaving (originating from) my computer.
Inbound - packets attempting to enter my computer.
None Outbound/Inbound - Obviously no firewall rules out or in, however, NAT translation is on, providing some level of security.
Low Outbound -
This script seems to allow all outbound traffic, except for NETBIOS.
1) title - obvious meaning [ Security Level 1 OUT rules ].
2) begin - required to delimitate this sections start.
3) Rules - since this is not defined in the help file as a necessary item, I would think it would default to a "Rule Name" then for our convenience. It will apply to everything that follows, because there is no other "Rule Name" listed.
3a) drop to port >= 135, to port > done, alert 4 [Dropping NETBIOS Traffic] - these 5 ports control NETBIOS traffic, and will not allowed out of the computer. Message [Dropping NETBIOS Traffic] will appear in the firewall log. (Alert 4 is black text with a clear background color...I have only seen clear, yellow, and red backgrounds. I guess severity goes up with lower numbers...IE: Alert 1 will have a red background.) Because of the done, the script will then exit (go to end) if this rule is a match. Otherwise, we go on to the next test.
3b) pass all - just what it says. If no match to part 3a of this "Rule Name", then allow the connection and continue on. Though probably not necessary, it does finalize the action for everything else, so...OK. Proceed to the next test.
4) end - required to delimitate this sections conclusion.
Low Inbound -
This script seems to block inbound traffic from IP 0.0.0.0 (?), permit DNS usage (?), and block all ICMP (ping) responses (make the machine appear not to exist on the Internet, but see below).
1) title - obvious meaning [ Security Level 1 IN rules ].
2) begin - required to delimitate this sections start.
3) Rules - same as above. "Rule Name".
3a) pass all - let everything come in. Go on to the next test. (Seems kinda dumb to have this here, since it really does nothing.)
4) AddresDrop - same as above, but new "Rule Name".
4a) drop from addr 0.0.0.0 >> done, alert 4 [ 0.0.0.0 Source IP Address] - not sure what this means as far as IP address is concerned, but drop anything from IP 0.0.0.0, put [ 0.0.0.0 Source IP Address] in the firewall log with clear color, then exit, if this is a match. Otherwise, proceed to the next test.
4b) pass protocol udp, to port 53 >> done
4c) pass protocol udp, from port 53 >> done - these two allow DNS protocol...not sure how the rule works though (and why is an "outbound" rule {to port 53?} in the "inbound" file??). If a match though, go to end. Otherwise, proceed to the next test.
4d) drop protocol icmp >> alert 4 [ICMP Message To WAN IP] - as TheWiseGuy said, this drops all ICMP (ping), and puts [ICMP Message To WAN IP] in the firewall log with clear color. Interestingly, when PING-ed by GRC, they will report a reply to ICMP Echo...I don't know why. If I understand this right, this rule will not forward the PING Echo request to my computer, so therefore it cannot respond. Am I missing something?? Proceed to next test.
5) end - required to delimitate this sections conclusion.
OK...time for comments.
--
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:
Interestingly, when PING-ed by GRC, they will report a reply to ICMP Echo...I don't know why. If I understand this right, this rule will not forward the PING Echo request to my computer, so therefore it cannot respond. Am I missing something??
If the rules are processed from the top down
title [ Security Level 1 IN rules ]
begin
Rules
pass all
I would guess this is why you respond to ICMP and it is really the rest of the rules that do nothing.  But I'm just guessing.
--
Dog and Butterfly | |
| From the Help file as noted above -
Rules Section
The rules section of the RDL file or buffer is delimited by the begin an end keywords. The rules listed between these delimiters are parsed and converted to a decision tree data structure used by the packet filter engine. The rules listed are implemented sequentially as listed in the RDL source. 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).
Since there is no done after the pass all statement, I think that it would take note of that, but continue on down to the drop protocol icmp statement, where it should then be stopped.
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? | |
TheWiseGuyDog And ButterflyPremium,MVM
join:2002-07-04
Yonkers, NY
kudos:1 Reviews:
·Optimum Online
| 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. | |
|
