Guy Fraser wrote:
On 2007-Dec-07, at 13:35, John Summerfield wrote:
Guy Fraser wrote:
On 2007-Dec-07, at 09:46, Gordon Messmer wrote:
Daniel B. Thurman wrote:
So... am I to read this as it is a good idea to disable all ICMP
requests? I get a LOT of ICMP requests from the Internet probing
at my ports, which are disabled. This is a good idea?
That's impossible. UDP ports can only be tested by UDP packets, and
TCP ports can only be tested by TCP packets. ICMP is a different IP
protocol which doesn't feature numbered ports. As such, blocking
ICMP won't prevent port scans, it'll just prevent some of your own
outbound connections from working properly.
If you block ICMP echo reply {ICMP type 0} and ICMP unreachable {ICMP
type 3}
packets from egress {going out from your machine} your machine will
not answer
ping requests {ICMP type 8} or send unreachable messages for ports
that do not
have any listeners running on them, or are blocked. Another good thing
Why is blocking type 0 good?
So you do not get hammered by pings.
Oh, You block ping replies so your IAP can't test your network
connectivity. if your IAP also blocks echo replies, then neither of you
can test.
pings are small packets, I would expect the bottleneck to be on the
wire. If i were malicious enough to want to hammer your system, I'd use
bigger packets. A chain email about poor little Freddy who's dying of
cancer, wants to collect a world-record number of pictures of cuddly
critters and could you send them to freddy@xxxxxxxxxxx has been known to
work fairly well. or "/." the victim
This http://www.cisco.com/warp/public/707/21.html has a section on Flood
Management. Read it, it doesn't apply to many on this list.
Why is blocking type 3 good?
If you reject packets, your host may send an unreachable response.
if you reject packets, that's exactly what you should do. I suggest
dropping them.
to block
is ICMP type 5 which asks the recipient to redirect packets elsewhere.
What's the problem with these?
Google for ICMP redirect, and check the security implications.
This suggests it's not a real problem:
http://www.cs.columbia.edu/~smb/talks/ipext-acsac.ps
Unfortunately I had to twist my head over to read it, so I didn't read
it all.
This http://www.cisco.com/warp/public/707/21.html says, "No end node
ever sends a redirect, and no redirect is ever traversed more than one
network hop." and goes on to recommend blocking them at an
administrative boundary.
Blocking all ICMP can have unintended consequences, but is best if it is
blocked bidirectionally. Allowing ICMP responses from your machine
allows
the "scanner" to know you are there and which ports are blocked or
unused.
dropping packets to protected ports is sufficient to protect them, and
is established practice.
Yes, but are you certain the original poster is dropping all packets
sent to
ports that do not have listeners ?
No, but I counselled it. Just as I counsel mostly leaving ICMP alone.
I prefer to use a more complicated ICMP blocking ruleset, but no longer
have a Linux machine to show an example.
This is the generic part of the ipfw ruleset, I am now using on the OS X
Leopard machine I got to replace my Fedora Workstation :
--- snip ---
# Clear Firewall and start from scratch
$IPFW -f flush
# Allow all internal traffic
$IPFW add 1000 allow ip from any to any via lo0
# Deny and log spoofed traffic
$IPFW add 1010 deny log ip from 127.0.0.0/8 to any in
$IPFW add 1020 deny log ip from any to 127.0.0.0/8 in
# Deny Multicast packets
#$IPFW add 1030 deny log ip from 224.0.0.0/3 to any in
#$IPFW add 1040 deny log tcp from any to 224.0.0.0/3 in
Don't those break Bonjour?
That is why they are commented out
# Block outgoing ICMP unreachable packets
$IPFW add 1050 deny icmp from me to any out icmptypes 3
# Block incoming redirection packets
$IPFW add 1060 deny icmp from any to me in icmptypes 5
# Block outgoing echo reply packets
$IPFW add 1070 deny icmp from me to any in icmptypes 0
# Block incoming echo request packets
$IPFW add 1080 deny icmp from any to me in icmptypes 8
Those limit your network functionality for limited (if any gain)
In your opinion.
well, if you don't use all the ICMP then it's a fair assumption your
network isn't properly controlled.
With my setup, dropping connexion requests from the Internet to port
5432, you time out regardless of whether postgresql is running at all.
I could also unconditionally send ICMP 3 to Internet hosts, regardless
of whether postgresql is running or not.
Probably, the correct response to an unwelcome request is to send ICMP
3 code 9, but I don't know a reason that it matters if I don't tell
the untrusted the whole truth.
I did not say this was the whole Firewall ruleset. This is just the top
part of what I use on my workstation. I clipped the rules so I didn't
have to obscure my access control lists for for the ports I do listen on.
Use what works for you, I did not start this conversation saying what you
do is wrong.
That is true, but I do think some of your advice is wrong. It's
perfectly possible that I am wrong, but so far you've failed to convince me.
The original poster was asking about blocking ICMP, if you want to debate
how to set up the ultimate firewall, start your own thread. The best way
to firewall is to return nothing to anything but what you intend on
responding to. Sending false responses, does not protect you, but often
antagonizes the hacker. There are far too many elements involved in
hardening a machine that I will not go into here that are far beyond
just configuring a firewall.
Proper use of ICMP requires coordination with other aspects of a
firewall. Generally, not generating ICMP packets is better than blocking
outgoing ICMP, and ignoring incoming ICMP packets can lead to network
problems.
I note that the setup on my SL5 box explicitly allows all ICMP:
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
and according to "essential Mac OS X Panther Server Administration,"
Bartosh & Faas,: O'reilly, OS X does too. (Our xserve with Tiger does
too, but I'm not sure I'd call its rules a 'firewall').
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
