- NANOG - lists.nanog.org

RE: Clueless service restrictions (was RE: Anti-spam System Idea)
by Chen, Weijing 17 Feb '04

17 Feb '04

Sound like an any to any end to end signaling/control mechanism with authentication capabilities. Smell fishy (packet version of dial tone?) -----Original Message----- From: Alex Bligh [mailto:alex@alex.org.uk] Sent: Tuesday, February 17, 2004 3:48 PM To: Tony Hain; nanog(a)merit.edu Cc: Alex Bligh Subject: Re: Clueless service restrictions (was RE: Anti-spam System Idea) The real problem here is that there are TWO problems which interact. It is a specific case of the following general problem: * A desire for any to any end to end connectivity using the protocol concerned => filter free internet * No authentication scheme

2 1

Data center design ideas
by Michael.Dillon＠radianz.com 17 Feb '04

17 Feb '04

Someone was recently looking for tips on data center design. If you have a look at the following URL, they have a flash presentation with an overview of their new $25 million data center including some building layout diagrams http://oneandone.co.uk/xml/static/hn_data_center --Michael Dillon

3 3

An alternate plan for reducing spam
by just me 17 Feb '04

17 Feb '04

http://www.wired.com/news/culture/0,1284,57760,00.html --mghali(a)snark.net------------------------------------------<darwin>< Flowers on the razor wire/I know you're here/We are few/And far between/I was thinking about her skin/Love is a many splintered thing/Don't be afraid now/Just walk on in. #include <disclaim.h>

1 0

Commerce IPv6 RFC News
by Alfred Lee 17 Feb '04

17 Feb '04

I understand that the winter NANOG meeting had a panel session about IPv6 futures etc. I have been told by Doug Montgomery from NIST, who attended the session, that Tony Hain (from Cisco) pointed out that DoC has an RFC out on this topic and suggested that interested parties find the call and reply. The following announcement provides links to the Commerce IPv6 RFC for interested parties who may wish to participate. The U.S. Department of Commerce has formed an IPv6 Task Force to study deployment issues. The Task Force has published an RFC (Request for Comments) in the January 21, 2004 Federal Register, inviting interested parties to comment on a variety of IPv6-related issues. We have also posted the RFC on our website, at http://www.ntia.doc.gov/ntiahome/frnotices/2004/IPv6RFCFinal.htm, along with a press announcement at http://www.ntia.doc.gov/ntiahome/press/2004/IPv6_01152004.htm. Our comment deadline is March 8, 2004. We hope that you and your affiliated organizations will comment in our proceeding and look forward to your help in building a solid public record for our IPv6 study. Please contact me if you have questions. Alfred Lee Senior Advisor Office of Policy Analysis and Development National Telecommunications & Information Administration U.S. Department of Commerce Suite H4725 Washington, D.C. 20230 Phone: 202 482 1880 alee(a)ntia.doc.gov

1 0

Meeting stats from Miami
by Susan Harris 17 Feb '04

17 Feb '04

Greetings - here's some information about the last NANOG meeting (and thanks to Bob Stovall, Jason Russell, and Carol Wadsworth of Merit for gathering the stats): ====================================================================== NANOG 30 Feb. 8-10, 2004 Miami, Florida Host: Terremark Total Attendees: 488 (down from 529 at NANOG29) Speakers: 51 (3 panels) Tutorials: 4 Countries represented: 17 Peak data transmission from hotel 8.3M Peak data transmission to hotel 10.5M Wireless card loans: 26 Typical # of ethernet users: 28 Largest simultaneous # of wireless users: 335 Concurrent RealMedia viewers: up to 112 Meeting coordination: Merit Squid, DNS, DHCP: Measurement Factory Multicast/IPv6 feed: Florida International University Multicast/IPv6 equipment: Internet2 Sponsors: Arbor, Cariden, Cisco, Force10, Juniper, OPNET, Packet Design Procket, QoSmetrics, Riverstone, Switch and Data

1 0

RE: Anti-spam System Idea
by Lawrence Baldwin 16 Feb '04

16 Feb '04

> The problem is not as much actual open relays (which are now rare and almost universlly blocked) but open proxies We have come up with some terms to clarify types of open proxies: *Naturally occurring* open proxy/relay: System on which the owner has intentionally installed a mail or proxy server but has left it mis-configured such that anyone can relay through it. *Synthetic* open proxy/relay: System on which miscreant has dropped (through virus, worm, infected download, etc.) a mail or proxy server on owners system, thus enabling open relaying. By open, I mean *anyone* who discovers the ports the proxy is listening on can utilize it. *Synthetic* protected proxy/relay: Same as above, but proxy contains some sort of authentication mechanism limiting who can use the proxy...e.g. JUST the spammers....this obviously defeats open proxy testing. Others also refer to Synthetic proxies as "hijacked proxies" or "ProxyBots". Some other comments on this approach: First, I definitely agree that current RBL approaches to spam are not very effective due to the dynamic nature of Synthetic open proxies. Though I can't prove it, I suspect that as much as 90% of current spam is transmitted through such proxies...and that the majority of these proxies are installed on compromised consumer Internet connections (cable, dsl, and yes, dialup!). Current RBLs DO discover all types of proxies, however, it a matter of how much time elapses between when a given IP begins to relay spam and when it is detected and blacklisted. I suspect that the current detection delay is measured in at least HOURS and perhaps even DAYS. Furthermore, many consumer connections utilize dynamic IPs (e.g. DHCP, PPPoE, and PPP )...I suspect that sometimes an infected system has changed IP addresses several times before the first IP that relayed spam from is even listed! And don't discount dialup connections, 28.8Kbps is plenty of bandwidth to spam through when you have 10,000 of such systems in your ProxyBot army...and the fact that the relay's IP will change after each dialup connection means you'll never be RBLed for very long. DHCP, though technically dynamic addressing is far less of a problem as IP address do NOT typically change very often...remember DHCP leases are renewed automatically by the client when the lease is 50% to expiration. Many DHCP clients also cache their previously leased IP (e.g. Windows) and explicitly request the same IP even across lease expirations...depending on the service provider, DHCP clients often maintain the same IP for months at a time (aka "sticky IP"). Some PPPoE gateways also maintain username to IP caches so sticky IPs can also result in that scenario as well. I agree that strategy of not accepting mail from a given IP until it has been open proxy tested would likely be effective in stopping proxy spam. Unfortunately this approach is also highly irresponsible...and spammers would quickly migrate the proxy approach to defeat open proxy testing. In order for such scanning to be effective you would need to perform two stages scans against 65,000 ports (if you limit to TCP only). First you have to find all open ports (65,000 probes * 3 for retries), then you'd need to do at least a HTTP, SOCKS V4 and SOCKS V5 (65,000 * 3 types * 3 for retries =585000 probes) proxy test against each of those ports. That's about 13MB of traffic just for the TCP scanning phase. Although a lot of the scanning would be directed at consumer Internet users (who probably wouldn't even notice), a significant amount would be directed at bona-fide mail servers. The administrators of the latter will likely NOT appreciate this and they WILL complain. Frankly, I think the complaints are justified...if someone did that level of scanning into my network (on a daily basis no less) I'd be obligated to investigate, potentially wasting hours of time until I find out the intent behind it. Despite the activity having good intentions, bottom line is has wasted my time...now multiply that time by the 1000s of network and security administrators that would do the same. Even if such an approach was initially effective it would ultimately fail. Spammers would simply migrate to authenticated proxies, proxying via UDP (which can almost impossible to scan for), or proxying using custom protocols thus defeating SOCKS and HTTP relaying tests. Personally, I think the better approach to fighting proxy spam is to identify the spammers that are *upstream* from the proxies and then get one or more of them thrown in jail, not for spamming, but for violating federal or state computer intrusion laws. Spammers are currently using open proxies because they are free and anonomous, until you make them non-anonomous AND costly (jail) there's nothing will stop them. This is not as hard as it sounds...if you are an ISP you have hijacked proxies on your network. The RBLs can tell you which IPs are hijacked proxies, all you need do is capture Netflow data and examine the upstream IPs pummeling the hijacked proxy on it's SOCKS and/or HTTP proxy port. The results of such analysis is extremely enlightening...these spammers have NOT moved off-shore, they are NOT using multiple levels of proxy chaining and obfuscation, they are spamming DIRECTLY from their web hosting and corporate offices in North America, and as is often the case, South Florida. The other approach is to identify the "master" servers that are controlling these ProxyBot networks (most hijacked proxies "call home" to the master to report their IP and current proxy port info). In the last few months I have reverse-engineered several proxyBots and identified quite a few master servers....some hosted at US-based web hosting companies. If you take out a master server, you take out 1000s or 10s of 1000s of proxies. What amazes me is that master servers that I identified back in Oct 2003 are STILL operational today. This suggests to me that almost no one is pursuing this approach. I suspect the problem is one of a lack of coordination within service provider organizations. They all want to stop spam, but they seem more focused on preventing it from coming in vs. stopping it from going out from their own customers. Sorry, but if you can't even stop it from being sent from you own subscribers you're not going to find any solutions to the more difficult problem of blocking inbound spam. An effective fight requires a combination of Netflow data (from network engineering/ops), spam complaints (from Abuse dept), spam proxy code (from customers system), and forensic examination (by security researchers or in-house security teams). Apply this approach across several large SP networks and I guarantee it will become clear where the majority of spam is really being transmitted from... Regards, Lawrence Baldwin Chief Forensics Officer myNetWatchman.com Atlanta, GA +1.678.624.0924

2 1

Re: Anti-spam System Idea
by Joe St Sauver 16 Feb '04

16 Feb '04

Lawrence Baldwin noted: #Personally, I think the better approach to fighting proxy spam is to #identify the spammers that are *upstream* from the proxies and then get one #or more of them thrown in jail, not for spamming, but for violating federal #or state computer intrusion laws. Spammers are currently using open proxies #because they are free and anonomous, until you make them non-anonomous AND #costly (jail) there's nothing will stop them. I believe this analysis is precisely correct. #This is not as hard as it sounds...if you are an ISP you have hijacked #proxies on your network. The RBLs can tell you which IPs are hijacked #proxies, all you need do is capture Netflow data and examine the upstream #IPs pummeling the hijacked proxy on it's SOCKS and/or HTTP proxy port. ... or the non-standard proxy zombie port de jour. (Depending on how long the box has been spewing, you may also notice scans/probes from good guys attempting to determine what's up with the behavior being observed from that host, but that's easy enough to spot and ignore when you do the traffic analysis). #The #results of such analysis is extremely enlightening...these spammers have NOT #moved off-shore, they are NOT using multiple levels of proxy chaining and #obfuscation, they are spamming DIRECTLY from their web hosting and corporate #offices in North America, and as is often the case, South Florida. ... and from Texas and California and New York, among others. And if you start looking at end-to-end performance and operational issues, it is easy to understand why spammers have NOT moved overseas when shovelling traffic through proxy spam zombies: -- If connecting from overseas, they have trans-pacific latencies and potential packet loss issues (with the reduced throughput that implies), and they can get that comparatively crumby throughput via expensive connections which are potentially subject to governmental interference, with any required systems work being a "remote hands" operation (with inconvenient time zone-related and potential language-related issues). Besides, some people may even block all traffic at their border from those overseas providers... or -- they can get very low latencies from multiple redundantly-connected geographically diverse colo providers here in the US at comparative rock bottom prices and with easy physical access to their systems... that is, they can do this as long as people DON'T bother doing as Lawrence suggests. If you DO start looking at inbound netflow data associated with compromised hosts, things become pretty clear, pretty darn quickly. And if you tie in AOL scomps or other abuse reports, it becomes pretty trivial to even tell *which* spammer is abusing your compromised hosts from domestic colo providers -- you then know WHO, WHAT, WHEN, WHERE, WHY and HOW people are abusing that host. Frost, apply candles, present to law enforcement for processing and attention (or blackhole/filter the colo block at your border, if you're the impatient type or are skeptical about getting law enforcement involved). To tell you the truth, I've been quite surprised that major broadband providers with tens of thousands of compromised customer hosts haven't done that already. Regards, Joe St Sauver (joe(a)oregon.uoregon.edu) University of Oregon Computing Center

1 0

Re: Anti-spam System Idea
by Michael.Dillon＠radianz.com 16 Feb '04

16 Feb '04

>To me, the approach you advocate is something like saying "do away with any centralized >law enforcement, force everyone to carry guns, and if anyone suspects that someone >else is committing a crime, they are obliged to shoot them." I believe that blocking >spam at its source is far easier than blocking it at every possible destination. The >less parties involved in blocking the spam, the higher the probability that the spam >will be successfully blocked. To do this you need to form a police force and a judiciary. Neither are possible in the absence of an organized society. The first step is for some of the larger senders/receivers of email to sit down around a table and form an email services consortium that can set "best current practice" standards and police those standards. This is something that network operators can do. --Michael Dillon

1 0

Re: Identifying IP address types
by Michael.Dillon＠radianz.com 16 Feb '04

16 Feb '04

>1.0.168.192.in-addr.arpa in ptr some1.example.net > in hinfo Dynamic Dialup >2.0.168.192.in-addr.arpa in ptr some2.example.net > in hinfo Static xDSL And why shouldn't an ISP be allowed to sell dialup or XDSL services to someone who runs their own SMTP server? Let's not start mucking around with the ISP's business model here. IN HINFO "No SMTP" If the ISP's customer does have an SMTP server, all they need to do is talk to their supplier and get this changed to IN HINFO "SMTP OK" Of course, I have to add the obligatory plug for LDAP here since this is the kind of thing LDAP was made for. I know that the early DNS was envisioned to support all of these different needs but over time DNS was simplified and focused on doing one job well while people who needed a more general purpose directory migrated to using LDAP. Also, just because some (or all) ISPs publish a directory of SMTP capable IP addresses doesn't mean that third parties cannot continue to publish their own directories as well. And if these 3rd party directories lost the pejorative naming (blacklist, block lists) then perhaps more people would volunteer useful attributes to be published in them. --Michael Dillon

1 0

RE: Anti-spam System Idea
by Michael.Dillon＠radianz.com 16 Feb '04

16 Feb '04

>If these exist then why are we still having problems? Why do we let >customers who have been infected flood the networks with traffic as they do? Someone sent me a message on Friday with a Dykstra quote that sums it all up... It is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead -- E.W Dijkstra, 1930-2002 It simply isn't possible to block spam no matter how many axes we use and how cleverly they are designed. If we would put the same amount of effort into a secure Internet email architecture, then the whole SPAM issue would just fade away. Today, there it is not possible to secure the email system by securing a subset of email servers. SPAM can enter the system at any email server and therefore we have to secure all servers in order to block SPAM. But any particular email server also needs to accept legitimate email from a large and unbounded number of sending servers. So it is a very, very hard problem to either separate SPAM sources from legitimate email sources or to separate SPAM messages from legitimate email messages. However, if the world shifted and the only way to send email was to use a secure authenticated submission protocol to pass the message to an ISP with whom you have a business relationship, then the scale of the problem changes. Now you only have to secure the submission servers and any particular organization can more easily distinguish between the small number of customers and the larger number of non-customers. Of course, this also means that all SMTP servers must also be secured to only accept email from known authenticated sources. This is technically possible if we had the will. However, today few people have the will to attempt to fix this problem because of the phantom SPAM problem. We see the symptoms of the email architecture disease and assume that SPAM is the disease itself rather than merely a symptom of the disease. In the meantime, Internet users are discarding the use of email in favor of instant messaging networks, some of which are more secure than email and have less SPAM. You will note that IM services are rarely offered by an ISP to its customers as part of a service bundle. The net effect of this is that one of the value-added services that smaller ISPs can offer is becoming eroded and replaced by a value-added service that is only offered by the largest ISPs. --Michael Dillon

1 0