Long response with answers inline... --- sean@donelan.com wrote:---------------------------
Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery!
Depends on how you ask the questions. How about: Should a statefull firewall be provided for casual broadband dynamic Internet access connections by default? Users may change the default settings of the stateful firewall as they choose. 1. Unsolicited inbound (to user LAN) traffic ----------------------------------------------------- The ultimate answer is: It depends. :-) As you know, it depends on your network and who your users are. My experiences are with a global network of cold potato routing for high-end enterprises, a 10,000 person university and, currently, a state-wide ILEC. In these networks no, internet access should not be closed partially by default and then allowed to be opened by a user. Little tutus out in Hana are not going to be able to figure it out when trying to use things their keiki on the mainland are telling them to use that're not on port 80. College students are just going to open everything so they don't have to worry blockages of the newest, kewlest thing to start up that they want to try. Enterprises want to be in as complete control of their services as possible, so perhaps there, if they all have technically adept network folks. ----------------------------------------------------- Are there LAN-only protocols and other data packets which shouldn't be accepted on WAN Internet access links without prior coordination (if ever)? 1. Anti-spoofing controls of source addresses 2. Proxy/gratitious ARP, ICMP redirects, DHCP server->client, RIP? 3. "Local" multicast data and broadcasts 4. "Sanity" checks of IP headers (i.e. source==destination, loopback, etc) which should never appear on the wire 5. Layer 2 non-Internet (non-IP, non-IPv6, non-ARP, non-PPPOE) Are there some protocols that should have prior coordination when using some Internet access types, e.g. dynamic or unauthenticated connections? 1. outbound to off-net SMTP (port 25) instead of MSA (port 587) 2. NetBios over TCP, the exploding Microsoft protocol? ------------------------------------------------------ The first 1-5...OK, possibly, but that isn't what the person was speaking about. The second 1-2, no, unless it's VERY clear to your customers upfront. I used to be of the 'second 1-2' opnion, but I've since changed my mind on the kind of networks I help operate. It's funny (in a sick kind of way) how much stuff you can break when you filter unless you have the time to do a *very complete* traffic analysis over an extended time period. Folks do all sorts of crazy crap that I think they shouldn't do (off-LAN Micro$loth file sharing, for example), but are doing and some have done for a long time. The hard part is I now always take over networks that have been in operation a long time and enabling these policies can be very painful after the fact. Establishing them when the network is new is a different story. scott
On Mon, 10 Mar 2008, Scott Weeks wrote:
The hard part is I now always take over networks that have been in operation a long time and enabling these policies can be very painful after the fact. Establishing them when the network is new is a different story.
Whatever you decide, whether you know what the policies are or not, there are always have a set of default network policies. The question is do you explain to you customers just as carefully what your default policy doesn't do, as well as what it does. Do you take just as much time to carefully explain the risks and what may break to your customers of allowing that traffic as you would of not allowing that traffic. It seems to be very painful whatever decision is made.
We have a two-dozen line long ACL applied to our CMTS and BRAS blocking Windows and "virus" ports and have never had a complaint or a problem. We do have a more sophisticated residential or large-biz customers ask, but only once has our ACL been the source of a problem and it's only because the OEM version of the software didn't implement communications the same way as their branded version. Frank -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Sean Donelan Sent: Monday, March 10, 2008 2:30 PM To: Scott Weeks Cc: nanog@merit.edu Subject: Re: Customer-facing ACLs On Mon, 10 Mar 2008, Scott Weeks wrote:
The hard part is I now always take over networks that have been in operation a long time and enabling these policies can be very painful after the fact. Establishing them when the network is new is a different story.
Whatever you decide, whether you know what the policies are or not, there are always have a set of default network policies. The question is do you explain to you customers just as carefully what your default policy doesn't do, as well as what it does. Do you take just as much time to carefully explain the risks and what may break to your customers of allowing that traffic as you would of not allowing that traffic. It seems to be very painful whatever decision is made.
participants (3)
-
Frank Bulk - iNAME
-
Scott Weeks
-
Sean Donelan