Hello, Bugtraq,

I am not quite sure this hasn't been already discussed before, if so,
please excuse me...

There were quite a lot of "DNS DoS-ing with spoofed udp"-related
messages here recently. What I'd like to discuss is something similar in
concept - a denial of service via spoofing the source of UDP packets so
that we have an "amplifying effect". 

A lot of people configure sysklogd to collect log messages from the
network with the "-r" option. 
Most security concerns in that case are related to DoS attacks that
would fill your logs with garbage, eventually consuming all the
available storage on the logs partition, thus effectively disabling
further logging, as well as making log analysis harder. 

Now what happens if syslogd accepts log messages from everywhere (e.g in
case the people in charge of it rely on the organisation's external
firewall and the attacker has already got access on a machine in the
internal network, or if the firewall is just poorly configured, or the
worst - it's just not firewalled)? The log-collecting system can easily
be flooded with dummy messages originating from random spoofed sources.
The problem here is that sysklogd cannot be configured not to resolve
the hostnames it receives messages from (well, at least my  sysklogd
1.4.1-17 cannot).

So what's the issue?

Let's say an attacker sends 5000 UDP packets with spoofed source address
to the logging system (the victim). hping is a good tool for this.
So, the attacker sends / 5000 UDP packets * (28 bytes header  + 2 random
bytes of data) / to the victim

The victim host now tries to resolve the spoofed sources' hostnames, so
sysklogd sends 5000 PTR queries to its DNS server which are:
/ 5000 DNS queries * (28 bytes header + about 10-15 bytes of query
data) /

Eventually the DNS server replies to the victim with:
/ 5000 DNS answers * (28 bytes header + at least 20-40 bytes of answer
data) /

So with our 5000*30=150000 bytes' sent bytes, the logging system gets an
extra traffic of about 5000*40+5000*60=500000 bytes..
Which is about 3-4x amplification (I think it is even a good case,
because many ISPs tend to set long PTR records for their dialup/cable
users' ip addresses). And the DNS server that is used by sysklogd will
also be flooded with PTR queries for random addresses (the probability
that answers are not cached is high)..

The result will be that first : flooded machine may not log everything
sent to it, and second: it will create a good ammount of useless network
traffic, some times more more than the original flood. It may affect the
proper work of the DNS server too.

I know that good IP filtering on the sysklogd box is the best fix, but
always resolving hostnames of the log messages' sender is definitely not
a good idea..