Uhmm, would the 255.255.255.255 wildcard not be 255.255.255.0?
Cisco has a method of tracing SMuRF, do they not? Anyone know how they do
it?! Is it some imbedded thing, or do they call the owners of each
network and pray that they have Ciscos?
You could always "deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm log" on
your cores. Deny ICMP from critical portions of your network. Create a
little script which tail -fs the log, parses it, sorts it and counts it.
If the script counts more then xxx hits on a certain IP or a certain
number of IPs on your network from the same source or a multiple sources
on the same network, you have your upstream. Once you have them, you can
call them and ask them to do the same until you find the real source.
This will not protect against someone smurfing your dialup users and they
can do just as much damamge as the former, but they are more likely to
bitch if they can't ping so it's a toss up.
No, because you only want to stop the packets coming into the broadcast
address, not the entire network. (You may want to block the entire network,
say for security reasons, but that's a slightly different issue).
I suspect that you are confused with the wildcarding. The second parameter
is a mask for the first. All ones on the mask mean it matches exactly the
first address. Leaving the last octet of the mask 0 means it matches all ip
addresses that begin with x.y.z, including the broadcast address.
--Dean
Yes, Dan, but any potential smurf-_amplifier_ who might need to do this
_knows_ this about _their own network_, and can adjust accordingly.
Cheers,
-- jra
but it doesn't matter:
Again folks:
Two things will cut 99.44% of the smurf:
Get as many net-ops as you can to 1) turn no ip-directed broadcast (if
they have a knob (or bitch long and loud)) and 2) filter outbound
packets with forged source addresses (or bitch long and loud if you
don't have a knob).
It's said that a problem changes in type when it chanegs _enough_ in
magnitude. I suspect that it won't be another 12 months before a
router with both those knobs is _required_ to meet the (new version of
the) Router Requirements RFC, much less to actually _get_ a
connection. If you can't filter the appropriate stuff, get the hell
off _my_ Internet. 
Cheers,
-- jr 'wanna see the Bill of Sale? ;-)' a
I do not know. I think it's urgent nessecaty to create some method to
back-trace any SRC address, realised (at least) by CISCO, because it's
clean we are not ready (we - hw. vendors, CEF is too new and unchecked
futore and do not work at middle-class routers and access-servers where
it's place for the SRC filtering) to make strict src-filtering at the
customer-links level.
>measurement.
Oops. I misunderstood this first time round. I don't think you can easily
detect smurf initiations, because you have to guess at the broadcast
address.
It's not difficult to detect SMURF initiators belongs to your own
customers. For us, it's easy because we have IP accounting at the core
routers and have some anti-smurf monitoring;
If you saw ICMP-request packets with the DST address looks as broadcast,
it's the bell for your noc _let's check where are this packets
originated_ - and this trace you to the SMURFer at 90% of the cases.
And this 0.0.0.255 255.255.255.0 address/wildcard_bits assumption makes a
great approximation for the broadcast addresses.
I think it is much easier to detect and block forged source addresses,
which are also necessary for the hacker who is operating out of your
network.--Dean
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Plain Aviation, Inc dean@av8.com
LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com
We Make IT Fly! (617)242-3091 x246
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
That was us, and we do plan on prosecuting. We're in the process of
collecting information now.
Something that happened during this attack should be a great concern to
all of us. In addition to the usual broadcast addresses being used as
amplifiers for this smurf attack, the attacker also used network
addresses. It seems that many stacks and routers will respond to a
packet with a network address in the same way as a broadcast address.
Luckily Cisco's "no ip directed-broadcast" already took that into account
and blocks those packets, however, if you don't have a Cisco and are
having to configure manual filters to avoid being an amplifier site, you
_must_ filter out network addresses as well as broadcast addresses.
Please, spread the word.
P.S. I'd like to publicly thank Icon, Digex, and BBN as well as the EPA
(yes folks, the Environmental Protection Agency, they were being used as
an amplifier in this attack) for their help in tracing this attack to the
source.
Brandon Ross Network Engineering 404-815-0770 800-719-4664
Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com
Mosher's Law of Software Engineering: Don't worry if it doesn't work
right. If everything did, you'd be out of a job.
Using "deny icmp" as anything other than an extremely temporary measure
while you (or your customers) are actively under DoS attack and focused
only on the affected hosts/nets (the systems under attack and/or the smurf
amplifiers if it is a smurf attack) is downright irresponsible. Even
then, it will cause problems but they may be less than those caused by the
DoS attack. Most ICMP traffic is necessary to the correct operation of
the net.
Filtering ICMP not only breaks ping, it breaks path mtu discovery which
can cause much grief which is hard for the people affected to diagnose.
Breaking PMTU discovery has the effect that connections between any two
hosts that have an MTU greater than that of the smallest MTU hop on the
path will not be able to communicate. Packets will be dropped,
consistently enough to prevent communications even though some small part
of each flow will frequently get through (generally the same part). This
is a pattern (packet size) sensitive packet loss not a random one so TCP
retransmission does not recover. For SMTP, the HELO, MAIL, RCPT dialog
will happen and then the connection will hang on the message DATA (unless
the message is very short) tying up the servers at both ends until they
timeout. Normally all attempts to resend the message will also fail.
For HTTP, the browser will probably be able to do a "HEAD" (short
response) but a "GET" will fail. The symptom to the user is that
they are consistently unable to get through to certain web sites
with the connection stalling at the same place each time. On very rare
ocassions, I have seen a connection actually succeed to one of these
unreachable servers when it was sufficiently loaded that it transmitted
the data in smaller chunks.
If this happens to you, a workaround is to set the Max MTU to 576 on each
of your clients (to fix outbound connections) and servers (to fix inbound
ones). Setting the Mtu on your router does not seem to work (it might
help in one direction (of data flow), by sending ICMP too bigs to your
inside hosts at a threshold lower than the lost ICMP too bigs, but not the
other direction in which both sets of "too bigs" get dropped. This does
put a higher packet load on the backbone (more smaller packets have to be
routed). The cause is usually because a router somewhere drops packets
which are too large but have the DF (don't fragment) bit set without
generating the required ICMP too big message (there is some defective
hardware out there) or, more likely, that some cluelesss network operator
filtered all ICMP traffic, usually as a naive attempt to protect against
real or anticipated DoS attacks.
This is made much worse by filtering software which does not allow
you to filter specific ICMP types and (unfragmented) packet sizes.
A much better way to handle most of the DoS attacks (except smurf)
is to force fragment reassasembly on a router which is not sucseptible
before forwarding the packets; this puts a significant load on the
router so it is best done on a router/firewall close to the
systems being protected (which is also desireable because it
gives more protection).
As an aside on the original topic, filtering on 0.0.0.255 mask 0.0.0.255
is also irresponsible and never should have been suggested here.
The lame arguments that anyone who has a host in that range is
asking for trouble are specious; just because they may be adversely
affected by some clueless individual somewhere does not justify
your being clueless as well. Yes, personally, I would avoid putting
a (externally accessable) host at .255 because of the general clue
deficit.
> You could always "deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm log" on
Using "deny icmp" as anything other than an extremely temporary measure
while you (or your customers) are actively under DoS attack and focused
only on the affected hosts/nets (the systems under attack and/or the smurf
amplifiers if it is a smurf attack) is downright irresponsible. Even
then, it will cause problems but they may be less than those caused by the
DoS attack. Most ICMP traffic is necessary to the correct operation of
the net.Filtering ICMP not only breaks ping, it breaks path mtu discovery which
can cause much grief which is hard for the people affected to diagnose.
Agreed. It is amazing how clueless so many people are about this problem,
even major backbone providers that just don't seem to be able to
understand it. http://www.worldgate.com/~marcs/mtu/ for newbie-level
details on PMTU-D and why it needs functioning ICMP.
[...]
This is made much worse by filtering software which does not allow
you to filter specific ICMP types and (unfragmented) packet sizes.
A much better way to handle most of the DoS attacks (except smurf)
is to force fragment reassasembly on a router which is not sucseptible
before forwarding the packets; this puts a significant load on the
router so it is best done on a router/firewall close to the
systems being protected (which is also desireable because it
gives more protection).
If it reassembles fragments then it isn't a router.
This isn't really so surprising, because 0 used to be the broadcast address
before being changed to 255. (~1986 or so, I think, right around the time
4.3 BSD came out if I remember correctly.) Many systems still respond to 0
as a broadcast address. Older Sun systems still default the broadcast
address to 0. It's an anachronism that could be dropped.
But it is interesting that the person would have thought to use it in a
smurf attack... If they know that much, they really should have known
better than to smurf. I hope they throw the whole bookcase at them...
--Dean
This isn't really so surprising, because 0 used to be the broadcast address
before being changed to 255. (~1986 or so, I think, right around the time
4.3 BSD came out if I remember correctly.) Many systems still respond to 0
as a broadcast address. Older Sun systems still default the broadcast
address to 0. It's an anachronism that could be dropped.
Not surprising, but also not mentioned on NANOG until now, at least not as
far as I remember.
But it is interesting that the person would have thought to use it in a
smurf attack... If they know that much, they really should have known
better than to smurf. I hope they throw the whole bookcase at them...
Hopefully, we will.
Brandon Ross Network Engineering 404-815-0770 800-719-4664
Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com
Mosher's Law of Software Engineering: Don't worry if it doesn't work
right. If everything did, you'd be out of a job.
Wholesale filtering of ?.?.?.255 is irresponsible but if you have
downstream networks who are unable to block directed broadcasts then it is
a reasonable stopgap measure to block ?.?.?.255 traffic in those
downstream network blocks only. But at the same time you should *DEMAND*
that the downstream customer's router vendor fix their broken equipment or
else advertise that it is suitable only for use on networks that are not
interconnected with the Internet.
Wholesale filtering of ?.?.?.255 is irresponsible but if you have
downstream networks who are unable to block directed broadcasts then it is
a reasonable stopgap measure to block ?.?.?.255 traffic in those
Only if the downstream networks are no bigger than a class C and/or
you have the permission of all customers affected by that filter
and the filter only affects packets destined to your customers
(not outbound packets to the net). If you have any downstreams
larger than a /24, you should allow those through.
Even then, your netmask should have 1s on the left and right
(i.e. 255.255.0.255) for a /16 subnetted at /8.
Really, you should filter the known broadcast addresses of
your downstream networks with the cooperation of those networks.
What I was objecting to was the idea that some ISP would get
the idea that it was a good idea to filter all .255 destined traffic
passing through their network and the general idea that it was
ok for an ISP to assume that .255 was a broadcast address when
they should actually know their downstream networks in more detail
than that (although they might not know about subnetting).
Actually, even if they don't know the subnet structure before hand, they
will discover this, as far as is relevent to smurfing, when they perform
a smurf scan on their own CIDR blocks. Any address that results in
multiple smurf type echo replies from different addresses would be
considered a broadcast address; any that didn't, wouldn't.
And, of course, any ISP should always inform their downstream contacts
of any filtering which affects packets to/from their downstream network
(no matter how standard) and this information should be propagated
downward (possibly excluding details of the firewall protecting
the ISPs servers provided that that firewall is not inline for
packets between the downstream and either upstream, peers, or
other downstreams).
downstream network blocks only. But at the same time you should *DEMAND*
that the downstream customer's router vendor fix their broken equipment or
else advertise that it is suitable only for use on networks that are not
interconnected with the Internet.
Indeed.
In the following comments, "firewall" will refer to a packet filtering
box, not a proxy box. In a separate message, in private email, another
participant, Marc Slemco, pointed out that IP fragment reassembly by a
router is contrary to RFC 1812 and dangerous in some situations because
the fragments could take separate routes. So, I would consider the
following conditions to be necessary before one used fragment reassembly:
- The firewall in question is the only route in or out of
a network (i.e. if there are multiple links they all come
to the same box).
- An exception to the above rule could, perhaps, be granted,
if all the firewalls protecting a multiply connected leaf network
were programmed to behave in such a way that fragments which
took multiple routes were sent to the same box to be reassembled.
One still needs to consider what happens when one of the boxes is
down. One also needs to be careful, from a security perspective, that
the method of relaying fragments does not cause them to be mistaken for
traffic originating inside; simply "routing" all fragments which arrive
at firewall1 and firewall2 to firewall0 (or using a hash) would not be
acceptable (unless you had a dedicated fragment network), some form
of encapsulation would be needed.
- And the deviation from RFC-1812 was well documented, preferably
somewhere readily accessable from both inside and outside the protected
network. Actually, I would like to see a RFC for using DNS
to associate (perhaps using text records) a URL to a WEB page
which documents any ideosyncracies of any given router with
the canonical forward DNS entry for that router. That way,
there would be a consistent way to document broken hardware
or hardware which had to, for some reason, deviate from the RFC's.
I.e., you MUST not do this, but if you do it anyway, you MUST
confess :-). And confession should not be confused with absolution.
[Another pet peeve: people who fail to include reverse address
DNS records for their router addresses. It is so easy to do
(Telepathy - Powering Successful Brands) ].
It is also possible, I suspect, if you have multiple links, for some
packets to be consistenly fragmented and the fragments routed consistently
over multiple routes (based on size or some other criteria) including
one which was down so that you received (consistently) some but not all
fragments for a while. Combination of retransmission, fragmentation,
and multiple routes could conceivably even conspire to produce
hostile DoS style improperly fragmented packets entirely by accident
(i.e. the overlapping fragment style); this is regardless of whether you
reassemble packets at your firewall(s).
But if you are protecting a leaf network with a firewall, I still do think
you should normally reassemble packets at the firewall; you simply cannot
trust all the different stacks inside the firewall in most situations.
But conformance with RFC-1812 is likely to mean you have to
have a single firewall (a single point of failure, possibly
with an offline backup) between the protected organization and all
outside connections or that some new code be written.
Really, you should filter the known broadcast addresses of
your downstream networks with the cooperation of those networks.
Exactly! You can run your own tests for likely broadcast addresses and if
you find an open broadcast address you should contact the downstream
network and ask if they can block directed broadcasts and if they can't
then you should get their permission to filter traffic to the open
broadcast address and regardless of their permission you should contact
the vendor of their equipment to inquire why the equipment is broken and
unsuitable for use on the Internet. And it would be nice to forward any
vendor info to Craig Huegen chuegen@quadrunner.com so he can update his
SMURF document and submit it for publication as an informational RFC with
all the vendor info in place.
What I was objecting to was the idea that some ISP would get
the idea that it was a good idea to filter all .255 destined traffic
passing through their network
Yuk!
Actually, even if they don't know the subnet structure before hand, they
will discover this, as far as is relevent to smurfing, when they perform
a smurf scan on their own CIDR blocks. Any address that results in
multiple smurf type echo replies from different addresses would be
considered a broadcast address; any that didn't, wouldn't.
Exactly! And by cleaning up your downstream vulnerabilities you reduce the
chances that your entire address space will be blocked by other network
operators.
Sorry, I do not know who wrote original message, but it should be
corrected as::
deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm echo-request log
to prevent smurf originating, or
deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm echo-reply
to prevent smurf flooding into your network.
No important ICMP are affected this case.
Really? I thought that extended access-lists needed wildcard masks which
is why I said 255.255.255.0. If an inbound access-list on a hssi says:
access-list 101 deny icmp any 0.0.0.255 255.255.255.0
It is denying only packets with a destination to any.any.any.255. In the
example below, he is actually denying anything from anywhere, not the
broadcasts:
<snip>
deny ip any x.y.z.255 255.255.255.255
</snip>
If he wanted to deny ip to broadcasts on a specific network, he would:
deny ip any x.y.z.255 0.0.0.0
or
deny ip any host x.y.z.255
Am I lost here?! =P
Then how do you propose to effectively block smurf coming IN? You are
totally asking for it if you need to rely on your upstreams to protect
you. I agree with you. If we all deny ICMP, yeah it will fuck up the
Internet -- Good. I hope we all suffer. Maybe then people will
start to listen and actually do something instead of sitting back laughing
at everyone else who is getting attacked because they are convinced that
it will never happen to them.
Seriously.. what do you recommend? I'm totally open. I'm using deny icmp
to protect myself. I'm up to an alternative.