Re: Providers removing blocks on port 135?
At 01:55 PM 21/09/2003, Justin Shore wrote: On Sun, 21 Sep 2003, Mike Tancsa wrote: Yes, this is all too familiar. Luckily it was not so acute for us. The porn company in question was using legit credit cards and we knew where they were located. We too got to the point where I had to contemplate blocking dialups with no ANI as I had already blocked all access from their phone numbers. However, once they started doing that I called up their office yelling and screaming law suits and I guess they figured there were other ISPs that didnt care as much and moved on to them. I don't know if you did this but if it were me I'd have contacted two other places. The first would have been the credit card companies with the stolen credit cards. The credit cards in our case were legit. They were different numbers, but they were not stolen. They are usuaully fairly responsive when it comes to them loosing money. Secondly after I contacted the local police, state BI, and perhaps the FBI (assuming no luck could be had with any of them) I am in Canada, but I know that it has been stated that the FBI will not investigate computer fraud if damage is under $100,000. I would have given the story to the local media. There's nothing like a little bad PR to give law enforcement a little kick in the butt. I doubt a porn company with international clientele would give a toss about what the local media say. If your newspapers where you're at are anything like our's, they love to print a good scandal involving the local government. Local government has nothing to do with it. It was just some dime a dozen porn company. ---Mike
Re: Providers removing blocks on port 135?
Mike Tancsa wrote: Local government has nothing to do with it. It was just some dime a dozen porn company. Back to the everyone's doing it, so let's not bother syndrome. -Jack
Re: Providers removing blocks on port 135?
Mike Tancsa wrote: I am not advocating that at all. (everyone's doing it, so let's not bother) However, I dont see what the municipal government has to do with a matter like this. I imagine its a civil issue where you have to get the lawyers involved :( Certainly if the company persisted, we would have done so. The fact that they can then go to another ISP who does not care and allows them to use their network is another issue. Of course, it depends on the local laws, but in many locations, pornography has a lot of restrictions and when those restrictions are broken, it becomes a criminal matter. For example, most of my user's have family accounts. This means that their email is not only theirs but their children and grandchildren's. Even if the owner of the account is an adult, the fact that their children are present when they read their email means that all pornographic spam they receive is essentially being delivered to a minor. This is especially true with misleading subject lines where children are exposed to unwanted material before anyone realizes it. In Oklahoma, at least, it is a criminal offense to expose children to pornographic material. -Jack
Re: Providers removing blocks on port 135?
At 01:18 PM 23/09/2003, Jack Bates wrote: Mike Tancsa wrote: I am not advocating that at all. (everyone's doing it, so let's not bother) However, I dont see what the municipal government has to do with a matter like this. I imagine its a civil issue where you have to get the lawyers involved :( Certainly if the company persisted, we would have done so. The fact that they can then go to another ISP who does not care and allows them to use their network is another issue. Of course, it depends on the local laws, but in many locations, pornography This user was sending *out* from our network, not to our users. It would have been up to the authorities in said localities to bring charges against them. I did what I could here. The only cost effective way to deal with things like this is for the ISP to act which we did. Oklahoma would be foolish to spend tens of thousands of dollars to go after this idiot. Really, your state money is better spent elsewhere. This is not very different than the ISPs out there not bothering to clean up their infected users (my favorite rant for the quarter). Looking at http://isc.sans.org/port_details.html?port=135repax=1tarax=2srcax=2percent=Ndays=70Redraw=Submit+Query it would appear by the number of source addresses, there has not been any significant reduction in blaster and its variants. ---Mike has a lot of restrictions and when those restrictions are broken, it becomes a criminal matter. For example, most of my user's have family accounts. This means that their email is not only theirs but their children and grandchildren's. Even if the owner of the account is an adult, the fact that their children are present when they read their email means that all pornographic spam they receive is essentially being delivered to a minor. This is especially true with misleading subject lines where children are exposed to unwanted material before anyone realizes it. In Oklahoma, at least, it is a criminal offense to expose children to pornographic material. -Jack
Re: Providers removing blocks on port 135?
On Tue, 23 Sep 2003, Mike Tancsa wrote: The credit cards in our case were legit. They were different numbers, but they were not stolen. That would make a difference. The credit card companies probably wouldn't care if you told them that the cards were being used by their customer for illegal activity. Stolen, maybe. Anything else they could probably care less about. They are usuaully fairly responsive when it comes to them loosing money. Secondly after I contacted the local police, state BI, and perhaps the FBI (assuming no luck could be had with any of them) I am in Canada, but I know that it has been stated that the FBI will not investigate computer fraud if damage is under $100,000. I didn't realize you were in Canada. That makes a difference. The dollar amount with the FBI varies widely. I've heard over $5,000, $25,000, $50,000, now $100,000. I don't think there's a hard set rule. I think it basically boils down to the old fashioned will-it-get-us-good-PR-with-little-or-not-work rule of thumb. :) I doubt a porn company with international clientele would give a toss about what the local media say. Local media would have been useful not against the spammers but against the local lw enforcement that refuses to do anything about it. Since however your local law enforncement can't do much about (international borders et al) then the local media wouldn't really care. Local government has nothing to do with it. It was just some dime a dozen porn company. Ditto for what I said above. The part about being in Canada changes things considerably from what I was assuming. I must have missed that earlier. Still it's worked in the past in other circumstances so the practice is fairly sound. It just won't work in your case. My only other advice would involve what's suggested in man 8 syslogd under SECURITY THREATS, option number 5. Best of luck. Justin
Re: Providers removing blocks on port 135?
In article [EMAIL PROTECTED], Justin Shore [EMAIL PROTECTED] wrote: Now I'm going to get even more off-topic. It occurs to me that major changes to a protocol such as SMTP getting auth should justify utilizing a different tcp/ip port. Think about it like this. If authenticated forms of SMTP used a different TCP/IP port we netadms could justify leaving that port open on these same dynamically assigned netblocks in the theory that they are only able to connect to other authenticated SMTP services. Doesn't that seem logical? That's not exactly a new idea. http://www.faqs.org/rfcs/rfc2476.html (december 1998). Mike.
Re: Providers removing blocks on port 135?
On zaterdag, sep 20, 2003, at 21:36 Europe/Amsterdam, Sean Donelan wrote: Should any dialup, dsl, cable, wi-fi, dhcp host be able to use any service at any time? For example run an SMTP mailer, or leave Network Neighborhood open for others to browse or install software on their computers? As someone who has been using IP for a while now, I would very much like to be able to use any service at any time. Or should ISPs have a default deny on all services, and subscribers need to call for permitssion if they want to use some new service? Should new services like Voice over IP, or even the World Wide Web be blocked by default by service providers? Obviously not. Blocking services that are known to be bad or vulnerable wouldn't be entirely unreasonable, though. But who gets to decide which services should be blocked? Some services are very dangerous and not very useful, so blocking is a no brainer. Other services are only slightly risky and very useful. Where do we draw the line? Who draws the line? As a HOST requirement, I think all hosts should be client-only by default. That includes things when acting as like hosts such as routers, switches, print servers, file servers, UPSes. If a HOST uses a network protocol for local host processes (e.g. X-Windows, BIFF, Syslog, DCE, RPC) by default it should not accept network connections. It should require some action, e.g. the user enabling the service, DHCP-client enabling it in a profile, clicking things on the LCD display on the front ofthe printer, etc. Get yourself a Mac. :-) I think it would useful to set aside a block of port numbers for local use. These would be easy to filter at the edges of networks but plug and play would still be possible. SERVICE PROVIDERS do not enforce host requirements. But someone has to. The trouble is that access to the network has never been considered a liability, except for local ports under 1024. (Have a look at java, for example.) I believe that the only way to solve all this nonsense is to have a mechanism that is preferably outside the host, or at least deep enough inside the system to be protected against application holes and user stupidity, which controls application's access to the network. This must not only be based on application type and user rights (user www gets to run a web server that listens on port 80) but also on application version. So when a vulnerability is found the vulnerable version of the application is automatically blocked. I don't see something like this popping up over night, though.
Re: Providers removing blocks on port 135?
Iljitsch van Beijnum wrote: But someone has to. The trouble is that access to the network has never been considered a liability, except for local ports under 1024. (Have a look at java, for example.) I believe that the only way to solve all this nonsense is to have a mechanism that is preferably outside the host, or at least deep enough inside the system to be protected against application holes and user stupidity, which controls application's access to the network. This must not only be based on application type and user rights (user www gets to run a web server that listens on port 80) but also on application version. So when a vulnerability is found the vulnerable version of the application is automatically blocked. Go and count the Pinto´s on US101 or I-880. :-) I don't see something like this popping up over night, though. For this to be really effective, there needs to be an unbroken chain of authentication for code from the author to your PC and additionally the operating system needs to change to get rid of the notion of superuser. As have been said multiple times on this and other lists, most consumer users expect their stuff just work and unfortunately Microsoft translated this requirement to Always Local Administrator which has catastrophic security consequences. The chain above does not have to mean that there is central authority enabling the code to run on your box, it can as well give the right to you or some place in the organization where it makes sense. Pete
Re: Providers removing blocks on port 135?
Yes, this is all too familiar. Luckily it was not so acute for us. The porn company in question was using legit credit cards and we knew where they were located. We too got to the point where I had to contemplate blocking dialups with no ANI as I had already blocked all access from their phone numbers. However, once they started doing that I called up their office yelling and screaming law suits and I guess they figured there were other ISPs that didnt care as much and moved on to them. ---Mike At 10:39 PM 20/09/2003, [EMAIL PROTECTED] wrote: At one time, signing up for throwaway dial-up accounts was a common spammer MO. We got hit a couple times, and they were like a plague of vermin [the spammers]. They'd sign up giving us bogus contact info and a freshly stolen (active) credit card. When the account was activated, they'd dial in using half a dozen or so lines and pump out as much spam (direct-to-MX) as they could. The really annoying bit is, we'd terminate them, they'd call right back, and sign up again, giving different bogus info and card numbers. We'd block them by ANI, and they'd block caller-ID when calling us. I ended up being forced to block access to some of our dial-up numbers both by ANI, and if there was no ANI, and then had to setup exceptions for a few customers in those areas who we never got ANI for. When I tried getting police in their areacode to investigate, they had no interest/were too busy...even though I could give them phone numbers the accounts were used from and stolen credit cards. To put a little operational spin in here...how many of you run dial-up networks where you refuse logins unless you get ANI?...and if you do this, do you also maintain an ANI blacklist? Anyway...they moved on to proxy abuse, then outright theft by creating their own proxies on compromised MS Windows boxes. Both methods have the advantage of totally hiding the spammer from the recipients and bandwidth amplification. I imagine you could utilize multiple spam proxies on broadband connections pumping out your spam while connected via dial-up yourself. If you look at the numbers at http://njabl.org/stats, about 5% of the hosts that have ever been checked are currently open relays (or nobody's bothered to remove them). IIRC, at one point, this was nearly 20%. 13.6% are open proxies...and the disparity is definitely still growing, with about 10x as many open proxies as relays being detected daily. Unfortunately, the new breed of purpose-built spam proxies are generally not remotely detectable, so the proxy percentage would be even higher if it included the newer spam proxies. -- Jon Lewis [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Providers removing blocks on port 135?
My guess is that you haven't heard of the current issue with various servers running SMTP AUTH. These MTAs are secure by normal mechanisms, but are being made to relay spam anyway. You're right. It's been a while since I was last on the front lines of this issue. It's hard enough to get mailservers secured when they are maintained by real sysadmins on static IPs with proper and informative PTR records. When the IP addresses sourcing the spam are moving targets, with generic PTR records, and the machines are being operated by end users with no knowledge that their computer is even capable of sending direct to MX mail, the situation is impossible to solve without ISP intervention via Port filtering, etc. So, what you're saying is that a large number of easily compromised hosts are the Root Cause. While blocking port 25 traffic from these systems is a convenient patch, it's not a solution to the root cause. The solution is to make the hosts less vulnerable. One step towards doing that will be to put real product liability on the vendor of the software and the corporations running fleets of compromised systems. Right now, Windows owns the world and the hackers own Windows. The only corporate wake-up call that seems to get understood is one that comes from the legal department. If the person running the system in question chooses to do so, yes, they should be able to do so. If the person running the system in question wants to run server class services, such as ftp, smtp, etc, then they need to get a compatible connection to the internet. There are residential service providers that allow static IP addressing, will provide rDNS, and allow all the servers you care to run. They generally cost more than dial-ups or typical dynamic residential broadband connections. As a rule, you tend to get what you pay for. There are lots of different scenarios available. The bottom line is still that, while an effective workaround, blocking internet ports is not a solution to the root cause of the problem. When we decide that workarounds are solutions, we only invite an arms race of escalating denial of services. My concern is that we seem to have reached a place where we take for granted the immutable vulnerability of systems and, therefore, don't seek to solve the problem, but, instead decide to move from one workaround to the next. I agree the workarounds are necessary for now, but, that doesn't mean we should accept them as permanent solutions. We should work to solve the root cause of the problem as well. Owen -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Margie Arbon Mail Abuse Prevention System, LLC [EMAIL PROTECTED] http://mail-abuse.org
Re: Providers removing blocks on port 135?
On Sun, 21 Sep 2003, Mike Tancsa wrote: Yes, this is all too familiar. Luckily it was not so acute for us. The porn company in question was using legit credit cards and we knew where they were located. We too got to the point where I had to contemplate blocking dialups with no ANI as I had already blocked all access from their phone numbers. However, once they started doing that I called up their office yelling and screaming law suits and I guess they figured there were other ISPs that didnt care as much and moved on to them. I don't know if you did this but if it were me I'd have contacted two other places. The first would have been the credit card companies with the stolen credit cards. They are usuaully fairly responsive when it comes to them loosing money. Secondly after I contacted the local police, state BI, and perhaps the FBI (assuming no luck could be had with any of them) I would have given the story to the local media. There's nothing like a little bad PR to give law enforcement a little kick in the butt. If your newspapers where you're at are anything like our's, they love to print a good scandal involving the local government. Justin
Re: Providers removing blocks on port 135?
Has anyone else notice the flip-flops? To prevent spam providers should block port 25. If providers block ports, e.g. port 135, they aren't providing access to the full Internet. Should any dialup, dsl, cable, wi-fi, dhcp host be able to use any service at any time? For example run an SMTP mailer, or leave Network Neighborhood open for others to browse or install software on their computers? Or should ISPs have a default deny on all services, and subscribers need to call for permitssion if they want to use some new service? Should new services like Voice over IP, or even the World Wide Web be blocked by default by service providers? As a HOST requirement, I think all hosts should be client-only by default. That includes things when acting as like hosts such as routers, switches, print servers, file servers, UPSes. If a HOST uses a network protocol for local host processes (e.g. X-Windows, BIFF, Syslog, DCE, RPC) by default it should not accept network connections. It should require some action, e.g. the user enabling the service, DHCP-client enabling it in a profile, clicking things on the LCD display on the front ofthe printer, etc. If the device is low-end and only has a network connection (e.g. no console), it may have a single (i.e. telnet or web; but not both) management protocol enabled provided it includes a default password which can not be discovered from the network (i.e. not the MAC address), is different for each device (i.e. not predictable), and is only accessiable from the local network (e.g. the internal subnet interface). A proprietary protocol is not an adequate substitute. Static passwords are inherently insecure if you get enough guesses, so the device should block use of the default password after N failed attempts until the device is manually reset. I recognize this is a potential denial of service, and for non-default passwords vendors may decide to do something else. But if the user hasn't changed the default password; they probably aren't using it anyway. SERVICE PROVIDERS do not enforce host requirements.
Re: Providers removing blocks on port 135?
Hi, NANOGers. ] I still disagree with this. To prevent SPAM, people shouldn't run open ] relays and the open relay problem should be solved. Breaking legitimate ] port 25 traffic is a temporary hack. I suspect that most spam avoids open relays. The abuse of proxies, routers, and bots for this purpose is far more in vogue. Watch out for worms such as W32.Sanper, which also provide a built-in spam relay network. Remove all of the open mail relays and you are left with...lots of spam. More at NANOG... ;) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: Providers removing blocks on port 135?
However, I'm not convinced blocking port 25 on dialups helps much with that. What it does help with is preventing them from connecting to open relays. The real solution in the long run will be two-fold: 1. Internet hosts need to become less penetrable. (or at least one particular brand of software) 2. SMTP AUTH will need to become more widespread and end-to-endish. Owen --On Saturday, September 20, 2003 4:53 PM -0500 Rob Thomas [EMAIL PROTECTED] wrote: Hi, NANOGers. ] I still disagree with this. To prevent SPAM, people shouldn't run open ] relays and the open relay problem should be solved. Breaking legitimate ] port 25 traffic is a temporary hack. I suspect that most spam avoids open relays. The abuse of proxies, routers, and bots for this purpose is far more in vogue. Watch out for worms such as W32.Sanper, which also provide a built-in spam relay network. Remove all of the open mail relays and you are left with...lots of spam. More at NANOG... ;) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: Providers removing blocks on port 135?
--On Saturday, September 20, 2003 2:46 PM -0700 Owen DeLong [EMAIL PROTECTED] wrote: I still disagree with this. To prevent SPAM, people shouldn't run open relays and the open relay problem should be solved. Breaking legitimate port 25 traffic is a temporary hack. Very little spam coming off dialups and other dynamically assigned, residential type connections has anything to do with open relays. The vast majority of it is related to open proxies (which the machine owners do not realize they are running) and machines that have been compromised by various viruses and exploits. These are machines that should not be running outbound mailservers, and in most cases, the owners neither intend nor believe that their systems are sending mail. Merely stating that people shouldn't run open relays didn't stop spam four years ago and it is less likely to do so now. My guess is that you haven't heard of the current issue with various servers running SMTP AUTH. These MTAs are secure by normal mechanisms, but are being made to relay spam anyway. It's hard enough to get mailservers secured when they are maintained by real sysadmins on static IPs with proper and informative PTR records. When the IP addresses sourcing the spam are moving targets, with generic PTR records, and the machines are being operated by end users with no knowledge that their computer is even capable of sending direct to MX mail, the situation is impossible to solve without ISP intervention via Port filtering, etc. If the person running the system in question chooses to do so, yes, they should be able to do so. If the person running the system in question wants to run server class services, such as ftp, smtp, etc, then they need to get a compatible connection to the internet. There are residential service providers that allow static IP addressing, will provide rDNS, and allow all the servers you care to run. They generally cost more than dial-ups or typical dynamic residential broadband connections. As a rule, you tend to get what you pay for. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Margie Arbon Mail Abuse Prevention System, LLC [EMAIL PROTECTED] http://mail-abuse.org
Re: Providers removing blocks on port 135?
On Sat, 20 Sep 2003, Margie wrote: My guess is that you haven't heard of the current issue with various servers running SMTP AUTH. These MTAs are secure by normal mechanisms, but are being made to relay spam anyway. Would this be a reference to the qmail-smtp-auth patch that recently was discovered, that if misconfigured, could allow incorrect relays? If so, I would say that this was an isolated incident for a single patch for a specific MTA and only when it was misconfigured. I'm not sure I would describe that as secure by normal mechanisms nor quite the epidemic it was the first week or two. I'm not necessarily making a statement one way or the other on port 25 filtering, but SMTP Auth, when properly configured and protected against brute force attacks is certainly a useful thing. YMMV of course. andy -- PGP Key Available at http://www.tigerteam.net/andy/pgp
Re: Providers removing blocks on port 135?
On Sat, 20 Sep 2003 15:05:08 -0700 Owen DeLong [EMAIL PROTECTED] wrote: | I'm not convinced blocking port 25 on dialups helps much with that. | What it does help with is preventing them from connecting to open | relays. There are so few open relays now that spammers have moved on. They now use, almost without exception, compromised Windows boxes acting as open proxies, or on which a trojan spam-sender of some sort has been installed - usually by one of the recent stream of viruses/worms. Blocking outbound port 25, other than via a designated smarthost, would at least prevent the direct-to-MX traffic from compromised boxes - which currently seems to be the spammers method of choice. | The real solution in the long run will be two-fold: | 1. Internet hosts need to become less penetrable. |(or at least one particular brand of software) | | 2. SMTP AUTH will need to become more widespread and end-to-endish. Right on both counts. But end-to-end may have to include the senders' fingers: as if bundled mail-client software contains the AUTH password it will be trivial for the spammers to hijack at the client level. And users won't like having to key in their password each time, meaning that trivial, guessable passwords will often be used. In recent weeks one particular spammer seems to have perfected a knack of breaking SMTP AUTH passwords on a widespread basis. Governments on both sides of the Pond may be reluctant to make spam illegal, but the issue is not spam (or we couldn't be discussing it here). This is a matter of system and network security, and if law enforcement had the skills, resources and motivation to deal with what are clear breaches of existing laws, admins' jobs would be significantly easier. Until then, we have to deal with issues as they arise. Networks need to be contactable quickly when compromised sites start to be misused, and to respond immediately. Not just wait until Monday Morning in their timezone ... if we can't deal with the incidents in real time, how can we expect law enforcement to do anything? Hello Comcast, Skynet, Ireland-onLine, NTL in the UK ... need I go on? Where's Declan McC when we need him? -- Richard
Re: Providers removing blocks on port 135?
On Sat, 20 Sep 2003 23:22:34 +0100 Ray Bellis [EMAIL PROTECTED] wrote: What we do have though are (optional) *inbound* filters that make sure no-one can connect to their privileged ports over TCP/IP, and a mandatory filter that says only our network can deliver to their SMTP service. We don't get problems with open-relays on dialups. We didn't have any problems with MS-Blaster on dialups either... I would suggest instead that you have mandatory sending via your relays, and allow inbound connections to port 25. Sympatico, last I checked, didn't have any restrictions until you tripped off their alarms, at which point you needed to configure your smtpd to send mail via their relays. If they continued spewing copious amounts of spam, cut them off entirely until they fix their configuration. There are a couple of pluses to this type of setup; people like me who have dozens of (required) email addresses can forward them all to their home machine. Some of my family also much prefer this even though they've only got one or two email addresses. It also ensures that they can't send spam directly no matter what the source; blocking inbound connections will certainly stop open relays, but it won't stop trojans and worms and whatnot that are really just spamware. (Note that I consider spamware included in other applications and hidden from the user trojans.) pgp0.pgp Description: PGP signature
Re: Providers removing blocks on port 135?
* [EMAIL PROTECTED] (Ray Bellis) [Sun 21 Sep 2003, 00:25 CEST]: What we do have though are (optional) *inbound* filters that make sure no-one can connect to their privileged ports over TCP/IP, and a mandatory filter that says only our network can deliver to their SMTP service. There's an ISP in the Netherlands who do that too for their DSL customers. Unfortunately, their mail servers are not that reliable to begin with and also spool mail only for 4 hours, so if your connection is down for the weekend (happens more often if you work for a company in direct competition with the telco that owns this particular ISP) all your mail bounces instead of getting spooled somewhere and delivered later... -- Niels.
Re: Providers removing blocks on port 135?
On Sat, 20 Sep 2003, Margie wrote: If the person running the system in question wants to run server class services, such as ftp, smtp, etc, then they need to get a compatible connection to the internet. There are residential service providers that allow static IP addressing, will provide rDNS, and allow all the servers you care to run. They generally cost more than dial-ups or typical dynamic residential broadband connections. As a rule, you tend to get what you pay for. So if someone wants to run Outlook or Netbios from home, they need to get a server-class connection to the Internet? If everyone buys a server-class connection, we end up back were we started. The problem is many clients act as servers for part of the transaction. Remember X-Windows having ports 6000-6099 open on clients? IRC users need to have Identd port 113 open. Microsoft clients sometimes need to receive traffic on port 135, 137-139 as well as transmit it due to how software vendors designed their protocols. Outlook won't receive the new mail message, and customers will complain that mail is slow. And do we really want to discuss peer-to-peer networking, which as the name suggests, peer-to-peer. It costs service providers more (cpu/ram/equipment) to filter a connection. And even more for every exception. Should service providers charge customers with filtering less (even though it costs more), and customers without filtering more (even though it costs less)? If the unfiltered connection was less expensive, wouldn't everyone just buy that; and we would be right back to the current situation? In the old regulated days of telephony, service providers could get away with charging business customers more for a phone line or charging for touch-tone service. But the Internet isn't regulated. There is always someone willing to sell the service for less if you charge more than what it costs.
Re: Providers removing blocks on port 135?
--On Saturday, September 20, 2003 6:36 PM -0500 Andy Walden [EMAIL PROTECTED] wrote: Would this be a reference to the qmail-smtp-auth patch that recently was discovered, that if misconfigured, could allow incorrect relays? No, that was the tip of the iceberg. If so, I would say that this was an isolated incident for a single patch for a specific MTA and only when it was misconfigured. I'm not sure I would describe that as secure by normal mechanisms nor quite the epidemic it was the first week or two. We've seen the same behavior out of Postfix, QMail, Imail, Mdaemon, Exchange, Sendmail, Mercury, Merak, NTMail, and others that I can't recall off the top of my head. In some cases, the relaying was fixed with the release of a new patch or a conf change. In others, particulary Exchange, the guest account was enabled, allowing open authentication. The big BUT is that there is a not insignificant number of other machines that have either been shown to have been brute forced or we've yet to determine the mechanism that allows the relay. The problem is not small. I'm not necessarily making a statement one way or the other on port 25 filtering, but SMTP Auth, when properly configured and protected against brute force attacks is certainly a useful thing. YMMV of course. Yes, it is a useful thing. It's not the ultimate answer. A machine that tests secure by any test we are willing to run, that requires fifteen character passwords, with mulitple special characters required, that is STILL relaying indicates there is a bad thing happening somewhere. -- Margie
Re: Providers removing blocks on port 135?
On Sat, 20 Sep 2003, Margie wrote: Very little spam coming off dialups and other dynamically assigned, residential type connections has anything to do with open relays. The vast majority of it is related to open proxies (which the machine owners do not realize they are running) and machines that have been compromised by various viruses and exploits. These are machines that should not be running outbound mailservers, and in most cases, the owners neither intend nor believe that their systems are sending mail. Merely stating that people shouldn't run open relays didn't stop spam four years ago and it is less likely to do so now. This veers off the original topic. Of course I don't think any of us recall what that was anyways... I remember back when I first started using the DUL. Of all the DNSBLs I used at the time it blocked the most spam of any of them. I mean that by long shot. About the time the DUL and other MAPS lists went commericial is about the same time I noticed fewer and fewer hits on the DUL. We still pay for an AXFR (IXFR) of it but it doesn't block nearly as much as it used to. The open proxy lists block an unbelievable amount of spam. In theory the DUL would take care of this if it also list residential dynamically assigned cable/dsl lines (if it doesn't already, hmmm...). Still the open proxy DNSBLs seem to be more effective now. Bottom line, use every DNSBL you possibly can and don't be afraid to pay for them. I strongly recommend redirecting SMTP traffic for this same class of user as well. Now I'm going to get even more off-topic. It occurs to me that major changes to a protocol such as SMTP getting auth should justify utilizing a different tcp/ip port. Think about it like this. If authenticated forms of SMTP used a different TCP/IP port we netadms could justify leaving that port open on these same dynamically assigned netblocks in the theory that they are only able to connect to other authenticated SMTP services. Doesn't that seem logical? Justin
Re: Providers removing blocks on port 135?
On Sat, 20 Sep 2003, Sean Donelan wrote: It costs service providers more (cpu/ram/equipment) to filter a connection. And even more for every exception. Should service providers charge customers with filtering less (even though it costs more), and customers without filtering more (even though it costs less)? If the unfiltered connection was less expensive, wouldn't everyone just buy that; and we would be right back to the current situation? Abosulutely. At least if the customer wants technical support or plans on paying for their bandwidth. It costs *more* resources for an ISP to *not* filter ports and it costs them *less* resources to filter known ports that are rarely used by Joe Blow average user but the cause of 99% of their (our) headaches. How many people here have ever worked in a helpdesk with hundreds of users calling you for help when they've been infected with the latest greatest Netbios-enabled virus and lost their report, thesis, archived email, pictures of the kids, you name it. I used to work at a Unv helpdesk. Every single time the mail server hiccuped for whatever reason, or the personal webserver was offline for a few minutes of maintenance in the week hours of the morning (no matter whether it was 2 minutes of 2 days) people would inundate us with complaints. All the real problems had to be put on hold so we could answer the phones. Technical support costs an ISP many times that of the neccessary CPU and RAM resources on an access server or border router needed to filter malicious ports. Why don't we just wait until we identify that a user has been infected or compromised (by whatever resource-hog of a method that entails). Then we can just disable their account and wait for them to call. Those calls are always the most pleasant of the day. When did proactive security measures become criminal? Was there a memo I missed? Justin
Re: Providers removing blocks on port 135?
On Sat, 20 Sep 2003, Justin Shore wrote: This veers off the original topic. Of course I don't think any of us recall what that was anyways... I remember back when I first started using the DUL. Of all the DNSBLs I used at the time it blocked the most spam of any of them. I mean that by long shot. About the time the DUL and other MAPS lists went commericial is about the same time I noticed fewer and fewer hits on the DUL. We still pay for an AXFR (IXFR) of it but it doesn't block nearly as much as it used to. At one time, signing up for throwaway dial-up accounts was a common spammer MO. We got hit a couple times, and they were like a plague of vermin [the spammers]. They'd sign up giving us bogus contact info and a freshly stolen (active) credit card. When the account was activated, they'd dial in using half a dozen or so lines and pump out as much spam (direct-to-MX) as they could. The really annoying bit is, we'd terminate them, they'd call right back, and sign up again, giving different bogus info and card numbers. We'd block them by ANI, and they'd block caller-ID when calling us. I ended up being forced to block access to some of our dial-up numbers both by ANI, and if there was no ANI, and then had to setup exceptions for a few customers in those areas who we never got ANI for. When I tried getting police in their areacode to investigate, they had no interest/were too busy...even though I could give them phone numbers the accounts were used from and stolen credit cards. To put a little operational spin in here...how many of you run dial-up networks where you refuse logins unless you get ANI?...and if you do this, do you also maintain an ANI blacklist? Anyway...they moved on to proxy abuse, then outright theft by creating their own proxies on compromised MS Windows boxes. Both methods have the advantage of totally hiding the spammer from the recipients and bandwidth amplification. I imagine you could utilize multiple spam proxies on broadband connections pumping out your spam while connected via dial-up yourself. If you look at the numbers at http://njabl.org/stats, about 5% of the hosts that have ever been checked are currently open relays (or nobody's bothered to remove them). IIRC, at one point, this was nearly 20%. 13.6% are open proxies...and the disparity is definitely still growing, with about 10x as many open proxies as relays being detected daily. Unfortunately, the new breed of purpose-built spam proxies are generally not remotely detectable, so the proxy percentage would be even higher if it included the newer spam proxies. -- Jon Lewis [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Providers removing blocks on port 135?
Title: Providers removing blocks on port 135? Anyone know anything about prorviders removing ACLs from their routers to allow ports 135/445/ back into their network? Curious only because customers are calling in saying that Verizon, Cox, Bellsouth, and DSL.net are doing so and seem to have a big problem with the fact that we're hesitent follow their lead. Adam
Re: Providers removing blocks on port 135?
Adam Hall wrote: Anyone know anything about prorviders removing ACLs from their routers to allow ports 135/445/ back into their network? Curious only because customers are calling in saying that Verizon, Cox, Bellsouth, and DSL.net are doing so and seem to have a big problem with the fact that we're hesitent follow their lead. No two networks are the same, nor do they have the same issues. The new RPC exploit worm will be interesting to watch on the above networks if they've dropped their blocks. There's also a question of at which layer they have done so. For example, if blocks were removed from central sites in favor of blocks that were pushed out to the end users. Allowing the various scans out costs other people money. If nothing else, I'll leave 135 in place long enough to ensure that the number of users that are infected are manageable. My transit customers are all telling me the same thing. They are still pushing it to get people cleaned up and patched. They want their blocks to remain (so they don't have to pay us more). -Jack
Re: Providers removing blocks on port 135?
On Fri, 19 Sep 2003, Adam Hall wrote: Anyone know anything about prorviders removing ACLs from their routers to allow ports 135/445/ back into their network? Curious only because customers are calling in saying that Verizon, Cox, Bellsouth, and DSL.net are doing so and seem to have a big problem with the fact that we're hesitent follow their lead. Well, first you would have to find providers willing to say they had ACLs, then willing to say the ACLs that didn't exist are being removed. Although 135, 139, 445, etc ACLs still seem to be very wide-spread, they are not network or service provider wide. It may vary by region, provider, wholesale arrangement, etc. A provider may have some ACLs in Atlanta, but not in Boston. Or even in the same city, some circuits may go through different wholesale arrangements resulting in different ACLs.
Re: Providers removing blocks on port 135?
FWIW, my opinion is that blocking this at the customer edge per customer request is fine. Any other blocking by an ISP is damage and should be routed around like any other internet damage. Owen
RE: Providers removing blocks on port 135?
I agree entirely with this. You shouldn't call yourself an ISP unless you can transport the whole Internet, including those bad Microsoft ports, between the world and your customers. On the other hand, what's a provider to do when their access hardware can't deal with a pathological set of flows or arp entries? There isn't a good business case to forklift out your DSLAMs and every customer's matching CPE when a couple of ACLs will fix the problem. For that matter, there isn't a very good business case for transporting Nachi's ICMP floods across an international backbone network when you can do a bit of rate-limiting and cut your pipe requirements by 10-20%. Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Owen DeLong Sent: Friday, September 19, 2003 10:03 AM To: Jack Bates; Adam Hall Cc: '[EMAIL PROTECTED]' Subject: Re: Providers removing blocks on port 135? FWIW, my opinion is that blocking this at the customer edge per customer request is fine. Any other blocking by an ISP is damage and should be routed around like any other internet damage. Owen
RE: Providers removing blocks on port 135?
OK... Obviously, you need to do what you need to do to keep things running. However, that should be a temporary crisis response. If your equipment is getting DOS'd for more than a few months, we need to find a way to fix a bigger problem. Permanently breaking some service (regardless of what we think of it. Personally, I'll be glad to see M$ go down in flames) is _NOT_ the correct answer. Owen --On Friday, September 19, 2003 10:14 AM -0700 Matthew Kaufman [EMAIL PROTECTED] wrote: I agree entirely with this. You shouldn't call yourself an ISP unless you can transport the whole Internet, including those bad Microsoft ports, between the world and your customers. On the other hand, what's a provider to do when their access hardware can't deal with a pathological set of flows or arp entries? There isn't a good business case to forklift out your DSLAMs and every customer's matching CPE when a couple of ACLs will fix the problem. For that matter, there isn't a very good business case for transporting Nachi's ICMP floods across an international backbone network when you can do a bit of rate-limiting and cut your pipe requirements by 10-20%. Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Owen DeLong Sent: Friday, September 19, 2003 10:03 AM To: Jack Bates; Adam Hall Cc: '[EMAIL PROTECTED]' Subject: Re: Providers removing blocks on port 135? FWIW, my opinion is that blocking this at the customer edge per customer request is fine. Any other blocking by an ISP is damage and should be routed around like any other internet damage. Owen
RE: Providers removing blocks on port 135?
Well, we could start by having every ISP do what we do, which is to find worm-infected customers inside our network and get them patched or turned off. But that's a lot of work. (Especially when you've got a new worm to track down every week) The scary/unfortunate part to me is that these things never seem to go away... Check your web server's log for the last hit from Code Red, for instance. (6 minutes ago, from 203.59.48.139, on the server I just checked) Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: Owen DeLong [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:23 AM To: Matthew Kaufman; 'Jack Bates'; 'Adam Hall' Cc: [EMAIL PROTECTED] Subject: RE: Providers removing blocks on port 135? OK... Obviously, you need to do what you need to do to keep things running. However, that should be a temporary crisis response. If your equipment is getting DOS'd for more than a few months, we need to find a way to fix a bigger problem. Permanently breaking some service (regardless of what we think of it. Personally, I'll be glad to see M$ go down in flames) is _NOT_ the correct answer. Owen
RE: Providers removing blocks on port 135?
On Fri, 19 Sep 2003, Matthew Kaufman wrote: I agree entirely with this. You shouldn't call yourself an ISP unless you can transport the whole Internet, including those bad Microsoft ports, between the world and your customers. I disagree. In my opinion a NSP shouldn't filter traffic unless one of its customers requests it. However I strongly believe that an ISP (where it's customers are Joe Blow average citizen and Susy Homemaker) should take every reasonable step to protect it's users from malicious traffic and that includes filtering ports. For example I have no reservation about NATing basic dialup users. I also have no problem with filtering ports for services they shouldn't be running on a dialup connection (HTTP, FTP, DNS) or for services that IMHO have no business on the public internet (including every single Microsoft port I can identify). To not do so is IMHO to run a network in an extremely negligent manner. We do this very thing with email. We filter known malicious messages, attachments, and spam from email. I don't think there's a reasonable person among us that can complain about that. Why not do it to network traffic then? If we should allow every bit of traffic to pass unmolested by ACLs then we should allow all email to pass by unmolested by anti-virus and spam checks. It's a two-way street. On the other hand, what's a provider to do when their access hardware can't deal with a pathological set of flows or arp entries? There isn't a good business case to forklift out your DSLAMs and every customer's matching CPE when a couple of ACLs will fix the problem. For that matter, there isn't a very good business case for transporting Nachi's ICMP floods across an international backbone network when you can do a bit of rate-limiting and cut your pipe requirements by 10-20%. A good point. Justin
RE: Providers removing blocks on port 135?
I agree. In my opinion, at this point, the larger issue that we really need to find a way to address is to force a recall on the Exploding Pinto and get real product liability available to the victims. Not just the moron who bought the Exploding Pinto knowing it would probably explode, who, actually should have some culpability, but, more importantly, there should be actual liability on the part of the manufacturer and the reckless operator to the innocent bystander victims (ISPs, Web sites, etc.) that are forced to try to repair or work around the damage, handle the traffic, etc. The Virus-of-the-week club is not going to go away until somebody gets a multi-million dollar judgement against Micr0$0ft for the damage inflicted by their Exploding Pinto, or, until businesses start to see that there is liability for running unpatched windows systems to the tune of If you keep driving your Exploding Pinto, you may have to pay $$$ to the victims of the explosion when it occurs. Case 1 will lead Micr0$0ft to start rethinking some of it's less secure design decisions. Case 2 will lead businesses to evaluate whether Windows is _REALLY_ a cost effective choice or not. Until at least one, preferably both of these things happens, we are going to be stuck with the consequences of other people choosing to run Whine-Doze whether we run it, or even want to know that anyone runs it or not. Owen --On Friday, September 19, 2003 10:32 AM -0700 Matthew Kaufman [EMAIL PROTECTED] wrote: Well, we could start by having every ISP do what we do, which is to find worm-infected customers inside our network and get them patched or turned off. But that's a lot of work. (Especially when you've got a new worm to track down every week) The scary/unfortunate part to me is that these things never seem to go away... Check your web server's log for the last hit from Code Red, for instance. (6 minutes ago, from 203.59.48.139, on the server I just checked) Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: Owen DeLong [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:23 AM To: Matthew Kaufman; 'Jack Bates'; 'Adam Hall' Cc: [EMAIL PROTECTED] Subject: RE: Providers removing blocks on port 135? OK... Obviously, you need to do what you need to do to keep things running. However, that should be a temporary crisis response. If your equipment is getting DOS'd for more than a few months, we need to find a way to fix a bigger problem. Permanently breaking some service (regardless of what we think of it. Personally, I'll be glad to see M$ go down in flames) is _NOT_ the correct answer. Owen
RE: Providers removing blocks on port 135?
Why do you get to decide that, I can't, from a hotel room, call my ISP and put up a web server on my dialup connection so someone behind a firewall can retrieve a document I desperately need to get to them? Why _SHOULDN'T_ I run a web server to do this over a dialup connection? Why do you get to dictate to _ANYONE_ what things they can and can't do with their most portable internet access? How can you say that it is negligent to refuse to DOS your customers unless they request it? (blocking traffic to me that I want is every bit as much a denial of service as flooding my link). The distinction may be blurrier these days, but there *is* a difference between networking and internetworking. Whereas I'd agree that interconnections between networks be unencumbered to the greatest degree possible, the administrator of a network can be slightly more draconian in order to keep the network running smoothly. This statement applies, IMHO, to any provider who sells service to individual users. It may be a huge wide area dialup network, but it's still a network, in which the average customer is not a professional network administrator but rather a user of indeterminate knowledge level. Now, if as an ISP you operate an internetwork (network of networks) and a network of users, the challenge is obviously how do you draw the distinction between user/customers and network/customers. I think it's do-able (DHCP being one criteria that comes to mind), but there there are a lot of permutations to consider.
Re: Providers removing blocks on port 135?
Owen DeLong wrote: Yes. I responded to this in a previous post. We must do what we must do temporarily to keep things running. However, breaking the net is not a long term solution. We must work to solve the underlying problem or it just becomes an arms-race where eventually, no services are useful. I agree, and as a point of fact, many ISP's allow their users to opt out of spam. The ability to opt out of port filtering is a little more difficult, but it is not impossible. Most authentication methods designed have support for telling connection equipment what security lists to use and how to treat a specific user. Some systems, like mine, do not run authentication models that support this, but I consider it very wise to change. In my case, I will maintain a filter anywhere in the network that it is required in order to help protect the network and the users who rely upon the network. Currently, estimates show that removing port 135 at this junction would allow the current Blaster infected users to become infected with Nachi/Welchia which has more network impact. Some segments, despite blocks, have already had small outbreaks which we had to irradicate. In addition, dialups have very little bandwidth to begin with. The amount of traffic generated on icmp and 135 is currently high enough to severly cripple connectivity on an unprotected dialup account. I do agree that it is a temporary measure. Yet, one must remember that each network has it's own definitions of temporary, drastic, and appropriate. I now return you to contacting those infected users in your network. :) -Jack
Re: Providers removing blocks on port 135?
Why do you get to decide that, I can't, from a hotel room, call my ISP and put up a web server on my dialup connection so someone behind a firewall can retrieve a document I desperately need to get to them? Why _SHOULDN'T_ I run a web server to do this over a dialup connection? Why do you get when scp or ftp over an ssh tunnel are much easier/lighter weight? or you could hand out ASNs and run third-party BGP from your hotel room back to the trusted core... there are lots of ways to get your critical content to the right party, some are more cost effective than others. The name Rube Goldburg comes to mind here... The distinction may be blurrier these days, but there *is* a difference between networking and internetworking. true enough. --bill
