Some root-servers.net capitalised

doktornotor

Same results, initially it talks to the 1st fw's DNS server, then it proceeds to talk to the root servers again.

When you have this set to

Outgoing Network Interfaces = Wan only

then it's hardly surprising it won't query another FW on your LAN or god knows where. Sigh.

So do you know what other setting changes I should make to the 2nd fw in order to stop unbound/DNS Resolver from talking to the root-servers.net and just use the DNS servers from the 1st fw?

Sure. Disable the DNS Resolver and kindly use the fine DNS Forwarder. It's there for exactly this purpose, plus won't overwhelm you with settings – preventing you from creating stupid configurations and shooting yourself into the foot repeatedly.

@firewalluser:

I still havent found any reason for the capitalised G & M.root-servers.net though, but I have not packet captured them to see if they go out on the net like that or not.

No, they do not go OUT like that. They come BACK like that when you resolve the PTR of the root server's IP address. Get some more tinfoil.

P.S. Kindly post a screenshot of the freaking settting if you are going to "debug" your "issues" in future. Absolutely NOT interested in wading through the messy descriptions.

firewalluser

@doktornotor:

@firewalluser:

Same results, initially it talks to the 1st fw's DNS server, then it proceeds to talk to the root servers again.

When you have this set to

Outgoing Network Interfaces = Wan only

then it's hardly surprising it won't query another FW on your LAN or god knows where. Sigh.

Maybe I didnt explain how its laid out properly.

Internet –>fw1---->fw2---->Lan
fw1 runs unbound
fw2 runs unbound and I know I could run the forwarder here as I could also do on fw1.

@firewalluser:

So do you know what other setting changes I should make to the 2nd fw in order to stop unbound/DNS Resolver from talking to the root-servers.net and just use the DNS servers from the 1st fw?

Sure. Disable the DNS Resolver and kindly use the fine DNS Forwarder. It's there for exactly this purpose, plus won't overwhelm you with settings – preventing you from creating stupid configurations and shooting yourself into the foot repeatedly.

Well I'll give this a go tomorrow now, but I wanted to keep unbound in the loop as this is running on the main fw anyway and I'm trying to establish the states not blocking or rejecting properly in my other post.

In order to test/debug anything, its generally recognised the environment/settings are kept as identical as possible when trying to recreate problems.

I didnt think unbound would for some unexplained reason so far, still insist on talking with the root-servers unless maybe there is a bug somewhere in pfsense or the unbound package or incorrect settings. Despite your settings, unbound still insists on talking to the root-servers at which point you suggest using the forwarder.

@firewalluser:

I still havent found any reason for the capitalised G & M.root-servers.net though, but I have not packet captured them to see if they go out on the net like that or not.

No, they do not go OUT like that. They come BACK like that when you resolve the PTR of the root server's IP address. Get some more tinfoil.

I'm not saying they go out like that, I'm asking why do those two appear capitalised in the pfsense fw logs?

P.S. Kindly post a screenshot of the freaking settting if you are going to "debug" your "issues" in future. Absolutely NOT interested in wading through the messy descriptions.

Sure.

@doktornotor:

Are you on LSD? The only thing I modified here was moving the 0x20 P.S. to a new post – since you meanwhile posted another post.

In response to the above, I've been thinking about this, hypothetically speaking, if I was subjected to a MITM attack with code injection changing what you had typed when I saw it earlier today, this is not unlike SQL Injection when taking down/over SQL Servers, & we know MITM is possible when considering this coincidental post from earlier today. https://forum.pfsense.org/index.php?topic=94838.0

So with that in mind, it then prompted another question. How would we know ESF have not had their certs nicked?
How does one go about proving that little conundrum other than reissue some new ones and send out an alert?

I think its a pertinent question considering todays news about the US Govt employee db hack that goes back to 1985, it makes you wonder what the NSA are doing to protect their infrastructure and made me wonder about ESF servers which last time I checked was based in Texas.

I've still got other questions based on what you have said which seems to contradict my interpretation of the online docs but I'll see if we can actually get unbound to not talk with the root-servers first.

doktornotor

@firewalluser:

I'm not saying they go out like that, I'm asking why do those two appear capitalised in the pfsense fw logs?

God almighty. Because whatever server your are quering for the PTR returns them like that. Period. And it's not even the LOG. It's the IP being RESOLVED in the WebGUI because you clicked the i to do so. Stop clicking there and the CAPS "pattern" won't bother you.

Out of this conspiracy idiocy, enough time wasted.

firewalluser

@doktornotor:

@firewalluser:

I'm not saying they go out like that, I'm asking why do those two appear capitalised in the pfsense fw logs?

God almighty. Because whatever server your are quering for the PTR returns them like that. Period. And it's not even the LOG. It's the IP being RESOLVED in the WebGUI because you clicked the i to do so. Stop clicking there and the CAPS "pattern" won't bother you.

Out of this conspiracy idiocy, enough time wasted.

@doktornotor:

They are all capitalized. ftp://ftp.internic.net/domain/named.cache


 unbound-control -c /var/unbound/unbound.conf list_stubs
. IN stub prime M.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 2001:dc3::35 2001:500:3::42 2001:7fd::1 2001:503:c27::2:30 2001:7fe::53 2001:500:1::803f:235 2001:500:2f::f 2001:500:2d::d 2001:500:2::c 2001:500:84::b 2001:503:ba3e::2:30 202.12.27.33 199.7.83.42 193.0.14.129 192.58.128.30 192.36.148.17 128.63.2.53 192.112.36.4 192.5.5.241 192.203.230.10 199.7.91.13 192.33.4.12 192.228.79.201 198.41.0.4

As for patterns, try more thick tinfoil.

When I run unbound-control -c /var/unbound/unbound.conf list_stubs in the gui command prompt I see what you see, ie they are all capitalised on the 1st fw which is running unbound. I cant say about all the ipv6 addresses as they go off the screen, but the below is identical to what you have posted.


. IN stub prime M.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET.

I cant see any reason why a program code would selectively just capitalise the G & M root servers when the above command shows they are all capitalised and yet the system fw log in the gui, shows all the ip addresses I've looked at over and above the root server ip addresses as lower case. It doesnt seem logical. If you dont know, say so, I'll keep digging to find out why as it seems odd.

Edit. I should add to be clear I run this command on fw1, not the virtual fw2.

Derelict

On your pfSense you will find the drill command. It is from the same people who brought you unbound. Using it to find out which name servers are returning what values would be a good exercise in learning to use it.

(Are you just sitting around looking for shit to complain about?)

doktornotor

@firewalluser:

yet the system fw log in the gui

It's NOT in the fsckin' log. It's being resolved (!!!) by the webgui when you click the I icon… By the DNS server that happens to gets queried for the x.x.x.x.in-addr.arpa. Kindly do some Google on PTR/reverse DNS records, instead of this conspiracy bullshit.


# dig @8.8.8.8 33.27.12.202.in-addr.arpa ptr

; <<>> DiG 9.9.6-P1 <<>> @8.8.8.8 33.27.12.202.in-addr.arpa ptr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50919
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;33.27.12.202.in-addr.arpa.     IN      PTR

;; ANSWER SECTION:
33.27.12.202.in-addr.arpa. 939  IN      PTR     M.ROOT-SERVERS.NET.

;; Query time: 134 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jun 06 00:49:34 CEST 2015
;; MSG SIZE  rcvd: 86


# dig @192.168.0.151 33.27.12.202.in-addr.arpa ptr

; <<>> DiG 9.9.6-P1 <<>> @192.168.0.151 33.27.12.202.in-addr.arpa ptr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62637
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;33.27.12.202.in-addr.arpa.     IN      PTR

;; ANSWER SECTION:
33.27.12.202.in-addr.arpa. 86343 IN     PTR     m.root-servers.net.

;; Query time: 2 msec
;; SERVER: 192.168.0.151#53(192.168.0.151)
;; WHEN: Sat Jun 06 00:50:19 CEST 2015
;; MSG SIZE  rcvd: 86


# dig @8.8.8.8 4.0.41.198.in-addr.arpa ptr

; <<>> DiG 9.9.6-P1 <<>> @8.8.8.8 4.0.41.198.in-addr.arpa ptr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38883
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;4.0.41.198.in-addr.arpa.       IN      PTR

;; ANSWER SECTION:
4.0.41.198.in-addr.arpa. 86     IN      PTR     a.root-servers.net.

;; Query time: 127 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jun 06 00:55:01 CEST 2015
;; MSG SIZE  rcvd: 84

What you see is the reply from the DNS server. There's no conspiracy shit nor hidden code nor any similar bullcrap in pfSense! Go ask the admin of the DNS server that you are hitting why they "pattern" with CAPS. Hopefully they'll send some medication to you. >:( >:( >:(


;; AUTHORITY SECTION:
27.12.202.in-addr.arpa. 85809   IN      NS      mango.itojun.org.
27.12.202.in-addr.arpa. 85809   IN      NS      ns-wide.wide.ad.jp.
27.12.202.in-addr.arpa. 85809   IN      NS      ns.tokyo.wide.ad.jp.

jahonix

@doktornotor:

I have better things to do with my life than investigating absolutely irrelevant nonsense.

Obviously.
That's why you are still posting in this thread a couple hours later. ::)

NOYB

@doktornotor:

… I have better things to do with my life than investigating absolutely irrelevant nonsense.

Wish you would go do them instead of carrying on a thread about "absolutely irrelevant nonsense" so that you can make snide remarks.

firewalluser

@doktornotor:

@firewalluser:

I'm not saying they go out like that, I'm asking why do those two appear capitalised in the pfsense fw logs?

God almighty. Because whatever server your are quering for the PTR returns them like that. Period. And it's not even the LOG. It's the IP being RESOLVED in the WebGUI because you clicked the i to do so. Stop clicking there and the CAPS "pattern" won't bother you.

Out of this conspiracy idiocy, enough time wasted.

Trying to find out which server this is at the moment, unbound had a 3 hour fart yesterday after making some innocuous changes yesterday so I gave up getting online, although I was always under the impression all url's were lower case, I must have missed when upper case was allowed or I was supplied incorrect data originally.

Anyway still havent found a way to stop unbound from talking to the root-servers.net or even why I get supplied different root-servers.net to you, so looking through the online unbound information now as ip address permutations are quite variable and sometimes quite unique in some circumstances which generates its own patterns but not LSD related. ;)

I appreciate your perseverance. :)

@NOYB:
@jahonix:

This is educational for sock puppet training. :D

Derelict

JFC. FQDNs are case-insensitive. You guys are on tilt. Get over yourselves.

Derelict

@firewalluser:

@doktornotor:

@firewalluser:

I'm not saying they go out like that, I'm asking why do those two appear capitalised in the pfsense fw logs?

God almighty. Because whatever server your are quering for the PTR returns them like that. Period. And it's not even the LOG. It's the IP being RESOLVED in the WebGUI because you clicked the i to do so. Stop clicking there and the CAPS "pattern" won't bother you.

Out of this conspiracy idiocy, enough time wasted.

Trying to find out which server this is at the moment, unbound had a 3 hour fart yesterday after making some innocuous changes yesterday so I gave up getting online, although I was always under the impression all url's were lower case, I must have missed when upper case was allowed or I was supplied incorrect data originally.

Anyway still havent found a way to stop unbound from talking to the root-servers.net or even why I get supplied different root-servers.net to you, so looking through the online unbound information now as ip address permutations are quite variable and sometimes quite unique in some circumstances which generates its own patterns but not LSD related. ;)

I appreciate your perseverance. :)

@NOYB:
@jahonix:

This is educational for sock puppet training. :D

DNS and BIND. Liu and Albitz.

Buy it. Read it. Learn it. Live it. Else piss the fuck off.

NOYB

@firewalluser:

… I was always under the impression all url's were lower case, I must have missed when upper case was allowed or I was supplied incorrect data originally.

Domain names have always (or at least for a very long time) been case insensitive. Any particular usage of them is free to change or maintain their case.

Case sensitivity of the path portion of URL's is dependent upon the web server.
For instance Apache on a Linux machine will probably be case sensitive. IIS on a Windows machine probably case insensitive.

Derelict

Case sensitivity on the web server is not DNS. DNS is case-insensitive. Read the goddamn RFC.

NOYB

@Derelict:

Case sensitivity on the web server is not DNS. DNS is case-insensitive. Read the goddamn RFC.

I know. But someone brought URL into the conversation so thought I point it out.

Derelict

My patience with @firewalluser is wearing thin. Sorry.

firewalluser

@Derelict:

On your pfSense you will find the drill command. It is from the same people who brought you unbound. Using it to find out which name servers are returning what values would be a good exercise in learning to use it.

(Are you just sitting around looking for shit to complain about?)

Thanks for the heads up on drill, wrt to the other, I'm actually trying to find out how someone changed the password on the hdd which is set in the uefi bios of my Intel D847 pfsense box, this then led me onto the states not blocking/rehect issue which is in another post.

As this is a hw/bios layer before freebsd/pfsense or any other OS, it might be something in the bios thats allowed it, I dont know yet, but I have updated the bios and I have also noted that what it displays in the bios change log is incomplete.

Some bios changes never get logged at all, but switching between the default modern mouse & keyboard driven bios ui and the older dos-like keyboard only bios ui also shows the modern ui omits entrys from that log which appear in the older bios ui log. So it appears Intel have some inconsistency's at least in their bios for the NUC's which might have been exploited by others and demonstrated/targeted at me for some reason. They certainly have a lot of bios updates as others have noted on these boards back around Xmas time for these devices.

As this box was running pfsense I think its a good idea to try and find anything out of the ordinary which might have made this possible and see if there is a way to prevent it from happening again. Otherwise its entirely possible lots of hw could be compromised en-masses should a massive cyber attack occur which takes out lots of business equipment or pwns it at the very least at the hw/bios level irrespective of any OS being installed. I've also established that methods exist which enable the hdd passwords to be reset and/or changed which are set using the bios contrary to manufacturers claims its impossible to reset lost/forgotten HDD pwd's, but to do this whilst a firewall OS was running for just 67days is pretty good talent imo or some bad backdoors/bugs somewhere.

@Derelict:

My patience with @firewalluser is wearing thin. Sorry.

Why? Surely the above and my other posts where I have alluded to the above is justification to ask questions, seek guidance etc?

I apologise if asking questions is the wrong thing to do, but how else do people learn to be more secure if they cant ask questions using the methods provided, namely the forums in this case. I've already had an export license turned down by the UK Govt which took longer than the usual 6 week application process for an answer due to the technology it used and what I had also developed. I've since shut that business down as it was going to be a standalone business and written off the vast amounts of time and money invested in that product. However as I've also had other websites "fail to be available to any websurfers" which was hosted by other businesses, business phones lines not working for weeks so I get no calls due to exchange faults, I feel the best thing to do is learn and do as much as possible in house. As I'm ready to release some new business software for different sectors before I put my website, mail & phonesystem online I need to make sure its secure.

I like pfsense, what attracted me to it was the fact it was running a version of BSD, and the major OS running Bind (I believe its called) that is the root of the whole internet was BSD. 3 of the 5 machines iirc was running this for redundancy. If BSD was good enough to be the major OS for being the root of the whole internet, then surely some of that would be present in FreeBSD and thus pfsense I figured.

I want pfsense to be as good a product as possible, is there anything wrong with that?

And as always I'm always learning, the data we are exposed to shapes our bias, our intellect and even when we do get told something, sometimes the significance doesnt register straight away.

doktornotor

@firewalluser:

I'm actually trying to find out how someone changed the password on the hdd

this then led me onto the states not blocking/rehect issue which is in another post.

As this is a hw/bios layer before freebsd/pfsense or any other OS, it might be something in the bios thats allowed it, I dont know yet, but I have updated the bios and I have also noted that what it displays in the bios change log is incomplete.

So it appears Intel have some inconsistency's at least in their bios for the NUC's which might have been exploited by others and demonstrated/targeted at me for some reason. They certainly have a lot of bios updates as others have noted on these boards back around Xmas time for these devices.

lots of hw could be compromised en-masses should a massive cyber attack occur which takes out lots of business equipment or pwns it at the very least at the hw/bios level irrespective of any OS being installed. I've also established that methods exist which enable the hdd passwords to be reset and/or changed which are set using the bios contrary to manufacturers claims its impossible to reset lost/forgotten HDD pwd's, but to do this whilst a firewall OS was running for just 67days is pretty good talent imo or some bad backdoors/bugs somewhere.

firewalluser

@doktornotor:

@firewalluser:

I'm actually trying to find out how someone changed the password on the hdd

this then led me onto the states not blocking/rehect issue which is in another post.

As this is a hw/bios layer before freebsd/pfsense or any other OS, it might be something in the bios thats allowed it, I dont know yet, but I have updated the bios and I have also noted that what it displays in the bios change log is incomplete.

So it appears Intel have some inconsistency's at least in their bios for the NUC's which might have been exploited by others and demonstrated/targeted at me for some reason. They certainly have a lot of bios updates as others have noted on these boards back around Xmas time for these devices.

lots of hw could be compromised en-masses should a massive cyber attack occur which takes out lots of business equipment or pwns it at the very least at the hw/bios level irrespective of any OS being installed. I've also established that methods exist which enable the hdd passwords to be reset and/or changed which are set using the bios contrary to manufacturers claims its impossible to reset lost/forgotten HDD pwd's, but to do this whilst a firewall OS was running for just 67days is pretty good talent imo or some bad backdoors/bugs somewhere.

Your images are not visible on my machine as it doesnt allow anything from non-pfsense domains through now when I access pfsense domains, so as I was going to reply with a "I dont understand your post do you think its this ie what you have re quoted of mine" I then saw the URLS quoted.

http://www.troll.me/images/y-u-no/thread-y-u-no-lock.jpg
http://www.demotivationalposters.org/image/demotivational-poster/0903/derailed-train-derailed-thread-demotivational-poster-1237346157.jpg

So putting the images aside for a moment, do you think its more likely its the hw level/layer thats been compromised then?

TIA.

doktornotor

I think you already got answer to the TOPIC here (multiple times, in fact). This pfSense forum is NOT the place for your conspiracy nonsense.

firewalluser

Its no longer a conspiracy when it happens to one's self. I guess Snowden is all a fabrication & conspiracy as well and I didnt read it the media, but his reports certainly explains some of whats happened to myself and customers when looking back through support calls.

All a figment of the imagination I guess, and next I'll be renamed Walter Mitty. ::)