Some root-servers.net capitalised
-
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: 84What 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. -
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. ::) -
… 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.
-
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. :)
This is educational for sock puppet training. :D
-
JFC. FQDNs are case-insensitive. You guys are on tilt. Get over yourselves.
-
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. :)
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.
-
… 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. -
Case sensitivity on the web server is not DNS. DNS is case-insensitive. Read the goddamn RFC.
-
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.
-
My patience with @firewalluser is wearing thin. Sorry.
-
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.
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.
-
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.
-
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.jpgSo putting the images aside for a moment, do you think its more likely its the hw level/layer thats been compromised then?
TIA.
-
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.
-
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. ::)
