Rob:
Heya. Some quick answers (am posting this on-list, as
you suggested)
1. Actually, echowall is the one doing more filtering, not less. Charles'
default script lets many of the broadcast-noise stuff go thru to the
end, where it gets logged by the last "catch and log everything that
made it this far" rule. In echowall, I filter for most of the harmless
noise and drop it without logging. In fact, the lines I sent you came
right out of the echowall.rules file. :)
2. As you can see, echowall "allow queries for our ident, even if service
isn't running". This actually is better than reject'ing or deny'ing, as
services like IRC or SMTP which sometimes query for ident will come
around faster if you let the packet fail "normally", sans firewall. If
you wanted to activate an identd server...the port is ready and waiting.
3. You'll likely get as many different answers about which ICMP to
let across a firewall as their are firewall script authors. In general,
I recognize only one ICMP type as a real threat: type 5, an ICMP Redirect
command. If your router listened to this packet then all outgoing traffic
from your router *could* have been redirected to whoever sent the
packet: perhaps some hacker's machine, or perhaps a dead-end and
someone is trying a Denial of Service attack upon you. Speaking of DOS
attacks, you're right about echo-replies (type 0) not always being harmless.
An "echo reply" is a reply from what is commonly known as "ping" -- if
you or someone on your LAN ping'd someone recently, an echo-reply
is the remote machine's reply. Since the LAN my firewall protects has
users on it, and not just servers, incoming pings (echo requests) are
blocked but replies to pings initiated from behind the firewall are allowed
thru. Were it the other way, where there were just servers being protected
and no users, I would switch that around: allow echo-requests but deny
echo-replies. IIRC, in the DDOS attacks of mid-2000, there were some
reported cases where echo-reply packets were used in a DOS manner.
Finally...there's tracerouting, which uses ICMP type 11, or "ICMP time
exceeded in transit" messages. That is, when you traceroute someone, it
sends out packets to the destination IP address with a TTL set to 1, then 2,
then 3, etc. It then records where the ICMP type-11 packets come back
from, and so knows the packet's route. Pretty keen. Some firewall rules
prevent the sending of ICMP type-11 packets in the firewall's external
interface's output rule, which renders you immune from being
"traceroute'd". Again, IMO, it depends whether your protecting a LAN of
servers or a LAN or users.
Hope this helps!
-Scott
At 8:50 PM +0100 7/2/01, Rob Moore wrote:
>Scott
>
>Couple of questions,
>
>1. more of an observation really - the original query i reported with
>ES2Beta
>denying broadcast packets from what turned out to be my cable modem has gone
>away with echowall. Indeed I can now connect from my internal lan to the
>weblet
>running on the modem (was not able to do that before). I should emphasise
>that this
>is NOT a problem; it just means that i dont need the lines you gave....
>
>So, somewhere in Charles' default script presumably he is doing some further
>filtering than your default script?
>
>
>2. With ES2Beta if I use any of the web-based port scanners, eg. grc.com,
>all
>of the critical ports that are scanned report "stealth".
>
>With echowall, port 113 is returned as "closed" instead of stealth. Would
>this mean
>that if I had an identd server running on my fw box connecting machines
>would get
>a response? How would one add some extra rules to cover this, or have I got
>the wrong
>end of the stick?
>
>
>3. ICMP -wise what's your view on what should be filtered; I'm told that
>generally
>echo-requests should be denied unless from isp for qos monitoring, etc.
>
>Rob
_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-user
