website security problems

johnpoz

@jc1976 said in website security problems:

i ended up canning squid/clamav

Ah you were running through a proxy - that for sure could cause speed issue.. Because your not just routing traffic your processing all of it as the proxy, etc.

pfblocker shouldn't be able to cause slowdown - since its just doing dns.. and filtering what dns you want to filter, it has nothing to do with the actual processing of the traffic through pfsense.

jc1976

@johnpoz nah not through a proxy.

i am SO FED UP WITH THIS!! it just doesn't work!

i thought it was my pc, so i switch... same thing.. i'm running pfsense stock out of the box, only change is that i have dns over tls enabled with cloudflare..

just got a gl.inet that i was going to set up for my folks.. maybe i'll take that.. i dunno.. tired of dealing with this..

sorry for the venting

johnpoz

@jc1976 said in website security problems:

i have dns over tls enabled with cloudflare..

And do your security issues go away if you just let pfsense do dns? I have been using pfsense for 10+ years and there is really nothing in pfsense that would do this..

As I went over going to amazon.com without a www gets you a redirection 301 that tells your browser to go to www.amazon.com etc.c.

Pfsense has ZERO to do with that - ZERO!! There is nothing other than IPS or a proxy that would have anything to do with any of that.. Are you trying to go through cloudflare proxy to get to these sites?

stephenw10

@stephenw10 said in website security problems:

Mmm, I could certainly believe DNS shenanigans.

Try just resolving locally, stop sending your queries to Cloudflare.

Yup.

bPsdTZpW

@stephenw10 said in website security problems:

@stephenw10 said in website security problems:

Mmm, I could certainly believe DNS shenanigans.

Try just resolving locally, stop sending your queries to Cloudflare.

Yup.

Yup.

jc1976

@bpsdtzpw
ok folks, i think i've figured it out...

firstly, i apologize profusely for venting.. I was really pushed to my limits with this thing.. i love pfsense and will always support it.

unfortunately, A) i don't know how to get in touch with an actual "engineer" at comcast/xfinity, and B) i dunno if that would even matter...

if you think i'm a conspiracy theorist, well....?? check this out.

I believe comcast is blocking dns over tls on alternate dns providers.

i don't have any issues using the ip of other providers, however once i enable DoT (out port 853) all the problems start happening. I tried quad9, and at first all things sprang back to life.. a hour later it got wonky again. far better than with cloudflare, but still isn't working properly..
All web browsing works properly if i enable DoH in my browser. My problem is my apps. I have a few big packages that i use for trading futures and those are running into problems. once i disable DoT the issues abate...

Some might think "well, just stop using DoT or just use Comcasts resolvers... My response is: i pay for this connection.. i should be able to use it however i want, PERIOD! Privacy is a RIGHT! and if we want to use another dns provider, we have THE RIGHT to do so and our isp does NOT have the right to stop us!

johnpoz

@jc1976 said in website security problems:

I believe comcast is blocking dns over tls on alternate dns providers.

That is a pretty big claim.. And your dot client should complain that the cert of the server its talking to does validate..

Blocking 853 would be one thing - but seems your saying its intercepting and sending you wrong info? A simple way to validate dot is with the kdig util

example here is to google dns that support dot

root@NewUC:/tmp# kdig -d @8.8.8.8 +tls-ca +tls-host=dns.google.com www.pfsense.org
;; DEBUG: Querying for owner(www.pfsense.org.), class(1), type(1), server(8.8.8.8), port(853), protocol(TCP)
;; DEBUG: TLS, imported 128 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=dns.google
;; DEBUG:      SHA-256 PIN: 65dUhctCga6DL7Xr0hDFi+V8V/3asGMbMO7Hg3MKhTY=
;; DEBUG:  #2, C=US,O=Google Trust Services LLC,CN=GTS CA 1C3
;; DEBUG:      SHA-256 PIN: zCTnfLwLKbS9S2sbp+uFz4KZOocFvXxkV06Ce9O5M2w=
;; DEBUG:  #3, C=US,O=Google Trust Services LLC,CN=GTS Root R1
;; DEBUG:      SHA-256 PIN: hxqRlPTu1bMS/0DITB1SSu0vd4u/8l8TjPgfaAp63Gc=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 13175
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 512 B; ext-rcode: NOERROR
;; PADDING: 404 B

;; QUESTION SECTION:
;; www.pfsense.org.             IN      A

;; ANSWER SECTION:
www.pfsense.org.        300     IN      A       208.123.73.69

;; Received 468 B
;; Time 2021-11-22 13:23:39 CST
;; From 8.8.8.8@853(TCP) in 64.3 ms
root@NewUC:/tmp#

Not a fan of dot or doh - but I am with you that ISP shouldn't be doing anything with my traffic other than routing it.. I normally block dot and doh locally so that none of my devices attempt to use it.. But that is my call, not the isp call, etc.

stephenw10

Mmm, exactly that^.

I could believe something is blocking port 853 entirely but not that it's intermittently blocked or only for some types of queries. Because, yeah, the latter implies something is intercepting the TLS and MITMing it.
It seems more likely that Cloudflares DoT resolvers respond differently in some way. Though I'm not sure why that would be.

I personally have DoT configured to Google DNS just to test that it works and have never seen an issue.

Steve

johnpoz

Here is doing such a test to cloudflare

root@NewUC:/tmp# kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com  www.pfsense.org
;; DEBUG: Querying for owner(www.pfsense.org.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 128 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: RKlx+/Jwn2A+dVoU8gQWeRN2+2JxXcFkAczKfgU8OAI=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
;; DEBUG:      SHA-256 PIN: e0IRz5Tio3GA1Xs4fUVWmH1xHDiH2dMbVtCBSkOIdqM=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.3)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 54600
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; PADDING: 404 B

;; QUESTION SECTION:
;; www.pfsense.org.             IN      A

;; ANSWER SECTION:
www.pfsense.org.        300     IN      A       208.123.73.69

;; Received 468 B
;; Time 2021-11-22 14:48:04 CST
;; From 1.1.1.1@853(TCP) in 40.1 ms
root@NewUC:/tmp#

stephenw10

Indeed. And testing pfsense.org returns exactly the same thing. As expected.

johnpoz

If the isp was actually intercepting dot that would be a HUGE claim.. I would also be concerned that the dot client would accept it - unless some serious shenanigans were going on with the cert being by a trusted ca..

Just out an block - ok, isp has the right to block traffic I guess, I would be looking for a new isp, etc..

bPsdTZpW

I wonder whether the OP has an infected host?

stephenw10

Some ARP poisoning or something?

Seems like it affects multiple hosts on the network so it would have to be something pretty weird.

Do you have anything else on your network that claims to be a security appliance @jc1976?

There are those single interface devices you can get the claim to filter all the bad stuff that work exactly like that. Just terrible!

Steve

jc1976

@stephenw10

nope, no other security devices. My network is as follows:

pfsense (intel i340-t4 nic, so support isn't an issue).
currently, no packages installed.. only rules are the default ones for ip4 & ip6 traffic, plus the ones autocreated for bogon networks.
the nat portforward to send all dns requests to the resolver has been disabled.
all DoT has been disabled and it's using 9.9.9.9 for DNS.

DHCP is only enabled on WAN.
LAN dhcp is handled by my wifi AP (192.168.1.2) - Asus rogue gt5300.. (was given to me), with a 8 port switch. WAN port is disabled and the dhcp server has all devices pointing to the pfsense box (192.168.1.1) for dns/gateway.

that's it! no additional firewalling and other than my phone, all MY devices are hardwired.

it's all really aggravating because it was all set up and working perfectly with squid/clamAV, pfblockerng-dev, suricata, DoT to cloudflare... then it all went to hell and has never worked right since. i've gparted it and loaded pfsense from scratch so many times i'm surprised the SSD hasn't burnt out from all the writes (joke)..

i spent my entire weekend reloading and even reloaded win10pro on my workstation, thinking that it might be a corrupt tcpip stack (because after doing a tcp and winsock reset, it would work momentarily, then fail again).

so, i'm at a loss, and i eventually called comcast but trying to get routed to a REAL engineer aint happening... and yes, i would LOVE to switch to verizon.. the building next to me has it...
the building behind me has it...
i can look out my back window and see the pole where the fiber terminates... an installation technician saw it all said it would be an easy install!
but their engineering crew who have never seen my area claim it can't be done..
(been fighting with them for 3+ months)..

I'm gonna live off the grid.. build myself a treehouse... dress myself in a 'coon skin and tie it up with a bungee chord... LOL

stephenw10

Hmm, well not much to cause an issue there. Assuming the Asus isn't doing something unexpected, which seems unlikely.

Can we see a screenshot of your Unbound config? That's about the only place there could be any issue.

Steve

jc1976

@stephenw10

yeah! wish i thought of that (sending a screenshot of the unbound config). i'm away for the holiday but will do so once i get back home.

I thought about resetting my wifi AP because.... well, why not?.. everything else has been rebuilt from the ground up..

Thanks for your input, i'll send the config once i get home.

happy holidays folks!

jc1976

@jc1976

Ok, as promised i'm including pics of my lan & wan ruleset (there aren't any floating rules), dns resolver settings, and my dashboard, showing no installed packages.

Also, i restored my wifi AP to factory defaults and re-did it from the ground, up. very few settings changes aside from putting it on the same subnet, setting it's ip, and having it point all dhcp clients to my pfsense firewall.

johnpoz

@jc1976 said in website security problems:

and having it point all dhcp clients to my pfsense firewall.

Huh - APs don't have anything to with such a thing. APs don't provide dhcp.

If your going to forward - then having dnssec enable is pointless.. quad9 already does dnssec - be it you have it set or not.

stephenw10

Yeah, disable DNSSec if you are forwarding traffic.

I would also try just going back to resolving mode directly and see if that clears the issue. I expect it will.

Steve

jc1976

@johnpoz
well, let me clarify..

An asus ROG gt5300 wifi router was given to me, so i have that set up as the dhcp server. the wan port is not used. I have it set to hand out ip addresses from 192.168.1.11 on up. it's ip address is 192.168.1.2 and it points all devices to use the pfsense firewall at 192.168.1.1 as the dns server and gateway.
My reasoning behind this setup is, should my firewall ever go down for what ever reason (most likely because i've screwed around with it too much and it puked),
A) i wouldn't lose any device connectivity on the network (ie, i can still watch movies streaming from my nas while i rebuild the firewall haha).
And
B), i can quickly swap in a backup router for internet connectivity while again, never losing device inter-connectivity. no need to wait for devices to be assigned new ips or any of that, which is advantageous considering the issues my GF and i have been having when she has to swap in the backup.