Re: Customer-facing ACLs
--- dave.nanog@alfordmedia.com 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
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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Scott Weeks Sent: Friday, March 07, 2008 5:57 PM To: nanog@merit.edu Subject: Re: Customer-facing ACLs --- dave.nanog@alfordmedia.com 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.
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
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 ---
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
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.
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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] 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.
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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] 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.
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
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:joelja@bogus.com] Sent: Friday, March 07, 2008 11:41 PM To: frnkblk@iname.com Cc: 'Mark Foster'; Dave Pooser; nanog@merit.edu Subject: Re: Customer-facing ACLs Frank Bulk wrote: 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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] 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.
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.
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
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:justin@justinshore.com] Sent: Saturday, March 08, 2008 12:28 PM To: frnkblk@iname.com 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: than
there are running abusive telnet and SSH scans.
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
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.
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
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 - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
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
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
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
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 <randy@psg.com> 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
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
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
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
On 3/9/08, Jason Lixfeld <jason@lixfeld.ca> 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.
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
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.
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.
> 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
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 C&C. Then the C&C 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
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
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
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
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
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
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?
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
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
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_________
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
participants (25)
-
Adrian Chadd -
Al Iverson -
Andy Davidson -
Andy Dills -
Bill Woodcock -
Carpenter, Jason -
Chris Marlatt -
Dave Pooser -
David Conrad -
Frank Bulk -
Frank Bulk - iNAME
-
Jason Lixfeld -
Jay Hennigan -
Joel Jaeggli -
Jon Lewis -
Justin Shore -
Mark Foster -
Mark Prior -
Marshall Eubanks -
Paul Vixie -
Randy Bush -
Scott Weeks -
Sean Donelan -
William Allen Simpson -
William Norton