March 2008 - Test - lists.nanog.org

RE: Customer-facing ACLs
by Scott Weeks 12 Mar '08

12 Mar '08

--- frnkblk(a)iname.com wrote: -------------------- 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 ---------------------------------------- I'd like to ask the same question of you that I just did to Chris. How'd you implement that or has it been there since the network was new? ------ frnkblk(a)iname.com wrote: ------------ From: "Frank Bulk - iNAME" <frnkblk(a)iname.com> Those ACLs were added when I came on board. Again, only one complaint in 3+ years. -------------------------------------------- Do you mean they were already there when you arrived, or do you mean you just put in ACLs after arriving? No research into traffic? No contact to customers? No elaborating to the less technical folks in the company about what was going to happen? etc... We have over 100k DSL folks and most're DHCP. I'd be afraid to do that without research into the traffic via "permit TCP NNN log" type ACLs and other methods. I believe I will take Sean D's sugestion and read MAAWG's docs. Makes me wonder, though, if we took over the Hawaii part of VZ's network and it was completely open, does that mean the rest of their network is similarly open? scott

2 1

RE: Customer-facing ACLs
by Scott Weeks 11 Mar '08

11 Mar '08

--- frnkblk(a)iname.com wrote: -------------------- 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 ---------------------------------------- I'd like to ask the same question of you that I just did to Chris. How'd you implement that or has it been there since the network was new? scott

3 2

Re: Customer-facing ACLs
by Scott Weeks 11 Mar '08

11 Mar '08

--- morrowc.lists(a)gmail.com wrote: uunet dialup has blocked port25 in both directions since 2002... little to no complaints. (well, they may have received complaints since I left, but... thank John StClair for the work behind that filtering actually.) ----------------------------------------- I'd be curious as to how they implememted this. Prop up ALCs and deal with the complaints as they came? If, not how was the research done as to what was legitimate tcp25 and what wasn't. For how many customers? Residential, business or both? DHCP only or static too? etc... scott

1 0

Re: Customer-facing ACLs
by Scott Weeks 11 Mar '08

11 Mar '08

Apologies for the delay... --- sean(a)donelan.com wrote: On Mon, 10 Mar 2008, Scott Weeks wrote: > The default policy is we allow eveything. It takes no explaining. If you don't bother to explain to the same customers who you believe couldn't figure out how to change the default settings, what the risks and how to protect their computers on the Internet, is it any wonder that normal user's have such a difficult time being safe on the Internet? ------------------------------------------ Haven't you answered this in past posts on the subject? What are ISPs responsibilities and all... ----------------------------- Implementing source address verification can take years, but if you never start, you will never finish. Implementing sanity checks for IP headers can take years, but if you never start, you will never finish. Implementing unsolicited/unwanted traffic controls can take years, but if you never start, you will never finish. Do you think caller-id/call-blocking/harrassing-call-trace were easy, or rather they took years of hard work. Although the technology may change, people seem to stay the same. And people seem to be adept at doing the same stuff with new technology to other people. ----------------------------- Yes, but each situation is different and you could not imagine how spread thin some netgeeks can get. Especially in a company that doesn't understand (yet) what it is we do. You could not imagine how thin it is here, but you REALLY learn a lot in a situation like this. scott

1 0

Customer-facing ACLs
by Justin Shore 11 Mar '08

11 Mar '08

This question will probably get lost in the Friday afternoon lull but we'll give it a try anyway. What kind of customer-facing filtering do you do (ingress and egress)? This of course is dependent on the type of customer, so lets assume we're talking about an average residential customer. Do you block SYNs destined to your customers? Do you rate-limit SYNs destined for your customers? SYNs on privileged ports? Do you block any customer-facing egress traffic at all? What about ingress? SMTP, NetBIOS, MS-SQL, common proxy ports (3128, 6588)? What ICMP types do you allow or disallow? I'm assuming everyone uses uRPF at all their edges already so that eliminates the need for specific ACEs with ingress/egress network verification checks. Do you filter anything destined to your network infrastructure on your customer-facing edges? Does anyone filter traffic destined to the PE side of a PE-CE link from the outside world? For those of you with cable networks, what all do you block with the CM? We're considering blocking NetBIOS and DHCP server traffic (DHCP server packets are already blocked at the CMTS but this would keep that junk off our infrastructure). For SMTP we permit access to our SMTP servers on tcp/25 to all our broadband users. We also permit our customers with static IPs (residential and business) to send SMTP without restrictions. After those permits we explicitly block tcp/25. This has worked fairly well for us. It sure makes it easy to find infected PCs with spambots. We don't touch tcp/587. For ICMP we permit echo, replies, packet-too-big, and time-exceeded. Everything else gets dropped. Frags are explicitly dropped before any permits. We also block common proxy ports to and from the customers (the to includes ports not always used for proxies). This has been very effective in catching a number of bots that scanned for open Squid proxies or script kiddie junk that used WinGate with the default settings. Is there a BCP for customer-facing ACLs? Justin

13 13

Prepare for router Wednesday
by Hank Nussbacher 11 Mar '08

11 Mar '08

http://www.techworld.com/security/news/index.cfm?RSS&NewsID=11665 "Following the lead of Microsoft and Oracle, Cisco Systems will start releasing security patches for some of its products on a schedule. ... The first of these scheduled updates will occur on Wednesday, 26 March, and Cisco will continue to release patches on a twice-yearly schedule after that, Cisco said in a note posted Wednesday on its website. These firmware updates will ship on the fourth Wednesday of September and March each year." -Hank

1 0

Re: 3rd party network monitoring
by Ethan Katz-Bassett 11 Mar '08

11 Mar '08

Another you might want to look at is our system Hubble (http:// hubble.cs.washington.edu) which monitors reachability problems. I presented a preliminary study at NANOG40 (http://www.nanog.org/ mtg-0706/bassett.html), and now it is running continuously. Some of the other changes since the talk: - It monitors 78,000+ prefixes, with pings from 100 sites and traceroutes from 35 sites around the world. Once we roll over to the list used by the sister project iPlane, the number of prefixes will be 142,000+. - We developed a technique using source-spoofed probes to isolate the failures to forward or reverse paths. - The website lets you query for the status of an address. For now, failed pings trigger traceroutes, but we plan to start looking at latency changes as well. If you look at the site, I'd appreciate any feedback on what we have and where we should be going with it, as we'd like this to become a useful tool. If you have a prefix we can start monitoring, please feel free to write me or use the feedback form on the website to give us a pingable address to use, and I should be able to incorporate it. Thanks. ethan > > -------- Original Message -------- > Subject: 3rd party network monitoring > Date: Tue, 04 Mar 2008 12:02:27 -0500 > From: Darrell Hyde <dhyde(a)hostmysite.com> > To: nanog(a)merit.edu > > > In light of the recent major outages experienced by XO and Abovenet, I > have become very interested in finding a 3rd party vendor to > monitor the > availability of my network from a variety of locations. > > I've looked at keynote / redalert, but oddly enough they don't seem to > be able to monitor simple ICMP round-trip times - they (or at least > the > sales folk that I've spoken with) insist on checking the status of > a TCP > port or the response time of a web server. > > Google searches have yielded a few leads, but nothing terribly > promising. > > Can anybody recommend a vendor for this type of service? I suppose I > could always just get a bunch of VPS accounts here and there and run > smokeping, but I'd really like to avoid that. > > - Darrell

1 0

Customer-facing ACLs
by Ang Kah Yik 11 Mar '08

11 Mar '08

Hi Justin (and all others on-list) I understand your grounds for blocking outbound SMTP for your customers (especially those on dynamic IP connections). It probably will do good to block infected customers that are spewing spam all over the world. However, considering the number of mobile workers out there who send email via their laptops to corporate SMTP servers, won't blocking outbound SMTP affect them? Since these corporate types (I'm guessing here) are probably unaware of how to change their email client's SMTP configurations, chances are that blocking outbound SMTP will probably cause quite a lot of pain. After all, there are also those who frequently move from place to place so they're going to have to keep changing SMTP servers every time they go to a new place that's on a different ISP. Cheers -- ANG Kah Yik (bangky)

6 6

Re: Customer-facing ACLs
by Scott Weeks 11 Mar '08

11 Mar '08

Long response with answers inline... --- sean(a)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

3 2

Peering with the Internet Alert Registry
by Josh Karlin 10 Mar '08

10 Mar '08

All, Some of you are aware of the site for network operators: http://iar.cs.unm.edu/ which has running for two years now. The purpose of the site is to detect and distribute network anomaly information to the network operators that need to know. The flip side of our proposed security system, Pretty Good BGP (PGBGP), lowers the local preference of anomalous routes on BGP routers for 24 hours, giving operators time to respond to anomalous routes before they can fully propagate. Now, PGBGP is in actual routing software (Quagga), which we soon hope to distribute. As an initial means of test, we will switch the IAR to it (instead of scraping RIPE/RouteViews with a script). This means that we will need peers to provide the IAR with BGP updates (we will not propagate any route updates to your routers). Currently we have three BGP streams, more would be appreciated. If you would like to contribute to our research project, please reply directly to me. More information about the project can be found here: http://cs.unm.edu/~karlinjf/pgbgp/ <http://cs.unm.edu/%7Ekarlinjf/pgbgp/> Thanks! Josh

2 2