June 1998 - Test - lists.nanog.org

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 21 Jun '98

21 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 20 Jun '98

20 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 19 Jun '98

19 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

Government scrutiny is headed our way
by Michael Dillon 19 Jun '98

19 Jun '98

Government scrutiny is headed our way http://www.fcw.com/pubs/fcw/1998/0615/fcw-frontcyber-6-15-1998.html The feds are worried that it is too hard to track down cyber attackers. Although the article doesn't say this explicitly I expect that it won't be long before we see politicians calling for some sort of mandated tracing capabilities between network providers And since IOPS http://www.iops.org/ is hosted by a government funded agency located on the outskirts of DC, I expect that it will be involved in this whole thing. If we could track attacks to their source more quickly, then government would not feel the need to intervene. This may require some changes to router software but unless network operators ask for the changes, the manufacturers will not do it. We need some sort of protocol that will recursively track spoofed source address packets back to their source one hop at a time. Given a destination address the protocol would track it to the previous hop router and recurively initiate the same tracking procedure on that router. Once the attack is tracked to the source, the probe would unroll and report the results to all routers along the probe path for logging or reporting. We have seen that when misconfigured equipment can be quickly identified, such as the smurf amplifiers, then we can apply pressure and get things fixed. Similarly if we can quickly identify the source of a spoofed source address attack then we can apply pressure to get filters in place and have people arrested or secure an insecure machine as the case may be. -- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael(a)memra.com http://www.memra.com - *check out the new name & new website*

7 13