DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times
-
@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.
-
@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
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.
per @johnpoz suggestion i have unchecked "Register DHCP", should I re-enable for testing purposes?
@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
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.
good suggestion. I THINK i found it. My wife recently purchased a fancy humidifier that, for some reason, has internet connectivity. So i will confirm when i'm home but that's most likely it...So no errant devices that aren't accounted for aside from the stale lease i booted.
-
@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
i have unchecked "Register DHCP", should I re-enable for testing purposes
No, having it on is unlikely to help here. It's hard to keep track of multiple threads over a few days...
So is unbound no longer restarting? But still the errors? I do not have another idea. Perhaps, on the DNS Resolver advanced page raise Log Level temporarily and see if that provides any info.
-
@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
This is going to restart unbound..
i thought this was fixed last year, no?
