bob@MorningStar.Com (Bob Sutterfield) (06/18/91)
When a gateway is configured as a firewall, what is the polite thing to do about those packets that aren't passed? The packet itself should be dropped on the floor, but should the originating system be told anything about it? Suppose 25/tcp (SMTP) is allowed through but 23/tcp (Telnet) is blocked. Should the gateway return a Host Unreachable in response to a telnet request? Or maybe only a Port Unreachable or Protocol Unreachable, which would leave the originator wondering what other ports might be reachable or which protocols might be passed? RFC792 says that the destination host may send the Unreachable message back to the source host, but implies that only a host may send a Port or Protocol unreachable. Should the firewall, since it's assuming the filtering responsibility, also assume responsibility for the ICMP returns? RFC1009 doesn't seem to address this area except to suggest in 4.4 that address filters be supported, so I must rely on precedent for protocol filter behavior. What is polite? What is common?
kdenning@genesis.Naitc.Com (Karl Denninger) (06/18/91)
In article <BOB.91Jun17182958@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes: >When a gateway is configured as a firewall, what is the polite thing >to do about those packets that aren't passed? The packet itself >should be dropped on the floor, but should the originating system be >told anything about it? > >Suppose 25/tcp (SMTP) is allowed through but 23/tcp (Telnet) is >blocked. Should the gateway return a Host Unreachable in response to >a telnet request? Or maybe only a Port Unreachable or Protocol >Unreachable, which would leave the originator wondering what other >ports might be reachable or which protocols might be passed? RFC792 >says that the destination host may send the Unreachable message back >to the source host, but implies that only a host may send a Port or >Protocol unreachable. Should the firewall, since it's assuming the >filtering responsibility, also assume responsibility for the ICMP >returns? I return a "host unreachable" for any hosts behind our firewall. On >all< protocols and ports. This is as (from my reading) it should be -- the host IS unreachable. IF you're doing SMTP mail, and don't recognize the MX records, you will end up bouncing the mail. Then again, if you're doing SMTP, you should know what an MX record is ;-) The choice of having all points beyond the firewall unreachable directly was a policy one here at the company.... -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company.
barns@GATEWAY.MITRE.ORG (06/19/91)
"Son of 1009" aka the Router Requirements RFC (draft) says something about this. The proposal will be different from anything now done, assuming the draft is agreed to (and that stage isn't far away now). The idea is to make a new ICMP Unreachable subtype code for generic "communication administratively prohibited". There are existing codes (documented in RFC 1122 only) for "communication with host administratively prohibited" (code 10) and "communication with network administratively prohibited" (code 9). I think I would prefer that the new code be sent for a protocol-specific firewall and probably for a host or network-wide prohibition as well. (Such was the intent of the proposal, which by the way wasn't mine. Apparently there is some fast algorithm for filtering packets that works in such a way that you can decide that something failed much quicker than you can decide why it failed. Since the router world is now benchmark-driven, the vendors want the code structure to support this way of doing things.) People with (intelligent) opinions on what routers ought to do about anything related to IP ought to be feeding their inputs to the Router Requirements Working Group. Unless something surprising occurs, the next meeting ought to be at the Atlanta IETF at end of July/beginning of August. A (hopefully fairly current) draft is available at the usual Internet-Drafts repositories including nnsc.nsf.net, in directory internet-drafts, filename draft-ietf-rreq-iprouters-01.txt. The beginning of the document has lots of info about how to contribute to its development. It would make sense for people to read the draft before commenting on what it should say. Bill Barns / MITRE-Washington / barns@gateway.mitre.org
glass@postgres.Berkeley.EDU (Adam Glass) (06/21/91)
In article <BOB.91Jun17182958@volitans.MorningStar.Com> Bob Sutterfield writes:
When a gateway is configured as a firewall, what is the polite thing
to do about those packets that aren't passed? The packet itself
should be dropped on the floor, but should the originating system be
told anything about it?
Suppose 25/tcp (SMTP) is allowed through but 23/tcp (Telnet) is
blocked. Should the gateway return a Host Unreachable in response to
a telnet request? Or maybe only a Port Unreachable or Protocol
Unreachable, which would leave the originator wondering what other
ports might be reachable or which protocols might be passed? RFC792
says that the destination host may send the Unreachable message back
to the source host, but implies that only a host may send a Port or
Protocol unreachable. Should the firewall, since it's assuming the
filtering responsibility, also assume responsibility for the ICMP
returns?
RFC1009 doesn't seem to address this area except to suggest in 4.4
that address filters be supported, so I must rely on precedent for
protocol filter behavior. What is polite? What is common?
The Host Requirements RFCs (rfc1122 and the other one) define 6 new codes for use in the ICMP Destination Unreachable datagrams. these are
6 = destination network unknown
7 = destination host unknown
8 = source host isolated
9 = communication with destination network
administratively prohibited
10 = communication with destination host
administratively prohibited
11 = network unreachable for type of service
12 = host unreachable for type of service
Unfortunately, I don't think much software actually understands these
yet. 9, and 10 are much more explicit and truthful than 'host unreachable'.
What an older implementation might do with an unknown code is anybody's guess.
I've also seen 'network down' used by a cisco box somewhere.
BTW: are you doing a hacking a 4.X bsd tcp-ip implementation to do
packet filtering?
later,
Adam Glass
--
Adam Glass |Internet: glass@postgres.Berkeley.EDU
various roles at Berkeley |Home : glass@Chaos.orgmogul@pa.dec.com (Jeffrey Mogul) (06/25/91)
In article <BOB.91Jun17182958@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes: >When a gateway is configured as a firewall, what is the polite thing >to do about those packets that aren't passed? The packet itself >should be dropped on the floor, but should the originating system be >told anything about it? The system I implemented (see my paper in Proc. 1989 Summer USENIX Conf.) currently sends "Host Unreachable" packets, but only in those cases specified in the filtering rules. E.g., the manager of the gateway can say: from any to any tcp port telnet reject notify; from any to any tcp port finger reject; This means that telnet users will get notification via ICMP, and finger users will see their connections time out. (This is a contrived example; in real life, we tend to send notifications except in cases where nobody is likely to be listening and the traffic rate could be high.) In my implementation, the choice of ICMP type+code is wired into the kernel. Given that I allow fine-grained choice of when to send an ICMP, it might also be reasonable to add fine-grained choice of which ICMP code to send. However, we've been running this way for more than 2 years without any problems. [This code is now shipping with Ultrix (release 4.2) so if I made the wrong choice, I guess I'll hear about it.] -Jeff
tr@samadams.princeton.edu (Tom Reingold) (06/27/91)
mogul@pa.dec.com (Jeffrey Mogul) writes:
$ The system I implemented (see my paper in Proc. 1989 Summer USENIX
$ Conf.) currently sends "Host Unreachable" packets, but only in
$ those cases specified in the filtering rules. E.g., the manager
$ of the gateway can say:
$ from any to any tcp port telnet reject notify;
$ from any to any tcp port finger reject;
$ This means that telnet users will get notification via ICMP, and finger users
$ will see their connections time out. (This is a contrived example; in
$ real life, we tend to send notifications except in cases where nobody
$ is likely to be listening and the traffic rate could be high.)
$ In my implementation, the choice of ICMP type+code is wired into the kernel.
$ Given that I allow fine-grained choice of when to send an ICMP, it might
$ also be reasonable to add fine-grained choice of which ICMP code to send.
$ However, we've been running this way for more than 2 years without any
$ problems. [This code is now shipping with Ultrix (release 4.2) so if I
$ made the wrong choice, I guess I'll hear about it.]
Forgive me if I am mentioning something that has been discussed here
before...
Is this sort of approach a "good idea"? It has become common, with
different methods of implementation. Would it not make more sense to
take the burden of security away from networks and put it on hosts? To
me, it seems that firewalls like these are analogous to roadblocks on
highways that are placed there because a criminal MIGHT be using the
road to commit a crime. I prefer to be presumed innocent and I like
having a road that is free for both me and the criminals. I prefer
banks putting up heavy locks to prevent robberies over roadblocks on
roads.
What do network experts feel about this?
--
Tom Reingold
tr@samadams.princeton.edu OR ...!princeton!samadams!tr
"Warning: Do not drive with Auto-Shade in place. Remove
from windshield before starting ignition."ejm@riscit.NOC.Vitalink.COM (Erik J. Murrey) (06/27/91)
In article <tr.677973063@samadams>, tr@samadams.princeton.edu (Tom Reingold) writes: |> Forgive me if I am mentioning something that has been discussed here |> before... |> |> Is this sort of approach a "good idea"? It has become common, with |> different methods of implementation. Would it not make more sense to |> take the burden of security away from networks and put it on hosts? To |> me, it seems that firewalls like these are analogous to roadblocks on |> highways that are placed there because a criminal MIGHT be using the |> road to commit a crime. I prefer to be presumed innocent and I like |> having a road that is free for both me and the criminals. I prefer |> banks putting up heavy locks to prevent robberies over roadblocks on |> roads. |> I wish the world were perfect enough to do this. Why configure all 10,000+ hosts with stiffer security options when you have small handful of gateways connecting them to the outside world? You also better hope that all 10,000+ hosts are running new enough software to prevent the network attacks that a firewall can stop. And please tell me what happens when an Engineer connects his brand-spanking-new workstation to the network with no passwords on his accounts. Do you have a security patrol that checks? --- Erik J. Murrey Vitalink Communications NOC ejm@NOC.Vitalink.COM ...!uunet!NOC.Vitalink.COM!ejm
rpw3@rigden.wpd.sgi.com (Rob Warnock) (06/27/91)
In article <tr.677973063@samadams> tr@samadams.princeton.edu (Tom Reingold) writes: +--------------- | Is this sort of approach a "good idea"? It has become common, with | different methods of implementation. Would it not make more sense to | take the burden of security away from networks and put it on hosts? To | me, it seems that firewalls like these are analogous to roadblocks on | highways that are placed there because a criminal MIGHT be using the | road to commit a crime. I prefer to be presumed innocent and I like | having a road that is free for both me and the criminals. I prefer | banks putting up heavy locks to prevent robberies over roadblocks on roads. +--------------- Well, to me the analogy is less to roads and more to my house. I have several rooms in my house, and some have private files that I need to protect very well and some have nothing of very much importance at all. But I'd rather put a lock on the front door (the firewall) and enjoy the convenience of being able to walk freely from room to room, picking up a novel here and a confidential file there, as opposed to leaving the front door wide open and then having to use a key to get from the bedroom to the bathroom, a key to get from the bathroom to the kitchen, and a key to get from the kitchen to the study. Organizations which prefer, for whatever reasons, to have a more "homey" atmosphere within their "walls" (internal internet) tend to prefer the firewall approach. It allows the conveniece of, say, open guest accounts on internal systems without worrying about uninvited outside "guests". Yet a "well-behaved" firewall -- together with a few specially-secured servers -- still allows a controlled degree of sharing and communication. (E.g., my house allows the postal deliveryperson to drop mail through the slot, allows the gas meter to be read, and allows garbage to be carted away -- all without my being there to approve it.) I guess it just depends on your situation and perspective. -Rob ----- Rob Warnock, MS-1L/515 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
tjc@ecs.soton.ac.uk (Tim Chown) (06/27/91)
In <113425@sgi.sgi.com> rpw3@rigden.wpd.sgi.com (Rob Warnock) writes: >Organizations which prefer, for whatever reasons, to have a more "homey" >atmosphere within their "walls" (internal internet) tend to prefer the firewall >approach. It allows the conveniece of, say, open guest accounts on internal >systems without worrying about uninvited outside "guests". Yet a "well-behaved" >firewall -- together with a few specially-secured servers -- still allows a >controlled degree of sharing and communication. (E.g., my house allows the >postal deliveryperson to drop mail through the slot, allows the gas meter >to be read, and allows garbage to be carted away -- all without my being >there to approve it.) The problem comes with remembering to shut all the windows ... ;-) Tim --
gary@sci34hub.sci.com (Gary Heston) (06/27/91)
In article <tr.677973063@samadams> tr@samadams.princeton.edu (Tom Reingold) writes: >mogul@pa.dec.com (Jeffrey Mogul) writes: >$ [ how he does a firewall ] >Forgive me if I am mentioning something that has been discussed here >before... Many things are discussed repeatedly, in search of a better conclusion that the last time. No forgiveness needed... >Is this sort of approach a "good idea"? Yes. After all, it's a network admins' job to keep the network secure as well as up-and-running. > It has become common, with >different methods of implementation. Would it not make more sense to >take the burden of security away from networks and put it on hosts? To >me, it seems that firewalls like these are analogous to roadblocks on >highways that are placed there because a criminal MIGHT be using the >road to commit a crime. I prefer to be presumed innocent and I like >having a road that is free for both me and the criminals. I prefer >banks putting up heavy locks to prevent robberies over roadblocks on >roads. Not quite a good analogy. Domains are more like private housing areas, or apartment complexes, which don't have public roads thru them. You can drive anywhere on the public roads (use the InterNet) you want, and shouldn't be hindered by roadblocks (firewalls) without some act on your part (note that this is contrary to MADDs' attitude), but you have no business driving around in my parking lot (accessing my domain). Rules for use of public property differ from those for private property. The property owner (network admin) is perfectly within their rights to refuse access (respond Host Unreachable) to anyone that isn't paying rent or a member of the private community (users). I want to see wide access for everyone, myself. My first responsibility is to the users and our employer, though. >What do network experts feel about this? I'll want to see that as well. I'm certainly no expert, yet. -- Gary Heston System Mismanager and technoflunky uunet!sci34hub!gary or My opinions, not theirs. SCI Systems, Inc. gary@sci34hub.sci.com I support drug testing. I believe every public official should be given a shot of sodium pentathol and ask "Which laws have you broken this week?".