Network Operators and smurf

Mailman List Mirror (Read Only)
1

I block *ALL* packets from any netblock which is implicated as a smurf
amplifier, on the first offense.

I will remove those blocks when I can PROVE that they can no longer be used
as a smurf amplifier. To date, NOBODY on the list has come forward and said
"we've audited and fixed, please remove the block".

PSU (which is on the list) said "we're looking into it" but that was more
than two weeks ago! How long does it take to telnet into your routers and
check the ethernet interfaces for the correct configuration? A day or so?
Perhaps, even if you have a HUGE netwokr.

It does not require two weeks.

First, I am not speaking for Penn State, although I am a member of the
University's CERT team. Second, I am not asking that any block be removed.
Such a request would have to come from others at PSU.

It may require two weeks when you have to deal with the multiple domains of
control one finds at this University. This means that you can not just walk up
to some machines and pull the plug without have large quantities of excrement
start flowing rapidly down hill from on high and sweeping everything in it's
path away.

The security office been very active in checking out which routers are still
vulnerable. Unfortunately there are a number of `routers' (read multi-homed
UNIX systems) that are not directly connected to the university's backbone that
have not been secured. These machines usually are being administered by a grad
student who is more interested in study for comprehensive exams than in
installing the necessary patches to fix the problem. In that case the security
office will usually offer to assist in securing these systems. Sometimes that
offer will not be accepted, or it may take a week for everyone to come to an
agreement as to what needs to be done.

So, yes, it may very well take more that two weeks to complete. But, I believe
that all routers that make up the University backbone and are maintained by the
Office of Telecommunication have been secured.

-- Dan Ehrlich

Blocking just ICMP is pointless - block EVERYTHING. The only way we ever
get this fixed is to make it HURT to be on the blacklist.

--
--
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV
         > NEW! Corporate ISDN Prices dropped by up to 50%!
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost

What config options/access-lists are you using. If Martin says his
routers choked, and you say yours don't, I'd like to know (as would
anyone, I think) what you are running and how you are running it. I
assume you are using access-lists. Are you using NetFlow? On which
interfaces? Are you blocking inbound echo-reply? To where? Everywhere
or just your core network? The problem I'm faced with, is I'm currently
blocking ICMP to my core networks, NOT to customers or dialup ports. They
will REALLY bitch if I start doing that. I'm going to change it to block
echo-reply to those networks only.

Currently, the measures "I" am taking is:

o outbound access-list permitting ONLY networks which source on our
router.

o inbound access-list denying ICMP (which will be modifiec to block ICMP
echo-reply only) to core networks along with .0 and .255 address blocks.

o no ip directed-broadcast on ALL interfaces

o ip route-cache flow (so I can get some information on these *ssholes)

What else do I need?! What am I doing wrong with the above (if anything)

TiA...

:Since I have started blacklisting people, the list has grown to more than 4

0

:netwroks.
:
:However, only ONE, and that one was very short (< 5 minutes) smurf has take

n

:down a customer circuit or our IRC server since the last edits were made to
:the amplifier list over a week ago.
:
:I'm going to try to post a web page on this tonight. What we're doing here
:WORKS. It inconveniences a few people (those who amplify smurfs), but it
:WORKS and it STOPS the smurf attacks from burying your connections.
:
:Our core routers don't even get mildly bothered doing the discards.
:
:--
:--
:Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
:http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/D

OV

: | NEW! Corporate ISDN Prices dropped by up to 50%!
:Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUN

TS

:fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no co

st

2

On Sun, Apr 26, 1998 at 04:50:11PM -0400, Daniel R Ehrlich put this into my mailbox:

First, I am not speaking for Penn State, although I am a member of the
University's CERT team. Second, I am not asking that any block be removed.
Such a request would have to come from others at PSU.

It may require two weeks when you have to deal with the multiple domains of
control one finds at this University. This means that you can not just walk
up to some machines and pull the plug without have large quantities of
excrement start flowing rapidly down hill from on high and sweeping
everything in it's path away.

You may already know this, but it doesn't hurt to reiterate.

I've had to deal with this to a certain extent at a local university. What
you need to do is to draft a security policy that explains what action you
can take when a machine connected to the campus network is used in some sort
of hack/DoS attempt. The policy should say something like, "We will attempt
to contact the maintainer of the box. If we cannot contact the maintainer
or the maintainer cannot repair the box within 6 hours, we will disconnect
the box from the network." Modify as required for your site.

Then, go to the highest level of management you can, without pissing
too many folks off (yes, university politics suck). Get them to sign off on
it, and keep going all the way up to the chancellor, or whoever the Big Guy
is. Make sure that you explain that every time someone uses a University box
to hack or DoS, the university is wide-open for lawsuits and such - especially
if folks knew about the problem and didn't take action.

Then, you have the ammunition you need to disconnect problem boxes when they
crop up. If the Whiny Researcher In Question throws a fit, wave the policy
in their face and explain that they should have thought of that before putting
an insecure box on the net.

(You might also discuss with the researcher the fact that anyone hacking
into their box can steal their data; I understand research types are very
protective of their data, and paranoid that someone else might get ahold
of it. This might at least encourage them to secure their boxes better.)

-dalvenjah