DNS rebind 'attack'
-
well no shit ;) Its not a valid public IP.. Where is the query coming from to your resolver, and what exactly are you trying to do?
-
That's exactly what I'm trying to find out.
There is no clue which interface it is coming on, or 'who' the requesting IP address is - at least then I could isolate the PC or mobile device doing it.
This is the most recent - but it seems to be loop back which I am guessing is the DNS forwarder at work - the originator isn't there.
Oct 10 19:19:01 filterdns: failed to resolve host rzeszow.vectranet.pl will retry later again.
Oct 10 19:19:01 dnsmasq[7076]: cached rzeszow.vectranet.pl.number36 is NXDOMAIN
Oct 10 19:19:01 dnsmasq[7076]: query[AAAA] rzeszow.vectranet.pl.number36 from 127.0.0.1
Oct 10 19:19:01 dnsmasq[7076]: cached rzeszow.vectranet.pl.number36 is NXDOMAIN
Oct 10 19:19:01 dnsmasq[7076]: query[A] rzeszow.vectranet.pl.number36 from 127.0.0.1
Oct 10 19:19:01 dnsmasq[7076]: cached rzeszow.vectranet.pl is NODATA-IPv6
Oct 10 19:19:01 dnsmasq[7076]: query[AAAA] rzeszow.vectranet.pl from 127.0.0.1
Oct 10 19:19:01 dnsmasq[7076]: possible DNS-rebind attack detected: rzeszow.vectranet.pl -
well do a simple sniff on your interfaces for 53 to catch who is doing the query to pfsense.
but you got something else wrong that it doesn't resolve - because clearly it does.
-
Doesn't work - again here's the latest - the information is coming from pFsense itself according to this - this capture came from the LAN
20:19:00.862880 IP 10.100.1.201.33747 > 10.100.1.254.53: UDP, length 37
20:19:00.863221 IP 10.100.1.254.53 > 10.100.1.201.33747: UDP, length 37
20:19:04.706770 IP 10.100.1.247.49308 > 10.100.1.254.53: UDP, length 46
20:19:04.807304 IP 10.100.1.254.53 > 10.100.1.247.49308: UDP, length 76
20:19:06.846506 IP 10.100.1.201.2770 > 10.100.1.254.53: UDP, length 37
20:19:06.846750 IP 10.100.1.254.53 > 10.100.1.201.2770: UDP, length 53
20:19:14.448190 IP 10.100.1.247.52720 > 10.100.1.254.53: UDP, length 33
20:19:14.482650 IP 10.100.1.254.53 > 10.100.1.247.52720: UDP, length 72and yet these are the messages
Oct 10 20:19:04 dnsmasq[23110]: forwarded www.electricsheepfencing.com to 208.67.222.222
Oct 10 20:19:04 dnsmasq[23110]: query[A] www.electricsheepfencing.com from 10.100.1.247
Oct 10 20:19:01 filterdns: failed to resolve host rzeszow.vectranet.pl will retry later again.
Oct 10 20:19:01 dnsmasq[23110]: cached rzeszow.vectranet.pl.number36 is NXDOMAIN
Oct 10 20:19:01 dnsmasq[23110]: query[AAAA] rzeszow.vectranet.pl.number36 from 127.0.0.1
Oct 10 20:19:01 dnsmasq[23110]: cached rzeszow.vectranet.pl.number36 is NXDOMAIN
Oct 10 20:19:01 dnsmasq[23110]: query[A] rzeszow.vectranet.pl.number36 from 127.0.0.1
Oct 10 20:19:01 dnsmasq[23110]: cached rzeszow.vectranet.pl is NODATA-IPv6
Oct 10 20:19:01 dnsmasq[23110]: query[AAAA] rzeszow.vectranet.pl from 127.0.0.1
Oct 10 20:19:01 dnsmasq[23110]: possible DNS-rebind attack detected: rzeszow.vectranet.plit doesn't resolve either - I don't own the ip-tracker site I merely report what it does. There are a few sites that 'resolve' but they simply show the information that you did - truncated - they do not show rzeszow only the parent and associated DNS servers.
DNS Records – VECTRANET.PL
Record Type TTL Priority Content
vectranet.pl MX 1 day 4 vnet.vectranet.pl
vectranet.pl NS 1 day dns2.vectranet.pl
vectranet.pl NS 1 day dns3.vectranet.pl
vectranet.pl NS 1 day dns1.vectranet.pl
vnet.vectranet.pl A 1 day 95.160.170.125 ()
vnet.vectranet.pl AAAA 1 day 2a00:9f00:a:3::125
dns1.vectranet.pl A 1 day 109.241.239.11 ()
dns1.vectranet.pl AAAA 1 day 2a00:9f00:1:3::11
dns2.vectranet.pl A 1 day 88.156.222.22 (Suwalki, 61, PL)
dns2.vectranet.pl AAAA 1 day 2a00:9f00:0:3::22
dns3.vectranet.pl A 1 day 95.160.170.95 ()
dns3.vectranet.pl AAAA 1 day 2a00:9f00:a:3::33
vectranet.pl SOA 1 day dns2.vectranet.pl. dns.vectranet.pl. 1557 28800 7200 604800 86400
mail.vectranet.pl CNAME 1 day vnet.vectranet.pl
www.vectranet.pl A 1 day 88.156.222.94 (Suwalki, 61, PL) -
those queries are not from pfsense
20:19:00.862880 IP 10.100.1.201.33747 > 10.100.1.254.53: UDP, length 37
20:19:00.863221 IP 10.100.1.254.53 > 10.100.1.201.33747: UDP, length 37download it and open in wireshark so you can see what the query is.. That looks to be from 1.201 asking pfsenes 1.254 for some dns query..
But I would look to see why pfsense can not resolve it - where are you forwarding too, your isp? Do you have any over rides in place, ns overrides as well?
-
No don't have any overrides at all in place.
The only thing that I do is enforce the 'no unauthorised' DNS rule. I force all local clients to resolve via the pFSense which then utilises 208.67.222.222 or 208.67.220.220 (OpenDNS). I don't have any restrictions really set in OpenDNS currently since there is nobody living here that I want to keep under control any more - kids have all gone.
I maintain this to keep rogue applications under control, and it looks like there is one trying to do something 'nasty' - there is nothing present in my network that should be trying to connect to a server in Poland - especially via DNS.
The clue is in the way it has tagged on my 'local' domain / workgroup - or has pFSense done that because the 'original' wouldn't resolve
rzeszow.vectranet.pl.number36
which obviously will never resolve, and since I don't have a machine with a zeszow.vectranet.pl name, and my domain certainly isn't vectranet.pl.number36 - but this says the request is internal.
Now here's the kicker - .201 is my aquarium controller …. runs an embedded OS, isn't accessible to anyone but me, and shouldn't be trying to access the outside world although it does connect to my SQL server to store data. The internal address if pfSense is 1.254.
I have pFSense configured to block 'require domain' for external DNS requests.
What I really want is to find the guilty party that is doing this, it would help so much if when the 'rebinding' attack is detected that more specific information was stored - requester IP and MAC address would be of enormous use right now. Packet captures and then trying to link the two together is a pain in the hole.
-
again just sniff your traffic download it to wireshark and see what is doing the query. something on pfsense clearly wouldn't be doing a query for that… So it must be something on your network asking for it.
as to the number36, that is your local domain? yes all clients normally walk up the tree with their suffix searh.. Yeah quite possible for the local domain to get added to the query.
bit confused with how you worded this
"I have pFSense configured to block 'require domain' for external DNS requests."
Do you mean you have it checked or unchecked? Normally this would be checked.. so your not asking opendns for "hostname"
"If this option is set, pfSense DNS Forwarder (dnsmasq) will not forward A or AAAA queries for plain names, without dots or domain parts, to upstream name servers. If the name is not known from /etc/hosts or DHCP then a "not found" answer is returned. "
So your saying you sniffed all your dns queries from your network, and then opened in wireshark and see no queries for this?? And wireshark is logging this error while you were sniffing?
-
Pretty much yes. I have the 'require domain' option checked. I've loaded it in wireshark but can find nothing with that damn web url in it, going to return to this tomorrow I think.
-
Well I have been capturing all day, on three different interfaces, I've even been listening to all local traffic directly via wireshark …
and this stupid 'url' doesn't appear anywhere 'this' PC, my web server and the firewall are all that is left enabled / connected.
STILL the event is reported in the resolver log - I am forced to state that this 'event report' is USELESS - it provides no real clues where the source of the event is, it must know because it detected the request, so it must know where it came from, packet capture has so far failed utterly to identify information that clearly pFsense is seeing but is failing to report sufficient detail to identify the culprit.
The Linux community may think that it's OK to waste an entire day hacking around and packet capturing looking for something that should be included with the event by default - I'm afraid that I don't.
Think I may need to set up an internal MS Server based DNS box with Wireshark on it and route everything through it to nail this issue down.
-
filterdns and dnsmasq are two entirely unrelated components, aside from the fact dnsmasq will resolve filterdns's queries. Since it's in filterdns, you're using that FQDN in an alias, which it then has to resolve, which fails by default because it resolves to a private IP. If you don't want it to do lookups on that, don't configure it in an alias (where it has to do lookups).
-
Kind of misses the point - I don't want that URL - it isn't in an Alias - well it wasn't - it is now - a block alias.
My issue is that I want the 'reporter' of the 'possible binding attack' to be a little more verbose - the information provided is as useful as a message that says 'an error occured' … oh really - care to say what in or where.
There was no trace of the URL in question anywhere on my LAN - 18 hours of packet capture and not one instance - and yet pFsense continued to report it. I captured using pFSense AND Wireshark 1.12.
Since the URL could not be detected on the LAN the only place it could be was on one of the 'external' connections of which I have two, but packet capture on those was also unrevealing, either way the source of this URL was NOT internal so it was either external or my pFSense box had been compromised.
The minute I disabled the DNS forwarder the offending 'URL' miraculously and instantly appeared in the block table - how ???.
So not only was this issue internal in pFSense but whatever it was prevented the URL from being placed into the block table. I have been getting a lot of probing / harvesting attacks on our e-mail server for the last week, may or may not be related - postfix may stop unapproved mail but it doesn't stop login attempts - and our e-mail server is stupid - it actually responds 'no such user' or 'incorrect password' - I wish it would just stay silent !!
Either way IMHO the culprit is / was pFSense or at least the box it is on, I've since 'rebuilt' it from scratch with new ISO and also re-entered all data from an 'edited' xml restore. I was chasing a ghost, by adding the URL to an alias in an attempt to block access to it I 'perpetuated' the potential rebinding attack' report.
I have since transferred all DHCP and DNS services to an internal MS based server, all communication in and out of that server is going through wireshark, it is the only device on my LAN permitted to make DNS requests outside the firewall and even then only to my two designated DNS servers, so far the offending 'URL' has not resurfaced. My only issue with that of course is that for pFSense to check for updates it needs a public DNS - something that I'll let it have once a week. I could find no way to point pFSense at an internal DNS box (on LAN). Whatever tried to use the URL is going to get found if it raises its head again.
Perhaps I should add 'verbose reporting' on DNS as a feature request.
-
Oct 10 19:19:01 filterdns: failed to resolve host rzeszow.vectranet.pl will retry later again.
DOH!!! CMB hit it right on the head - you must be feeding it to dnsmasq somewhere..
Did you download your config xml and search in it?? Could be lots of different places. endpoint for vpn, captive portal settings, etc. Somewhere it tries to get resolved.
-
He did indeed - I was as I said chasing a ghost, I'd already spotted it - BUT
I only put the URL into an alias because it was getting reported by 'something', at the time I didn't have 'log_queries' enabled so I didn't know where from. I don't tolerate 'unknown' behaviour within my network so my first response was to add the URL as an entry in a block table - I have a bad boy table that I use to block 'bad behaviour' sources and targets - spammers that aren't in another blocklist, multiple chinese sites, people that try to log into my mailserver multiple times with multiple users from same IP etc etc.
When I saw the constant 'dns rebinding' the first thing I did was to put it into this 'block table' - while I searched for the culprit, the culprit has not been found on my local LAN despite 18 hours of packet capturing, I am still running wireshark with the url as a filter - but on the DNS / DHCP server that I created where it isn't such a pain to 'start capture, stop capture, download - - yada yada'.
I also completely rebuilt pFSense in case it had been compromised, and so far this URL doesn't appear anywhere so I have kind of fixed the issue but not in the preferred manner, it would have been nice to know who was originating the request that prompted me to 'block it' in the first place.
I would expect that where a URL does resolve to a private IP that the bogon filters should deal with it, where an IP generates such an event the system shouldn't keep re-trying but should put it into some 'holding place' for investigation - and should provide sufficient information to give the investigation a place to start - i.e. source Network, source IP, source MAC, date, time.
Every one gets retarded about stuff getting in - 80% of security breaches are caused 'internally' by users - so events noted by things trying to get out must carry even more weight / priority.