Denial of service attacks apparently from UUNET Netblocks
Ladies and Gentlemen, This evening, at 11:45 PM CDT, a serious and severe denial of service attack was launched against MCSNet. This was a very well-coordinated effort which crippled us for over an hour. The individuals involved sourced traffic from 207.76.*.* towards *unicast* addresses within our network and to bogus addresses also in the same netblocks. The machines implicated individually as sources, so far, all appear to be MAX TNTs within UUNET's core. Examples are 207.76.40.175 and 207.76.57.161/164. Each of the source addresses hit several machines with essentially-identical packet and byte counts over a sustained period. The attack came from several different core blocks in 207.76, and was received on *both* of our primary DS-3 feeds, burying the core network segments inside our Chicago offices and rendering the network essentially unusable. We have taken measures to both capture repeat attempts and filter selected source locations in an attempt to prevent a reoccurance. We *did* get a good trace on the tail end of the attack; it clearly delineated the source of the data. Due to the highly-concentrated nature of this attack, its unicast destinations, the fact that we refuse source-routed traffic and further refuse directed broadcasts, I am at this point assuming that the source addresses which we saw are genuine. This might indicate that either someone inside UUNET was responsible, or that someone has penetrated UUNET's internal security and compromised the source devices. As TNTs are typically connected to very-high-speed egress pathways, they would be quite capable of sourcing the data flows we saw this evening. Again, this was *NOT* a smurf attack; it neither fit the profile nor would it have had the pattern of source and destination addresses which we captured. We are treating this as a criminal matter and referring it to the federal authorities in the morning. At this point our network status is nominal. Other operators may wish to be on the lookout for similar types of attacks, and extreme packet rates which are sourced from these address blocks. We have taken preventive measures against a repeat performance; this may inconvenience some legitimate users, but frankly, until we can figure out what's going on and UUNET decides to get on the phone with us relating to this incident we're going to act conservatively to preserve our operational status. Again, we're not casting aspersions on UUNET directly in this matter, other than the documented fact that the source addresses of the packets were all within the above listed netblock. However, it is worthy of note that of the various carriers we contacted during this incident, NONE were able to be reached with someone who knew what they were doing for over an *HOUR*. Folks, this is unacceptable. Our customers were in touch with me inside of 10 minutes into this thing, and I find it incredible that none of the other national providers involved think this kind of incident is important enough to have people on-call and available during off-hours to cover this. If someone of these people HAD been available, we might have caught the perpetrator(s) in the act. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Ladies and Gentlemen,
This evening, at 11:45 PM CDT, a serious and severe denial of service attack was launched against MCSNet.
The machines implicated individually as sources, so far, all appear to be MAX TNTs within UUNET's core.
Examples are 207.76.40.175 and 207.76.57.161/164.
More specifically, TNT's in UUNET's New York dialup area: Name: e24.tnt16.nyc3.da.uu.net Address: 207.76.57.161 Name: e24.tnt19.nyc3.da.uu.net Address: 207.76.57.164 Name: tnt31.nyc3.da.uu.net Address: 207.76.40.175
This might indicate that either someone inside UUNET was responsible, or that someone has penetrated UUNET's internal security and compromised the source devices. As TNTs are typically connected to very-high-speed egress pathways, they would be quite capable of sourcing the data flows we saw this evening.
More likely, since these are going to be dynamically allocated addresses, it was a single UUNET customer dialing in multiple times (ISDN...) and slamming the bits at you.
If someone of these people HAD been available, we might have caught the perpetrator(s) in the act.
S'okay. Have the feds subpoena UUNET for the connect logs for these max'es. UUNET keeps the logs and is capable, given the exact time of the attack(s), of going through the logs, identifying exactly who it was, and if it's one of their customers, giving the personal info to the feds. If it's a reseller's customer, they can get the user info and forward it to the reseller and inform the feds who they need to talk to for the personal info. Whoever it was is as good as nailed. Steve Mansfield steve@nwnet.net NorthWestNet Network Engineer 425-649-7467
Steve Mansfield writes... [snip snip snip]
S'okay. Have the feds subpoena UUNET for the connect logs for these max'es. UUNET keeps the logs and is capable, given the exact time of the attack(s), of going through the logs, identifying exactly who it was, and if it's one of their customers, giving the personal info to the feds. If it's a reseller's customer, they can get the user info and forward it to the reseller and inform the feds who they need to talk to for the personal info. Whoever it was is as good as nailed.
Unless it was a stolen account. With more and more "naive" users coming online, the chance of this kind of thing happening is greater and greater. You can shut off the account. Feds can visit the home of whoever owns the account. They can even be blocked from ever getting any account at any ISP for life. But if this possibility is fact, you won't have the perp and they can attack again. Now if the telco has records of all the phone calls you can find out where the calls actually came from. Maybe that's the perp. Maybe not. What is ultimately needed is some better real time detection of this kind of thing sufficiently deployed so that it is present on all routers where the exposure exists. You may not catch the perp, but you might reduce the damage it causes. How to encourage this to be done is left as an exercise for the reader. -- Phil Howard +-------------------------------------------------------------+ KA9WGN | House committee changes freedom bill to privacy invasion !! | phil at | more info: http://www.news.com/News/Item/0,4,14180,00.html | milepost.com +-------------------------------------------------------------+
I would not be surprised if the caller's phone number were logged, most modern modem banks talk ANIS and DNIS, which if I'm remembering correctly is basically caller ID. I'm thinking of putting this on our POP, as there doesn't seem to be an extra charge to get the data from the telco. Charles ~~~~~~~~~ ~~~~~~~~~~~ Charles Sprickman Internet Channel INCH System Administration Team (212)243-5200 spork@inch.com access@inch.com On Mon, 6 Oct 1997, Phil Howard wrote:
Date: Mon, 6 Oct 1997 21:30:11 -0500 (CDT) From: Phil Howard <phil@charon.milepost.com> To: steve@nwnet.net Cc: nanog@merit.edu Subject: Re: Denial of service attacks apparently from UUNET Netblocks
Steve Mansfield writes...
[snip snip snip]
S'okay. Have the feds subpoena UUNET for the connect logs for these max'es. UUNET keeps the logs and is capable, given the exact time of the attack(s), of going through the logs, identifying exactly who it was, and if it's one of their customers, giving the personal info to the feds. If it's a reseller's customer, they can get the user info and forward it to the reseller and inform the feds who they need to talk to for the personal info. Whoever it was is as good as nailed.
Unless it was a stolen account. With more and more "naive" users coming online, the chance of this kind of thing happening is greater and greater. You can shut off the account. Feds can visit the home of whoever owns the account. They can even be blocked from ever getting any account at any ISP for life. But if this possibility is fact, you won't have the perp and they can attack again.
Now if the telco has records of all the phone calls you can find out where the calls actually came from. Maybe that's the perp. Maybe not.
What is ultimately needed is some better real time detection of this kind of thing sufficiently deployed so that it is present on all routers where the exposure exists. You may not catch the perp, but you might reduce the damage it causes.
How to encourage this to be done is left as an exercise for the reader.
-- Phil Howard +-------------------------------------------------------------+ KA9WGN | House committee changes freedom bill to privacy invasion !! | phil at | more info: http://www.news.com/News/Item/0,4,14180,00.html | milepost.com +-------------------------------------------------------------+
I would not be surprised if the caller's phone number were logged, most modern modem banks talk ANIS and DNIS, which if I'm remembering correctly is basically caller ID. I'm thinking of putting this on our POP, as there doesn't seem to be an extra charge to get the data from the telco.
I would have to disagree, in Canada anyway, the telco charges extra for these features, andand while the modemracks will support it few if any ISP are gonna spend the $$$ for it. Until of course they are attacked and loose business and then the VP's the cost of NOT having it. -Jim
Charles
~~~~~~~~~ ~~~~~~~~~~~ Charles Sprickman Internet Channel INCH System Administration Team (212)243-5200 spork@inch.com access@inch.com
On Mon, 6 Oct 1997, Phil Howard wrote:
Date: Mon, 6 Oct 1997 21:30:11 -0500 (CDT) From: Phil Howard <phil@charon.milepost.com> To: steve@nwnet.net Cc: nanog@merit.edu Subject: Re: Denial of service attacks apparently from UUNET Netblocks
Steve Mansfield writes...
[snip snip snip]
S'okay. Have the feds subpoena UUNET for the connect logs for these max'es. UUNET keeps the logs and is capable, given the exact time of the attack(s), of going through the logs, identifying exactly who it was, and if it's one of their customers, giving the personal info to the feds. If it's a reseller's customer, they can get the user info and forward it to the reseller and inform the feds who they need to talk to for the personal info. Whoever it was is as good as nailed.
Unless it was a stolen account. With more and more "naive" users coming online, the chance of this kind of thing happening is greater and greater. You can shut off the account. Feds can visit the home of whoever owns the account. They can even be blocked from ever getting any account at any ISP for life. But if this possibility is fact, you won't have the perp and they can attack again.
Now if the telco has records of all the phone calls you can find out where the calls actually came from. Maybe that's the perp. Maybe not.
What is ultimately needed is some better real time detection of this kind of thing sufficiently deployed so that it is present on all routers where the exposure exists. You may not catch the perp, but you might reduce the damage it causes.
How to encourage this to be done is left as an exercise for the reader.
-- Phil Howard +-------------------------------------------------------------+ KA9WGN | House committee changes freedom bill to privacy invasion !! | phil at | more info: http://www.news.com/News/Item/0,4,14180,00.html | milepost.com +-------------------------------------------------------------+
[ On Tue, October 7, 1997 at 10:40:57 (-0300), James deleskie wrote: ]
Subject: Re: Denial of service attacks apparently from UUNET Netblocks
I would not be surprised if the caller's phone number were logged, most modern modem banks talk ANIS and DNIS, which if I'm remembering correctly is basically caller ID. I'm thinking of putting this on our POP, as there doesn't seem to be an extra charge to get the data from the telco.
I would have to disagree, in Canada anyway, the telco charges extra for these features, andand while the modemracks will support it few if any ISP are gonna spend the $$$ for it. Until of course they are attacked and loose business and then the VP's the cost of NOT having it.
Exactly. Just because the telco charges for ANI service (and maybe it requires extra cost options in the NAS) is no excuse for not having it fully implemented and securely logged. Not doing so is negligent (perhaps not criminally so, but probably enough to get named as a party to any action against the perpetrators, assuming they can be discovered without such logs). -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
Keep in mind, that even if that ANI was obtainable that it still doesnt solve the problem at hand. Denial Of Service attacks have just as much political infastructure problems as they do technical ones. A majority of the DoS attacks that MCI assists in tracing originate from "Jump" points; comprimised shell accounts that offer high bandwidth capascity. These shell accounts ("T3 Eggdrop Shells") are high commodity items on hacker trading grounds, like IRC (eg; #shells). DoS attacks usually involve several hub points; traversing several ISPs (reducing response times), Jump Off points (needing coordination), and then their is the final hop; usually a dialup account - either stolen, or created using a stolen credit card, making ISP subscriber information useless. Even if the magical ANI information can be obtained (eg; ANI and CLID can actually be part of the accounting stream for some NASes), this data isn't typically provided to the victim, or victim's ISP without a court order, requiring law enforement assistance. Despite the fact that a majority of customers we deal with do not want Law Enforcement assistance ("I just want the attack to stop"), the ones who do want it have to deal with jurisdictional office politics and heavy case loads. A majority of Denial Of Service Attacks do not fit the minimum jurisdictional-specific dollar loss, nor Felony class baseline to be considered a worthwhile case to pursue. Additionally, since a majority of these attacks are sourced from minors (read; High Dweeb Factor), prosecution of these individuals is also not usually an option (unless, of course, you are in Texas). Civil remidies, however, should not be ruled out; as their effects are sometimes greater felt than criminal prosecution; loss of computer equipment and heavy fines that involve garnished wages for the next 5-10 years typically equate to "Gee, if I do this again, I won't be able to buy Doom". Rather than the criminal prosecution, which results in probation and a now "professional" history that allows the hacker to pursue a carrer in security consulting ("He MUST know what he's talking about, he's a convicted computer hacker"). :sigh: The social/political issues need to be addressed just as strongly as the technology issues. Speed bumps don't prevent speeding, radar traps do. Not wanting to get into an analogy war here, you get the point. I would recommend that ISPs obtain NOC and Security contacts for all that they peer with,and I would recommend that customers of ISPs obtain NOC and Security Team telephone and pager numbers of their ISPs. If your ISP doesn't have such information, nag them until they get it, or move to another ISP. Pre-Plan for these attacks; on-the-fly coordination just doesn't cut it when you dealing with high-impact, fast cycle time attacks. Security teams at ISPs should also obtain contact information for their local and federal law enforcement offices. Such contacts should be tested regularly, (eg; monthly) to ensure they are accurate. You can also ask Law Enforcement to provide you with a briefing on the types of computer investigations they are working on and seeing, which may help you plan your method of attack or compensation, or help you justify your continued existance with your upper management. Other source of information/contact would be NCSA'a ISPSEC team (http://www.ncsa.com), IPOS team, CERT (http://www.cert.org), and FIRST (http://www.first.org). Also, MCI has released a Denial Of Service "tracking" program called DoStracker that helps to automate detection and tracing of these types of attacks through large backbone networks. DoSTracker is freely available to the public and can be found at: ftp://ftp.mci.net/outgoing/dostrack742812.tar ================================================================ Dale Drew MCI Telecommunications Sr. Manager internetMCI Security Engineering Voice: 703/715-7058 Internet: ddrew@mci.net Fax: 703/715-7066 MCIMAIL: Dale_Drew/644-3335 At 10:40 AM 10/7/97 -0300, James_deleskie wrote:
I would not be surprised if the caller's phone number were logged, most modern modem banks talk ANIS and DNIS, which if I'm remembering correctly is basically caller ID. I'm thinking of putting this on our POP, as there doesn't seem to be an extra charge to get the data from the telco.
I would have to disagree, in Canada anyway, the telco charges extra for
the modemracks will support it few if any ISP are gonna spend the $$$ for it. Until of course they are attacked and loose business and then the VP's the cost of NOT having it.
-Jim
Charles
~~~~~~~~~ ~~~~~~~~~~~ Charles Sprickman Internet Channel INCH System Administration Team (212)243-5200 spork@inch.com access@inch.com
On Mon, 6 Oct 1997, Phil Howard wrote:
Date: Mon, 6 Oct 1997 21:30:11 -0500 (CDT) From: Phil Howard <phil@charon.milepost.com> To: steve@nwnet.net Cc: nanog@merit.edu Subject: Re: Denial of service attacks apparently from UUNET Netblocks
Steve Mansfield writes...
[snip snip snip]
S'okay. Have the feds subpoena UUNET for the connect logs for these max'es. UUNET keeps the logs and is capable, given the exact time
of the
attack(s), of going through the logs, identifying exactly who it was, and if it's one of their customers, giving the personal info to the feds. If it's a reseller's customer, they can get the user info and forward it to the reseller and inform the feds who they need to talk to for the
info. Whoever it was is as good as nailed.
Unless it was a stolen account. With more and more "naive" users coming online, the chance of this kind of thing happening is greater and greater. You can shut off the account. Feds can visit the home of whoever owns
account. They can even be blocked from ever getting any account at any ISP for life. But if this possibility is fact, you won't have the perp and they can attack again.
Now if the telco has records of all the phone calls you can find out where the calls actually came from. Maybe that's the perp. Maybe not.
What is ultimately needed is some better real time detection of this kind of thing sufficiently deployed so that it is present on all routers where the exposure exists. You may not catch the perp, but you might reduce
these features, andand while personal the the
damage it causes.
How to encourage this to be done is left as an exercise for the reader.
-- Phil Howard +-------------------------------------------------------------+ KA9WGN | House committee changes freedom bill to privacy invasion !! | phil at | more info: http://www.news.com/News/Item/0,4,14180,00.html | milepost.com +-------------------------------------------------------------+
On Tue, Oct 07, 1997 at 01:03:14AM -0400, Charles Sprickman wrote:
I would not be surprised if the caller's phone number were logged, most modern modem banks talk ANIS and DNIS, which if I'm remembering correctly is basically caller ID. I'm thinking of putting this on our POP, as there doesn't seem to be an extra charge to get the data from the telco.
Unless you are using CallerID authentication, the Ascend MAXes do not log the caller's number. I assume that the TNT's have the same problem. --Eric -- Eric Wieling (eric@ccti.net), Corporate Communications Technology Sales: 504-585-7303 (sales@ccti.net), Support: 504-525-5449 (support@ccti.net)
On Tue 07 Oct, Eric Wieling wrote:
On Tue, Oct 07, 1997 at 01:03:14AM -0400, Charles Sprickman wrote:
I would not be surprised if the caller's phone number were logged, most modern modem banks talk ANIS and DNIS, which if I'm remembering correctly is basically caller ID. I'm thinking of putting this on our POP, as there doesn't seem to be an extra charge to get the data from the telco.
Unless you are using CallerID authentication, the Ascend MAXes do not log the caller's number. I assume that the TNT's have the same problem.
If they are handed the CLID by the Telco they do log the Called number to Radius Accounting even if you are just authenticating by PAP etc... aid -- Adrian J Bool | mailto:aid@u-net.net Network Operations | http://www.noc.u-net.net/ U-NET Ltd, UK | tel://44.1925.484461/
On the MAX's that I have set up, I log that info to syslog (Local 7), and can pull it up at will. If you need a hand, just let me know. By combining the syslog output, and the RADIUS accounting logs, we can definately prove at least the home address of the attacker. Alex P On Tue, 7 Oct 1997, Eric Wieling wrote:
On Tue, Oct 07, 1997 at 01:03:14AM -0400, Charles Sprickman wrote:
I would not be surprised if the caller's phone number were logged, most modern modem banks talk ANIS and DNIS, which if I'm remembering correctly is basically caller ID. I'm thinking of putting this on our POP, as there doesn't seem to be an extra charge to get the data from the telco.
Unless you are using CallerID authentication, the Ascend MAXes do not log the caller's number. I assume that the TNT's have the same problem.
--Eric
-- Eric Wieling (eric@ccti.net), Corporate Communications Technology Sales: 504-585-7303 (sales@ccti.net), Support: 504-525-5449 (support@ccti.net)
On Tue, 7 Oct 1997, Eric Wieling wrote:
On Tue, Oct 07, 1997 at 01:03:14AM -0400, Charles Sprickman wrote:
I would not be surprised if the caller's phone number were logged, most modern modem banks talk ANIS and DNIS, which if I'm remembering correctly is basically caller ID. I'm thinking of putting this on our POP, as there doesn't seem to be an extra charge to get the data from the telco.
Unless you are using CallerID authentication, the Ascend MAXes do not log the caller's number. I assume that the TNT's have the same problem.
This is incorrect -- all our dialin routers are MAX 4000s and TNTs. We do not authenticate based on calling number, but both the called and calling number are logged through the Radius accounting server. If you have ISDN PRI, at least with BellSouth, you get the ANI/DNIS information for free (they can't turn it off), but they will charge you for it if you specifically ask for it. John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801
On Tue, 7 Oct 1997, Eric Wieling wrote:
On Tue, Oct 07, 1997 at 01:03:14AM -0400, Charles Sprickman wrote:
I would not be surprised if the caller's phone number were logged, most modern modem banks talk ANIS and DNIS, which if I'm remembering correctly is basically caller ID. I'm thinking of putting this on our POP, as there doesn't seem to be an extra charge to get the data from the telco.
Unless you are using CallerID authentication, the Ascend MAXes do not log the caller's number. I assume that the TNT's have the same problem.
Hmmmm.... I have a few Ascend Max 400Xs using PRI T-1s for ISDN dialup and they log ANI, DNIS and a slew of other session specific info to LOCAL4. We don't use CallerID authentication. Here's an example of a single ISDN session, sanitized info is in braces. {Date Time FQDN} ASCEND: slot 0 port 0, line 1, channel 6, Incoming Call, {10-DIGIT-ANI} {Date Time FQDN} ASCEND: slot 9 port 4, Assigned to port, {10-DIGIT-ANI} {Date Time FQDN} ASCEND: call 50 AN slot 9 port 4 64K {7-DIGIT-DNIS} {Date Time FQDN} ASCEND: slot 9 port 4, LAN session up, {USERNAME} {Date Time FQDN} ASCEND: call 50 CL 0K u={USERNAME} c=2 p=65 {Date Time FQDN} ASCEND: slot 9 port 4, line 1, channel 6, Call Disconnected {Date Time FQDN} ASCEND: slot 9 port 4, Call Terminated {Date Time FQDN} ASCEND: slot 0 port 0, LAN session down, {USERNAME} {Date Time FQDN} ASCEND: call 50 CL 0K Now, I don't know if the analog modems in maxen will log this inf. or not, but it's worth knowing that a max can do it for some types of calls. - Mike Mike Diehn, ......................mdiehn@mindspring.net NOC Systems Engineer ................MindSpring Enterprises, Inc.
On Tue, 7 Oct 1997, Mike Diehn wrote:
On Tue, 7 Oct 1997, Eric Wieling wrote:
On Tue, Oct 07, 1997 at 01:03:14AM -0400, Charles Sprickman wrote:
I would not be surprised if the caller's phone number were logged, most modern modem banks talk ANIS and DNIS, which if I'm remembering correctly is basically caller ID. I'm thinking of putting this on our POP, as there doesn't seem to be an extra charge to get the data from the telco.
Unless you are using CallerID authentication, the Ascend MAXes do not log the caller's number. I assume that the TNT's have the same problem.
Hmmmm.... I have a few Ascend Max 400Xs using PRI T-1s for ISDN dialup and they log ANI, DNIS and a slew of other session specific info to LOCAL4. We don't use CallerID authentication.
Here's an example of a single ISDN session, sanitized info is in braces.
{Date Time FQDN} ASCEND: slot 0 port 0, line 1, channel 6, Incoming Call, {10-DIGIT-ANI} {Date Time FQDN} ASCEND: slot 9 port 4, Assigned to port, {10-DIGIT-ANI} {Date Time FQDN} ASCEND: call 50 AN slot 9 port 4 64K {7-DIGIT-DNIS} {Date Time FQDN} ASCEND: slot 9 port 4, LAN session up, {USERNAME} {Date Time FQDN} ASCEND: call 50 CL 0K u={USERNAME} c=2 p=65 {Date Time FQDN} ASCEND: slot 9 port 4, line 1, channel 6, Call Disconnected {Date Time FQDN} ASCEND: slot 9 port 4, Call Terminated {Date Time FQDN} ASCEND: slot 0 port 0, LAN session down, {USERNAME} {Date Time FQDN} ASCEND: call 50 CL 0K
Now, I don't know if the analog modems in maxen will log this inf. or not, but it's worth knowing that a max can do it for some types of calls.
One question, "can't the sender (aka the person initiating the call) forge the ANI information?" I know on a cisco (1003 series) it will croak if this is incorrect, but what about an Ascend or other ISDN device? Unless things have changed I don't think the TELCO's in the USA guarantee the ANI is correct. bye, ken emery
On Tue, Oct 07, 1997 at 11:43:24AM -0700, ken emery wrote:
One question, "can't the sender (aka the person initiating the call) forge the ANI information?" I know on a cisco (1003 series) it will croak if this is incorrect, but what about an Ascend or other ISDN device? Unless things have changed I don't think the TELCO's in the USA guarantee the ANI is correct.
In short: no. It's exceptionally difficult to forge ANI, with one small exception. _Some_ originating end-offices apparently don't validate ANI information handed to them by PBXs... otherwise, spoofing ANI requires intercepting the loop to the receiving sub, or subverting the switch. This was discussed at length in one of the telecom newsgroups, about 4 months ago, search for "ANI spoof" or "CNID spoof". Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
On Tue, Oct 07, 1997 at 12:47:33PM -0400, Mike Diehn wrote:
Hmmmm.... I have a few Ascend Max 400Xs using PRI T-1s for ISDN dialup and they log ANI, DNIS and a slew of other session specific info to LOCAL4. We don't use CallerID authentication.
Here's an example of a single ISDN session, sanitized info is in braces.
{Date Time FQDN} ASCEND: slot 0 port 0, line 1, channel 6, Incoming Call, {10-DIGIT-ANI} {Date Time FQDN} ASCEND: slot 9 port 4, Assigned to port, {10-DIGIT-ANI} {Date Time FQDN} ASCEND: call 50 AN slot 9 port 4 64K {7-DIGIT-DNIS} {Date Time FQDN} ASCEND: slot 9 port 4, LAN session up, {USERNAME} {Date Time FQDN} ASCEND: call 50 CL 0K u={USERNAME} c=2 p=65 {Date Time FQDN} ASCEND: slot 9 port 4, line 1, channel 6, Call Disconnected {Date Time FQDN} ASCEND: slot 9 port 4, Call Terminated {Date Time FQDN} ASCEND: slot 0 port 0, LAN session down, {USERNAME} {Date Time FQDN} ASCEND: call 50 CL 0K
Here is what I get in MY syslog: {Date Time host} ASCEND: slot 0 port 0, line 1, channel 2, Incoming Call, MBID 106 {Date Time host} ASCEND: slot 4 port 1, Assigned to port, MBID 106 {Date Time host} ASCEND: slot 4 port 1, line 1, channel 2, Call Connected, MBID 106 {Date Time host} ASCEND: call 106 AN slot 4 port 1 64K {7-DIGIT-DNIS} {Date Time host} ASCEND: slot 4 port 1, LAN session up, {USERNAME} I am in BellSouth territory. Another poster to this list reported that BellSouth cannot turn off ANI/CallerID. I'll open a ticket with Ascend and post my findings. --Eric -- Eric Wieling (eric@ccti.net), Corporate Communications Technology Sales: 504-585-7303 (sales@ccti.net), Support: 504-525-5449 (support@ccti.net)
At 03:49 PM 10/7/97 -0500, Eric Wieling wrote:
Here is what I get in MY syslog:
{Date Time host} ASCEND: slot 0 port 0, line 1, channel 2, Incoming Call,
MBID 106
{Date Time host} ASCEND: slot 4 port 1, Assigned to port, MBID 106 {Date Time host} ASCEND: slot 4 port 1, line 1, channel 2, Call Connected, MBID 106 {Date Time host} ASCEND: call 106 AN slot 4 port 1 64K {7-DIGIT-DNIS} {Date Time host} ASCEND: slot 4 port 1, LAN session up, {USERNAME}
I am in BellSouth territory. Another poster to this list reported that BellSouth cannot turn off ANI/CallerID. I'll open a ticket with Ascend and post my findings.
MBID is reported when the MAX/TNT does NOT receive the caller-number, so I would question if BellSouth can disable Caller-ID....also you could do a PRI D-channel trace on the MAX of the incoming call to verify the contents - i.e. see if the caller-ID info element is included. [debug - "pridisp 256" should do it, "pridisp off" to turn off tracing]. Kevin
On Tue, 7 Oct 1997, Kevin Smith wrote:
MBID is reported when the MAX/TNT does NOT receive the caller-number, so I would question if BellSouth can disable Caller-ID....also you could do a PRI D-channel trace on the MAX of the incoming call to verify the contents - i.e. see if the caller-ID info element is included.
We initially didn't specify anything about getting ANI/DNIS information, and we got it on our BellSouth PRIs. At some point later, we ordered more and they asked us if we wanted that information and we said yes. On the next bill, we were getting charged an outrageous amount for this service, and we called and asked why we weren't being billed for it on other lines, and they said that we didn't have that service on the other lines. So, we told them to turn off that service on the new lines. It was removed from our bill, but we still got the information in the call setup messages. Thus, I assumed from this that BellSouth did not have the ability to enable/disable that information on PRIs (I assume that the switches, which have been 5ESS or DMS, have that ability but BellSouth either chooses not to or does not know how to disable it). The similar situation is present on ISDN BRIs -- they will happily charge you extra for CallerID, but if you tell them you don't want it you still get it. John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801
At 09:55 AM 10/7/97 -0500, Eric Wieling wrote:
On Tue, Oct 07, 1997 at 01:03:14AM -0400, Charles Sprickman wrote:
I would not be surprised if the caller's phone number were logged, most modern modem banks talk ANIS and DNIS, which if I'm remembering correctly is basically caller ID. I'm thinking of putting this on our POP, as there doesn't seem to be an extra charge to get the data from the telco.
Unless you are using CallerID authentication, the Ascend MAXes do not log the caller's number. I assume that the TNT's have the same problem.
Both MAX and TNT log called and calling number to syslog/Radius when they are presented by Telco. Kevin
On Tue, Oct 07, 1997 at 09:55:56AM -0500, Eric Wieling wrote:
Unless you are using CallerID authentication, the Ascend MAXes do not log the caller's number. I assume that the TNT's have the same problem.
Then I'd suggest that Ascend customers strongly recommend an appropriate firmware feature upgrade to the manufacturer. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
At 02:56 PM 10/7/97 -0400, Jay R. Ashworth wrote:
On Tue, Oct 07, 1997 at 09:55:56AM -0500, Eric Wieling wrote:
Unless you are using CallerID authentication, the Ascend MAXes do not log the caller's number. I assume that the TNT's have the same problem.
Then I'd suggest that Ascend customers strongly recommend an appropriate firmware feature upgrade to the manufacturer.
I'd suggest they take a look at the features they *ALREADY* have ;) [Both MAX4000 and TNT *do* log the caller and called number]. Kevin
Just to clear things up a bit, if you look in your radius accounting logs, you will see the "Caller-ID=xxxxxxxxxxx" on any start records that receive the info from the telco. Alex P On Tue, 7 Oct 1997, Kevin Smith wrote:
At 02:56 PM 10/7/97 -0400, Jay R. Ashworth wrote:
On Tue, Oct 07, 1997 at 09:55:56AM -0500, Eric Wieling wrote:
Unless you are using CallerID authentication, the Ascend MAXes do not log the caller's number. I assume that the TNT's have the same problem.
Then I'd suggest that Ascend customers strongly recommend an appropriate firmware feature upgrade to the manufacturer.
I'd suggest they take a look at the features they *ALREADY* have ;)
[Both MAX4000 and TNT *do* log the caller and called number].
Kevin
I called Ascend Tech support today. The tech telnetted into my Max, poked around, looked at the PRI D Channel info, and saw that BellSouth was passing the CallerID info to the Max. We are running 4.5Ci23 on the Max. The tech claimed that this version of the software (for the Max 1600 -- Yeah, I know it's an old box) did not support reporting of the CallerID info. We will be upgrading to 4.6Dp4 sometime later this week and will see what happens. On Tue, Oct 07, 1997 at 06:09:56PM -0400, Alex Przekupowski wrote:
Just to clear things up a bit, if you look in your radius accounting logs, you will see the "Caller-ID=xxxxxxxxxxx" on any start records that receive the info from the telco.
Alex P
On Tue, 7 Oct 1997, Kevin Smith wrote:
At 02:56 PM 10/7/97 -0400, Jay R. Ashworth wrote:
On Tue, Oct 07, 1997 at 09:55:56AM -0500, Eric Wieling wrote:
Unless you are using CallerID authentication, the Ascend MAXes do not log the caller's number. I assume that the TNT's have the same problem.
Then I'd suggest that Ascend customers strongly recommend an appropriate firmware feature upgrade to the manufacturer.
I'd suggest they take a look at the features they *ALREADY* have ;)
[Both MAX4000 and TNT *do* log the caller and called number].
Kevin
-- Eric Wieling (eric@ccti.net), Corporate Communications Technology Sales: 504-585-7303 (sales@ccti.net), Support: 504-525-5449 (support@ccti.net)
On Tue, 7 Oct 1997, Jay R. Ashworth wrote:
On Tue, Oct 07, 1997 at 09:55:56AM -0500, Eric Wieling wrote:
Unless you are using CallerID authentication, the Ascend MAXes do not log the caller's number. I assume that the TNT's have the same problem.
Then I'd suggest that Ascend customers strongly recommend an appropriate firmware feature upgrade to the manufacturer.
Cheers, -- jra
The Ascend MAX equipment does log it if the information is provided by the telco. It doesn't matter if your doing authentication based on it or not, it will still be logged to radius accounting and/or syslog. Joe Shaw - jshaw@insync.net NetAdmin - Insync Internet Services
On Tue, Oct 07, 1997 at 01:03:14AM -0400, Charles Sprickman wrote:
I would not be surprised if the caller's phone number were logged, most modern modem banks talk ANIS and DNIS, which if I'm remembering correctly is basically caller ID. I'm thinking of putting this on our POP, as there doesn't seem to be an extra charge to get the data from the telco.
ANI. Actually, it's commonly CNID, which is slightly more useful. If your calls are delivered over ISDN PRI, it's usually free. I think they actually do charge for delivery over normal T-spans, as it takes extra equipment. The gear has to log it, though. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
I would not be surprised if the caller's phone number were logged, most modern modem banks talk ANIS and DNIS, which if I'm remembering correctly is basically caller ID. doesn't seem to be an extra charge to get the data from the telco.
ANI. Actually, it's commonly CNID, which is slightly more useful.
Just want to make sure all parties here do not think ANI == CNID. They are different critters. You get CNID usually. Real time ANI is available on 800 trunks, but at a cost. -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
David Lesher put this into my mailbox:
I would not be surprised if the caller's phone number were logged, most modern modem banks talk ANIS and DNIS, which if I'm remembering correctly is basically caller ID. doesn't seem to be an extra charge to get the data from the telco.
ANI. Actually, it's commonly CNID, which is slightly more useful.
Just want to make sure all parties here do not think ANI == CNID. They are different critters. You get CNID usually. Real time ANI is available on 800 trunks, but at a cost.
I realize this is probably something one learns in Telco 101, which I haven't taken, but if CNID == Caller ID, wouldn't ANI be *more* useful? Or does CNID report the number regardless of Caller-ID blocking on PRI lines/etc? (I'm assuming that CNID == standard Caller-ID as it appears on POTS, and that ANI == the special service that 800-lines get that *always* reports the number, regardless of blocking..if I'm wrong, I'll accept the LART.) -dalvenjah -- Dalvenjah FoxFire (aka Sven Nielsen) College is a fountain of knowledge... Founder, the DALnet IRC Network and the students are there to drink. e-mail: dalvenjah@dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/
Dalvenjah FoxFire sez:
Just want to make sure all parties here do not think ANI == CNID.
I realize this is probably something one learns in Telco 101, which I haven't taken, but if CNID == Caller ID, wouldn't ANI be *more* useful?
They came up from different requirements; using different approaches.
Or does CNID report the number regardless of Caller-ID blocking on PRI lines/etc?
(I'm assuming that CNID == standard Caller-ID as it appears on POTS, and that ANI == the special service that 800-lines get that *always* reports the number, regardless of blocking..if I'm wrong, I'll accept the LART.)
ANI is a BILLING number. Call an 500/800/900# line & that is what they see. Ex: All 5280 lines at Engulf and Devour will report the main billing number of 666-7836. CNID is the calling number. {IN THEORY} even in a large system [university] the calling number /"extension" appears. But... often times there are PBX's with outgoing-only trunks {Why? a history of crude signaling schemes, mostly...} that even if they do ring in; they end up somewhere else than you intended... ANI is not blockable. CNID is. The block can be ignored by the final switch, however, if you are "privileged" enough. And if you want to spend the $$ [i.e. Fort Meade..] you get dedicated outgoing trunks that don't pass SS7 at all. -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
On Tue, Oct 07, 1997 at 06:20:01PM -0700, Dalvenjah FoxFire wrote: [ David Lesher:]
Just want to make sure all parties here do not think ANI == CNID. They are different critters. You get CNID usually. Real time ANI is available on 800 trunks, but at a cost.
I realize this is probably something one learns in Telco 101, which I haven't taken, but if CNID == Caller ID, wouldn't ANI be *more* useful?
Sometimes. CNID bounces around with forwarded calls, as was pointed out to me in private mail earlier today, whilst ANI will be from the _last_ site in a forwarding chain -- since that's the only place an INWATS subscriber is paying for a call from.
Or does CNID report the number regardless of Caller-ID blocking on PRI lines/etc?
No, CNID is Caller-ID. Blocking is _supposed_ to be implemented by the _terminating_ end office. If you receive your traffic over dedicated trunks from an IXC, rather than a LEC, you're not _supposed_ to get it... but I'd be unsurprised if some IXC's get this wrong. I _would_ be surprised if many LEC's were blowing this.
(I'm assuming that CNID == standard Caller-ID as it appears on POTS, and that ANI == the special service that 800-lines get that *always* reports the number, regardless of blocking..if I'm wrong, I'll accept the LART.)
You assume correctly. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
On Tue, 7 Oct 1997, Jay R. Ashworth wrote:
Sometimes. CNID bounces around with forwarded calls, as was pointed out to me in private mail earlier today, whilst ANI will be from the _last_ site in a forwarding chain -- since that's the only place an INWATS subscriber is paying for a call from.
As has been pointed out, it is dangerous to generalize from a singular experience, but what we get from BellSouth over PRIs is the last number that the call originated from. For a couple of our cities, we have a call forwarding service that will carry blocks of 10 simultaneous calls using remote call forwarding. They are in an area-calling band, which has a capped rate, so we can offer local numbers to customers that don't have area calling. The limitations are that BellSouth's reporting is utterly useless (so we have to use our logs to try and figure out the utilization of those trunks), ISDN calls aren't forwarded, and the calling number the Ascend gets is that of our number that is fowarded to here. Thus, we have no usefull caller identification for those lines. Our BellSouth rep has always used the terms ANI and CNID interchangeably. John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801
[ On Tue, October 7, 1997 at 23:38:37 (-0500), John A. Tamplin wrote: ]
Subject: Re: Denial of service attacks apparently from UUNET Netblocks
have area calling. The limitations are that BellSouth's reporting is utterly useless (so we have to use our logs to try and figure out the utilization of those trunks), ISDN calls aren't forwarded, and the calling number the Ascend gets is that of our number that is fowarded to here. Thus, we have no usefull caller identification for those lines.
OUCH! I guess that would mean you'd have to subpoena call detail records for those lines from BellSouth if you ever wanted to find out who really called them. Those lines could be oh-so-useful to a cracker with access to somone else's dial-out modems.... I know these schemes are all to common in lots of places, and obviously they're cheaper to set up and run than a remote POP, but do you really need all the added risks? -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
Greg A. Woods sez:
Thus, we have no usefull caller identification for those lines.
OUCH!
I guess that would mean you'd have to subpoena call detail records for those lines from BellSouth if you ever wanted to find out who really called them. Those lines could be oh-so-useful to a cracker with access to somone else's dial-out modems....
Difficult. MUDS are really tough [or were.... my knowledge may be out of date] to pry out of RBOC's. Word to the wise, folks.. If you EVER have cause to seek same, move IMMEDIATELY. They are the equivalent of /tmp and flushed in a day or so. You'll likely need the Feebs or such to get anywhere. -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
On Mon, Oct 06, 1997 at 09:30:11PM -0500, Phil Howard wrote:
Steve Mansfield writes...
[snip snip snip]
S'okay. Have the feds subpoena UUNET for the connect logs for these max'es. UUNET keeps the logs and is capable, given the exact time of the attack(s), of going through the logs, identifying exactly who it was, and if it's one of their customers, giving the personal info to the feds. If it's a reseller's customer, they can get the user info and forward it to the reseller and inform the feds who they need to talk to for the personal info. Whoever it was is as good as nailed.
Unless it was a stolen account. With more and more "naive" users coming online, the chance of this kind of thing happening is greater and greater. You can shut off the account. Feds can visit the home of whoever owns the account. They can even be blocked from ever getting any account at any ISP for life. But if this possibility is fact, you won't have the perp and they can attack again.
Now if the telco has records of all the phone calls you can find out where the calls actually came from. Maybe that's the perp. Maybe not.
What is ultimately needed is some better real time detection of this kind of thing sufficiently deployed so that it is present on all routers where the exposure exists. You may not catch the perp, but you might reduce the damage it causes.
How to encourage this to be done is left as an exercise for the reader.
Uh, the other side of this is that if it was done over ISDN, then the ANI of the caller *IS* in the logs on the ISP side. Even if the account is stolen, the access point is known. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
On Mon, 6 Oct 1997, Phil Howard wrote:
Steve Mansfield writes...
S'okay. Have the feds subpoena UUNET for the connect logs for these max'es. UUNET keeps the logs and is capable, given the exact time of the attack(s), of going through the logs, identifying exactly who it was, and if it's one of their customers, giving the personal info to the feds. If it's a reseller's customer, they can get the user info and forward it to the reseller and inform the feds who they need to talk to for the personal info. Whoever it was is as good as nailed.
Unless it was a stolen account. With more and more "naive" users coming online, the chance of this kind of thing happening is greater and greater. You can shut off the account. Feds can visit the home of whoever owns the account. They can even be blocked from ever getting any account at any ISP for life. But if this possibility is fact, you won't have the perp and they can attack again.
[SNIP]
Phil Howard +-------------------------------------------------------------+
Although this is all true, it still doesn't explain the fact that UUNet is allowing broadcast packets through their network. One would think that with the recent increase in broadcast DoS attacks, that UUNet would have taken a much more proactive stance. But, being an outspoken UUNet customer, and having experienced a DoS attack (by proxy, as they were attacking one of our customers) a little over a week ago (all day Sunday, Sept. 28th), I can say they definitely have done nothing but drag their heels. When we called, we were told we'd get to speak to a UUNet security team member, and we did speak to them. Then, a few hours later after our 10Minus connection went down several times and BGP reset countless times, we finally got tired, and took the link to our customer down, reset BGP, and the flooding stopped. Unfortunately, UUNet hadn't taken the time to do any packet captures while we were under attack, so they couldn't do anything. Finally at 12:00am Monday morning, we called in again, and brought the link up. We were told that there would be a member of the security team paged and we would hear from him/her within the hour. 3 hours later after getting no response we shut the link down and went home. Later that day, at aprox. 12pm, I called UUNet security team, and have heard nothing about the incident since I sent them what I captured with the sniffer. Unfortunately, the offending addresses were probably forged, so without anyone to capture those packets and trace them back, the person who took down our 10Mbps Ethernet connection to UUNet gets away scott free. I don't like that, and I find the level of service I received again to be unsatisfactory. If one of my customers was under attack, and I acted with the same behaviour as UUNet, I would be searching for another job right now. With that aside, I'm glad my DS3 circuit stayed up. Without it, we would have been completely screwed. Joe Shaw - jshaw@insync.net NetAdmin - Insync Internet Services
:: Joe Shaw writes ::
Although this is all true, it still doesn't explain the fact that UUNet is allowing broadcast packets through their network. One would think that with the recent increase in broadcast DoS attacks, that UUNet would have taken a much more proactive stance.
167.132.194.255 is not a broadcast address. 167.132.2.15 is a broadcast address. How would you expect UUNet to know that? - Brett (brettf@netcom.com) ------------------------------------------------------------------------------ ... Coming soon to a | Brett Frankenberger .sig near you ... a Humorous Quote ... | brettf@netcom.com
On Tue, Oct 07, 1997 at 09:03:15PM -0500, Brett Frankenberger wrote:
:: Joe Shaw writes ::
Although this is all true, it still doesn't explain the fact that UUNet is allowing broadcast packets through their network. One would think that with the recent increase in broadcast DoS attacks, that UUNet would have taken a much more proactive stance.
167.132.194.255 is not a broadcast address.
167.132.2.15 is a broadcast address.
How would you expect UUNet to know that?
- Brett (brettf@netcom.com)
On the device which forwarded the packet(s) to the device which echoes them, it *does* know. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Karl, we just went thru basically the same thing with UUNET. I have >500MB of log files to show for it too :-(. The attack started around 7pm CDT, Sep 24th. Good thing we are not totally dependent on uunet. With the help of a kid in their NOC whom I badgered into working with me, I believe we had located a router which would accept source routed packets. I say believe, because when we found something "not right" he had to hang up on me and call someone else. A few minutes later the attack stopped. When I called back an hour or so later there was no mention of whom I had talked to in their "call log" and I didn't get the name as it was about the 5th person I was transfered to. When the uunet security people returned my call (I left voice mail, "Our office ours are from 8am to 5pm eastern time") fully 3 days later. they did mention that they would be 24x7 "real soon now." But otherwise couldn't be of much help since the attack was no longer in progress. I guess we just go out of business while waiting. Anyway, I made them the offer to email them a few hundred megs of logs which they declined. Oddly enough, the FBI called back within a few minutes and did want the logs (we burned 'em a cd) I've attached a small snippet of a tcpdump of the attack. It appears to differ from yours as the source address changes. It was directed at one of our 28.8 dialup ports. The incoming packet rate averaged about 2mb. 19:56:56.851502 snap 0:0:0:8:0 19.191.138.170.1900 > 206.66.14.112.57030: S 674719801:674719801(0) win 65535 (ttl 21, id 13324) 19:56:56.851502 snap 0:0:0:8:0 3.167.56.59.1900 > 206.66.14.112.57031: S 674719801:674719801(0) win 65535 (ttl 21, id 13325) 19:56:56.851502 snap 0:0:0:8:0 14.252.139.99.1900 > 206.66.14.112.57032: S 674719801:674719801(0) win 65535 (ttl 21, id 13326) 19:56:56.853455 snap 0:0:0:8:0 249.101.146.59.1900 > 206.66.14.112.57033: S 674719801:674719801(0) win 65535 (ttl 21, id 13327) 19:56:56.853455 snap 0:0:0:8:0 240.101.24.102.1900 > 206.66.14.112.57034: S 674719801:674719801(0) win 65535 (ttl 21, id 13328) 19:56:56.853455 snap 0:0:0:8:0 154.252.81.12.1900 > 206.66.14.112.57035: S 674719801:674719801(0) win 65535 (ttl 21, id 13329) 19:56:56.854432 snap 0:0:0:8:0 103.31.255.241.1900 > 206.66.14.112.57036: S 674719801:674719801(0) win 65535 (ttl 21, id 13330) 19:56:56.854432 snap 0:0:0:8:0 222.245.112.22.1900 > 206.66.14.112.57037: S 674719801:674719801(0) win 65535 (ttl 21, id 13331) 19:56:56.854432 snap 0:0:0:8:0 154.36.44.37.1900 > 206.66.14.112.57038: S 674719801:674719801(0) win 65535 (ttl 21, id 13332) 19:56:56.854432 snap 0:0:0:8:0 37.31.237.183.1900 > 206.66.14.112.57039: S 674719801:674719801(0) win 65535 (ttl 21, id 13333) 19:56:56.854432 snap 0:0:0:8:0 76.167.191.100.1900 > 206.66.14.112.57040: S 674719801:674719801(0) win 65535 (ttl 21, id 13334) 19:56:56.854432 snap 0:0:0:8:0 131.254.10.213.1900 > 206.66.14.112.57041: S 674719801:674719801(0) win 65535 (ttl 21, id 13335) 19:56:56.855409 snap 0:0:0:8:0 74.60.41.73.1900 > 206.66.14.112.57042: S 674719801:674719801(0) win 65535 (ttl 21, id 13336) 19:56:56.855409 snap 0:0:0:8:0 243.40.34.99.1900 > 206.66.14.112.57043: S 674719801:674719801(0) win 65535 (ttl 21, id 13337) 19:56:56.855409 snap 0:0:0:8:0 82.253.99.126.1900 > 206.66.14.112.57044: S 674719801:674719801(0) win 65535 (ttl 21, id 13338) 19:56:56.855409 snap 0:0:0:8:0 234.163.66.215.1900 > 206.66.14.112.57045: S 674719801:674719801(0) win 65535 (ttl 21, id 13339) 19:56:56.855409 snap 0:0:0:8:0 156.36.2.91.1900 > 206.66.14.112.57046: S 674719801:674719801(0) win 65535 (ttl 21, id 13340) 19:56:56.857362 snap 0:0:0:8:0 15.222.135.25.1900 > 206.66.14.112.57047: S 674719801:674719801(0) win 65535 (ttl 21, id 13341) 19:56:56.857362 snap 0:0:0:8:0 145.99.239.187.1900 > 206.66.14.112.57048: S 674719801:674719801(0) win 65535 (ttl 21, id 13342) 19:56:56.857362 snap 0:0:0:8:0 29.174.213.63.1900 > 206.66.14.112.57049: S 674719801:674719801(0) win 65535 (ttl 21, id 13343) 19:56:56.857362 snap 0:0:0:8:0 19.146.15.118.1900 > 206.66.14.112.57050: S 674719801:674719801(0) win 65535 (ttl 21, id 13344)
Hot Diggety! Doug Davis was rumored to have said...
19:56:56.854432 snap 0:0:0:8:0 37.31.237.183.1900 > 206.66.14.112.57039: S 674719801:674719801(0) win 65535 (ttl 21, id 13333) 19:56:56.854432 snap 0:0:0:8:0 76.167.191.100.1900 > 206.66.14.112.57040: S 674719801:674719801(0) win 65535 (ttl 21, id 13334) 19:56:56.854432 snap 0:0:0:8:0 131.254.10.213.1900 > 206.66.14.112.57041: S 674719801:674719801(0) win 65535 (ttl 21, id 13335) 19:56:56.855409 snap 0:0:0:8:0 74.60.41.73.1900 > 206.66.14.112.57042: S 674719801:674719801(0) win 65535 (ttl 21, id 13336)
Ouch...painful. A whole lot of SYNs with forged source address, eh? Hmm... interesting. Karl, if I might ask - did your attack originate from any specific port, like 1900 as is listed here? I'm just curious since I'd like to get a rough idea if there's some program other than smurf.c out there that makes use of a specific port by default, or if this is just a one time occurence by a few separate idiots. And as usual, thanks for the heads up from folks on NANOG. -Dan Foster Frontier Internet Internet: dsf@frontiernet.net
No. This was a transmission of 1K packets and was not in the style of any previously-seen attack that I'm aware of. Its a new thing. There was no attempt to SYN flood, or hit broadcast addresses, or use source-routing. All of that is protected against fairly well here. This was a simple "the machines are on a 10Mbps pipe, so hit them with 30Mbps of traffic and flood their NIC ports to the point that they're useless". -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal On Tue, Oct 07, 1997 at 07:01:34AM -0400, Dan Foster wrote:
Hot Diggety! Doug Davis was rumored to have said...
19:56:56.854432 snap 0:0:0:8:0 37.31.237.183.1900 > 206.66.14.112.57039: S 674719801:674719801(0) win 65535 (ttl 21, id 13333) 19:56:56.854432 snap 0:0:0:8:0 76.167.191.100.1900 > 206.66.14.112.57040: S 674719801:674719801(0) win 65535 (ttl 21, id 13334) 19:56:56.854432 snap 0:0:0:8:0 131.254.10.213.1900 > 206.66.14.112.57041: S 674719801:674719801(0) win 65535 (ttl 21, id 13335) 19:56:56.855409 snap 0:0:0:8:0 74.60.41.73.1900 > 206.66.14.112.57042: S 674719801:674719801(0) win 65535 (ttl 21, id 13336)
Ouch...painful. A whole lot of SYNs with forged source address, eh? Hmm... interesting. Karl, if I might ask - did your attack originate from any specific port, like 1900 as is listed here?
I'm just curious since I'd like to get a rough idea if there's some program other than smurf.c out there that makes use of a specific port by default, or if this is just a one time occurence by a few separate idiots.
And as usual, thanks for the heads up from folks on NANOG.
-Dan Foster Frontier Internet Internet: dsf@frontiernet.net
On Tue, 7 Oct 1997, Karl Denninger wrote:
No. This was a transmission of 1K packets and was not in the style of any previously-seen attack that I'm aware of. Its a new thing.
There was no attempt to SYN flood, or hit broadcast addresses, or use source-routing. All of that is protected against fairly well here. This was a simple "the machines are on a 10Mbps pipe, so hit them with 30Mbps of traffic and flood their NIC ports to the point that they're useless".
That's exactly what we saw here as well, except we did see some broadcast traffic. They hit us with so much traffic that our 10Mbps link was useless. The offending sites I got were 192.195.100.1, 128.132.45.105, 167.152.96.78, but according to the customer they believe those to be forged. I'm almost certain that at least some of these sites had to be used, as the source routed traffic should have been stopped at the router. This did stop the traffic from coming through, but it didn't stop it from killing the link once it got here. Joe Shaw - jshaw@insync.net NetAdmin - Insync Internet Services
On Tue, Oct 07, 1997 at 09:30:01AM -0500, Joe Shaw wrote:
On Tue, 7 Oct 1997, Karl Denninger wrote:
No. This was a transmission of 1K packets and was not in the style of any previously-seen attack that I'm aware of. Its a new thing.
There was no attempt to SYN flood, or hit broadcast addresses, or use source-routing. All of that is protected against fairly well here. This was a simple "the machines are on a 10Mbps pipe, so hit them with 30Mbps of traffic and flood their NIC ports to the point that they're useless".
That's exactly what we saw here as well, except we did see some broadcast traffic. They hit us with so much traffic that our 10Mbps link was useless. The offending sites I got were 192.195.100.1, 128.132.45.105, 167.152.96.78, but according to the customer they believe those to be forged. I'm almost certain that at least some of these sites had to be used, as the source routed traffic should have been stopped at the router. This did stop the traffic from coming through, but it didn't stop it from killing the link once it got here.
Joe Shaw - jshaw@insync.net NetAdmin - Insync Internet Services
Our core doesn't pass source-routed traffic at all, nor will it forward traffic destined for a MAC-layer broadcast address anywhere on our core. This doesn't make it impossible to forge packets and play games, but it sure makes it more difficult. If you have the cooperation of those you interconnect with during an attack with this configuration, it makes it rather easy to find the source of the packets, assuming that they continue for some period of time. I can think of only one way to do this which wouldn't involve sourcing the streams from the indicated machines *and* generate the kind of volume we saw. I won't go into it here, because it would be trivial to do, and it might be what actually happened. But if it *IS* then I'm even more pissed off, because that points to severe and unconscionable misconfiguration of hardware within UUNET's core. If *that* is the case then we're going to block all packets eminating from address range(s) implicated in this kind of attack, now or in the future, until the guilty parties fix their configurations. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
participants (22)
-
Adrian Bool -
Alex Przekupowski -
Brett Frankenberger -
Charles Sprickman -
Dale Drew -
Dalvenjah FoxFire -
Dan Foster -
David Lesher -
dougd＠airmail.net -
Eric Wieling -
James_deleskie -
Jay R. Ashworth -
Joe Shaw -
John A. Tamplin -
Karl Denninger -
Karl Denninger
-
ken emery -
Kevin Smith -
Mike Diehn -
Phil Howard -
Steve Mansfield -
woods＠most.weird.com