- NANOG - lists.nanog.org

RBL Update (Re: Lets go vixie!! rbl)
by Paul Vixie 22 Jun '98

22 Jun '98

paradox(a)nac.net (Ryan Pavely) writes: > Wholy jesus :) > > http://maps.vix.com/cgi-bin/lookup?207.68.152.137 > > ps.. 207.68.152.137=msn.com's mx host. well, ok, so we blackholed microsoft (for the second time now). the blockade lasted 3.5 days, and they used several interesting tricks: first they moved their mail relays to different addresses -- hoping, i suppose, that we would not notice the spam being relayed through the new set? then they sent out a simply *amazing* bit of direction to their customers (many of them, it seems, were calling the 1-800-* number asking why their mail was bouncing). we heard it from one of their customers who was kind enough to include in their complaint to us the mail they'd been given by their microsoft network representative: |Greetings-- | |I am at a loss. I contacted MSN to see what it could do about helping |correct a problem with mail we send to my wife's sister. It says it cannot |help me. What do I have to do in order to send mail to this family member? | |I am enclosing MSN's response to my query; it includes my message sending |them to the MAPS screens: |---------------------------------------------------------- |Hello, | |Thank you for posting to Ask msn Member Support. I appreciate the |opportunity to assist you. | |We apologize for the inconvenience of having your mail blocked by this |server. I have visited the website that the message referred you to and |regret to inform you that we can do nothing from MSN as far as |configuration settings to your system to stop them from blocking the mail. |It is their system that set the block, and it will need to be their system |that removes it. According to the website that you were referred to they |are only blocking that particular IP address. If in fact this is true then |you should be able to send E-mail after you log off MSN and log back on. |MSN gives you a new IP address each time you log on. I do not know for |sure, but am more likely to believe that they have in fact blocked all MSN |and MSN.COM domain names from sending mail. If this is true then even |changing IP addresses will not help you send mail to the address you are |attempting to mail. You need to contact the postmaster of the domain you |are attempting to send mail through. In all likelihood this would be |addressed as "postmaster@(domain name.com)" where (domain name) represents |the name of the ending of the address you are attempting to send to. For |example...if you were attempting to send to an MSN address it would be |"postmaster(a)msn.com" I apologize for the trouble, but if anyone can stop |this domain from blocking users mail transport it is the domain itself. |Hope this helps explain things. | |In order to ensure a quick response to future concerns; please continue to |utilize the on-line forms at the address provided below. If you reply to |this email, be sure to include the original message. | |http://memberservices.msn.com/ | |We hope you are enjoying The Microsoft Network, and we look forward to |meeting all your service needs. | |Thanks, |msn Member Support and i have to admit, until i saw the above text, i was worried that maybe we shouldn't have blackholed MSN. whenever we have to blackhole something large, we get mail from RBL subscribers asking "are you crazy?" or similar. i hate to shake the tree too hard all at once -- the wrong things fall out. but when i saw what microsoft was telling their customers, it became clear to me that this was a battle we could not avoid. hearts and minds, etc. i'd like to correct one misimpression, though: i don't do the RBL alone. i make the decision whenever we have to blackhole somebody, since i'm the one that gets sued. but there's a team of volunteers working night and day to research spam sources and relays, answer phones, help people reconfigure their sendmail (or other mailers), and fill my inbox with just the really *high*quality* spam rather than the run-of-the-mill stuff that doesn't need blackholing (or which came from or through a place that was willing to plug their spam leak.) any indication you may have seen that i could last even five minutes as the main and only RBL guy was incorrect, and holding that view in any form would dishonour the very real and necessary work performed by the whole MAPS RBL team. microsoft, btw, finally called in late this morning and said "ok, we give up, we'll turn off third party relay on our mail gateways." it's not done yet, but they told us when to expect it to be done, and so we've removed them from the RBL until at least that time. we're still getting about two complaints per minute from the backlog of msn.com customers who are only now getting back and finding bounced mail in their inboxes. hopefully it'll level off soon. the only other fun thing i'd've said had i made it to NANOG for my usual RBL status update this last time, is that someone asked us to remove 2.0.0.0/8 from the RBL since the IP address of their mail server ended in ".2" and some customer had done a manual "nslookup" in the RBL.MAPS.VIX.COM zone for their address but without reversing it first (remember, we're like IN-ADDR.ARPA) and had cancelled a leased T1 on the basis that they refused to deal with spammers. OUCH! i hate it when that happens. i offered to intercede, but was told that it was just too late. however, we can't removed 2.0.0.0/8 from the RBL until IANA allocates it, as we still get periodic complaints from people who get blackholed when they try to use unallocated address space. we ask where they got their address space and then we never hear back from them. but note -- the only reason it doesn't work for them is the RBL; there's not wide-enough-spread ingress route filtering going on out there, since most of the net, except for RBL subscribers, is actually reachable from unallocated address space. i know that jerry and tony and others are working on this, but i thought i'd point out to those assembled that it's a REAL problem -- try it yourself and note how far you can get, assuming that your BGP neighbors don't filter ingress, it's definitely a safe bet that THEIR neighbors won't. -- Paul Vixie La Honda, CA "Many NANOG members have been around <paul(a)vix.com> longer than most." --Jim Fleming pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network)

20 34

RE: Government scrutiny is headed our way
by Andrew Metcalf 22 Jun '98

22 Jun '98

I have never heard of either of these things, and I don't think they are worthy of the NANOG list. I use WinGate at home, it is a Win95 gateway program, so you can have a little proxy at home for your other systems with only one dialup. I'm sure many of you are familiar with it. I can't even imagine how it could generate spoofed packets in its legitimate form ( and I don't know of anyone who has modified it to do so). Go to Yahoo or win95.com and look up Wingate for more info. As far as I remember the reason SMURFING is called SMURFING is because the executable is called smurf! How would you "ban that code"? Ban a commercially viable product? The system.exe file? What is that? I have not heard of that either, I assume you are talking about win95 still. Maybe you mean system.dat (system registry)? The registry cannot be modified to spoof packets my friend. Surely what you are talking about is not true. Neither of these claims is worth techical merit. I'll now go back to my normal lurking. thanks andrew If we believe absurdities, we shall commit atrocities. - Voltaire On Sunday, June 21, 1998 5:03 AM, Henry Linneweh [SMTP:linneweh@concentric.net] wrote: > Now that we have gotten down to the nitty gritty here. > > AGAIN the main mechanism for spoofing the smurf attacks is A program > call wingate, ban that code and this problem will be cut more than in half. > > Next there is a rumor that 8000 users have been infected with a tweaked > system.exe file that makes that user a smurf amplifier unwittingly. These > are things to watch for. I wish there was an easier way to break bad news. > > Henry > >

2 1

Tracking cooperation (Re: Government scrutiny is headed our way)
by Hal Murray 22 Jun '98

22 Jun '98

> >One possibility might be to offer a reward to the NOC that gets the > >evidence on the first smurfer to get tossed in jail or fined more > >than $100K. > Who is going to put up the money? I was thinking more of pride or honor rather than serious cash. Maybe a plaque would be a better carrot. Or a plaque and enough cash to take the team out for a good dinner. How much would "Our NOC has it's act together" be worth when recruting? How many people on this list would chip in $5?

2 1

Re: Government scrutiny is headed our way
by Hal Murray 21 Jun '98

21 Jun '98

> If A NOC refuses to obey the law and investigate on behalf of a paying > client that DoS has occurred than they become party to a criminal act > after the fact and are as guilty as the originator of the attack and can > be held accountable and their staff can arrested and you have the > right to sue for $4000.00 as do each one of your individual > customers. The catch in there is "paying client". The typical smurf packet hops through several organizations (ISPs). The victim only has a contract with his ISP. Where did $4K come from? Do you have a URL describing that law?

1 0

Re: RBL Update (Re: Lets go vixie!! rbl)
by Paul Vixie 21 Jun '98

21 Jun '98

> >The agreement Paul Vixie makes RBL users sign states that EXPLICITLY. No. > >You are not allowed to use the RBL unless you disclose such use fully to > >your customers and/or downstreams. There is apparently some ambiguity surrounding my use of the verb "publish" in the RBL Subscriber Agreement. I will see that this is fixed in V2.1. > "Makes"... makes how? I simply enabled it in my sendmail configs and ran > with it. Didn't even SEE where it mentioned that I *HAD* to go agree to > stuff. There is no requirement that anyone sign a license if they aren't subscribing, where "subscribing" means receiving it as an eBGP4 or DNS "feed". If you're using "FEATURE(rbl)" in sendmail 8.9.0, or a similar feature of other mailers, you're using the RBL but you're not a subscriber (and more power to you). > Dunno what the solution is, but I can see a somewhat real problem here. The first line of complaint is the ISP who uses the RBL. If someone turns it on without notifying their customers / downstreams, they'll hear about it right quick. -- Paul Vixie La Honda, CA "Many NANOG members have been around <paul(a)vix.com> longer than most." --Jim Fleming pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network)

2 1

Tracking cooperation (Re: Government scrutiny is headed our way)
by Sean Donelan 21 Jun '98

21 Jun '98

>Would you and other operators be willing to modify peering agreements >to include serious fines for running a smurf amplifier or allowing >packets with bogus source addresses to enter the system? See my previous rant about providers barely honoring existing agreements. I don't see the point in adding things that are going to be ignored. >Tracking back bogus source addresses seems hard. Would fines on >smurf amplifiers be good enough to fix the smurf problem? Or do >we need to catch a smurfer to use as an example? In reality this isn't a problem unique to the Internet industry. Every type of carrier (trucking, railroad, telephone, financial etc) has the same problem of tracking things. And in every case it is, and I suspect, always will be a difficult problem anytime the package is tranferred between multiple carriers. It barely works when everything works correctly. Tracing false information is done only when the loss is greater the cost of trying to track it down. Even the financial industry has found it in their interest to ignore a great number of things below a certain threshold. Identity fraud is a good example. It may cost the individual a great deal of time and effort to track down someone fraudlently using their identity, but for most financial institutions it is an inmaterial amount. >Currently, NOCs don't have much financial interest in tracking down >a smurfer. Yes and no. The NOCs have a great deal of potential liability, but in most cases take the gamble nothing will happen if they ignore it. Think of it as a reverse lottery. There is a one-in-a-trillion chance you might have a billion dollar liability, but think of all the one dollar trouble tickets you saved by doing nothing. >One possibility might be to offer a reward to the NOC that gets the >evidence on the first smurfer to get tossed in jail or fined more >than $100K. Who is going to put up the money? Even for CALEA the government is putting up a rather trivial amount of money, relying instead on the big stick of huge fines for non-compliance. >Another might be to setup peering contracts that encourage ISPs/NSPs >to track down smurfers. See above. >I can't quite come up with the right thing to suggest. Everything >I think of has too many possibilities for gaming. In other industries the solution has been to require a police report. Not because the police wil do anything, but because filing a false police report is a felony just about everywhere. Filing a false trouble ticket isn't. The problem is most police won't make a report unless it is clear a crime has been comitted. Breach of contract is not a crime, but fraud is. >Do smurf attacks always happen late at night and on weekends? Smurfs tend to be highly correlated with activity on IRC. Peak IRC activity happens at night and on weekends. However it should be pointed out this is just a correlation, not a cause and effect. I suspect, but have no proof, that smurfs patterns tend to follow your typical criminal patterns, and happen during peak ISP hours 6pm to 11pm. Unlike more typical cracking activities, I don't see the same out-of-phase pattern of smurfs. >Would major NSPs be willing to setup a smurf hotline so trusted smart >people, like Karl, could bypass the first several layers of screening >and get the data to the right person fast? What an excellent idea! -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Layer 2 broadcast address aggregation and SMURF: Was RE: Smurf Amp Nets
by Martin, Christian 20 Jun '98

20 Jun '98

>On Thu, Jun 18, 1998 at 10:16:38PM -0700, Vern Paxson wrote: >> > 0.0.0.0 >> > 10.0.4.0 >> > 127.0.0.0 >> > 255.255.255.0 >> >> These are pretty cool, I must say. Exactly how does the smurf attacker >> route their echo requests to them? >> >> Vern > >They are straight forged packet flows. These also can be situations where layer two devices have private networks mixed in with public networks on the same VLAN. Remember broadcast address translation between layer 3 & 2 through a store-and-forward (or cut-through - any MIN type box will do this) switch will generate MAC layer frames and deliver them out of each port in the VLAN. I know broadcast pings on a Cisco device that is connected to a switch, where the output interface has IP block A, and the VLAN has IP blocks C, D, E, will result in replies from all networks connected to the VLAN, not just the IP block configured on the router. This is why on almost every attack we've seen here, there have been RFC 1918 addresses involved as amplifiers. Christian

1 0

RE: RFC781 timestamp
by Hirohisa TANIGUCHI 20 Jun '98

20 Jun '98

Thanks for reply; > If I remember correctly, that service is part of tcp-small-servers (or maybe > udp-smaller-servers) which most people have disabled due to the potential > for exploitation in DOS attacks. I think {tcp|udp}-small-servers is for configuring "small" services like echo,discard, and so on ... I've seen that for many routers IP timestamp option is enabled at least for flag = 1. Ciao, -- Hirohisa Taniguchi (taniguti(a)ntttqn.tnl.ntt.co.jp)

2 1

Re: Smurf Amp Nets
by Richard Thomas 20 Jun '98

20 Jun '98

-----Original Message----- From: Karl Denninger <karl(a)mcs.net> To: Vern Paxson <vern(a)ee.lbl.gov> Cc: Andrew Herdman <andrew(a)whine.com>; nanog(a)merit.net <nanog(a)merit.net> Date: Friday, June 19, 1998 9:37 AM Subject: Re: Smurf Amp Nets >On Thu, Jun 18, 1998 at 10:16:38PM -0700, Vern Paxson wrote: >> > 0.0.0.0 >> > 10.0.4.0 >> > 127.0.0.0 >> > 255.255.255.0 >> >> These are pretty cool, I must say. Exactly how does the smurf attacker >> route their echo requests to them? >> >> Vern > >They are straight forged packet flows. Nah those are machines on the relay being used sending those replies. Sometimes from machines given those ips and sometimes from misconfigured networks. I used to have one that would reply 500 times from 10.0.0.1. Just because the broadcast being used is 1.2.3.255 does not mean you will only get packets from 1.2.3.x, and conversely because you receive pings from 1.2.3.x and 1.2.4.x and 1.2.5.x does not necessarily mean there are 3 broadcasts being used. It could easily be only on 1.2.3.255 or even 1.2.69.255 for all you know (and I've seen strange cases of each). This is a complication when you are getting your bcasts from logs of a smurf attack because you never really know where those 10.0.0.0/8's come from, and a complication when you are getting your bcasts from a network scan because you sometimes see huge arrays of broadcasts that are actually just the same hosts being repeated on different broadcasts (ex: you just found 1.2.3.255 - 1.2.203.255 all have 200 dupes each, but closer examination reveals every broadcast returns replies from the same host). Fortunately these problems are even more annoying to the smurf kiddies where it is important to have an accurate estimation of the damage that will be inflicted.

1 0

Definitive documentation for RHWOIS/SWIP
by Howard C. Berkowitz 19 Jun '98

19 Jun '98

Would some kind soul point me to the most recent procedure writeups for RWHOIS and SWIP? I have an assortment of document references, but I'm not sure which is the most recent and definitive. Thanks.

2 2