pfSense using unreasonable amount of bandwidth while idle
-
@johnpoz
Well, I don't have RSS feeds, or other such junk going on in the box. and the lookups are showing the source being the loopback. Here are the packages I have installed:
I haven't (side)loaded any other software outside of the package manager, or installed any of my own scrips. I formerly had Suricata installed also, but it wasn't working due to RUST, so I uninstalled it. Although the package manager shows it gone, I still have a few traces of it, indicating an incomplete uninstall.
I also previously installed then uninstalled Acme. To my knowledge, that was a clean uninstallCan tell you for sure if there was something in pfsense out of the box causing this traffic, or even something common... The forums would be blowing up with hey why is there 300K of traffic all the time...
Yeah, instead we have one single, ridiculously long thread...ugh.
So what now? Would it make any difference at all if I take a full backup, do a factory reset, then restore from the backup? I have a feeling that would bring the problem right back. I don't want to reconfigure from scratch, though.
-
well iftop or nmap sure wouldn't be doing it, they don't even run anything unless you run them.
I guess snort could be be doing it? In theory - it could try and look for IPs that hit your wan..
Thought you said you removed pfblocker? I would remove them completely, both pfblocker and snort.. Just to be 110% sure its not them..
But what I can tell you for sure is there nothing in pfsense out of the box that would try and look those such fqdn..
What I would prob do, is do a clean install of pfsense with min sort of setup, an out of the box sort of setup.. And do you get such queries now?
I can tell you for sure my setup isn't doing anything of the sort.. I have logging of all queries turned on in unbound, and see nothing even close to those nonsense lookups.
-
Snort and Suricata do zero DNS queries unless the user manually clicks the designated icon on the ALERTS tab. Neither package does anything on its own with the exception of using
curlto perform the daily rules update check. During that processcurlwill look up the IP for the rules download URLs. However, those lookups are a miniscule amount of traffic. -
I hear yeah - but what else could be doing queries for such nonsense.. Seeing queries like this..
Lots and lots of them, and both A and AAA for just what looks to IPs, but not PTR queries but actual A and AAAA queries for what looks to be an IP.
I would say its some stupid client, but he states he is not doing any dns redirection, and log of the queries in unbound show they are from loopback.
-
There is no code within the PHP package that would do that (save for the
curlreference I mentioned), and I am quite familiar with the Snort binary code and know of nothing in there that would account for such activity.The last time I recall a discussion similar to this with mysterious DNS lookups it turned out to be a logging application of some type that was attempting to convert IP addresses to hostnames.
You know there is a setting on the pfSense firewall logging tab that turns this feature on, but I'm not sure if that is a permanent thing or just active while you have the firewall log tab open. It resolves IP to hostnames (or attempts to).
-
That is a good hint for sure.. You wouldn't be able to recall enough to find this thread where this was happening before? That might be a clue for sure.
I don't recall seeing such a thread.. But so many, and many are just the same over and over they all tend to blend together.
So you think it was something or could have something to do with logging in pfsense, or some package?? Prob the best clue we have had sofar in trying to track this down.
-
@johnpoz said in pfSense using unreasonable amount of bandwidth while idle:
That is a good hint for sure.. You wouldn't be able to recall enough to find this thread where this was happening before? That might be a clue for sure.
I don't recall seeing such a thread.. But so many, and many are just the same over and over they all tend to blend together.
So you think it was something or could have something to do with logging in pfsense, or some package?? Prob the best clue we have had sofar in trying to track this down.
I think it was a year ago or maybe a little more, but I don't recall more than that. My years are catching up with me. My memory has "read errors" sometimes now ...
.Oh, and that Firewall Log thing is actually an icon you click on the page, not a parameter.
-
Looking in all the settings for logging - and I don't see anything that should or could do that.. Unless something really odd going on if sending logs to remote syslog???
@CyberMinion Do you have logs being sent to remote syslog?
Also what about looking in your cron jobs for something? You can install the cron package to get look see to what is in there.
-
Thought you said you removed pfblocker?
I disabled it, but did not uninstall it. Think it makes a difference? I also tried this with Snort at one point btw, and yes, no change.
Looking in all the settings for logging - and I don't see anything that should or could do that.. Unless something really odd going on if sending logs to remote syslog???
I will look around as well
@CyberMinion Do you have logs being sent to remote syslog?
No, local logging only.
Also what about looking in your cron jobs for something? You can install the cron package to get look see to what is in there.
Not a bad idea...The only cron jobs I'm aware of are updating pfblocker's rules periodically. Do you have a suggestion of which package to try for this purpose?
-
Am I correct in thinking the queries you see are the odd-IP-as-FQDN followed by odd-IP-as-FQDN.yourdomain every time?
Is there anything that could be running on pfSense that actually queries like that?
My usual assumption when I see that sort of query pattern is that it's a Windows client.Also, reviewing this, the majority of this traffic appeared to be inbound on WAN. Just the nature of DoT?
Steve
-
@CyberMinion said in pfSense using unreasonable amount of bandwidth while idle:
Do you have a suggestion of which package to try for this purpose?
Yeah the cron package ;)
And yeah I would agree, whatever is doing those queries is messed up... So yeah it would scream some shit software on some windows machine if you ask me as well.
But he insists he is not doing dns redirection, and a windows client on the network would show its actual IP as source vs loopback. The only way to get loopback as the source, is something running on pfsense doing the query, or redirection.. Can you post up your portfowards tab?
Other thing could be proxy running, but he says not running that, etc.
And yeah the queries are adding his domain in a search suffix query, after the query.. After the first query.. Really just at a loss to what would/could be doing it.
I personally would do a clean slate..
And yeah using doh/dot especially when forwarding to multiple ns amounts to a low level dos on yourself when you have something basically looking for nonsense..
None of that shit that is being asked for is ever going to resolve.. Its just asking for nonsense, with extra helping of overhead on top of it, and lets not just ask 1 ns, lets ask them all.. Once the first nx comes back, you shouldn't be asking the next guy ever.. His sniffs are really a constant stream of asking for junk..
edit: I just counted up 1 second of dns queries in on of his sniffs, doing 30 queries a second for utter garbage.. If I filter on just queries in the 78 second long sniff, there are 1740 dns queries or 22 queries a second for the duration of the sniff.. all for garbage that will never resolve.
Forget that its adding his suffix, none of this shit would ever resolve
So what is doing them is the question.. I don't know how to look to see what is doing the query as far as process.. That would be the smoking gun, is to know what is actually asking for this nonsense. unbound is just doing what it was asked to do..
Guess you could try running through
sockstat -4 -p 53doing that trying to catch what process is talking to loopback on 53.. Other than unbound.
-
Someone may have already done this, and I missed it, but ARIN says the netblock 61.125.0.0/18 belongs to NTT-ME Corporation, which is located in Japan. The specific company brand listed is Xephion, which appears to be an ISP.
The 61.124.0.0/16 block of addresses is listed as belonging to Fujitsu, LTD. Specifically it seems to be registered for their InfoWeb service, which also appears to be a Japanese ISP.
-
@stephenw10 said in pfSense using unreasonable amount of bandwidth while idle:
Am I correct in thinking the queries you see are the odd-IP-as-FQDN followed by odd-IP-as-FQDN.yourdomain every time?
It tries to lookup the IP first, then adds the network name as if it was a FQDN, as descrided, and tries getting an A record, then an AAA record.
Is there anything that could be running on pfSense that actually queries like that?
My usual assumption when I see that sort of query pattern is that it's a Windows client.None that I am aware of. It is vaguely possible that a Windows client is triggering the problem, but once this "noise" is going on, no internal clients are needed to keep it going. I've tried pulling the LAN cables out of the box, but the problem continues. Is there any way a client could be triggering this problem, then disconnect and have the problem persist?
Also, reviewing this, the majority of this traffic appeared to be inbound on WAN. Just the nature of DoT?
Steve
Assuming you mean DoH, I did try disabling that, but this problem persisted. It is flowing to and from the WAN port only with nominal if any traffic on the internal ports. DoH adds a little "bulk" to the DNS, but not THIS much...
-
@bmeeks said in pfSense using unreasonable amount of bandwidth while idle:
Someone may have already done this, and I missed it, but ARIN says the netblock 61.125.0.0/18 belongs to NTT-ME Corporation, which is located in Japan. The specific company brand listed is Xephion, which appears to be an ISP.
The 61.124.0.0/16 block of addresses is listed as belonging to Fujitsu, LTD. Specifically it seems to be registered for their InfoWeb service, which also appears to be a Japanese ISP.
Yeah, a number of these seem to be owned by ISPs around the world. Another one it was doing was owned by a Chinese ISP...I blocked that one manually on the firewall, just because.
@johnpoz
Right...what a difficult to guess package name. Here's what I've got for jobs:
It's interesting to me that there are suricata and acme jobs here still.
-
This post is deleted! -
@CyberMinion said in pfSense using unreasonable amount of bandwidth while idle:
@bmeeks said in pfSense using unreasonable amount of bandwidth while idle:
Someone may have already done this, and I missed it, but ARIN says the netblock 61.125.0.0/18 belongs to NTT-ME Corporation, which is located in Japan. The specific company brand listed is Xephion, which appears to be an ISP.
The 61.124.0.0/16 block of addresses is listed as belonging to Fujitsu, LTD. Specifically it seems to be registered for their InfoWeb service, which also appears to be a Japanese ISP.
Yeah, a number of these seem to be owned by ISPs around the world. Another one it was doing was owned by a Chinese ISP...I blocked that one manually on the firewall, just because.
@johnpoz
Right...what a difficult to guess package name. Here's what I've got for jobs:
It's interesting to me that there are suricata and acme jobs here still.
The Suricata and Snort cron tasks should be removed when you delete the package from the firewall using the SYSTEM > PACKAGE MANAGER tab. However, they will remain in place and active if you simply disable Snort or Suricata on the interfaces. But I can guarantee you that neither of those packages is responsible for any of those DNS lookups. Since I wrote them, I know what they can and cannot do ...
-
That was just a very small sample of the IPs.. They are from all over.
I would say its something stupid trying to look up IPs that hit the wan, but its not that for sure.. He is not seeing 22 hits a second on his wan in noise ;)
-
@CyberMinion said in pfSense using unreasonable amount of bandwidth while idle:
DoH adds a little "bulk" to the DNS, but not THIS much...
No it adds a LOT of bulk! But no this is with doh off, and still seeing quite a bit of traffic..
Problem with doh other than the amount of added overhead, is when had that enabled could not actually see what was being queried for..
There for sure is nothing in pfsense out of the box that would be looking for this sort of garbage.. Its not trying to do PTRs on those Ips.. Its doing a normal A and AAAA query for what looks to be an IP.. Doing a normal A query for xxx.xxx.xxx.xxx is not going to return anything almost ever..
There should be nothing that looks for such FQDNs be it the suffix is added or not.. Trying to find a A or AAAA for what looks like an IP is nonsense.. In my little snippet of queries you would be looking for stuff with tld of .136, .207, .243 etc.. those are not TLDs that would ever be valid, ever..
So whatever it is asking for this is broken, borked, something.. Bad coding trying to parse thru a list of IPs maybe? Something clearly F'd up for sure.. Those are never going to be valid queries.. Now possible sure if you added a valid domain as the search suffix, you might find a A record like xxx.xxx.xxx.xxx.domain.tld - but search A for just xxx.xxx.xxx.xxx where that last .xxx would be the TLD is almost never going to be valid. You might be able to run a local NS where .xxx as a number is valid??? But why would anyone do such a thing, and sure never going to be viable on the public
There are no TLDs that are numbers
https://www.iana.org/domains/root/dbSo asking for something like A or AAAA for AAA.BBB.CCC.DDD where .ddd is the tld would never find anything.
Now in nslookup you ask for say 192.168.9.253, but it changes that for you to a PTR, see below the actual query/question that is asked "100.9.168.192.in-addr.arpa"
$ nslookup Default Server: pi-hole.local.lan Address: 192.168.3.10 > set debug > 192.168.9.100 Server: pi-hole.local.lan Address: 192.168.3.10 ------------ Got answer: HEADER: opcode = QUERY, id = 2, rcode = NOERROR header flags: response, want recursion, recursion avail. questions = 1, answers = 1, authority records = 0, additional = 0 QUESTIONS: 100.9.168.192.in-addr.arpa, type = PTR, class = IN ANSWERS: -> 100.9.168.192.in-addr.arpa name = i5-win.local.lan ttl = 3212 (53 mins 32 secs) ------------ Name: i5-win.local.lan Address: 192.168.9.100It doesn't do a A or AAAA query for 192.168.9.100
So whatever is asking for these is bad code? Or something being fed info to do a dns queries the wrong sort of info..
-
@bmeeks said in pfSense using unreasonable amount of bandwidth while idle:
The Suricata and Snort cron tasks should be removed when you delete the package from the firewall using the SYSTEM > PACKAGE MANAGER tab. However, they will remain in place and active if you simply disable Snort or Suricata on the interfaces. But I can guarantee you that neither of those packages is responsible for any of those DNS lookups.
I removed Suricata and acme through the package manager, but SNORT is still installed and active. If it won't cause any confusion with troubleshooting, maybe I'll just remove those jobs manually. Like I said...the Suricata uninstall messed up somewhere, for me.
Since I wrote them, I know what they can and cannot do ...
Nice! Well thank you for writing them, and for the input
-
@CyberMinion said in pfSense using unreasonable amount of bandwidth while idle:
I removed Suricata and acme through the package manager, but SNORT is still installed and active. If it won't cause any confusion with troubleshooting, maybe I'll just remove those jobs manually. Like I said...the Suricata uninstall messed up somewhere, for me.
It won't hurt anything to manually remove them. If the uninstall crashed, that might explain them hanging around. The uninstall routine within the Suricata GUI code specifically calls a pfSense system function to remove its cron tasks. But if the uninstall crashed or was not allowed to complete (by leaving the page prematurely, for instance), then the piece of code that makes that system call would not have executed.
