This past weekend I was contacted by several groups ranging from NASA to a
small service provider in the Bay area regarding one of our hosts port
scanning their networks using RESET packets. In each of these cases the
machine seemed to be scanning random addresses in their networks on random,
non-reserved (+1024), ports.
After investigating these claims it appears as if someone is sending SYN
packets to this machine (which serves ftp, which explains why the ports are
open through the cisco) with a spoofed source address causing the machine to
send RESET packets back to the spoofed host and setting off their firewalls.
I cannot seem to get past level-1 or level-2 support from my upstream, GTE/BBN
to find out where these packets are coming from to track this down. So, I come
to you...
Two currently on-going attacks are using the spoofed source addresses from the
networks 134.50.x.x and 130.221.x.x.
If you see activity from these networks inside of your borders, but the
networks are not inside of your borders please contact me off of the list.
Oh yeah, and filter this stuff out people, this is unacceptible.
Perhaps if you were to NAME these networks, they may be shamed into doing
something about the problem. Then again, they should be ashamed to begin
with for passing RFC1918 traffic, let alone loopback space.
Any provider who allows the passing of address space that isn't his own
(beyond whatever transit they may provide to their peers) is shameful.
How hard is it really to put a filter on your outbound links that says
drop all ip traffic heading out these links that isn't from my IP space?
It's just like martian filters for your inbound links, and we'd see a
significant decrease in spoofing based attacks if it was more widely
adopted. Not to mention it'll keep peers from dumping traffic on you.
Any provider who allows the passing of address space that isn't his own
(beyond whatever transit they may provide to their peers) is shameful.
How hard is it really to put a filter on your outbound links that says
drop all ip traffic heading out these links that isn't from my IP space?
It's just like martian filters for your inbound links, and we'd see a
significant decrease in spoofing based attacks if it was more widely
adopted. Not to mention it'll keep peers from dumping traffic on you.
When RFC 2267 was a draft, and since its publication, there have been a
variety of comments that the routers in place couldn't do ingress
filtering at an acceptable rate without impacting traffic flows. The
hope was that vendors would consider this in future designs, and some
appear to have done so.
I suspect most deployed routers do at least some filtering of packets on
most or all interefaces. In the past, some routers couldn't do these
lookups efficiently on source addresses, but that's really an
implementation issue. It's *possible* to design hardware that can handle
it, if there's a business case for doing so. ISPs should be interested
in doing such filtering.
Dialup server vendors have implemented the ability to push filters into
dialup ports. This facility should be used by those offering dialup
pools to ensure packets arriving on a dialup port have a source IP
address that matches the address the server gave to the user in the PPP
IPCP exchange. There are exceptions (LAN dialup) where this won't work,
which is why control of these filters must be available from a Radius
(or equivalent) server, and applied or not on a per-user basis.
Cisco implemened a feature called "Unicast RPF" That disallows
forwarding of packets on an interface where a reverse path is not
present. The command to activate it is:
ip verify unicast reverse-path
and according to Paul Ferguson (co-author of RFC 2267) it's in use by
many ISPs. Apparently this is very-low overhead. Paul has also indicated
the use of extended access lists on Cisco routers is very low overhead,
especially on routers using distributed express forwarding.
Perhaps RFC 2267 should at some point be promoted to a BCP. There was
some discussion about this a few months ago. Whether promotion to BCP
status would entice more network providers to use the facilities or not
is unclear.
[ On Wednesday, July 28, 1999 at 11:21:35 (-0400), Daniel Senie wrote: ]
Subject: Re: SYN spoofing
I suspect most deployed routers do at least some filtering of packets on
most or all interefaces. In the past, some routers couldn't do these
lookups efficiently on source addresses, but that's really an
implementation issue. It's *possible* to design hardware that can handle
it, if there's a business case for doing so. ISPs should be interested
in doing such filtering.
In fact it's easy to buy off-the-shelf hardware today that can do
wire-speed filtering, assuming one has worked such costs into the budget
of building a network backbone....
It is possible to do access filtering on the edges. Then comes the
operational aspects of actually making such a thing scale across many many
edge devices, especially when there are customers with their own space,
and who may have customers behind them with _their_ own space. If a
promising local isp is providing transit to a bunch of other local isps,
changing every access-list on every edge node every time one of the
customer isp's adds or deletes a customer, becomes a logistical nightmare.
Some promising local isp's are then faced with blowing out huge
access-lists virtually every hour of the day, and this becomes harder to
manage when you take into accounts and now you have several tens of
promising local isps all trying to match access-lists all around. Not to
mention the actual physical limits on current hardware regarding the size
of configurations.
While it is easy, it is not always practical because you often have
customers who advertise thousands of prefixes.
Or, in the simpler case, if you transit 500,000 pps on a single outbound
link/router, it becomes very expensive to do per packet filtering
outbound.
At our ingress points, for example, (from peers and customers) we do
filter bogus traffic so we in turn, do not pass undesirable traffic on.
At ingress points where you are only seeing 150,000 pps its not so bad
doing per packet filtering.
:Any provider who allows the passing of address space that isn't his own
:(beyond whatever transit they may provide to their peers) is shameful.
:
:How hard is it really to put a filter on your outbound links that says
:drop all ip traffic heading out these links that isn't from my IP space?
:It's just like martian filters for your inbound links, and we'd see a
:significant decrease in spoofing based attacks if it was more widely
:adopted. Not to mention it'll keep peers from dumping traffic on you.
As far as I can tell, if the RST packets are hitting their firewall,
it isn't just a case of filtering packets with a dst of an rfc1918
addr.
If someone is spoofing a scan from 10/8, and the responses are hitting
an interface on a firewall, that means that there is a route for 10/8
somewhere in that AS pointing to that firewall, which also means that
someone is allowing their customers to leak that route to them.
This is much worse problem than simply not filtering individual packets.
I think that most of the net knows not to announce rfc1918 addrs via
bgp, it just seems that some providers are allowing these routes to
pollute their IGP which, depending on the size of the AS, is just
as bad.