DNS Attacks From Foreign IP Addesses
-
How exactly do you remain connected to a UDP port? Since UDP is a connectionless protocol?
-
If I look at the "Network Monitor" on my DN Server it shows a handful of constant connections from external hosts to port 53 UDP.
Just wondered if I can do any thing about them, perhaps some setting in pfSense or do I just have to block them with firewall rule.
-
you sure its just not sending you lots of requests?
I personally would grab a sniff to see what traffic its sending you. Normally queries? Have you setup your public IP to be listed for a public domain name servers?
That would be the only reason I could see for opening up 53 tcp/udp to your dns - is that you want outside to query it. You do not have to forward ports to your dns to just have it do outside queries.
-
Yes its a public facing Domain Name Server for our clients Domain.
When I enter the IP Addreses into the "Automatic Log Block" alias list the firewall still allows the traffic through.
Should the BlockList be instant?
Also just to be sure I view the connections via:
Diagnostics > States
46.23.64.195:53 <- xx.xx.xx.xx:53 MULTIPLE:MULTIPLE
click on "Remove state entries"
-
If its public facing - then your going to have allow connections.. Why would you block people from doing queries to your nameserver for a public domain?
I am confused to why you would want to block someone from doing a query to your public name server? Do you feel this is some sort of dns attack? If you feel its an attack, again a sniff of the traffic between you and the IPs would be helpful - they could simply being doing queries to your domain.
that state you posted from what your xx out, I have to assume that is your IP. So that state is from your box to that public IP. So is your name server also use for recursive lookups?
Do you allow queries for domains that your not authoritative for? Normally this is bad practice for a public facing server that is authoritative for zones.
For example
udp 68.180.131.16:53 <- 192.168.1.7:43101 SINGLE:MULTIPLEI just did a query from a box on my network to ns1.yahoo.com which is that IP.
;; Query time: 20 msec
;; SERVER: 68.180.131.16#53(68.180.131.16)So you can see my state above. The direction of the arrow is from MY ip to that public nameserver to port:53
In your state that looks like your server talking to that 46.23.64.195 IP Which looks like http://forum.kazahstanki.com/ to me. when I look up that IP http://www.robtex.com/ip/46.23.64.195.html#ip
Now I show that also the IP for www.kazahstanki.com – which be warned looks to be a adult related site. Not blocked by my work filters ;) hehehe
For all we know someone is posting on that site with a signature pointing to something in one of your public domains, so that your getting a lot of queries for the record. Again a sniff will give you lots of info to work with. On pfsense do a capture under diag for port 53, and take a look at what is the traffic actually is.
If you just looking to adjust the timeouts for states. Yes they can be adjusted - what do you have your firewall set to in advanced, firewall optimization? normal, conservative, aggressive, high latency? I am set to normal, and show these as the state timeouts
[2.1-BETA0][admin@pfsense.local.lan]/root(1): pfctl -s t
tcp.first 120s
tcp.opening 30s
tcp.established 86400s
tcp.closing 900s
tcp.finwait 45s
tcp.closed 90s
tcp.tsdiff 30s
udp.first 60s
udp.single 30s
udp.multiple 60s
icmp.first 20s
icmp.error 10s
other.first 60s
other.single 30s
other.multiple 60s
frag 30s
interval 10s
adaptive.start 58200 states
adaptive.end 116400 states
src.track 0sBut since you say your running a public facing dns - its going to get lots of traffic I would assume, depending on the domain(s) in question being hosted on it.
But to answer your question directly - just putting in the block would not clear the state table. Put in your block, and then flush your states and then you should block after you clear the states.
Also keep in mind if this server is doing recursive for say your local users – that could generate all kinds of dns traffic. Does your name server just forward, or does it do lookups from roots? Dns can generate lots of weird traffic from all over the globe ;) Keep in mind allowing recursive lookups from public is not safe practice - this can be used for simple dos attacks to take down your dns. Not to that big of deal if you only allow recursive from your own users. But I would look to make sure you have a very valid reason to allow recursive from public. And going to have to be appropriately sized for the amount of traffic running public dns can generate. Also look to what your TTLs are set to. Low TTLs can generate a storm of traffic depending on the popularity of the domains being hosted.
-
First of all thank you so much for taking the time to reply lol I know enough about networking to be dangerous ;D
If its public facing - then your going to have allow connections.. Why would you block people from doing queries to your nameserver for a public domain?
I am confused to why you would want to block someone from doing a query to your public name server? Do you feel this is some sort of dns attack? If you feel its an attack, again a sniff of the traffic between you and the IPs would be helpful - they could simply being doing queries to your domain.
The connections I'm thinking of blocking are originating from a handful of public hosts which are sending me constant flow of DNS requests. Which I believe is some type of attack due to the constancy and amount
that state you posted from what your xx out, I have to assume that is your IP. So that state is from your box to that public IP. So is your name server also use for recursive lookups?
No the server has been locked down regarding recursive lookups and i've maid the suggested DDOS registry fixesDo you allow queries for domains that your not authoritative for? Normally this is bad practice for a public facing server that is authoritative for zones.
No only domain which we host for peopleFor example
udp 68.180.131.16:53 <- 192.168.1.7:43101 SINGLE:MULTIPLEHere is my States Table you can see multiple and multiple:
udp 46.23.64.195:53 <- 83.166.162.21:53 MULTIPLE:MULTIPLE
udp 83.166.162.21:53 -> 46.23.64.195:53 MULTIPLE:MULTIPLE
udp 83.166.162.21:53 <- 193.188.101.168:53 MULTIPLE:MULTIPLE
udp 193.188.101.168:53 -> 83.166.162.21:53 MULTIPLE:MULTIPLE83.166.162.21 is our DN server.
I just did a query from a box on my network to ns1.yahoo.com which is that IP.
;; Query time: 20 msec
;; SERVER: 68.180.131.16#53(68.180.131.16)So you can see my state above. The direction of the arrow is from MY ip to that public nameserver to port:53
In your state that looks like your server talking to that 46.23.64.195 IP Which looks like http://forum.kazahstanki.com/ to me. when I look up that IP http://www.robtex.com/ip/46.23.64.195.html#ip
Now I show that also the IP for www.kazahstanki.com – which be warned looks to be a adult related site. Not blocked by my work filters hehehe
lol save that URL for future testing purposes! ;DFor all we know someone is posting on that site with a signature pointing to something in one of your public domains, so that your getting a lot of queries for the record. Again a sniff will give you lots of info to work with. On pfsense do a capture under diag for port 53, and take a look at what is the traffic actually is.
Get me their home town i'll pay them a visit!
I ran wireshark on the DN Server and it's response after request after response after request and so on….... from the said host addressesIf you just looking to adjust the timeouts for states. Yes they can be adjusted - what do you have your firewall set to in advanced, firewall optimization? normal, conservative, aggressive, high latency? I am set to normal, and show these as the state timeouts
[2.1-BETA0][admin@pfsense.local.lan]/root(1): pfctl -s t
tcp.first 120s
tcp.opening 30s
tcp.established 86400s
tcp.closing 900s
tcp.finwait 45s
tcp.closed 90s
tcp.tsdiff 30s
udp.first 60s
udp.single 30s
udp.multiple 60s
icmp.first 20s
icmp.error 10s
other.first 60s
other.single 30s
other.multiple 60s
frag 30s
interval 10s
adaptive.start 58200 states
adaptive.end 116400 states
src.track 0sBut since you say your running a public facing dns - its going to get lots of traffic I would assume, depending on the domain(s) in question being hosted on it.
But to answer your question directly - just putting in the block would not clear the state table. Put in your block, and then flush your states and then you should block after you clear the states.
Also keep in mind if this server is doing recursive for say your local users – that could generate all kinds of dns traffic. Does your name server just forward, or does it do lookups from roots? Dns can generate lots of weird traffic from all over the globe Keep in mind allowing recursive lookups from public is not safe practice - this can be used for simple dos attacks to take down your dns. Not to that big of deal if you only allow recursive from your own users. But I would look to make sure you have a very valid reason to allow recursive from public. And going to have to be appropriately sized for the amount of traffic running public dns can generate. Also look to what your TTLs are set to. Low TTLs can generate a storm of traffic depending on the popularity of the domains being hosted.
No I'm not using the server for any other resolution just the DNS for clients Domain Names no internal resolutions/recursionsAlso I'm going to "Reset The States" now see if the IP's are blocked afterwards! wish me luck…....and again thanks for taking the time :)
Phil
-
Well the blocking thing works thanks :) one thing to watch for is "I've already added that IP Address!!!…...........oh........wait............no...that one's slightly different!" :)
-
"I ran wireshark on the DN Server and it's response after request after response after request and so on….... from the said host addresses"
But were they legit requests? What is the TTL of the response - one reason I can think of what your saying was happening would be a very short TTL.
Was it the same request over and over again? Or different requests? I am very curious to that traffic - if you don't want to post public would you mind sending me a PM.
I am glad you got what you wanted blocked to work - but blocking IPs from doing queries to your public DNS could be causing failure in legit use. Without seeing what was being asked and what the response was its hard to tell.
edit: BTW I just did a few queries to your dns IP you posted. Not really blocking recursive the way you would want.. I ask it for say www.yahoo.com and it returns the root hints, which is
MSG SIZE rcvd: 510
With a status of NO ERROR... But as example when I guery say ns1.google.com for www.yahoo.com I get a REFUSED STATUS and msg size returned is only
; <<>> DiG 9.8.1-P1 <<>> @ns1.google.com www.yahoo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 43576
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available;; QUESTION SECTION:
;www.yahoo.com. IN A;; Query time: 38 msec
;; SERVER: 216.239.32.10#53(216.239.32.10)
;; WHEN: Wed Jul 11 15:44:56 2012
;; MSG SIZE rcvd: 31You might want to look into how to returned refused if your not going to allow recursive queries.
-
Yes I did a little more "Digging" ( Linux people will find that amusing ) yesterday added the NS IP to my local PC's name server list. I didn't realise that the server would resolve external hosts even with Recursion Off lol, it just uses the Root Hints instead :) so i've now removed the Hints from the server and you get server fail now instead ::) ooops
Still getting random connections though which are taking up precious bandwidth and CPU :(
It seems that all legit DNS requests will connect as you said before with a: SINGLE>MULTIPLE 53 and then a MULTIPLE <single 53="" response.<br="">All of the dodgy connections are using MULTIPLE:MULTIPLE do you think pFsense and detect MULTIPLE:MULTIPLE udp 53 connections and block them :) ?
I will look at TTL values not changed them from MS defaults.</single>
-
Like I said running a dns, your going to get some crazy connections.
More than happy to help you figure out what it is, be it legit, noise, etc. Should it be blocked, if so what is best way.
Can you PM a sniff/capture of this dns traffic your seeing, or email it to me - I have PM'd you my normal email address.
BTW - yup repeated my www.yahoo.com test to your dns and SERVFAIL ;)
As to the multiple:multiple, where did you get that idea. All that is telling you is the state of the timeouts for the state. You have multiple packets on that state and side is how I read that. Does not mean its a bad one?? I have lots of states in that mode under udp, plenty for p2p - but then again I do host a dns server on this connection. But I do host ntp
udp 207.179.124.86:123 -> 192.168.1.40:123 MULTIPLE:MULTIPLE
udp 192.168.1.40:123 <- 24.13.xxx.xxx:123 <- 50.104.241.182:50054 MULTIPLE:MULTIPLE
udp 50.104.241.182:50054 -> 192.168.1.40:123 MULTIPLE:MULTIPLE
udp 192.168.1.40:123 <- 24.13.xxx.xxx:123 <- 63.224.174.10:281 MULTIPLE:MULTIPLE
udp 63.224.174.10:281 -> 192.168.1.40:123 MULTIPLE:MULTIPLE
udp 192.168.1.40:123 <- 24.13.xxx.xxx:123 <- 173.216.5.55:123 MULTIPLE:MULTIPLEPart of ntp.pool.org on both ipv4 and ipv6 – so there is a bit of traffic there from all over the planet. Notice its in multiple:multiple
-
You guys are making this WAY too complicated.. lol. Install pfblocker on the firewall and block whatever countries you like from accessing your network/DNS server.
-
Too complicated? His box is talking to dns servers.. That is not complicated. He just did not understand what a pool is and that yes it could be anywhere.
You didn't even read the thread did you.
-
I know this is a little late but a bit of good info is if its 53 udp its a query but if its 53 tcp its a zone transfer and that is bad. so you will just want to watch out for that from any ips. I just thought you could use this info.
-
DNS over TCP isn't just zone transfers - TCP is simply used where the response is too big to fit in a single UDP packet. That isn't uncommon with things like large MX records for instance.
-
@Cry:
DNS over TCP isn't just zone transfers - TCP is simply used where the response is too big to fit in a single UDP packet. That isn't uncommon with things like large MX records for instance.
true but just trying to state that might want to be more cautious of tcp connections. but most of the stuff going around the net are more or less just script kiddies, and the white noise of the internet.
