Hi Adi, #I am seeing an increasing number of hosts on our network become an open #proxy. So far the response to this has been reactive, once I receive #complaints from spam victims I deal with the source of the problem. The sheer act of having an abuse address and acting on reports received on it puts you a leg and a half up on a number of other service providers who have chosen to studiously ignore abused open proxies on their networks. #Is there an accepted way of blocking open proxy and open relay traffic at #the network edge? I think this is going to be an increasingly difficult problem to attack via blocks on specific ports; that is, while some folks may suggest blocking 1080/tcp, 3128/tcp, 5490/tcp, 6588/tcp, 8080/tcp, etc., you should be aware of an emerging class of viruses which are designed to create open proxies on uncommon and non-standardized high numbered ports which can then be exploited by the party controlling that virus (sort of a "make proxy hosts to order" operation). Jeem is probably the canonical example of this. The sheer magnitude of the problem also argues against manual construction of ACL's on a host-by-host basis; to date, having looked at this issue for maybe six months now, I believe the number of *known* open proxies is on the order of 120K hosts, few of which are sequentially disposed into nice CIDR-able netblocks (unless you're okay with the concept of lumping sheep with goats in the case of some thoroughly larded ISPs, if I may mix my metaphors). What's really needed is some way to take open proxy DNSBL data and instantiate a dump of that data onto a suitable appliance. It is probably too much state to burden a reasonable sized border route with, but you could imagine other devices that could probably handle it (at least for moderate speed flows), much as there are currently middle boxes which rip open packets to target peer to peer traffic. If you're interested in the issue of open proxies, you may want to see the paper I presented this April in Arlington VA at the Internet2 Member Meeting entitled "The Open Proxy Problem." Since that was a "suit" meeting, the talk backfills a bit about proxies at the start, but you can flip through the bits that are old news pretty easily. PDF and PowerPoint versions are available online at http://darkwing.uoregon.edu/~joe/proxies/ Regards, Joe St Sauver (joe@oregon.uoregon.edu) University of Oregon Computing Center
Joe St Sauver wrote:
What's really needed is some way to take open proxy DNSBL data and instantiate a dump of that data onto a suitable appliance. It is probably too much state to burden a reasonable sized border route with, but you could imagine other devices that could probably handle it (at least for moderate speed flows), much as there are currently middle boxes which rip open packets to target peer to peer traffic.
Along those lines, I have been running an ACL-based spam blocker at ingress for a little over six months, but it has really surpassed the manageable level for many devices. To put this in perspective, we use a feed from SPEWS level 1 data, current DShield block list, and some manual black/whitelist data, shove it through a perl script, and produce a TFTPable config file which is then 'config net'ed into our edge devices. The last few days of SPEWS data varies around 14000 lines (mix of CIDR blocks and individual hosts), currently 2400 lines in our local additions, yielding a merged ACL (with ingress blocks, bogons, Dshield blocks, and anti-spam) of ~15800 lines (~603kB). With 'service compress-config' enabled, this fits into a 3640 and doesn't kill it in the process (8xT1s). It overflows TCAM on a 6509 and forces process switching in the ingress direction, but otherwise works (1xGigE, 2x100FE). On the other hand, NJABL.ORG lists 255K open relays, 170K open proxies, and a spattering of dialups and other listings. This is way beyond ACLs that I could even imagine thinking about :-) Jeff
On the other hand, NJABL.ORG lists 255K open relays, 170K open proxies, and a spattering of dialups and other listings. This is way beyond ACLs that I could even imagine thinking about :-)
anyone who was facile with perl could transform a full list of open relays or proxies into something that avibgpd could use, so that you could have your access controls implemented as routes rather than acl's. if you combine that with policy routing so that you can blackhole traffic based on source rather than destination, you could get the added benefit of not having to take/deliver the SYN only to blackhole the resulting SYN-ACK. -- Paul Vixie
Hi, NANOGers. ] anyone who was facile with perl could transform a full list of open relays ] or proxies into something that avibgpd could use, so that you could... If anyone can recommend a trusted list of proxies, we could provide this data through something along the lines of the bogon route-server project. <http://www.cymru.com/BGP/bogon-rs.html> We're happy to provide it or mirror it through DNS as well, e.g. bad.proxy.ip.here.openproxy.cymru.com or something similar. Thanks, Rob, for Team Cymru. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Rob Thomas wrote:
Hi, NANOGers.
] anyone who was facile with perl could transform a full list of open relays ] or proxies into something that avibgpd could use, so that you could...
If anyone can recommend a trusted list of proxies, we could provide this data through something along the lines of the bogon route-server project.
If we could somehow blackhole *only* SMTP inbound, that would be ideal, but I feel that blackholing all IP from/to those sites would be far too much collateral damage. Jeff
--On Thursday, April 24, 2003 8:20 PM -0400 Jeff Kell <jeff-kell@utc.edu> wrote:
Rob Thomas wrote:
Hi, NANOGers.
] anyone who was facile with perl could transform a full list of open relays ] or proxies into something that avibgpd could use, so that you could...
If anyone can recommend a trusted list of proxies, we could provide this data through something along the lines of the bogon route-server project.
If we could somehow blackhole *only* SMTP inbound, that would be ideal,
That's easy... standard ACLs, however that only protects against open relays, does nothing about open proxies which are a MUCH bigger problem
but I feel that blackholing all IP from/to those sites would be far too much collateral damage.
On the plus side, things would get noticed by the owners of the 0wn3d boxes a lot quicker, and you wouldn't be aiding and abetting the skr1pt k1dd13s by letting the proxies run wild.
Jeff Kell wrote:
If we could somehow blackhole *only* SMTP inbound, that would be ideal, but I feel that blackholing all IP from/to those sites would be far too much collateral damage.
That's where the problem lies. We consider it inconvenient. Too often do we not take action because it would cause collateral damage. How many ISPs only warn their customers about worm/virus infection versus suspending the account until it is fixed? In the case of open proxies, the most highlighted damage is the sending of spam. However, these boxes can perform any server a hacker would like. To make it even nicer, there are dnsbl's out there to provide you a list of boxes that you can use to anonymize with. May not work with port 25, but how about port 80, 23, 21, 110, etc? The risk is real. We just choose to ignore it. It will come back to haunt us. Forget port 25 blocks. zap the whole IP. -Jack
On Thu, 24 Apr 2003 20:20:19 EDT, Jeff Kell said:
If we could somehow blackhole *only* SMTP inbound, that would be ideal, but I feel that blackholing all IP from/to those sites would be far too much collateral damage.
Unfortunately, for many of these hosts, there's no motivation to fix things until the collateral damage reaches the equivalent of having a live hand grenade stuffed into an appropriate bodily orifice. A lot of these are home systems - and the *quickest* way to get them all fixed would be if the 10 top websites refused to talk to them if they were known open proxies. On my more cynical days, I'd even advocate not worrying about the fact that home systems often have dynamic IP addresses - that provides MORE motivation for the ISP to track down the real offender before they start losing customers....
Hi I think that the end of the spam and open relays will be when the smtp servers talk only with servers with trust. The bgp approach peering and transit will be ported to a new smtp protocol. Other approach could be the dns system. A central authority that will have registered the stmp servers. This servers could delegate in other servers, etc. I don't know if is out there some draft about a new secure and spam free smtp protocol. But may be interesting for the big players that loose money (Bandwith, servers, staff, etc) accepting spam for their users. my 0.2 € or $ ;) regards, Daniel
Unfortunately, for many of these hosts, there's no motivation to fix things until the collateral damage reaches the equivalent of having a live hand grenade stuffed into an appropriate bodily orifice.
A lot of these are home systems - and the *quickest* way to get them all fixed would be if the 10 top websites refused to talk to them if they were known open proxies.
On Fri, 25 Apr 2003 14:31:57 +0200, Daniel Concepcion <dani@danielcp.net> said:
I think that the end of the spam and open relays will be when the smtp servers talk only with servers with trust.
There's 40 million .com's out there. Which ones do I trust?
The bgp approach peering and transit will be ported to a new smtp protocol. Other approach could be the dns system. A central authority that will have registered the stmp servers. This servers could delegate in other servers, etc.
The routing registries have fixed *all* those problems for BGP, haven't they? Remember - if an ISP will sell bandwidth to a spammer, they will sell a registration for their SMTP server. Any "central registry/DNS/whatever" scheme has to allow for that reality. Say this over and over until you understand: No anti-spam solution that involves asking either the spammer or their network provider any variant of the question "Are you a good witch or a bad witch?" can *possibly* work, because the spammer and their network provider both have reasons to lie and say "Good Witch". If you're going to ask *anybody*, it has to be a reputable *disinterested* third party. That's why RBLs are popular (and note the "disinterested" requirement - many RBLs become unpopular when they start using their entries to chase political agendas...)
I don't know if is out there some draft about a new secure and spam free smtp
protocol. But may be interesting for the big players that loose money (Bandwith, servers, staff, etc) accepting spam for their users.
Part of the problem is shady ISP's who *MAKE* money selling bandwidth/etc to the spammers.
--On Friday, April 25, 2003 2:31 PM +0200 Daniel Concepcion <dani@danielcp.net> wrote:
Hi
I think that the end of the spam and open relays will be when the smtp servers talk only with servers with trust.
Amazingly, even though I am posting in this thread... it is *not* about spam. Don't be fooled by the mention of open relays. Open proxies are abused for many purposes, of which spam is a minor one. I've seen open proxies in recent DoS source addresses for example.
I think that the end of the spam and open relays will be when the smtp servers talk only with servers with trust.
Amazingly, even though I am posting in this thread... it is *not* about spam.
Uops, sorry for the mistake ;) But for me the spam is really a big problem when use open proxys or relays or misconfigured smtp servers.
Don't be fooled by the mention of open relays. Open proxies are abused for many purposes, of which spam is a minor one. I've seen open proxies in recent DoS source addresses for example.
The big problem in dDoS are the smurf, virus and trojans. Generally every machine infected have an open proxy. But the open proxy itself isn't dangerous. They are only use as intermediate hop for attack machines or control other trojans. Regards, Daniel
--On Friday, April 25, 2003 4:31 PM +0200 Daniel Concepcion <dani@danielcp.net> wrote:
I think that the end of the spam and open relays will be when the smtp servers talk only with servers with trust.
Amazingly, even though I am posting in this thread... it is *not* about spam.
Uops, sorry for the mistake ;) But for me the spam is really a big problem when use open proxys or relays or misconfigured smtp servers.
Don't be fooled by the mention of open relays. Open proxies are abused for many purposes, of which spam is a minor one. I've seen open proxies in recent DoS source addresses for example.
The big problem in dDoS are the smurf, virus and trojans. Generally every machine infected have an open proxy. But the open proxy itself isn't dangerous. They are only use as intermediate hop for attack machines or control other trojans.
Sounds like you're arguing for widespread IP level blocking of open proxies then :)
Daniel Concepcion wrote:
The big problem in dDoS are the smurf, virus and trojans. Generally every machine infected have an open proxy. But the open proxy itself isn't dangerous. They are only use as intermediate hop for attack machines or control other trojans.
This is true for dDoS, but service denial is only one security concern. The proxies are often used to a) cloak originating source during dictionary and exploit attempts and b) circumvent security when the system with the proxy happens to be a "trust" system (it does happen). -Jack
Amazingly, even though I am posting in this thread... it is *not* about spam. Don't be fooled by the mention of open relays. Open proxies are abused for many purposes, of which spam is a minor one. I've seen open proxies in recent DoS source addresses for example.
It's the spam that cought my attention. QoS usually only becomes an issue when a single host produces massive amounts of traffic. Because of the way our network works I rarely get to know what is actually causing the problem, I just ACL the affected ip until the problem has been resolved. Adi
On 24 Apr 2003, Paul Vixie wrote:
On the other hand, NJABL.ORG lists 255K open relays, 170K open proxies, and a spattering of dialups and other listings. This is way beyond ACLs that I could even imagine thinking about :-)
anyone who was facile with perl could transform a full list of open relays or proxies into something that avibgpd could use, so that you could have your access controls implemented as routes rather than acl's. if you combine that with policy routing so that you can blackhole traffic based on source rather than destination, you could get the added benefit of not having to take/deliver the SYN only to blackhole the resulting SYN-ACK.
But how will the average BGP speaking router deal with an additional half million routes today or million routes in a few months? My guess is "not well"...or do you suggest some form of aggregation that would reduce the number of routes but penalize the innocent for being in the same /something as open systems? ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
anyone who was facile with perl could transform a full list of open relays or proxies into something that avibgpd could use, so that you could have your access controls implemented as routes rather than acl's. if you combine that with policy routing so that you can blackhole traffic based on source rather than destination, you could get the added benefit of not having to take/deliver the SYN only to blackhole the resulting SYN-ACK.
But how will the average BGP speaking router deal with an additional half million routes today or million routes in a few months? My guess is "not well"...or do you suggest some form of aggregation that would reduce the number of routes but penalize the innocent for being in the same /something as open systems?
i guess i have hopes of discovering a new and better equilibrium point, such that widely scalable, mechanistic shunning of open proxies would cause the owners of those hosts to wake up, smell the burning coffee, and contact their software vendor to demand improved security. but you're right, a half million additional routes would Break Stuff in most places. one could pixelize, aggregate on /28 or /24 boundaries, or maintain some kind of MRU. but it's all very hacky compared to "upgrade the bgp core to be able to handle a million more route$".
Paul Vixie wrote:
but you're right, a half million additional routes would Break Stuff in most places. one could pixelize, aggregate on /28 or /24 boundaries, or maintain some kind of MRU. but it's all very hacky compared to "upgrade the bgp core to be able to handle a million more route$".
You might as well do /28 or /24 boundaries considering the number of open proxies that are on dhcp with low lease times, and (while slow) even on dialup. It should be up front (and in BCP, AUP, etc) that any insecure system found on a network should be shut down immediately until the system is fixed (suspension of account, not termination). -Jack
--On Thursday, April 24, 2003 9:50 PM +0000 Paul Vixie <vixie@vix.com> wrote:
On the other hand, NJABL.ORG lists 255K open relays, 170K open proxies, and a spattering of dialups and other listings. This is way beyond ACLs that I could even imagine thinking about :-)
anyone who was facile with perl could transform a full list of open relays or proxies into something that avibgpd could use, so that you could have your access controls implemented as routes rather than acl's. if you
Which is exactly what opm.blitzed.org's BGP feed does ;) (I was taking avibgpd -> zebra for explosion, but when the BGP box comes back from the dead, will be native avibgpd)
--On Thursday, April 24, 2003 12:58 PM -0700 Joe St Sauver <JOE@OREGON.UOREGON.EDU> wrote:
Hi Adi,
# I am seeing an increasing number of hosts on our network become an open # proxy. So far the response to this has been reactive, once I receive # complaints from spam victims I deal with the source of the problem.
The sheer act of having an abuse address and acting on reports received on it puts you a leg and a half up on a number of other service providers who have chosen to studiously ignore abused open proxies on their networks.
Yep
# Is there an accepted way of blocking open proxy and open relay traffic # at the network edge?
...
What's really needed is some way to take open proxy DNSBL data and instantiate a dump of that data onto a suitable appliance. It is probably too much state to burden a reasonable sized border route with, but you could imagine other devices that could probably handle it (at least for moderate speed flows), much as there are currently middle boxes which rip open packets to target peer to peer traffic.
FWIW, if you can handle an extra 40k or so prefixes, blitzed.org can provide a BGP feed of their DNSBL (although the BGP talking machine is currently down for hardware issues).
On Thu, 24 Apr 2003, Joe St Sauver wrote:
The sheer magnitude of the problem also argues against manual construction of ACL's on a host-by-host basis; to date, having looked at this issue for maybe six months now, I believe the number of *known* open proxies is on the order of 120K hosts, few of which are sequentially disposed into nice CIDR-able netblocks (unless you're okay with the concept of lumping
That depends on who's "known" list you're looking at. I know of considerably more open proxies, and suspect the actual number of open proxies on the net today is at least several, if not many, times that number.
What's really needed is some way to take open proxy DNSBL data and instantiate a dump of that data onto a suitable appliance. It is probably too much state to burden a reasonable sized border route with, but you could imagine other devices that could probably handle it (at least for moderate speed flows), much as there are currently middle boxes which rip open packets to target peer to peer traffic.
That would be one heck of an ACL or routing table full of null routes. I doubt it can be done in a practical manner. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
participants (11)
-
Adi Linden -
Daniel Concepcion -
Jack Bates -
Jeff Kell -
jlewis＠lewis.org -
Joe St Sauver -
John Payne -
Paul Vixie -
Paul Vixie -
Rob Thomas -
Valdis.Kletnieks＠vt.edu