Re: Customer-facing ACLs
On 7 Mar 2008, at 23:57, Scott Weeks wrote: Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery! Oh, no, this one again. *** The Internet Is Not The Web. *** Could someone put that onto a t-shirt ? If it becomes normal for home users to only have 80 and 443, then how can I innovate and design something that needs a new protocol ? What happens to the new voice and video services for example ? On 11 Mar 2008, at 02:33, Christopher Morrow wrote: vpns fix this... They stop fixing stuff when they stop working. If you start running vpn services on tcp/80 (yuck, yuck, yuck), and naturally because it's the only port open lots of other non http protocol stuff does too, will filter-happy domestic providers start proxying the web instead of just filtering the rest of the traffic ..? Andy
Re: Customer-facing ACLs
On Mar 18, 2008, at 3:58 PM, Andy Davidson wrote: On 7 Mar 2008, at 23:57, Scott Weeks wrote: Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery! Oh, no, this one again. *** The Internet Is Not The Web. *** Could someone put that onto a t-shirt ? If it becomes normal for home users to only have 80 and 443, then how can I innovate and design something that needs a new protocol ? What happens to the new voice and video services for example ? The DOD has already been faced with this (I know of some AFB that have instituted this policy). The solution, of course, is to hire consultants (SIBR if possible) to port everything to port 80 ! You can't say they don't have a plan. Regards Marshall On 11 Mar 2008, at 02:33, Christopher Morrow wrote: vpns fix this... They stop fixing stuff when they stop working. If you start running vpn services on tcp/80 (yuck, yuck, yuck), and naturally because it's the only port open lots of other non http protocol stuff does too, will filter-happy domestic providers start proxying the web instead of just filtering the rest of the traffic ..? Andy
Re: Customer-facing ACLs
On Tue, 18 Mar 2008, Marshall Eubanks wrote: If it becomes normal for home users to only have 80 and 443, then how can I innovate and design something that needs a new protocol ? What happens to the new voice and video services for example ? The DOD has already been faced with this (I know of some AFB that have instituted this policy). The solution, of course, is to hire consultants (SIBR if possible) to port everything to port 80 ! That's been going on for years. Back when it was common for ISPs to run squid servers and transparently proxy to them (probably around 2000), I ran into a customer using some sort of aviation data in real time app which used port 80 (and wasn't HTTP). I had to special case traffic to that service's IP to get it not to hit squid. When I asked them why they were running a non-HTTP protocol on 80/tcp, the answer was that gets us through most firewalls. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Customer-facing ACLs
On Tue, Mar 18, 2008, Jon Lewis wrote: The solution, of course, is to hire consultants (SIBR if possible) to port everything to port 80 ! That's been going on for years. Back when it was common for ISPs to run squid servers and transparently proxy to them (probably around 2000), I ran into a customer using some sort of aviation data in real time app which used port 80 (and wasn't HTTP). I had to special case traffic to that service's IP to get it not to hit squid. When I asked them why they were running a non-HTTP protocol on 80/tcp, the answer was that gets us through most firewalls. There's patches to Squid to make it silently transparently proxy stuff that doesn't look like HTTP. (I need to make it knob-able before I commit it, as some people -like- having the must be HTTP implication of transparent interception.) Adrian
RE: Customer-facing ACLs
--- [EMAIL PROTECTED] 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? -- [EMAIL PROTECTED] wrote: From: Frank Bulk - iNAME [EMAIL PROTECTED] 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
RE: Customer-facing ACLs
Sorry, I should have been more clear. I added them a few months after I came on board. The ports that are blocked are either Window's SMB/RPC ports or the ones that (a long time ago) were used by worms. Correct, no research into traffic or contact with customers. Although some may argue that sharing one's files with their neighbor using Window's File and Print sharing is a valid service, it's generally accepted that that residential subscribers have no legitimate need to be communicating with those ports on the internet and they are 100 times to 1 more likely to carry malicious traffic than not. And as our history has shown, there's been close to zero issues. Yes, perhaps customers just didn't bother to call in to complain or that call wasn't escalated to me, but I think I could communicate a pretty convincing argument if required. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Weeks Sent: Wednesday, March 12, 2008 6:39 PM To: nanog@merit.edu Subject: RE: Customer-facing ACLs --- [EMAIL PROTECTED] 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? -- [EMAIL PROTECTED] wrote: From: Frank Bulk - iNAME [EMAIL PROTECTED] 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
Re: Customer-facing ACLs
Doesn't anyone RTFM before posting anymore? http://mail.google.com/support/bin/answer.py?hl=enanswer=13287 # Configure your client to match the settings below: Incoming Mail (POP3) Server - requires SSL: pop.gmail.com Use SSL: Yes Port: 995 Outgoing Mail (SMTP) Server - requires TLS: smtp.gmail.com (use authentication) Use Authentication: Yes Use STARTTLS: Yes (some clients call this SSL) Port: 465 or 587 There is no need to use smtp on port 25 with gmail. configure the client according to gmail's instructions and use 465 or 587. jc Frank Bulk - iNAME wrote: Those using Google for SMTP can still use their ISP's SMTP servers for outbound Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ang Kah Yik Sent: Monday, March 10, 2008 7:40 PM To: Andy Dills Cc: nanog@merit.edu Subject: Re: Customer-facing ACLs Hi Andy (and all who responded), Thanks for the heads-up on the redirection on SMTP traffic. I've yet to see an implementation of it but I agree that it's a possible solution. As for the issue I raised previously, perhaps corporate users isn't a good example but what about users of email services such as Gmail and the like?
Re: Customer-facing ACLs
Justin Shore wrote: 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. ha. I only wish that was true. We do filter all customer ports for IPs we believe from them, but darn few other providers do. (as based on my conversations with many providers when tracking down attacks from their networks) That said, we filter nothing else. Frags are explicitly dropped before any permits. ...? So you have no real, production sites?
Re: Customer-facing ACLs
On Tue, Mar 11, 2008 at 2:27 AM, Jo Rhett [EMAIL PROTECTED] wrote: Justin Shore wrote: 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. ha. I only wish that was true. We do filter all customer ports for IPs we believe from them, but darn few other providers do. (as based on my conversations with many providers when tracking down attacks from their networks) That said, we filter nothing else. Frags are explicitly dropped before any permits. ...? So you have no real, production sites? actually... depending upon platform the frags probably get through (on a cisco) if they are associated with another ongoing session... Cisco acls believe that frags are 'ok' (even if you deny fragments in the acl) unless the frag can't be put together with an existing session. Juniper just drops all frags...
Re: Customer-facing ACLs
Apologies for the delay... --- [EMAIL PROTECTED] 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
Re: Customer-facing ACLs
--- [EMAIL PROTECTED] 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
RE: Customer-facing ACLs
--- [EMAIL PROTECTED] 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
RE: Customer-facing ACLs
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? I would suggest a good resource is the MAAWG papers, and even though you are stretched thin, consider attending a MAAWG meeting. MAAWG has a lot of members that have already experienced the same situatations as you, and may be able to help. http://www.maawg.org/about/publishedDocuments Obviously, I'm biased, but I like how SBC handled it :-) Not that it was a problem free implementation.
RE: Customer-facing ACLs
Those ACLs were added when I came on board. Again, only one complaint in 3+ years. And customers wonder why I shudder when they tell me that they plug in their Win9x computers directly into their cable modem. I can't imagine how much worse it would be if I didn't block the SMB ports. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Weeks Sent: Tuesday, March 11, 2008 9:35 PM To: nanog@merit.edu Subject: RE: Customer-facing ACLs --- [EMAIL PROTECTED] 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
Re: NANOG laptops (was Re: Customer-facing ACLs)
William Allen Simpson wrote: Marshall Eubanks wrote: I used to count the proportion of Mac laptops in the room (or, at least, my row) to pass the time when I was bored. I remember at the 1999 Washington IETF I saw exactly one, and I could hear people whisper about it around me. I used to attend with various Powerbook flavors over the years. I'm sure that I wasn't the only person with a Mac at IETF in 1999. I snuck my SO into the terminal room with her Mac, too So there was two of us at least :) I probably still had my Blackbird. Mark.
Re: Customer-facing ACLs
Dave Pooser wrote: Do bots try brute force attacks on Telnet and FTP? All I see at my firewall are SSH attacks and spam. But sure, if there's a lot of Telnet abuse block 23 too; I think it's used about as rarely by normal customers as SSH is. Depending on the ip space I find FTP brute force attacks 10 times more common than SSH attacks. There really isn't a blanket rule you can impose. On a different note, unless you clearly advertise that you're offering filtered services I don't really find the practice ethical - and no a tiny line in the TOS doesn't really cut it IMHO. That doesn't mean it can't be done, simply spin the imposed ACL as a value-add and that your customers are now on a safer internet. Regards, Chris
Re: Customer-facing ACLs
Do bots try brute force attacks on Telnet and FTP? All I see at my firewall are SSH attacks and spam. But sure, if there's a lot of Telnet abuse block 23 too; I think it's used about as rarely by normal customers as SSH is. Depending on the ip space I find FTP brute force attacks 10 times more common than SSH attacks. There really isn't a blanket rule you can impose. On a different note, unless you clearly advertise that you're offering filtered services I don't really find the practice ethical - and no a tiny line in the TOS doesn't really cut it IMHO. That doesn't mean it can't be done, simply spin the imposed ACL as a value-add and that your customers are now on a safer internet. Does anyone have any handy links to actual raw data and papers about this? I'm sure we've all got our own personal datapoints to support automated network probes but I'd prefer to stuff something slightly more concrete and official(!) into the Wiki. Adrian
Re: Customer-facing ACLs
Adrian Chadd wrote: Does anyone have any handy links to actual raw data and papers about this? I'm sure we've all got our own personal datapoints to support automated network probes but I'd prefer to stuff something slightly more concrete and official(!) into the Wiki. SANS ISC might have some useful reports. I see a few links in this article: http://www.incidents.org/diary.html?storyid=4045 Justin
Re: Customer-facing ACLs
On Fri, 7 Mar 2008, Scott Weeks wrote: To me there is no question of whether or not you filter traffic for residential broadband customers. SBC in my area (Dallas) went from wide open to outbound 25 blocked by default/opened on request. I think doing the same thing with port 22 would hardly be an undue burden on users, and would help keep botnets in check. 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 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?
Re: Customer-facing ACLs
Long response with answers inline... --- [EMAIL PROTECTED] 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
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.
Re: Customer-facing ACLs
-- [EMAIL PROTECTED] wrote: -- 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. - The default policy is we allow eveything. It takes no explaining. I understand the port 25 issue and am reconsidering it for dynamic addresses on outbound traffic, but at least one person on NANOG showed me a use of that. Like network engineers at many other companies, I'm spread so thin that it's hard to find the time to do work like this and I keep putting it on the back burner. VZ had it completely open and I have followed that as we seperated this network from their network, as I can't take on the extra work of fixing brokenness that would result from applying the filter. scott
Re: Customer-facing ACLs
On Tue, 11 Mar 2008, Ang Kah Yik wrote: 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. For what it's worth, that's what port 587 was created for. And wouldn't those corporate types require VPN to access the network? On top of that, most who block 25 don't block it but direct it to internal mail servers where it can be subjected to limits and filtering. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
Re: Customer-facing ACLs
Hi Andy (and all who responded), Thanks for the heads-up on the redirection on SMTP traffic. I've yet to see an implementation of it but I agree that it's a possible solution. As for the issue I raised previously, perhaps corporate users isn't a good example but what about users of email services such as Gmail and the like? Some users do use the SMTP service instead of the web interface. But redirection should do the trick. And thanks to all who remind me about rfc 2476 - I'm not a mail admin so I'm not familiar with it but I'll read up on it. Andy Dills wrote: And wouldn't those corporate types require VPN to access the network? On top of that, most who block 25 don't block it but direct it to internal mail servers where it can be subjected to limits and filtering. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- For what it's worth, that's what port 587 was created for.
Re: Customer-facing ACLs
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? I understand the port 25 issue and am reconsidering it for dynamic addresses on outbound traffic, but at least one person on NANOG showed me a use of that. Like network engineers at many other companies, I'm spread so thin that it's hard to find the time to do work like this and I keep putting it on the back burner. VZ had it completely open and I have followed that as we seperated this network from their network, as I can't take on the extra work of fixing brokenness that would result from applying the filter. Like I said, there is always a default policy whether you know what that policy is or not. You probably end up spending the resources on the front-end or on the back-end. 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.
Re: Customer-facing ACLs
On Mon, Mar 10, 2008 at 7:58 PM, Ang Kah Yik [EMAIL PROTECTED] wrote: 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? vpns fix this... 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. 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.) 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. many config's actually just use WCCP to transparently redirect your smtp to an authorized SMTP server as Andy Dills points out. -Chris
Re: Customer-facing ACLs
I've attempted to summarise the replies I found useful in the Wiki: http://nanog.cluepon.net/index.php/MailTopics#Customer-Facing_ACLs My personal observations: * More information about what networks are doing would be nice! * More data points about probes/scans/etc would be nice! * Filtering technologies would be nice for ACLs - not shaping of things like BT/YT/etc - stuff like how to deploy per-customer ACLs on a variety of tech. I know I've used ACLs in Radius AV pairs in a SP environment for DSL aggregation; I've also used similar hackery in 802.1x for per-port ethernet ACLs in an Enterprise environment. Has anyone rolled out 802.1x style port authentication in a ethernet- edge scenario and included ACLs/shaping AV-pairs? Experience/Feedback would be great. Constructive comments appreciated. Adrian
Re: Customer-facing ACLs
Ang Kah Yik wrote: 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? 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. Thanks for joining the discussion. Frankly I'd be surprised to find many corps with an externally-accessible SMTP server that would accept mail on tcp/25. The only way they'd do it is with SMTP AUTH which (hopefully) implies the use of SMTP TLS as well. I know of very few corps that actually do this. Most of the corps I can think of are either running Exchange and utilizing RPC over HTTP, simply point their users to their company's webmail server, or require that their users VPN back to HQ to access their internal MTA. The sites that I can think of with external user-accessible SMTP daemons are entities with highly technical users. They utilize SMTP AUTH, TLS, and the Mail Submission Port on tcp/587. I'm afraid they are in the minority though. The MSP port is the best way to get around the blocks with decent MTAs. Your local MTA's support for other non-standard mechanisms for relaying mail from untrusted networks may also help with this problem (RPC over HTTP). Other than that I don't think there's enough demand for outgoing SMTP from the masses to warrant not blocking it. Redirecting generally takes care of that anyway. Thanks for the input though. All thoughts are welcome. Justin
RE: Customer-facing ACLs
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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.
RE: Customer-facing ACLs
Those using Google for SMTP can still use their ISP's SMTP servers for outbound Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ang Kah Yik Sent: Monday, March 10, 2008 7:40 PM To: Andy Dills Cc: nanog@merit.edu Subject: Re: Customer-facing ACLs Hi Andy (and all who responded), Thanks for the heads-up on the redirection on SMTP traffic. I've yet to see an implementation of it but I agree that it's a possible solution. As for the issue I raised previously, perhaps corporate users isn't a good example but what about users of email services such as Gmail and the like? Some users do use the SMTP service instead of the web interface. But redirection should do the trick. And thanks to all who remind me about rfc 2476 - I'm not a mail admin so I'm not familiar with it but I'll read up on it. Andy Dills wrote: And wouldn't those corporate types require VPN to access the network? On top of that, most who block 25 don't block it but direct it to internal mail servers where it can be subjected to limits and filtering. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- For what it's worth, that's what port 587 was created for.
NANOG laptops (was Re: Customer-facing ACLs)
Hi, On Mar 8, 2008, at 2:40 PM, William Norton wrote: I was quite surprised to see the large number of Mac laptops at NANOG 42. I didn't do a formal count but it seemed like about 1/4 to 1/3 of the laptops in use were Macs. ...You know, now that you mention it, I was also quite impressed with how many macbook pros there were in room as well. That would be good to informally track I think : what tools(laptops) do NANOG folk tend to use? Macbook Pro (all of IANA (with one recent exception) use Macs of one form or another). as this data might help SW dev types to target their netTools distributions to mac platforms more quickly. That would be nice. In the good ole days it seemed like 99% were PCs maybe a couple were reinstalled with some form of unix, I remember the 'good old days' a bit differently -- folks were indeed using PCs (Digital HiNote Ultras and hten Sony Vaio 505TXs) but reinstallation was the norm. Maybe it was just to crowd I hung out with... Regards, -drc
Re: NANOG laptops (was Re: Customer-facing ACLs)
i am moving to a macbook pro, or trying to, from a freebsd/winxp. but why did they have to 'add value' by mucking with freebsd and breaking my fingers? and whoever thought the mac screen was good never used my alienware 1920x1024. at the ipv4 econ meet on tasman last week, macs were in extreme majority. randy
Re: NANOG laptops (was Re: Customer-facing ACLs)
On Mar 9, 2008, at 3:21 PM, David Conrad wrote: Hi, On Mar 8, 2008, at 2:40 PM, William Norton wrote: I was quite surprised to see the large number of Mac laptops at NANOG 42. I didn't do a formal count but it seemed like about 1/4 to 1/3 of the laptops in use were Macs. ...You know, now that you mention it, I was also quite impressed with how many macbook pros there were in room as well. That would be good to informally track I think : what tools(laptops) do NANOG folk tend to use? Macbook Pro (all of IANA (with one recent exception) use Macs of one form or another). as this data might help SW dev types to target their netTools distributions to mac platforms more quickly. That would be nice. In the good ole days it seemed like 99% were PCs maybe a couple were reinstalled with some form of unix, I used to count the proportion of Mac laptops in the room (or, at least, my row) to pass the time when I was bored. Nanog-29 was the first where I saw a substantial proportion. I remember at the 1999 Washington IETF I saw exactly one, and I could hear people whisper about it around me. Now, there are too many to make it interesting. Regards Marshall I remember the 'good old days' a bit differently -- folks were indeed using PCs (Digital HiNote Ultras and hten Sony Vaio 505TXs) but reinstallation was the norm. Maybe it was just to crowd I hung out with... Regards, -drc
Re: NANOG laptops (was Re: Customer-facing ACLs)
So the overwhelming question for me is why? Is it simply the fact that the native *nix underpinnings are where most users (within the aforementioned demographic) spend most of their time anyway? That's what did it for me - repeated attempts to get FreeBSD to run stable on the Inspiron I had at the time. Note: The question isn't what's better, the question is what got all us router and systems jockeys so interested in the first place. If this is too OT (or has the potential to become so), feel free to kill it. On 9-Mar-08, at 3:29 PM, Randy Bush [EMAIL PROTECTED] wrote: i am moving to a macbook pro, or trying to, from a freebsd/winxp. but why did they have to 'add value' by mucking with freebsd and breaking my fingers? and whoever thought the mac screen was good never used my alienware 1920x1024. at the ipv4 econ meet on tasman last week, macs were in extreme majority. randy
Re: NANOG laptops (was Re: Customer-facing ACLs)
my laptop, and both my desktops, run KDE. the underlying operating system is usually something like opensuse (a linux distro) or pcbsd or desktopbsd (which are freebsd distros). all i need from the OS is to support KDE well, patch itself from a vendor mothership often, do suspend/resume and wireless. the laptop hardware itself is thinkpad, to get a 3-button mouse, full sized keys, and relative indestructibility. desktops are homebrew intel core-2, with 15-year-old ibm high-clicky keyboards and 10-year old logitech mice. the servers are all freebsd, to get /usr/ports (and recently, to get ZFS.) server hardware tends to be supermicro. starting to abandon 3ware/areca RAID in favour of either JBOD or multiport SATA-II, with ZFS. -- Paul Vixie
Re: NANOG laptops (was Re: Customer-facing ACLs)
On 3/9/08, Jason Lixfeld [EMAIL PROTECTED] wrote: So the overwhelming question for me is why? Is it simply the fact that the native *nix underpinnings are where most users (within the aforementioned demographic) spend most of their time anyway? That's what did it for me - repeated attempts to get FreeBSD to run stable on the Inspiron I had at the time. The slight differences in the OS X gui vs 'Doze or KDE drive me nuts, though. Full time Mac use doesn't interest me. Anybody that knows me from any of the other 90 lists I'm on has probably heard me talking up my Asus Eee PC, a $399 tiny Linux laptop, which I'm very happy with and works great. When I'm traveling, I'm all about small form factor and light -- and the Eee is far better (and far cheaper) than my previous travel computer, an OQO Model 02 UMPC. If you want a laptop with Linux out of the box, no weird driver issues (works great with my Sprint EVDO card), etc., etc., I'd highly recommend the Eee. Takes about 2 seconds to enable full KDE, comes with a bunch of stuff preloaded, and it only weighs a couple pounds. The downsides are few; the small disk space (4GB SSD) is probably the biggest. Since it has an SDHC card slot, I added a 16GB SDHC card to mine. I've also had a hell of a time getting the Cisco AnyConnect VPN client working (but normal pptp vpn support has been a breeze). Regards, Al Iverson -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA Remove lists from my email address to reach me faster and directly.
Re: Customer-facing ACLs
Dave Pooser wrote: I can understand the logic of dropping the port, but theres some additional thought involved when looking at Port 22 - maybe i'm not well-read enough, but the bots I've seen that are doing SSH scans, etc, are not usually on Windows systems. I can figure them working on Linux, MacOS systems - but surely the vast majority of 'vulnerable' hosts are those running OS's coming from our favourite megacorp? Which typically don't come shipped with neither SSH server nor SSH client... ? They typically don't ship with an SMTP server either. Considering that my preferred SSH client for Windows weighs in as a single 412k .exe, I'd imagine that bot designers are just writing their own SSH clients for brute-forcing. Or are simply writing a bot that sens TCP SYNs to port 22 and are reporting those hosts that responds with a SYN ACK back to the CC. Then the CC can direct other compromised hosts with a more complete rootkit (or compromised *nix host) to do brute-force userid/password guessing. Half the Mac users? You think? I know a dozen or so sysadmins who use Macs, and about a hundred users who wouldn't know SSH from PCP; I think that's probably a slightly skewed sample considering I'm a Mac geek who hangs around with Mac geeks, and I'd guess the consumer users are a larger percentage of the real-life population. I'd expect the number of folks who want SSH unblocked to be under 1% of a consumer broadband network, and probably closer to 0.1% or so. And again, it ought to be trivial to let your users unblock the system, either via phone call or via self-service Web page (though in the latter case you'd better use a captcha or something so the bot doesn't automatically unblock itself). Agreed. I don't think the end-user's OS makes them more or less likely to be using SSH unless the OS is a BSD or Linux (then I suspect you'd get a disproportionate # of SSH users compared to the other more simple OSs). Justin
Re: NANOG laptops (was Re: Customer-facing ACLs)
Macbook Pro (all of IANA (with one recent exception) use Macs of one form or another). All of PCH uses MacBook Pros. Except Gaurab, who uses a MacBook Air. :-) In the good ole days it seemed like 99% were PCs maybe a couple were reinstalled with some form of unix, I remember the 'good old days' a bit differently -- folks were indeed using PCs (Digital HiNote Ultras and hten Sony Vaio 505TXs) but reinstallation was the norm. Maybe it was just to crowd I hung out with... In the good _old_ days, before the HiNotes, everybody used Duos, then the HiNotes with FreeBSD, then the Vaios started creeping in, then the Titanium PowerBooks came out. -Bill
Re: NANOG laptops (was Re: Customer-facing ACLs)
definitely agree with supermicro, freebsd, zfs for servers. it rocks! and i lived through duo, hinote, viao, thinkpad, alienware, and now mac. i keep the alienware because it has real graphics, 1920x1024, as opposed to the mac. on the alienware, i run winxp with cygwin as host, vmware, and then the freebsd as guest. if the winxp gets sick, i can suspend the freebsd, reboot the xp, and resume the suspended freebsd. so the bsd has a much longer uptime than the host winxp opsys. how's that for a sick twist? randy
Re: NANOG laptops (was Re: Customer-facing ACLs)
On Sun, 9 Mar 2008, Randy Bush wrote: and i lived through duo, hinote, viao, thinkpad, alienware, and now mac. i keep the alienware because it has real graphics, 1920x1024, as opposed to the mac. There was a guy from Amazon at the San Jose meeting who'd transplanted an ultra-high-resolution 15 LCD into his MacBook Pro, after the original one had cracked. I _think_ it was 1280x2048, but I'm not sure I'm remembering accurately. The pixels were too fine for me to see, no matter how close I looked. He said the connector and bolt-positions were identical, but it had required that he compile a new driver before it worked. -Bill
Re: NANOG laptops (was Re: Customer-facing ACLs)
Marshall Eubanks wrote: I used to count the proportion of Mac laptops in the room (or, at least, my row) to pass the time when I was bored. I remember at the 1999 Washington IETF I saw exactly one, and I could hear people whisper about it around me. I used to attend with various Powerbook flavors over the years. I'm sure that I wasn't the only person with a Mac at IETF in 1999. I snuck my SO into the terminal room with her Mac, too In the *really* old days, MacTCP (and MacPPP, of course) were pretty common among my compatriots, talking to Sun farms. But in those days, I used PC desktops and laptops with KA9Q NOS. We ran an ISP entirely on MacOS machines (with NetBlazers and PortMasters) from 1994 to circa 1999, when Yellow Dog Linux became available.
Re: Customer-facing ACLs
I can understand the logic of dropping the port, but theres some additional thought involved when looking at Port 22 - maybe i'm not well-read enough, but the bots I've seen that are doing SSH scans, etc, are not usually on Windows systems. I can figure them working on Linux, MacOS systems - but surely the vast majority of 'vulnerable' hosts are those running OS's coming from our favourite megacorp? Which typically don't come shipped with neither SSH server nor SSH client... ? They typically don't ship with an SMTP server either. Considering that my preferred SSH client for Windows weighs in as a single 412k .exe, I'd imagine that bot designers are just writing their own SSH clients for brute-forcing. To me, at least half the users likely to be running either Linux or Mac are going to be the same users who're going to request they be allowed outbound SSH is the blocking of outbound SSH considered to be sufficiently useful that we're advocating it these days? Half the Mac users? You think? I know a dozen or so sysadmins who use Macs, and about a hundred users who wouldn't know SSH from PCP; I think that's probably a slightly skewed sample considering I'm a Mac geek who hangs around with Mac geeks, and I'd guess the consumer users are a larger percentage of the real-life population. I'd expect the number of folks who want SSH unblocked to be under 1% of a consumer broadband network, and probably closer to 0.1% or so. And again, it ought to be trivial to let your users unblock the system, either via phone call or via self-service Web page (though in the latter case you'd better use a captcha or something so the bot doesn't automatically unblock itself). -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
Re: Customer-facing ACLs
On Sat, Mar 08, 2008, Mark Foster wrote: To me, at least half the users likely to be running either Linux or Mac are going to be the same users who're going to request they be allowed outbound SSH is the blocking of outbound SSH considered to be sufficiently useful that we're advocating it these days? (Aren't we all just moving SSH to non-standard ports within our networks anyway?) .. I'm surprised botnets aren't big enough right now to do surreptitious port scans of machines (there's 'only' 64k ports nowdays!) over timeframes measured in weeks, from arbitrary bots (ie, not a single IP) to get a scanning footprint to later submit in the crack queue. Makes me think about Google, to be honest. Who has more machines, botnets, or google? :) Adrian
RE: Customer-facing ACLs
Sorry if I wasn't more clear, but I'm not asking about inbound attempts, I'm asking about the number of outbound attempts a host would perform. Frank -Original Message- From: Joel Jaeggli [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2008 11:41 PM To: [EMAIL PROTECTED] Cc: 'Mark Foster'; Dave Pooser; nanog@merit.edu Subject: Re: Customer-facing ACLs Frank Bulk wrote: The last few spam incidents I measured an outflow of about 2 messages per second. Does anyone know how aggressive Telnet and SSH scanning is? Even if it was greater, it's my guess there are many more hosts spewing spam than there are running abusive telnet and SSH scans. Judging by the hits on my firewall there's a fair amount of variation between the scanners that are doing a couple login attempts per hour, and the bot that's making thousands of login attempts with 4 or 5 connection attempts going at a time. We don't filter them till they hit a threshold. I don't even bother to log telnet attempts anymore so I can't say much about that. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Foster Sent: Friday, March 07, 2008 10:02 PM To: Dave Pooser Cc: nanog@merit.edu Subject: Re: Customer-facing ACLs Blocking port 25 outbound for dynamic users until they specifically request it be unblocked seems to me to meet the no undue burden test; so would port 22 and 23. Beyond that, I'd probably be hesitant until I either started getting a significant number of abuse reports about a certain flavor of traffic that I had reason to believe was used by only a tiny minority of my own users. Sorry, I must've missed something. Port 25 outbound (excepting ISP SMTP server) seems entirely logical to me. Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a concern? I can only assume it's to stop clients exploited boxen being used to anonymise further telnet/ssh attempts - but have to admit this discussion is the first i've heard of it being done 'en masse'. It'd frustrate me if I jacked into a friends Internet in order to do some legitimate SSH based server administration, I imagine... Is this not 'reaching' or is there a genuine benefit in blocking these ports as well? Mark.
Re: Customer-facing ACLs
Mark Foster wrote: Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a concern? I can only assume it's to stop clients exploited boxen being used to anonymise further telnet/ssh attempts - but have to admit this discussion is the first i've heard of it being done 'en masse'. I don't think there's much to be gained from blocking ingress 22 from customers. I don't see any SSH scans originating from my customers (though there is always the potential). I wouldn't have any issues with blocking outbound telnet though but I can't really justify it either since I don't see a real big problem with that kind of traffic originating on my network either. Now inbound SSH and Telnet (destined for my customers) should be blocked IMHO. Doing a little prodding around our netspace I've found most SSH installs to be of a known vulnerable version or at least an old version yet to have any vulnerabilities found in. Nothing positive could come from letting them get compromised. We would of course offer a way for users to get around the block. Our current approach is to have them sign up for a static IP (another $5/month). The fee keeps everyone from automatically signing up for is as free stuff but still gives the legit users an inexpensive way to get what they need. It'd frustrate me if I jacked into a friends Internet in order to do some legitimate SSH based server administration, I imagine... Agreed but remember that people like you, I and the rest of the readers of NANOG are a teeny tiny minority on the Internet. I could pick a couple thousand of my users at random and not find one that knows what SSH is. Is this not 'reaching' or is there a genuine benefit in blocking these ports as well? I don't think there's much to be gained from blocking telnet SSH from the customers to the Internet. Blocking SMTP in the same direction is critical IMHO. Blocking the same 3 ports back to the customer makes sense to me though. I think there is a real and tangible benefit to the exercise. Justin
Re: Customer-facing ACLs
It varies widely. I see some extremely slow scans (1 SYN every 2-5 minutes). This is what someone on the SANS ISC page mentioned I believe. I've also seen scans last for up to 10 minutes. The consistency of the speeds made me think that perhaps the scanning computer was on a slow link. The worst scans are the ones that last a second or two and hit us with a SYN for every IP in our allocations. That kind of scan and its flood of packets is the one that I don't think I can stop without some sort of QoS. I've seen coordinated scans with everything from 2 to about a dozen different hosts scanning seemingly random IPs across our network. I know it's coordinated though because together they hit every IP but never hit the same IP by more than one scanner. I've seen scans that clearly learn where the accessible SSH daemons are, that then feed this info back to the puppet master so he can command a different compromised host (or hosts) to then handle the attacks. I've also see a scanner first scan our network and then immediately start pounding on the accessible daemons. Finally I've see the scanner stop its scan in mid-stream, pound on an accessible daemon for a while with a pre-defined set of userids and then continue on with the scans. Clearly there's some variation in the scanning methods. Justin Frank Bulk wrote: The last few spam incidents I measured an outflow of about 2 messages per second. Does anyone know how aggressive Telnet and SSH scanning is? Even if it was greater, it's my guess there are many more hosts spewing spam than there are running abusive telnet and SSH scans.
RE: Customer-facing ACLs
While I don't do flow monitoring today, when monitoring for outbound spam with Wirekshark I have seen hosts systematically check all the hosts in the block for an open SMTP port. I'm sure a lot more is going on that I don't know. The patterns are obvious to the human observer -- too bad that such logic isn't built into the firewall. I know there are some enterprise security admins that subscribe to the approach that all inbound and outbound traffic is blocked by defacto, with a few ports opened up in either direction for known applications. Of course, port 80 becomes the port of choice for all the undesired apps. Frank -Original Message- From: Justin Shore [mailto:[EMAIL PROTECTED] Sent: Saturday, March 08, 2008 12:28 PM To: [EMAIL PROTECTED] Cc: 'Mark Foster'; Dave Pooser; nanog@merit.edu Subject: Re: Customer-facing ACLs It varies widely. I see some extremely slow scans (1 SYN every 2-5 minutes). This is what someone on the SANS ISC page mentioned I believe. I've also seen scans last for up to 10 minutes. The consistency of the speeds made me think that perhaps the scanning computer was on a slow link. The worst scans are the ones that last a second or two and hit us with a SYN for every IP in our allocations. That kind of scan and its flood of packets is the one that I don't think I can stop without some sort of QoS. I've seen coordinated scans with everything from 2 to about a dozen different hosts scanning seemingly random IPs across our network. I know it's coordinated though because together they hit every IP but never hit the same IP by more than one scanner. I've seen scans that clearly learn where the accessible SSH daemons are, that then feed this info back to the puppet master so he can command a different compromised host (or hosts) to then handle the attacks. I've also see a scanner first scan our network and then immediately start pounding on the accessible daemons. Finally I've see the scanner stop its scan in mid-stream, pound on an accessible daemon for a while with a pre-defined set of userids and then continue on with the scans. Clearly there's some variation in the scanning methods. Justin Frank Bulk wrote: The last few spam incidents I measured an outflow of about 2 messages per second. Does anyone know how aggressive Telnet and SSH scanning is? Even if it was greater, it's my guess there are many more hosts spewing spam than there are running abusive telnet and SSH scans.
Re: Customer-facing ACLs
Dave Pooser wrote: Half the Mac users? You think? I know a dozen or so sysadmins who use Macs, [raises hand...] and about a hundred users who wouldn't know SSH from PCP; I think that's probably a slightly skewed sample considering I'm a Mac geek who hangs around with Mac geeks, and I'd guess the consumer users are a larger percentage of the real-life population. I was quite surprised to see the large number of Mac laptops at NANOG 42. I didn't do a formal count but it seemed like about 1/4 to 1/3 of the laptops in use were Macs. I'd expect the number of folks who want SSH unblocked to be under 1% of a consumer broadband network, and probably closer to 0.1% or so. And again, it ought to be trivial to let your users unblock the system, either via phone call or via self-service Web page (though in the latter case you'd better use a captcha or something so the bot doesn't automatically unblock itself). I'm against the slippery slope of blocking ports by default, with the possible exception of SMTP if the provider offers a well-publicized local SMTP server. Servers that must leave ssh open to the Internet can and should consider using some form of time-out script like this one: http://www.pettingers.org/code/SSHBlack.html -- Jay Hennigan - CCIE #7880 - Network Engineering - [EMAIL PROTECTED] Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
Re: Customer-facing ACLs
I was quite surprised to see the large number of Mac laptops at NANOG 42. I didn't do a formal count but it seemed like about 1/4 to 1/3 of the laptops in use were Macs. ...You know, now that you mention it, I was also quite impressed with how many macbook pros there were in room as well. That would be good to informally track I think : what tools(laptops) do NANOG folk tend to use? as this data might help SW dev types to target their netTools distributions to mac platforms more quickly. In the good ole days it seemed like 99% were PCs maybe a couple were reinstalled with some form of unix, and the rare and incompatible couple of macs in the room were driven by freaks speaking a different language (appletalk) and hitting weirder clover keys than the rest of us. Now, Apple seems to be the neteng laptop of choice, what the cool kids drive. Bill
Re: Customer-facing ACLs
On Saturday 08 March 2008, Justin Shore wrote: 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. We supply to mid-to-small ISP's mostly, and sizeable enterprise customers; so the degree to which we can filter is limited. That said, at the edge, we run uRPF on all customer-facing ports (loose or strict, depending on the deployment). In addition, on each edge router's core-facing uplinks, we run egress ACL's matching RFC 1918 and RFC 3330 (yes, with uRPF downstream to the customers, this might seem redundant, but we've actually seen some 'catches', so it appears to help us solidify our filtering implementation). In the core, we don't filter or run uRPF, for obvious reasons. On our border routers, we deploy ingress filters, again, cutting off RFC 1918 and RFC 3330. On peering routers (private peering and exchange points), we run uRPF on our peering interface (taking care to run loose mode in case private peers also peer at the public exchange point). Again, upstream ACL's are implemented on core-facing uplinks to double-check. As you can tell, we don't filter protocols/ports/applications. We leave that to the customer, and insist on it. All the above goes for IPv6 as well, as appropriate. We are also quite picky about NLRI filtering (BGP), but that's beyond this scope :-). Hope this helps. Cheers, Mark. signature.asc Description: This is a digitally signed message part.
Re: Customer-facing ACLs
On Fri, 7 Mar 2008, Justin Shore wrote: 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? In my previous life, I worked at a mid-sized ISP. A common practice for bridged DSL customers was to block outbound traffic to the various Netbios ports, along with a few other ports that were added at the time to keep Slammer and friends under control. We also deployed filters through RADIUS that covered much of the same ground for dialup and PPPoE DSL users and it worked reasonably well. I do recall weighing the merits of extending that to drop outbound SMTP to exerything except our mail farm, but it wasn't deployed because there was a geat deal a fear of customer backlash and that it would drive more calls into the call center. jms
Re: Customer-facing ACLs
On Fri, 07 Mar 2008 13:55:05 CST, Justin Shore said: 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. You're new here, aren't you? :) pgpck6mspgZyp.pgp Description: PGP signature
Re: Customer-facing ACLs
[EMAIL PROTECTED] wrote: On Fri, 07 Mar 2008 13:55:05 CST, Justin Shore said: 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. You're new here, aren't you? :) Hopefully optimistic. Don't bum me out going into a weekend... :-) From the looks of my ingress BOGON ACLs on my borders (yes, I'm using ACLs and not null routes for a reason) I'd most people not reading NANOG (and maybe even some of them!) are not doing any ingress filtering on their customer source IPs. Sad Justin
Re: Customer-facing ACLs
I would *love* to be able to run uRPF on all of our edge devices, but we use Cisco ME3400s, 3550s, 3560s and they don't support it. :-( [EMAIL PROTECTED] wrote: On Fri, 07 Mar 2008 13:55:05 CST, Justin Shore said: 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. You're new here, aren't you? :)
Re: Customer-facing ACLs
On Fri, Mar 07, 2008 at 01:55:05PM -0600, Justin Shore wrote: 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. ... As part of a recent measurement project, we estimate the prevalence of ingress and egress blocking (though under the guise of neutrality). For customer facing filters, we leverage protocols which provide port-specific redirects, e.g. HTTP, Gnutella, etc. For traffic toward customers, we use port-specific tcptraceroutes. Some published data for the curious: http://ana.csail.mit.edu/rsp/ Reader's digest summary: NetBIOS ports (and the innocent profile service) 135-139 are among the most frequently blocked, along with SMTP, POP3 and filters that have stuck around due to various worms such as MS-SQL. That said, around 94% of the 16bit port space was unblocked by any network. Curious to other's answer to this high-level question -- and the more mundane question of filter maintenance. rob
Re: Customer-facing ACLs
Justin M. Streiner wrote: I do recall weighing the merits of extending that to drop outbound SMTP to exerything except our mail farm, but it wasn't deployed because there was a geat deal a fear of customer backlash and that it would drive more calls into the call center. This seems to be very common practice these days for larger ISPs/dialup aggregators using the appropriate RADIUS attributes on supported access servers. We generally restrict outbound SMTP on our dial-up users so they may only reach our hosts (or the mail hosts of our wholesale customers). Our DSL subscribers, both dynamic and static, are currently unfiltered -- but we're very quick to react to abuse incidents and apply filters when necessary until the user cleans up their network. I'm currently on the fence with regards to filtering SMTP for all of our dynamic DSL folks. It'd be nice to prevent abuse before it happens, but it's a matter of finding the time to integrate the filtering into our wholesale backend and making sure there aren't any unforeseen issues. -- Kameron
RE: Customer-facing ACLs
We also use ingress bogon ACLs at our borders. -- Tim Sanderson, network administrator [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Shore Sent: Friday, March 07, 2008 3:20 PM To: [EMAIL PROTECTED] Cc: NANOG Subject: Re: Customer-facing ACLs [EMAIL PROTECTED] wrote: On Fri, 07 Mar 2008 13:55:05 CST, Justin Shore said: 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. You're new here, aren't you? :) Hopefully optimistic. Don't bum me out going into a weekend... :-) From the looks of my ingress BOGON ACLs on my borders (yes, I'm using ACLs and not null routes for a reason) I'd most people not reading NANOG (and maybe even some of them!) are not doing any ingress filtering on their customer source IPs. Sad Justin
Re: Customer-facing ACLs
On Mar 7, 2008, at 12:55 PM, Justin Shore wrote: 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. We did ask some of these questions in the latest Infrastructure Security Survey, available here: http://www.arbornetworks.com/report Or here if you'd prefer not to register: http://www.tcb.net/wisr_2007_v3.pdf We're in the process of putting the next round of questions together, so if there are things you'd like added please let us know. -danny
Re: Customer-facing ACLs
--- 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. --- From a port-blocking point of view, some companies give access to the entire internet (good and bad) to their customers. Mine are mostly residential. scott fire + gasoline = religious argument on this issue that we've had *many* times in the past... ;-)
RE: Customer-facing ACLs
Same concerns here. Glad to know we're not alone. I think a transition to blocking outbound SMTP (except for one's own e-mail servers) would benefit from an education campaign, but perhaps the pain level is small enough that it can implemented without. One could start doing a subnet block a day to keep the helpdesk people sane, and then apply a global block at the edge once done to catch any subnets that one might have missed. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kameron Gasso Sent: Friday, March 07, 2008 2:44 PM To: Justin M. Streiner Cc: NANOG Subject: Re: Customer-facing ACLs Justin M. Streiner wrote: I do recall weighing the merits of extending that to drop outbound SMTP to exerything except our mail farm, but it wasn't deployed because there was a geat deal a fear of customer backlash and that it would drive more calls into the call center. This seems to be very common practice these days for larger ISPs/dialup aggregators using the appropriate RADIUS attributes on supported access servers. We generally restrict outbound SMTP on our dial-up users so they may only reach our hosts (or the mail hosts of our wholesale customers). Our DSL subscribers, both dynamic and static, are currently unfiltered -- but we're very quick to react to abuse incidents and apply filters when necessary until the user cleans up their network. I'm currently on the fence with regards to filtering SMTP for all of our dynamic DSL folks. It'd be nice to prevent abuse before it happens, but it's a matter of finding the time to integrate the filtering into our wholesale backend and making sure there aren't any unforeseen issues. -- Kameron
Re: Customer-facing ACLs
Scott Weeks wrote: fire + gasoline = religious argument on this issue that we've had *many* times in the past... ;-) I wore my flame-retardent tidy whiteys today though so I'm prepared. :-) I can understand the problem from both camps. As a tech-savvy user I don't want my provider to filter my Internet (I pay for both halves!). However having spent more time that I care to admit doing customer support and as a SP engineer I recognize the need to protect the masses who can't (or can't be bothered to) do it for themselves. SPs are really damned if we do and damned if we don't. Frankly I would rather do something than nothing. My overhead will increase in all categories if I do nothing. Infected hosts consume a significant portion of my resources. Tackling the problem reduces my overall support costs, increases 99% of my customers' overall satisfaction with our prices and services, but increases my labor costs and will spurn the ire of the 1% of my users who are tech-savvy enough to want/need unfiltered Internet access (or even understand the full implications of it, beyond the they're filtering something that was sent to me! limited thought process). To me there is no question of whether or not you filter traffic for residential broadband customers. The only thing beyond that is whether you as a SP also offer unfiltered packages. I personally thought the old SpeakEasy model was a nice approach. The unfiltered SysAdmin package was the perfect solution in my opinion. With my userbase I can think of only a tiny fraction of the users who would need such an offering. This would provide an acceptable solution for that very small percentage of users that need this kind of access. The other 99% of the users reap the benefits of our filtering. Problem solved IMHO. So that only leaves the question of what ports to block or rate-limit. Minimizing FPs is important. I think one could probably block 90% of the common crap without too much overhead. The remaining 10% would likely require too much labor to be worthwhile unless you were a sizable entity and could justify you RD by the sheer mass of your userbase. Justin
Re: Customer-facing ACLs
To me there is no question of whether or not you filter traffic for residential broadband customers. SBC in my area (Dallas) went from wide open to outbound 25 blocked by default/opened on request. I think doing the same thing with port 22 would hardly be an undue burden on users, and would help keep botnets in check. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
Re: Customer-facing ACLs
--- [EMAIL PROTECTED] wrote: To me there is no question of whether or not you filter traffic for residential broadband customers. SBC in my area (Dallas) went from wide open to outbound 25 blocked by default/opened on request. I think doing the same thing with port 22 would hardly be an undue burden on users, and would help keep botnets in check. Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery! scott
RE: Customer-facing ACLs
That's the problem isn't it? Who decides what can and cant go through. I think the tier approach is better, a basic user account where everything is blocked and a Sysadmin type account where everything is open. If the price is different enough then only people who are going to use those extra ports will actually pay for it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Weeks Sent: Friday, March 07, 2008 5:57 PM To: nanog@merit.edu Subject: Re: Customer-facing ACLs --- [EMAIL PROTECTED] wrote: To me there is no question of whether or not you filter traffic for residential broadband customers. SBC in my area (Dallas) went from wide open to outbound 25 blocked by default/opened on request. I think doing the same thing with port 22 would hardly be an undue burden on users, and would help keep botnets in check. Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery! scott CONFIDENTIALITY AND SECURITY NOTICE The contents of this message and any attachments may be confidential and proprietary and also may be covered by the Electronic Communications Privacy Act. This message is not intended to be used by, and should not be relied upon in any way by, any third party. If you are not an intended recipient, please inform the sender of the transmission error and delete this message immediately without reading, disseminating, distributing or copying the contents. Citadel makes no assurances that this e-mail and any attachments are free of viruses and other harmful code.
Re: Customer-facing ACLs
Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery! Do bots try brute force attacks on Telnet and FTP? All I see at my firewall are SSH attacks and spam. But sure, if there's a lot of Telnet abuse block 23 too; I think it's used about as rarely by normal customers as SSH is. And I'm amazed how often slippery slope arguments are deployed to oppose any sort of change at all. What percentage of consumer broadband users do you think use SSH to connect to remote servers? 1%? 0.1%? 0.01%? It seems intuitively obvious that the number of people who will call the help desk to unblock their SSH (which should be a ~2 minute call anyway, if not a self-service Web page with captcha) would be an order of magnitude less than the number of remote network users who WON'T be calling/emailing your abuse desk to complain about bots on your network hammering their servers. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
RE: Customer-facing ACLs
--- [EMAIL PROTECTED] wrote: That's the problem isn't it? Who decides what can and cant go through. I think the tier approach is better, a basic user account where everything is blocked and a Sysadmin type account where everything is open. If the price is different enough then only people who are going to use those extra ports will actually pay for it. We need to take this off-line. All long timers are groaning, rolling their eyes and putting this in their kill file. Try convincing your product managers to create a new product just to appease 'sysadmin types'. scott
RE: Customer-facing ACLs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Scott Weeks [EMAIL PROTECTED] wrote: We need to take this off-line. All long timers are groaning, rolling their eyes and putting this in their kill file. Try convincing your product managers to create a new product just to appease 'sysadmin types'. Or perhaps engage the discussion on a security-related mailing list. A couple of suggestions: The DShield list: http://lists.dshield.org/mailman/listinfo/list Funsec: https://linuxbox.org/cgi-bin/mailman/listinfo/funsec - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFH0fhsq1pz9mNUZTMRAkIxAKDs7DqstE6bDyNmAbRkqrCW78pAtwCdH1hm gKrRg7ZAkEat2zx7XzRG+Nk= =SRGz -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Customer-facing ACLs
Scott Weeks wrote: We need to take this off-line. All long timers are groaning, rolling their eyes and putting this in their kill file. Are the long-timers groaning and ignoring this thread? I certainly hope not. It's threads like these that need the benefit of their experience the most. Perhaps the long-timers could recommend a better destination for queries like these because I have more questions I want to ask (my next being about walled gardens). If they're tired of answering the same threads over and over again, then the query must be common enough to warrant a BCP or at the very least a couple documents in a knowledgebase somewhere. Perhaps my Google-fu isn't what it used to be but I couldn't manage to find any relevant docs online; not even a NANOG presentation. Try convincing your product managers to create a new product just to appease 'sysadmin types'. We're not in the business of alienating any customers. If we can create a bundle that meets a group of potential customers' needs we will. It's just another paragraph on the sales literature that we give our CSRs and a little more work that I'll have to do in configuration. I'm planning on rolling out SOHO and Gamer packages this year. Adding a SysAdmin package wouldn't be much additional work. I predict the adoption rate to be the highest with the Gamer package, followed by the SOHO package and finally the SysAdmin package. I hope this thread isn't destined for an untimely death. I've received a number of off-list queries for summary information because those individuals are also interested in customer-facing ACLs. The information I have to summarize at this point is brief and incomplete. Justin
Re: Customer-facing ACLs
On Fri, 7 Mar 2008, Dave Pooser wrote: Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery! Do bots try brute force attacks on Telnet and FTP? All I see at my firewall are SSH attacks and spam. But sure, if there's a lot of Telnet abuse block 23 too; I think it's used about as rarely by normal customers as SSH is. And I'm amazed how often slippery slope arguments are deployed to oppose any sort of change at all. What percentage of consumer broadband users do you think use SSH to connect to remote servers? 1%? 0.1%? 0.01%? It seems intuitively obvious that the number of people who will call the help desk to unblock their SSH (which should be a ~2 minute call anyway, if not a self-service Web page with captcha) would be an order of magnitude less than the number of remote network users who WON'T be calling/emailing your abuse desk to complain about bots on your network hammering their servers. Just straight up blocking outbound ports (with the debatable exception of port 25) seems heavy handed and too slanted toward admin convenience over customer satisfaction. It's a slippery slope because unlike with spam, people who are affected by brute force attacks have some degree of complicity through either negligance or laziness. Once you decide it's your job to protect other people's networks from their own stupidity, you may as well do full blown deep packet inspection and look for customers who are using your network to download kiddie porn...step by step you get closer to losing safe harbor, or at least having to pay a lawyer to convince otherwise. Perhaps a more thoughtful solution would work, but would take a bit of engineering. Ideally you would only block a certain class of brute-forceable ports once you cross some threshold amount of brief TCP sessions in a given period. I would suspect an extremely low false positive rate of blocking the ports of a user who has had, say 100 brief telnet, ssh, ftp, pop, or imap sessions in 5 minutes. Perhaps instead of filtering just those ports, you instead do a captive portal where they forced to a webapp which presents them with the logs of their issues and the suggestion they may be compromised, along with locally reachable resources to assist in correcting the issue. But just in case, if they feel it was an accidental situation (a perl script gone mad, say), they could merely click a button to open them right back up. However, three strikes and you're out until an admin reviews the case and considers the feedback (we run a cyber cafe, sometimes people come in with messed up laptops) and implements a whitelisting. Remember, YOUR customers are what matter. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
Re: Customer-facing ACLs
On Fri, Mar 07, 2008, Justin Shore wrote: Scott Weeks wrote: We need to take this off-line. All long timers are groaning, rolling their eyes and putting this in their kill file. Are the long-timers groaning and ignoring this thread? I certainly hope not. It's threads like these that need the benefit of their experience the most. Perhaps the long-timers could recommend a better destination for queries like these because I have more questions I want to ask (my next being about walled gardens). If they're tired of answering the same threads over and over again, then the query must be common enough to warrant a BCP or at the very least a couple documents in a knowledgebase somewhere. Perhaps my Google-fu isn't what it used to be but I couldn't manage to find any relevant docs online; not even a NANOG presentation. *waves* hai, I'm not an old-timer, but I'm still peripherally involved in this. As another poster pointed out, the access-list (and shaping! heh) rules available via RADIUS Vendor AV extensions are very, very useful. The little ISP I poke from time to time makes extensive use of them. The accounting software has some rudimentary profile support, so there's various types of customers which get certain RADIUS attributes. This allows for smart, home, business, and adrian users. Each gets different ACLs and shaping rules. There's a walled garden subnet for clients who haven't paid their bills. I haven't yet sat down and figured out how to drop users into a VRF based on something in the RADIUS reply, as this'd make for some very useful VPN and walled garden implementations, but its certainly on my todo list. Right after figure out IPv6, which is next on my list. Those running larger Cisco bbagg setups aren't rolling the old-school RADIUS authentication; Cisco apparently have some better stuff available now. I can't comment on its effectiveness for accounting/authorisation/filtering. Try convincing your product managers to create a new product just to appease 'sysadmin types'. We're not in the business of alienating any customers. If we can create a bundle that meets a group of potential customers' needs we will. It's just another paragraph on the sales literature that we give our CSRs and a little more work that I'll have to do in configuration. I'm planning on rolling out SOHO and Gamer packages this year. Adding a SysAdmin package wouldn't be much additional work. I predict the adoption rate to be the highest with the Gamer package, followed by the SOHO package and finally the SysAdmin package. I hope this thread isn't destined for an untimely death. I've received a number of off-list queries for summary information because those individuals are also interested in customer-facing ACLs. The information I have to summarize at this point is brief and incomplete. I'll update the NANOG Wiki with whatever information pops up. Amusingly, a newish WISP out here in Western Australia seems to have not implemented this sort of stuff, and wireless clients on the same node can see other local customers. I think their CPE device is a bridge, and this is about as dangerous as it sounds. It would be nice to have a BCP or presentation covering the how's and why's for the newer entrants into ths market. (Although that said, why would you help them? In business, you may just want (some of) your competitors to fail. :) Adrian
Re: Customer-facing ACLs
Just straight up blocking outbound ports (with the debatable exception of port 25) seems heavy handed and too slanted toward admin convenience over customer satisfaction. It's a slippery slope because unlike with spam, people who are affected by brute force attacks have some degree of complicity through either negligance or laziness. Sure, and I could* make the argument that since I have great spam filtering inbound I don't have to care about outbound spam from my network because if you receive it it's because of your negligence/laziness. But I think that in the case of spam as in the case of brute force attacks it's still the network operator's obligation to be a good netizen providing doing so places no undue burden on his own customers or his own staff. Blocking port 25 outbound for dynamic users until they specifically request it be unblocked seems to me to meet the no undue burden test; so would port 22 and 23. Beyond that, I'd probably be hesitant until I either started getting a significant number of abuse reports about a certain flavor of traffic that I had reason to believe was used by only a tiny minority of my own users. *but won't, ever -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
Re: Customer-facing ACLs
Blocking port 25 outbound for dynamic users until they specifically request it be unblocked seems to me to meet the no undue burden test; so would port 22 and 23. Beyond that, I'd probably be hesitant until I either started getting a significant number of abuse reports about a certain flavor of traffic that I had reason to believe was used by only a tiny minority of my own users. Sorry, I must've missed something. Port 25 outbound (excepting ISP SMTP server) seems entirely logical to me. Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a concern? I can only assume it's to stop clients exploited boxen being used to anonymise further telnet/ssh attempts - but have to admit this discussion is the first i've heard of it being done 'en masse'. It'd frustrate me if I jacked into a friends Internet in order to do some legitimate SSH based server administration, I imagine... Is this not 'reaching' or is there a genuine benefit in blocking these ports as well? Mark.
Re: Customer-facing ACLs
Dave Pooser wrote: To me there is no question of whether or not you filter traffic for residential broadband customers. SBC in my area (Dallas) went from wide open to outbound 25 blocked by default/opened on request. I think doing the same thing with port 22 would also people who do real work... hardly be an undue burden on users, and would help keep botnets in check. it would cause me to be a customer of a different service.
RE: Customer-facing ACLs
The last few spam incidents I measured an outflow of about 2 messages per second. Does anyone know how aggressive Telnet and SSH scanning is? Even if it was greater, it's my guess there are many more hosts spewing spam than there are running abusive telnet and SSH scans. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Foster Sent: Friday, March 07, 2008 10:02 PM To: Dave Pooser Cc: nanog@merit.edu Subject: Re: Customer-facing ACLs Blocking port 25 outbound for dynamic users until they specifically request it be unblocked seems to me to meet the no undue burden test; so would port 22 and 23. Beyond that, I'd probably be hesitant until I either started getting a significant number of abuse reports about a certain flavor of traffic that I had reason to believe was used by only a tiny minority of my own users. Sorry, I must've missed something. Port 25 outbound (excepting ISP SMTP server) seems entirely logical to me. Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a concern? I can only assume it's to stop clients exploited boxen being used to anonymise further telnet/ssh attempts - but have to admit this discussion is the first i've heard of it being done 'en masse'. It'd frustrate me if I jacked into a friends Internet in order to do some legitimate SSH based server administration, I imagine... Is this not 'reaching' or is there a genuine benefit in blocking these ports as well? Mark.
Re: Customer-facing ACLs
Frank Bulk wrote: The last few spam incidents I measured an outflow of about 2 messages per second. Does anyone know how aggressive Telnet and SSH scanning is? Even if it was greater, it's my guess there are many more hosts spewing spam than there are running abusive telnet and SSH scans. Judging by the hits on my firewall there's a fair amount of variation between the scanners that are doing a couple login attempts per hour, and the bot that's making thousands of login attempts with 4 or 5 connection attempts going at a time. We don't filter them till they hit a threshold. I don't even bother to log telnet attempts anymore so I can't say much about that. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Foster Sent: Friday, March 07, 2008 10:02 PM To: Dave Pooser Cc: nanog@merit.edu Subject: Re: Customer-facing ACLs Blocking port 25 outbound for dynamic users until they specifically request it be unblocked seems to me to meet the no undue burden test; so would port 22 and 23. Beyond that, I'd probably be hesitant until I either started getting a significant number of abuse reports about a certain flavor of traffic that I had reason to believe was used by only a tiny minority of my own users. Sorry, I must've missed something. Port 25 outbound (excepting ISP SMTP server) seems entirely logical to me. Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a concern? I can only assume it's to stop clients exploited boxen being used to anonymise further telnet/ssh attempts - but have to admit this discussion is the first i've heard of it being done 'en masse'. It'd frustrate me if I jacked into a friends Internet in order to do some legitimate SSH based server administration, I imagine... Is this not 'reaching' or is there a genuine benefit in blocking these ports as well? Mark.
Re: Customer-facing ACLs
Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a concern? I can only assume it's to stop clients exploited boxen being used to anonymise further telnet/ssh attempts - but have to admit this discussion is the first i've heard of it being done 'en masse'. On one test machine that I leave SSH unfirewalled on, I'll see 200-4000 SSH login attempts per day, trying to brute force it. Lets see, this morning in an eight-minute span from one IP in Aruba 100 attempts for root; other usernames attempted include admin, staff, sales, office, alias, stud (!), trash, guest, test, oracle, a few personal names, apache, svn, iraf, swsoft, gast, sirsi and nagios. And this is a relatively slow day. Telnet I wouldn't know about, but I'm told bots will try to force it as well. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
Re: Customer-facing ACLs
On Sat, 8 Mar 2008, Dave Pooser wrote: Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a concern? I can only assume it's to stop clients exploited boxen being used to anonymise further telnet/ssh attempts - but have to admit this discussion is the first i've heard of it being done 'en masse'. On one test machine that I leave SSH unfirewalled on, I'll see 200-4000 SSH login attempts per day, trying to brute force it. Lets see, this morning in an eight-minute span from one IP in Aruba 100 attempts for root; other usernames attempted include admin, staff, sales, office, alias, stud (!), trash, guest, test, oracle, a few personal names, apache, svn, iraf, swsoft, gast, sirsi and nagios. And this is a relatively slow day. Telnet I wouldn't know about, but I'm told bots will try to force it as well. Oh, there's plenty of names in one of my server logs too... looks almost like they've gone through a name-choosing handbook. I can understand the logic of dropping the port, but theres some additional thought involved when looking at Port 22 - maybe i'm not well-read enough, but the bots I've seen that are doing SSH scans, etc, are not usually on Windows systems. I can figure them working on Linux, MacOS systems - but surely the vast majority of 'vulnerable' hosts are those running OS's coming from our favourite megacorp? Which typically don't come shipped with neither SSH server nor SSH client... ? To me, at least half the users likely to be running either Linux or Mac are going to be the same users who're going to request they be allowed outbound SSH is the blocking of outbound SSH considered to be sufficiently useful that we're advocating it these days? (Aren't we all just moving SSH to non-standard ports within our networks anyway?) ... Mark.
