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.

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

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.

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

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

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

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

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

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.

Both MAX and TNT log called and calling number to syslog/Radius when they are
presented by Telco.

Kevin

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

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

Then I'd suggest that Ascend customers strongly recommend an
appropriate firmware feature upgrade to the manufacturer.

Cheers,
-- jra

I'd suggest they take a look at the features they *ALREADY* have :wink:

[Both MAX4000 and TNT *do* log the caller and called number].

Kevin

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

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

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

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

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

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.