what's that smell?

Mailman List Mirror (Read Only)
1

since the last time we cleared the firewall statistics on c.root-servers.net,
1895GB of udp/53 input has led to 6687GB of udp/53 output, but, and this is
the important part now so pay attention, 185GB of input was dropped due to an
RFC1918 source address.

who needs DDOS when most network operators aren't filtering RFC1918 on output?
(there's only been 4.2GB of udp/2002 and other wormy traffic, by comparison.)

current winners of the "sustained input traffic over 100KBits/sec" award are
164.58.150.146, 200.52.12.131, and 195.146.194.12. c-root keeps on ignoring
you, but you just never give up. congradulations, or something.

(note that c-root's network operator has offered to filter RFC1918 on
input from other AS's, but it's actually useful to keep on measuring it.)

2

to that end why doesnt bind ship with default zone files for rfc1918 space as
well as 127.0.0.0 ?

Steve

3

And to that end, I wonder how many of the bad queries are coming from MS
DNS servers.

4

to that end, i wonder how many of the bad queries are coming directly from
microsoft campus.

-Dan

5

Hope this doesn't come across as DNS-101, but is there some way to tell
what DNS server one uses? Kinda like telnetting to port 80 or 25? I
know if it is possible, it's just as possible for them to change the
output, but chances are the brainiacs of the world who don't filter
probably aren't smart enough to change what their DNS server 'appears'
to be either.

6

-----BEGIN PGP SIGNED MESSAGE-----
Hash: MD5

Hello Jason,

Monday, October 7, 2002, 7:14:41 PM, you wrote:

Hope this doesn't come across as DNS-101, but is there some way to tell
what DNS server one uses? Kinda like telnetting to port 80 or 25? I
know if it is possible, it's just as possible for them to change the
output, but chances are the brainiacs of the world who don't filter
probably aren't smart enough to change what their DNS server 'appears'
to be either.

This will work:

dig @nameserver.tld chaos txt version.bind

For BIND nameservers, but it is not a standard convention so it is not
supported by all nameservers, and most administrators disable the
output from the command at this point:

datacenterwire.com /home/allan#dig @ns1.vbind.com chaos txt version.bind

; <<>> DiG 8.3 <<>> @ns1.vbind.com chaos txt version.bind
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; version.bind, type = TXT, class = CHAOS

;; ANSWER SECTION:
VERSION.BIND. 0S CHAOS TXT "DNS, we aint got no stinkin DNS"

;; Total query time: 0 msec
;; FROM: datacenterwire.com to SERVER: ns1.vbind.com 66.150.201.103
;; WHEN: Mon Oct 7 17:37:39 2002
;; MSG SIZE sent: 30 rcvd: 86

allan
- --
Allan Liska
allan@allan.org
http://www.allan.org

7

to that end why doesnt bind ship with default zone files for rfc1918
space as well as 127.0.0.0 ?

won't help

8

Actually, that's a good thing. This makes it trivial to detect which peers
aren't doing egress filtering. If people just filtered RFC 1918 space,
everything would just look better, but the underlying problem wouldn't be
solved: it would still be possible to launch very hard to trace or stop
denial of service attacks from those networks.

9

Nope. As previously established, there are ISPs out there using RFC1918
networks in their infrastructure. Also, egress filtering is NOT easy, so
even those ISPs doing it may not be able to do it universally. Plus, lots
of attacks these days are mixing spoofed and legit traffic, or doing
limited spoofing (i.e. picking random addresses on the LAN where they
originate to make it past filters).

Kelly J.

10

What is difficult about dropping packets sourced from RFC1918 addresses before they leave your network?

I kind of assumed that people weren't doing it because they were lazy.

Joe

11

I am sure thats part of it. Also, it might be a CPU issue as well.

         ---Mike

12

Also, egress filtering is NOT easy,

I don't care. And it doesn't have to be egress filtering as such,
filtering packets you receive from your customers will work just as well.

Plus, lots of attacks these days are mixing spoofed and legit traffic,
or doing limited spoofing (i.e. picking random addresses on the LAN
where they originate to make it past filters).

What's your point? That because someone can do bad thing #1 that can't be
prevented, we should allow them to do bad thing #2 that can?

If they use (semi-) legitmate addresses, at the very least I can track
them and with some effort I can filter them. If they spoof then I can't do
anything. This is not acceptable.

13

But what's the point?

That's like complaining that the door isn't locked while the house has no
walls.

14

Jason,

There're multiple answers depending on what you mean by "DNS server one
uses."

Whois on the domain will list the DNS servers of record. Some domains
also spread load over RNS servers so a dig, per a previous answer, will
give more specific announced servers currently in the zone files.

If you're using a current Windows box ipconfig /all at a command prompt
will show the actual DNS your machine is caching. There are similar *nix
commands but I'm not at home right now...

Best regards,

15

I am sure thats part of it. Also, it might be a CPU issue as well.

Unicast RPF is affordable CPU-wise even in the most mediocre
boxes people tend to have.

Pete

16

Also, egress filtering is NOT easy,

What is difficult about dropping packets sourced from RFC1918 addresses
before they leave your network?

But what's the point?

Politeness, I guess. Seems rude to send traffic to peers when you absolutely know that the source address is inaccurate.

That's like complaining that the door isn't locked while the house has no
walls.

Right. The no walls problem is far more usefully tackled by filtering inbound at the edge, not outbound.

Joe

17

>> What is difficult about dropping packets sourced from RFC1918
>> addresses before they leave your network?

> But what's the point?

Politeness, I guess. Seems rude to send traffic to peers when you
absolutely know that the source address is inaccurate.

Politeness is good, truthfulness is usually better. If a peer isn't
properly filtering, I'd rather find out sooner (some RFC 1918 packets)
than later (DoS attack).

> That's like complaining that the door isn't locked while the house has
> no walls.

Right. The no walls problem is far more usefully tackled by filtering
inbound at the edge, not outbound.

No complaints from me if that is what people do.

18

I've checked the marketing stuff of several backbones, as far as I could
tell only one makes the blanket statement about source address
validation on their entire network.

http://www.ipservices.att.com/backbone/techspecs.cfm

   AT&T has also implemented security features directly into the backbone.
   IP Source Address Assurance is implemented at every customer
   point-of-entry to guard against hackers. AT&T examines the source
   address of every inbound packet coming from customer connections to
   ensure it matches the IP address we expect to see on that packet. This
   means that the AT&T IP Backbone is RFC2267-compliant.

What backbones do 100% source address validation? And how much of it is
real, and how much is marketing? On single-homed or few-homed stub
networks its "easy." But even a moderately complex transit network it
becomes "difficult." Yes, I know about uRPF-like stuff, but the router
vendors are still tweaking it.

If there is a magic solution, I would love to hear about it.
Unfortunately, the only solutions I've seen involve considerable work and
resources to implement and maintain all the "exceptions" needed to do 100%
source address validation.

Heck, the phone network still has trouble getting the correct Caller-ID
end-to-end.

19

IMHO, it's not too bad if you do it at your edges. Explicit
permits for valid source addrs is a well-known defense against
source spoofing which of course also addresses the RFC1918
leakage issue to some degree. It's not that hard to incorporate
this into customer installation and support processes.

A lot more difficult to manage at the borders.

20

If there is a magic solution, I would love to hear about it.

  to drop the rfc1918 space, there is a close to magic
solution.

  install this on all your internal, upstream, downstream
interfaces (cisco router) [cef required]:

"ip verify unicast source reachable-via any"

  This will drop all packets on the interface that do not
have a way to return them in your routing table.

Unfortunately, the only solutions I've seen involve considerable work and
resources to implement and maintain all the "exceptions" needed to do 100%
source address validation.

  Juniper has a somewhat viable solution to the 100% source
validation for bgp customers. they will consider non-best
paths in their unicast-rpf check on the customer interface. This
means that even if 35.0.0.0/8 is best returned via your
peer instead of via the provider the packet came in, but they
are advertizing the prefix to you, you will not drop the packet.

Heck, the phone network still has trouble getting the correct Caller-ID
end-to-end.

  Uh, this is because it costs another 1/2 a cent a minute (or more)
to provision a caller-id capable trunk (long distance) and people just
don't want to pay the extra money and it's cheaper to not identify
oneself. (This is why most telemarketers don't generate caller-id
or if they can, they supress it).

  - jared