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..
