first, apologies for bringing up an operational issue.
a long while back, i noticed my border filters were showing incoming
packets from 1918 addresses and my own address blocks. i wrote this off
to anomalies and did not have the time to pursue.
yesterday, i happened to notice it again. i described it on an internal
mailing list. other folk looked at their filters, and lo and behold, it
is a widespread problem.
fyi, my filter looks like the following:
! what we allow to come in the serials from the world
no access-list 105
! PSGnet
access-list 105 deny ip 147.28.0.0 0.0.255.255 any
access-list 105 deny ip 192.83.230.0 0.0.0.255 any
access-list 105 deny ip 198.133.206.0 0.0.0.255 any
! rfc1918
access-list 105 deny ip 127.0.0.1 0.255.255.255 any
access-list 105 deny ip 10.0.0.0 0.255.255.255 any
access-list 105 deny ip 172.16.0.0 0.15.255.255 any
access-list 105 deny ip 192.168.0.0 0.0.255.255 any
! block portmapper and nfsd attacks
access-list 105 deny udp any any eq sunrpc
access-list 105 deny tcp any any eq 2049
! block samba
access-list 105 deny tcp any any eq 137
access-list 105 deny tcp any any eq 138
access-list 105 deny tcp any any eq 139
!
! some other stuff
! allow all others
access-list 105 permit ip any any
the results of 30 hours of running are
deny ip 147.28.0.0 0.0.255.255 any (6 matches)
deny ip 192.83.230.0 0.0.0.255 any
deny ip 198.133.206.0 0.0.0.255 any
deny ip 127.0.0.0 0.255.255.255 any (375 matches)
deny ip 10.0.0.0 0.255.255.255 any (593 matches)
deny ip 172.16.0.0 0.15.255.255 any (201 matches)
deny ip 192.168.0.0 0.0.255.255 any (769 matches)
deny udp any any eq sunrpc (9 matches)
deny tcp any any eq 2049 (494 matches)
deny tcp any any eq 137
deny tcp any any eq 138
deny tcp any any eq 139
permit ip any any (9467763 matches)
when we tried it on routers in different parts of the network, it seemed
to show similar patterns.
anyone have clues other than net slime and misconfigured nats?
I try to drop this as close to the edge as possible
in some cases, but as you can see here:
deny ip host 0.0.0.0 any log-input (4322 matches)
deny ip 10.0.0.0 0.255.255.255 any log-input (625 matches)
deny ip 169.254.0.0 0.0.255.255 any log-input (887 matches)
deny ip 192.168.0.0 0.0.255.255 any log-input (11401 matches)
I get a few matches, it would appear that folks like the 192.168
the most, and the 172.16 the least (I have zero matches on this box).
Something dumb appears to be sending dhcp/bootp (0.0.0.0)
(I've got a hub at home that keeps doing that, i've not been able to
console into it yet)
My recommendation is to ignore it in the core, but start to drop
it once it hits your edges where you tend to have lower speed links
that can take filters.
u-rpf checks are nice also, it would be nice to see more folks
doing it, but that's life in this world.
If you could get everyone at the exchange points to filter,
that would be nice, but the fact of the matter is most traffic goes
across the private interconnects, which contiue to grow in size,
and it's not possible or is service degrading to filter such links.
Yo Randy!
> deny ip 10.0.0.0 0.255.255.255 any (593 matches)
> deny ip 172.16.0.0 0.15.255.255 any (201 matches)
> deny ip 192.168.0.0 0.0.255.255 any (769 matches)
[...]
> anyone have clues other than net slime and misconfigured nats?
The net-slime would be the folks that sent a src address at
you of your network (whcih I saw in your acl match).
> deny ip 10.0.0.0 0.255.255.255 any (593 matches)
> deny ip 172.16.0.0 0.15.255.255 any (201 matches)
> deny ip 192.168.0.0 0.0.255.255 any (769 matches)
[...]
> anyone have clues other than net slime and misconfigured nats?
If you did a traceroute thru a router using a private address on
one of it's interfaces you could see this. That would be legit.
What RFC 1918 says, is that you're supposed to ensure at border points
that private addresses are not leaked. ISPs who insist on using RFC 1918
addresses on their routers should be responsible for filtering out any
responses such routers make (e.g. traceroute packets) at their borders.
In reality, routers used in the ISP infrastructure are NOT good
candidates for RFC 1918 addresses. My present upstream (@Home network)
appears to use all of the RFC 1918 address blocks for their own use, and
leaks them everywhere. Had I known this before signing a contract, they
wouldn't have gotten my business.
An interesting passage from RFC 1918, a.k.a. BCP 5, is:
"Because private addresses have no global meaning, routing information
about private networks shall not be propagated on inter-enterprise
links, and packets with private source or destination addresses should
not be forwarded across such links. Routers in networks not using
private address space, especially those of Internet service providers,
are expected to be configured to reject (filter out) routing information
about private networks. If such a router receives such Information the
rejection shall not be treated as a routing protocol error."
when we tried it on routers in different parts of the network, it seemed
to show similar patterns.
anyone have clues other than net slime and misconfigured nats?
I actually have never seen a NAT box do this (but would like to hear
about such cases). The NAT implementations I've worked with have been
extremely good about avoiding leaks.
The likely cause is routers in people's infrastructure using private
address space for point to point links and as ways to avoid using up
public address space.
everybody seems to be focussed on the 1918 space packets and the
explanations seem half reasonable. as Daniel Senie <dts@senie.com> said,
the rules of the road say i should not be seeing packets from 1918 space.
i.e. at best these come from broken places.
but the uglier symptoms are packets from my own address space
deny ip 147.28.0.0 0.0.255.255 any (6 matches)
the loopback network
deny ip 127.0.0.0 0.255.255.255 any (375 matches)
and attempts on 111 and 2049
deny udp any any eq sunrpc (9 matches)
deny tcp any any eq 2049 (494 matches)
There have been a couple of things brought up here which bother me.
First of all, everyone seems to think that this paragraph:
"Because private addresses have no global meaning, routing information
about private networks shall not be propagated on inter-enterprise
links, and packets with private source or destination addresses should
not be forwarded across such links. Routers in networks not using
private address space, especially those of Internet service providers,
are expected to be configured to reject (filter out) routing information
about private networks. If such a router receives such Information the
rejection shall not be treated as a routing protocol error."
means that packets with source addresses from RFC 1918 space should not be
permitted on the global internet. While I agree that RFC 1918 addresses
should not be used on internet visible interfaces, I'm unaware of anywhere
in the RFC's where it says that "routers should be configured to reject
packets coming from RFC 1918 space." In fact, I can think of several
things which this will likely break, such as MTU path discovery. Note
that "routing information" is NOT the same as "packets from RFC1918
space".
Also, I've seen several people filtering stuff on borders such as:
deny tcp any any eq 2049
(and several other >1024 port numbers)
Remember, on machines where nothing is bound to 2049, 2049 is a perfectly
acceptable port to use for ANY type of TCP connection. Only ports below
1024 are reserved. If you happen to have a filter on say port 2049
between you and the destination and your TCP implementation gives you 2049
for a given TCP connection, the connection will fail.
First of all, everyone seems to think that this paragraph:
"Because private addresses have no global meaning, routing information
about private networks shall not be propagated on inter-enterprise
links, and packets with private source or destination addresses should
not be forwarded across such links. Routers in networks not using
private address space, especially those of Internet service providers,
are expected to be configured to reject (filter out) routing information
about private networks. If such a router receives such Information the
rejection shall not be treated as a routing protocol error."
means that packets with source addresses from RFC 1918 space should not be
permitted on the global internet. While I agree that RFC 1918 addresses
should not be used on internet visible interfaces, I'm unaware of anywhere
in the RFC's where it says that "routers should be configured to reject
packets coming from RFC 1918 space." In fact, I can think of several
things which this will likely break, such as MTU path discovery. Note
that "routing information" is NOT the same as "packets from RFC1918
space".
well...there is that part about
...packets with private source or destination addresses should not be
forwarded across such links.
that sort of clears it up for me.
Also, I've seen several people filtering stuff on borders such as:
deny tcp any any eq 2049
(and several other >1024 port numbers)
Remember, on machines where nothing is bound to 2049, 2049 is a perfectly
acceptable port to use for ANY type of TCP connection. Only ports below
1024 are reserved. If you happen to have a filter on say port 2049
between you and the destination and your TCP implementation gives you 2049
for a given TCP connection, the connection will fail.
...which was a mistake anyway. whoever it was that was developing nfs
decided to hardcode 2049 so that (a) it could be done as a regular
user and (b) it could be done even without portmapper support (even
though it was rpc based). it *should* have been moved to a reserved
or well-known port before official release, but it was not.
means that packets with source addresses from RFC 1918 space should not be
permitted on the global internet. While I agree that RFC 1918 addresses
should not be used on internet visible interfaces, I'm unaware of anywhere
in the RFC's where it says that "routers should be configured to reject
packets coming from RFC 1918 space."
As others have pointed out, there are indeed RFC sections which seem to
imply that packets coming from RFC 1918 space should not be visible on
the global Internet.
Furthermore, whether the RFC says so or not, I'm going to block these
packets at *my* border routers, because:
- I have absolutely *no* idea of where these packets might be coming
from,
- and I have no possibility of generating sensible replies to packets
with RFC 1918 source addresses.
> Furthermore, whether the RFC [1918] says so or not, I'm going to block
> these packets at *my* border routers, because:
Curious as to the cost (added latency) in doing RFC 1918 source address
filtering on all packets in the context of cost-benfit analysis.
The cost is dependent on the quality of the filtering implementation of
your routers. It's quite possible to implement source address filtering
as a part of ASIC-assisted routing, resulting in wire-speed filtering.
Whether any given vendor has or has not implemented their equipment to
allow wire speed filtering is something you might want to ask salesmen.
As it's something which network providers should be doing, its a
capability that should be demanded of the hardware vendors.
Furthermore, whether the RFC [1918] says so or not, I'm going to block
these packets at *my* border routers, because:
Curious as to the cost (added latency) in doing RFC 1918 source address
filtering on all packets in the context of cost-benfit analysis.
on a router that's not doing filtering, it's going to be a small hit.
i'm going to infer, however, that any router that's not doing
filtering is probably not doing much traffic. and any router that is
doing a lot of traffic, is already doing filtering. so it's less of a
hit.
> Furthermore, whether the RFC [1918] says so or not, I'm going to block
> these packets at *my* border routers, because:
Curious as to the cost (added latency) in doing RFC 1918 source address
filtering on all packets in the context of cost-benfit analysis.
Well, we added filtering of spoofed source addresses (ie. our own) at our
border routers quite a while ago. Adding filters for the RFC 1918 source
addresses was a complete no-brainer - three more lines in a filter that
already had around 15 lines. *No* visible (to us) increased processor
load or latency.
(I'm sure it can be measured - but in our case it's completely lost in
the noise.)
on a router that's not doing filtering, it's going to be a small hit.
i'm going to infer, however, that any router that's not doing
filtering is probably not doing much traffic. and any router that is
doing a lot of traffic, is already doing filtering. so it's less of a
hit.
huh? for packet filtering, which is what we've been discussing, my
experience is quite the opposite. one can't really afford packet
filters on routers with oc12s. and in a multi-path universe, filtering
for source address spoofing is best done at the edges anyway.
[ On Friday, April 23, 1999 at 16:15:30 (-0700), John Leong wrote: ]
Subject: Re: address spoofing
> Furthermore, whether the RFC [1918] says so or not, I'm going to block
> these packets at *my* border routers, because:
Curious as to the cost (added latency) in doing RFC 1918 source address
filtering on all packets in the context of cost-benfit analysis.
Well, there's no question as to the benefit if you actually use any of
those networks internally -- I for one never want to see a packet on a
public interface that appears to have come from one of my management
networks, and conversely I'm going to be extremely careful not to let
packets slip out from my management networks onto a public network,
especially in the case of internal misconfigurations.
It seems to me that if you're going to filter for one or two of your own
internal management networks then there's zero added cost to simply
increase the prefix to match the entire larger RFC 1918 group since your
private management networks are obviously going to be a part of *some*
RFC 1918 prefix, right!
It also seems that if you're going to filter for one prefix then you
probably won't lose much additional latency or router cycles if filter
the whole works, not to mention that you'll have additional piece of
mind in knowing that if someone internally starts using one of the other
RFC 1918 prefixes, or the test net, or whatever, you'll still be
protecting them too.
In fact I run filters on each server, with separate physical interfaces
for public and internal "management" traffic; as well as on the routers
with interfaces on the border in order to protect things even if some
wire gets plugged into the wrong port. Such configurations are far less
forgiving of sloppy configuration, of course, but that's the idea.
but the uglier symptoms are packets from my own address space
deny ip 147.28.0.0 0.0.255.255 any (6 matches)
I have vague memory of an old attack using ping with source address
equal to broadcast address of the target net.
That is over and above TCP connection hijacking, server attacks with
half openned TCP connections and such fumy things. On the other hand,
given you seem to have only 6 incidences, looks more like screw up than
real attack.
Wonder if its too much to ask the backbones to do sanity checks on their
customers T1 lines etc. Eg they arent smurf amplifiers, they have spoof
filters, yadda yadda.
If this happened perhaps the rate of DoS attacks would go down
[...]
but the uglier symptoms are packets from my own address space
deny ip 147.28.0.0 0.0.255.255 any (6 matches)
One of our customers has 129.129.0.0/16, and we sure receive a lot of
leaked packets with source and destination addresses in that range
from our upstream. (One of these days I'll try to get those traced
147.28.0.0 doesn't seem like a likely "random" prefix though. Maybe
an ex-customer/employee of yours didn't clean up their configuration
when they left?
