I'm having problems where my upstream bandwidth is being saturated. I've narrowed it down to a DNS issue of some type. If I stop the named service then my bandwidth drops to "normal" according to my untangle firewall. I'm running bind-9.3.6-20.P1.el5_8.6. I'm seeing the following in /var/log/messages: 2014-02-08T23:03:09.558315-05:00 mailserver named[3497]: network unreachable resolving 'hccforums.nl/ANY/IN': 2a00:1188:5::212#53 2014-02-08T23:03:09.558441-05:00 mailserver named[3497]: network unreachable resolving 'hccforums.nl/ANY/IN': 2001:7b8:606::85#53 2014-02-08T23:03:10.008926-05:00 mailserver named[3497]: client 174.128.253.163#5209: view external: no more recursive clients: quota reached 2014-02-08T23:03:11.001878-05:00 mailserver named[3497]: client 173.234.39.133#5209: view external: no more recursive clients: quota reached 2014-02-08T23:03:12.000487-05:00 mailserver named[3497]: client 173.234.39.133#5209: view external: no more recursive clients: quota reached 2014-02-08T23:03:13.000820-05:00 mailserver named[3497]: client 173.234.39.133#5209: view external: no more recursive clients: quota reached 2014-02-08T23:03:14.001501-05:00 mailserver named[3497]: client 192.126.118.105#5209: view external: no more recursive clients: quota reached 2014-02-08T23:03:15.005720-05:00 mailserver named[3497]: client 192.126.118.105#5209: view external: no more recursive clients: quota reached I've tried changing the following in /etc/named.conf but it doesn't seem to have any affect so I commented them back out. tcp-clients 1000; recursive-clients 10000; I also see a chroot directory, but if I grep for named it doesn't appear to be using the chroot(?): # ps aux | grep named named 3497 0.4 0.7 170088 15836 ? Ssl 23:02 0:02 /usr/sbin/named -u named root 3763 0.0 0.0 61192 764 pts/1 S+ 23:13 0:00 grep named I've also tried adding the following to iptables, but it also seems to have no affect: iptables --insert INPUT -p udp --dport 53 -m string --from 40 --to 56 --algo bm --hex-string '|09686363666f72756d73026e6c0000ff|' -j DROP -m comment --comment "DROP DNS Q hccforums.nl" Any suggestions or troubleshooting advice? Much appreciated. James
On 09.02.2014 04:19, James Pifer wrote:> I'm having problems where my upstream bandwidth is being saturated. > I've > narrowed it down to a DNS issue of some type. If I stop the named > service then my bandwidth drops to "normal" according to my untangle > firewall.Your dns server may be used in a reflection/amplification attack, is it an open resolver? Read e.g. http://www.mill-yard.com/2013/07/centos-bind-blocking-dns-reflection-or-amplification-ddos-attacks-using-recursive-dns-lookups/ -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Hi James, you seem to be running an open DNS resolver, is that correct? And if so, do you do it intentionally? I just received an US-CERT alert today that warns about ongoing amplification attacks, among others against DNS, but also against some other UDP based services. <https://www.us-cert.gov/ncas/alerts/TA14-017A> From the symptoms you describe I'd say that your DNS server is being used in such an attack.> I also see a chroot directory, but if I grep for named it doesn't appear > to be using the chroot(?): > # ps aux | grep named > named 3497 0.4 0.7 170088 15836 ? Ssl 23:02 0:02 > /usr/sbin/named -u named > root 3763 0.0 0.0 61192 764 pts/1 S+ 23:13 0:00 grep namedDo you have the bind-chroot package installed? Best regards, Peter. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.centos.org/pipermail/centos/attachments/20140209/d30437e4/attachment-0002.sig>
On Sun, Feb 9, 2014 at 3:55 PM, Peter Eckel <lists at eckel-edv.de> wrote:> Hi James, > > you seem to be running an open DNS resolver, is that correct? And if so, > do you do it intentionally? >Nux! and Peter are almost certainly correct. If the OP was to run tcpdump with the -A flag on the external/public-facing interface, I'd expect he'll see a slew of ANY queries. # untested # but the pipe to grep should highlight the word any while still displaying everything tcpdump's filter matches on (dns queries on port 53) tcpdump -i <public-facing_interface> -nnA port 53 | grep --color -i -E 'any|$' The OP likely doesn't want to be an open recursive DNS server. He can rate-limit DNS queries per source or better yet, set up bind views and separate ACLs ... trusted hosts in one and everyone else (external Internet hosts) in the other. In the internal/trusted view leave recursion enabled for those hosts (I expect that's what you want). AND most importantly in the external view _disable_ recursion. If there's no reason for you to answer any queries on your public facing interface, then disable it all together (you could be running an authoritative name server on that box, so you wouldn't want to do that!). Tips to secure your BIND install ... brought to you by Team Cymru [0] And while you're at it, if you're running ntpd - secure it too [1] if you haven't already. (Essentially disable monitor/monlist command responses.) [0] http://www.cymru.com/Documents/secure-bind-template.html [1] http://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html> > I just received an US-CERT alert today that warns about ongoing > amplification attacks, among others against DNS, but also against some > other UDP based services. > > <https://www.us-cert.gov/ncas/alerts/TA14-017A> > > From the symptoms you describe I'd say that your DNS server is being used > in such an attack. > > > I also see a chroot directory, but if I grep for named it doesn't appear > > to be using the chroot(?): > > # ps aux | grep named > > named 3497 0.4 0.7 170088 15836 ? Ssl 23:02 0:02 > > /usr/sbin/named -u named > > root 3763 0.0 0.0 61192 764 pts/1 S+ 23:13 0:00 grep > named > > Do you have the bind-chroot package installed? > > Best regards, > > Peter. > > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > >-- ---~~.~~--- Mike // SilverTip257 //