DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times
-
@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
or is this screenshot suffice to say it's disabled.
That's fine, I just didn't see a response above. Before 23.01 forwarding + DNSSEC didn't seem to be a problem but after 23.01 it often is.
There's a checkbox in the resolver settings to forward but if DNSSEC is disabled that point is irrelevant.
-
@SteveITS Happened again this morning. Though just for my wife. She got DNS_PROBE_FINISHED_NXDOMAIN error in chrome but said the amazon link worked (so weird) but I did not experience any issues by the time i got a browser opened. This is the log for around that time:
I did notice that attack from 180.101.88.225 with a Level 10 a LOT in the logs, is it possible my firewall has misidentified some of my devices as attackers? But then quickly resolves that's wrong before making the same mistake again soon?
-
@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
180.101.88.225 with a Level 10 a LOT in the logs, is it possible my firewall has misidentified some of my devices as attackers?
misidentified ?
It's 180.101.88.225. No doubt about it.
It that IP coming from your LAN ? Disconnect it, have it cleaned. Do have a talk with the owner.
Is the IP coming from the Internet ? Empty the WAN firewall rule list, and you're good. I would fire the pfSense admin
edit : no LAN IP, whois told me "180.101.88.225" is Chinese allocated.
Rip out your WAN cable now. We'll talk later ^^ -
@RickyBaker the “now monitoring attacks” is logged whenever a log file rotates so is normal.
The logged attacks though do indicate you have port 22 open on WAN, and check for other ports too, as that’s a good way to get hacked.
-
@SteveITS so close port 22 immediately?
-
@RickyBaker I'd close all ports on WAN that are not needed. By default WAN has no rules so all incoming traffic from the Internet is blocked.
-
@SteveITS I certainly did not intentionally leave any ports open...Am firing up my VPN now...These logs are saying this IP is TRYING to access my network, not accessing it though right?
-
@RickyBaker
Not "closing".
Don't use any firewall rules that allow SSH access (port 22) or actually any access on the WAN interface.
Exactly like the way you found it, when installing pfSense.
No rules on WAN = safe.
Opening port 22 = "China" (the entire planet in reality) is lining up for you to 'try'.There is an exception (as always) :
If you activate a VPN server (on pfSense), this will, by default, allow UDP traffic on port 1194 on the WAN interface.
If you need to access resources from the outside = WAN, use a VPN, or comparable. -
@Gertjan said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
There is an exception (as always) :
If you activate a VPN server (on pfSense), this will, by default, allow UDP traffic on port 1194 on the WAN interface.
If you need to access resources from the outside = WAN, use a VPN, or comparable.I do! there's always the concern i messed up during set up, but that was the intention. checking now
-
f#$k this looks wide open. i dunno how that happened it says it comes from OpenVPN wizard. Is this wrong? Should Destination port be changed from asterix to 1194?
-
@RickyBaker
also, DEF didn't put in this rule, that ip address is my Synology box, think it added this rule via UPNP? -
@RickyBaker I would guess, it was edited at some point and the description remained. If you look at the rule without saving it, it will show a created and last saved date at the bottom.
Yes it should be 1194 UDP.
The floating rule could be from traffic shaping? (per the m_P2P text)
-
@SteveITS this look right then?
disabled the floating rule and made this change and still have access to the pfsense remotely so seems to not have broken the openvpn connection, thank you for the confirmation.
I would LOVE to do traffic shaping but I have not actually attempted it in many years and recently redid all the rules to add VLANs so i'm very puzzled by this (I also don't even use the Synology really) but you are absolutely right that qP2P sure looks like a traffic shaping effort...very disconcerting
-
@RickyBaker yes that looks better and will not allow connections to 22/80/443.
What is the date on the floating rule? (bottom of the edit rule page)
-
@SteveITS that's it, Created and Updated 2/4/17 by Traffic Shaper Wizard. That was pre kids and pre VPN. Thanks for teaching me that trick. happy to just disable, possibly just delete
-
@SteveITS thanks so much for your help with this. Assuming for the best that the attacker was not able to gain access, what is my next steps? Could this have caused my weird DNS/DHCP problems or is this just a "happy" coincidence that y'all helped me find this vulnerability.
Currently tracking down the 4 DHCP leases that aren't statically assigned. FIgured out 2 of them, need to google Part II research for the 3rd and the 4th was idle so i just booted it
-
@RickyBaker I think it's just a coincidence but a fortunate one.
Is there anything notable in the DNS Resolver log when the outage happens?
-
The final device has this mac address manufacturer. The most common device seems to be a Dreo fan (which I don't have). Googling isn't ringing any bells and pointing to the IP address doesn't give me a splash page or anything. Any advice on blocking just this mac address so I can see what breaks?
@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
Is there anything notable in the DNS Resolver log when the outage happens?
Surprisingly sparse....
-
@RickyBaker the DHCP log seems like all the same as well:
-
@RickyBaker if your DNS outage wa around 6:26-6:40 and you have DHCP set to register leases in DNS, unbound would have restarted a bunch of times there.
re: MAC, it has to be something on the network. You could find its IP on the Status/DHCP leases page and create a rule on LAN to block (or allow, and/or log) it.
