pfBlocker reverse IP lookup on AD DNS
-
Hi I run similar commands to yours and I can see that it is talikng with my AD DNS to get response also Domain override had the correct IP address configured. I also tried DNS Lookup under the Diagnostics in the web configurator and there it will resolve the IP address to actual machine name.
As I said in my initial post Suricata is also able to resovle the IP address but not pfblocker -
@nicesub said in pfBlocker reverse IP lookup on AD DNS:
is also able to resovle the IP address but not pfblocker
Well pfblocker if it was going to resolve anything would just be asking unbound.. Because you don't see the name logged, maybe pfblocker has no option doing the query in the first place.
Like the firewall log, you have to click the little button to get it to try and resole something.. I don't use pfblocker in a manner that would ever log some clients IP anyway.. So not exactly sure where your looking - can you post a pic of what your looking at you feel should resolve?
Are you talking like here
I don't think pfblocker is doing a dns query for those, looks like its pulling it from the description or like the host name on a reservation or a what the client resported itself via dhcp lease.. They are not fqdn, so sure doesn't look like dns query.. If it was doing a dns query - then it would show what unbound returns when you do the query.
See that 192.168.9.100 up there what was showing (), I just added a description to that and it picks up the description name..
-
@johnpoz
Hi,
So for example here:
See how under SRC it just says 192.168.0.16 but not the name of the machine.
But for example here you can see that it will give the name for external IP:
So I only have issue with internal IPs getting resolved by pfblocker.
-
-
The issue is "AD DNS" is never used.
the code for the "report(s)" does not actually lookup the reverse. It builds up a "report cache" of local IP addresses, and then only looks to see if their names are in various tables
by putting just one entry on the Host Override table (with a description) and it will show that description on the report.
It is doing this on the basic assumption that if it is a pfSense itself would be making the request, it will not pass the DNS reverse upstream to external server as they would never know the answer. So a DNS request is not actually used.
That is to say that the entire function pfb_collect_localhosts only builds the report's cache of local names based on DHCP, DHCP Static, Overrides NAT IP and VIPs addresses and the "name" is then derived based on what is in each associated files.
Easy to fix. (code change)
-
So if I got you right, what I am expecting of pfblockerng is not doing it by design and it would require code update do to the reverse lookup on DNS.
I know I could list individual hosts in pfsense DNS resolver but that would be a chore to maintain as things are in reality dynamic.
I guess I will have to live with it.
-
@nicesub said in pfBlocker reverse IP lookup on AD DNS:
is not doing it by design
well now that is an interesting question
in this case, the design is not looking up the name by using DNS at all, but rather, by using the values in various table entries to obtain list of local IP <-> names that exist "right now" a report "cache"
it checks DHCP, DHCP Static, Host Overrides, NAT IP and VIPs and builds the local hostnames lists from that, but it never actually does a DNS lookup at this point. This is why specifically adding a host override (with a description, as that's the field it uses) displays on the reports.
The reports then just look in the array of IP/Names that has been pre-built and uses the names it finds (if any)
Part of the issue here is that all the IP's have to exists in one of the tables at the time the list is built or there will be no entry for the report to map to.
a) at report time, you would have to reverse lookup every potential IP at the time the list is built. (yes overhead "fill in the blanks" for those IPs not already in the entries previously added to the list, by the current address. But also the risk they no longer exist in DNS either.
b) although likely a rare case, DHCP addresses could move.. or a machine is online records some data and then goes offline with the IP given to a different system. Consider a series of report data that is recorded with local IP "1.2.3.4" named "bob"
time passes and "1.2.3.4" becomes "larry" you now run the report. anything previously recorded as "1.2.3.4" when it was "bob", would now be reported as "larry". This is not correct for those records recorded before the name changed. For the most part External IP/Names are recorded in the raw data at point in time, local IP/Names are not (they are only mapped, based on what is current at the time the report is displayed).Flaw or Design ?
IMHO, just like external IPs are recorded IP/Name at point of time, Local IP/Name should be recorded in the same fashion. That's a much bigger change considering the number of data points it touches.
One approach I had considered (just for the illusion it is working), was at report generation time: was that if there is no local hostname attempt to look it up and add it to the list. So it only gets looked up one time. From that point on every "like" IP on the report uses the same Name from the "list" the same as those added in the existing function. This works fine for anything in the DNS that currently has a reverse. This is a better approach to "a)" as you only lookup the ones that are actually on the report and only the first time they appear, but doesn't resolve "b)"
you can see this in for example the ip_permit, ip_block or any of the raw logs the system later reports on
looking at any given record, you will notice that both the remote and local IP address are recorded, but only the remote address is resolved and has the name (or unknown is there is no PTR) recorded/stored with the raw record. Any report generated later there is only best guess as to what the name of the local IP address was at that point in time.
the Issue actually gets much worse if you are sending the data to a syslog, and doing any reporting there, because over the much longer time frame that data exists, the likelihood of the local IP/Name combo changing is significantly greater. It requires every source record to contain the External IP/Name AND Internal IP/Name at the time the raw record is created. That is not currently the case.
At the end of the day, I just decided it is what it is, and live with it.
-
thank you for your lenghty reply. To be honest I fully agree with you that over time what was "bob" can become "larry" and hence what I expected would potentially be of limited use in some cases.
Reason why this behaviour bugged me is I was not sure if it is due my faulty configuration or some wierd bug so I just wanted to get to the bottom of it.
Other then that, as I am setting up pfblocker, someone at home comes to me and says "XYZ" is not opening on iternet so when I open the reports to see what is being blocked I do not know where to start from so first I have to run nslookup manually to be able to filter the reports. :)
Overall this is fair system and I am quite happy as it makes internet browsing much cleaner when you get rid of all the pop ups.
-
says "XYZ" is not opening on iternet
XYZ being an external address.
you might also look at
Status -> System Logs -> Firewall -> Normal Viewfilter as appropriate, if required then
the "i" will reverse either for you or say "cannot resolve" if there is no PTR record.
If it happened hours ago,
have them try XYZ again, then just refresh the Normal View after it has been attempted)But even if it doesn't resolve, this view will also have the rule name and Tracking number. So you know where to look next.
-
Thank you
