Odd dns replies from ARIN and now another server
-
So, starting about a week ago, u.arin.net started sending me about 400-500 DNS replies a day that pfSense is blocking. Which is odd because I use Quad9. I also have a NAT forward on all my interfaces to redirect port 53 to my pihole server which goes to Quad9 over TLS. I also have a reject rule to port 53 that isn't my pihole server. The NAT works. I can Dig @8.8.8.8 and put in a DNS entry that I added to my pihole and it returns that IP.
The guy that owns the netblock says he gets 2-3 calls a week about it and just says "It's normal DNS traffic" and people just go "Oops, sorry" but I do not use that IP. I see no outbound traffic to that IP. I straight up blocked outbound to that IP, and it still doesn't show anything. I sent him back an explanation that it may indeed be compromised, but he doesn't seem to care much.
Then today I started seeing an IP out of Mexico. 200.10.60.53. Same thing.
I disabled my Namecheap and DNS Made Easy Dynamic DNS updaters, no avail. I'm going to try and disable pfBlockerNG as well.
I mean they could be compromised and using a source of UDP 53 to try and get around IPS/IDS. Anyone else see this?
I also did a test, I set my default gateway to my backup internet on OPT1, flushed the state tables and left the for the day. All day long, both IPs continually were sending me packets to random destination ports on my primary WAN not my secondary.
Nevermind its not pfBlockerNG either... I'm at a loss people.
5_KIDS TCP/UDP * * 5_Kids address 53 (DNS) 10.25.10.2 53 (DNS) 4_IOIT TCP/UDP * * 4_IOIT address 53 (DNS) 10.25.10.2 53 (DNS) 3_WORK TCP/UDP * * 3_Work address 53 (DNS) 10.25.10.2 53 (DNS) 2_WIFI TCP/UDP * * 2_WiFi address 53 (DNS) 10.25.10.2 53 (DNS) 1_LAN TCP/UDP * * 1_LAN address 53 (DNS) 10.25.10.2 53 (DNS)0 /0 B IPv4 * * * 204.61.216.50 * * none LAN 1 /5.05 MiB IPv4 TCP/UDP * * 10.25.10.2 53 (DNS) * none NAT DNS Redirect 0 /0 B IPv4 TCP/UDP 1_LAN address * ! RFC1918 53 (DNS) * none -
It's probably a DNS reflection attack. So he may not be directly compromised but just have DNS servers vulnerable to that.
Steve
-
@phlmike said in Odd dns replies from ARIN and now another server:
sending me about 400-500 DNS replies a day that pfSense is blocking
Could you post what your seeing exactly for these blocks
;; ANSWER SECTION: 53.60.10.200.in-addr.arpa. 0 IN PTR d.in-addr-servers.arpa.that server is a Reverse Zone (PTR) ns.. if you did a query for a PTR, you would/could see traffic from that IP, etc..
;; QUESTION SECTION: ;in-addr.arpa. IN NS ;; ANSWER SECTION: in-addr.arpa. 3600 IN NS e.in-addr-servers.arpa. in-addr.arpa. 3600 IN NS f.in-addr-servers.arpa. in-addr.arpa. 3600 IN NS a.in-addr-servers.arpa. in-addr.arpa. 3600 IN NS b.in-addr-servers.arpa. in-addr.arpa. 3600 IN NS c.in-addr-servers.arpa. in-addr.arpa. 3600 IN NS d.in-addr-servers.arpa.While you might redirect traffic from your clients to use pihole which does dot to quad9, something on pfsense that wanted to look the the ptr that psfense saw.. Would talk to these servers, etc What is odd is that they would be blocked if you created the traffic. What exactly is blocking them - are you running IPS? But there are many things that could be doing a PTR query. For example clicking an IP in your firewall log to resolve would do a PTR - what packages are you running that could be doing ptr queries? Something like ntop for sure could be doing PTR queries for example.
-
@johnpoz
While I do RNDS lookups, nowhere near 400-500 per day. It is my home network. The issue is I cannot see anything going outbound, even when creating a rule to log traffic to that IP. I can't have traffic coming in without corresponding traffic going out.The only system that sends DNS traffic is my pihole server at 10.25.10.2 and that talks out of an IPSEC tunnel to a datacenter I have where it talks to the internet.
Unless PFSense is doing RDNS lookups, but then wouldn't I be able to at least see that traffic and why would the responses be blocked?
I only have pfBlockerNG installed. I tried disabling it. They kept coming in. I also switched my default gateway to my backup internet and those packets still came in on my regular internet - even after a state flush.
-
@phlmike said in Odd dns replies from ARIN and now another server:
why would the responses be blocked?
That is the question for sure.. Reset of states come to mind? Traffic being seen on wrong interface is another.. Are you using multiple wans, do you have some sort of vpn?
Without some more details of the setup its hard to say - but I agree, see blocks for traffic you created is odd. But those IPs wouldn't be just sending you traffic out of the blue..
even after a state flush.
That for sure would cause such blocks to be seen in the log.
What packages do you have installed - I know ntop can and does ptr queries.
edit: Some clue might bee gleaned from sniffing the traffic and seeing what the actual response that is being sent to you.. this would show you in what IP range the PTR is being done for, etc.
edit2: for example here I just tried to resolve some IPs in my firewall log, and you see I send traffic to that 200 IP you mentioned
-
@johnpoz
But would it happen hundreds of times a day? I normally only look at my firewall a few times a week, I'm not doing more than 2 IP lookups if that.If you want I can send you a config privately. The TLDR is, I have two internet lines with failover only (packet loss and high latency) and I have 4 IPSEC VPN tunnels and I report to two Dynamic DNS services (I did however disable those for a day each, no change). I also have 4 vlans. It's an SG-3100.
The same thing with the gateway change, I flushed all open states and then left for the entire day, at least 7 hours. For all 7 hours I had continuous hits to my primary wan. Over 100.
Edit: I know she runs a bit warm. I had taken out the vent fans in the rack for the winter, the bearings went and they were making noise. I have the new ones, but it was cold in my basement so I didn't get around to it. Then spring rolls around and 80F temps. I'll have the fans in the rack by today. 70C shouldn't hurt an ARM.
-
@phlmike normally pfsense shouldn't be just doing ptr lookups for any IP - and even if it did, responses shouldn't be blocked.
What packages do you have installed - do you happen to have a packet capture running? There is a setting when you do that where it would do a ptrs, but than again the response shouldn't be blocked.
If I had to guess - with your multiple interfaces for wan, for whatever reason I would "guess" that the response is coming in a interface pfsense doesn't expect..
Even though UDP is stateless - pfsense does track them.. And you should see a state for for where you sent a query, they might not last long, etc.
-
@johnpoz
I only use pfBlockerNG. Period.I am not running any capture currently and I do not see that checkbox for reverse DNS lookup, what menu is that under?
-
@phlmike under the packet capture menu
-
@johnpoz
Yep! unchecked! No capture running. I think @stephenw10 hit the nail on the head.I had email exchanges with the person who runs the network that the server is on as well as the CTO of ARIN itself. I intentionally left out my IP addresses. The torrents stopped yesterday. I just said "hey, I think its a DNS reflection Attack" and no mention or logs with my IP. I swapped out my IP for "redacted" on snippets I did send. My email comes from Office365 through OWA. Zero IP leakage.
Just saying that would be the coincidence of the century.... :-)
Thanks for the help! As always much appreciated.
-
@phlmike said in Odd dns replies from ARIN and now another server:
I only use pfBlockerNG
A quick google for pfblocker and PTR seems to point to it doing them.. I don't use most of pfblocker functionality - I only use to mange some aliases via geoip and other lists for native aliases.
Nor have I noticed any sort of blocks from dns root or gltd or in-appr servers.. But if I had to guess it prob related to that.. flagging @BBcan177 as he would be the guy to when and how pfblocker might do ptrs.. But even if was doing them the responses shouldn't be blocked unless issue with states or the answer coming in on on some interface pfsense doesn't expect the answer to come on
