website security problems

jc1976

Well, i don't mean to be all 'post hoc, ergo propter hoc' but so far it seems that the issue was in fact with comcast.

I went away for thanksgiving and before leaving i powered everything but the nas (firewall, wifi, cable modem) down. That was last tuesday and i returned home on Monday night.. powered everything back up..

last night i was opening my trading apps and they were still very sluggish to open and it seemed as though nothing had changed. however i said 'hell with it, might as well put everything back to cloudflare since quad9 hadn't resolved anything'.. so i did..
and EVERYTHING came alive again..

interesting...

even my trading apps that were causing me so many issues came alive.

i then went in and enabled full dns over tls, and the rules to redirect dns to the resolver and all worked perfectly!
so far, my gf is telling me all is working perfectly..

so, correct me if you pro's think otherwise, but it seems that the issue WAS on comcasts end and releasing the WAN ip and shutting it all down caused them to automatically kill my route completely.. and when i powered everything back on and was given a new ip address, i was given a new route as well and that resolved my issues..

does that make sense??

i'm gonna see how this works over the course of a few days then slowly start reintroducing the packages (pfblocker-dev, suricata, maybe squid/clamav).

thoughts/opinions?

jc1976

@stephenw10
just for my learning, why would i disable dnssec if i'm forwarding?
I understand that dnssec is problematic if using dns over tls (although i don't quite understand the mechanism of why it's problematic), however in this instance i don't have dns over tls enabled. so, wouldn't dnssec be a good thing?

or is dnssec one of those things that were a good idea in theory but more problematic than it's worth?

johnpoz

@jc1976 said in website security problems:

should my firewall ever go down for what ever reason

You understand dhcp server doesn't have to be running for network to work.. Clients grab an IP and then don't even start to renew until 50% of the lease.

So any client that has gotten a lease while your dhcp was up will be good for at min 50% of whatever your lease time is.. So in the case of say 24 hours lease, you should be good for like 12 hours before stuff stops having issues with their IPs.

Only issue would be some new client that tried to get a lease while your dhcp server was offline.

wouldn't dnssec be a good thing?

It is! But quad9 does it anyway.. There is no need to have unbound trying to do dnssec when you forward. When you forward, where you forward is either doing dnssec already, or they are not.. Enabling dnssec in unbound does nothing when you forward other than extra work and dns queries for no reason.. If you forward turn off dnssec, be it your just normally forwarding or using tls.

https://www.quad9.net/support/faq/#dnssec

Yes. Quad9 provides DNSSEC validation on our primary resolvers.

9.9.9.9, 149.112.112.112
2620:fe::fe, 2620:fe::9

In addition we validate DNSSEC on our EDNS enabled service.

9.9.9.11, 149.112.112.11
2620:fe::11, 2620:fe::fe:11

This means that for domains that implement DNSSEC security, the Quad9 system will cryptographically ensure that the response provided matches the intended response of the domain operator. In the event of a cryptographic failure, our system will not return an answer at all. This ensures protection against domain spoofing or other attacks that attempt to provide false data.

no need to wait for devices to be assigned new ips or any of that

Why would they need new IPs.. You can fire up a different dhcp server using the same range of IPs, and clients trying to renew their IPs would get what they asked for (unless that has been handed out already by this different dhcpd)

If your lease is long - which there really is little reason not to be on a home setup, with clients well under the dhcpd scope of IPs to hand out. Mine is 4 days for example, if my dhcp server went down - I prob wouldn't even know for min of like 2 days, unless new client came online.

I have never had dhcpd crash or go down on pfsense that I can recall. Without major something as an issue - like a complete pfsense crash (very very rare in my experience over the last 10 some years)

Gertjan

@jc1976 said in website security problems:

so i have that set up as the dhcp server.

I you really have to use the DHCP server of that device, I advise you it to throw away (apply local garbage collect rules, please ;) ).

You need an access point, a device that bridges RJ45 electrical able to 'radio waves' and back.
Fine if it does more, like 'DNS' or DHCP or 'routing' : these should all be switched of.
What comes in handy is that often a 6 port switch is build in : one, inside, on the LAN side for the AP, one for the WAN, and for 4 are accessible on the back as LAN. Great to daisy chain to other devices.
The WAN port can often be assigned as a LAN, now, when grandma manages to remove the LAN cable, she can not put it vack in the WAN socket, and breaking all the wifi while doing so.

@jc1976 said in website security problems:

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

Hein ?
The pool starts at 192.168.1.1 and it uses itself 192.168.1.2 ...
So the pool is just one IP ?

@jc1976 said in website security problems:

My reasoning behind this setup is, should my firewall ever go down

Actually ok, but if your pfSense goes down, leases will persist, and the network keeps on working.
It will take hours before devices start to assigned themselves a 169 type IP.
If pfSense goes down, it like electricity in the house : you won't be able to stay at home anyway.

pfSense normally goes down when you tell it to reboot.
I never saw it going down by itself or something like that. Not during the last 10 years I've been using pfSense.
Btw : power is also given to you (sort of) : so : don't trust 'them' neither. Get an UPS. This will take care of the situation where granny starts her chernobyl-type hair dryer that makes the fuses trip out.

@jc1976 said in website security problems:

just for my learning, why would i disable dnssec if i'm forwarding?

Because a resolver has to contact all the needed parties and question them, from top to bottom (from the root server down to the domain name server) and do all the checking.
When you use a forwarder, it's more like : you go to the local barber, and ask the guy : what is the number of the local garage ? He will give it to you, and you just have to trust him. You dial the number ... and you hope the garage will reply (and not someone else).

( but now the local barber knows the brand of your car .... and knows that you need a repair, and knows that you can't read or use devices to do the lookup your self - you might even be the example of "just gob everything for true, and don't do the fact checking yourself" - needless to say that the barber is going to use his favour against you )

I just made up this story, but their is some 'true' hidden in it.
Netgate - pfSense decided ** to include a resolver, so DNSSEC can be uses (and you data will not get send to some 'other' company or organisation.

Btw : not every domain name (domain name server) supports DNSSEC.

When you do DNSSEC checking yourself, you have to check this : https://dnsviz.net/d/test-domaine.fr/dnssec/ from top to bottom.
When you forward, you just wait while some one else is doing the job.

You might say : hey, @gertjan thinks forwarding is bad, only resolving is good. But nope, the question isn't black and white. It's just a choice I made after considering all the aspects. I do think I know what DNS and DNSSEC is, as I run my own domain name servers and all my domain names support DNSSEC (which is really next-level thing, because when you make an error, the domain name isn't reachable any more and you can't correct it instantly. Site and servers behind it become unavailable).

As regular DNS, DNSSEC queries (the answers actually) are cached. So, when you use a forwarder, chances are big that you get a cache hit, so the entire request takes less resources and might even be a bit faster.

edit : Probably a good thing : https://dnsviz.net/d/facebook.com/dnssec/ facebook doesn't support DNSSEC.
If they did, actually, they would do the world a huge favour.
As they would f*ck up some day.
24 hours later one thousand youtube video's, all the other news outlets and social media would explain you what DNSSEC is.
Just like granny now knows what BGP is.

**)
In the past, pfSense came with a fowarder, dnsmasq, but added also a resolver (unbound).
The forwarder is still present these days, but the resolver in resolver mode is default.
Unbound can also forward, if needed
I do not proclaiming knowing the real reasons why (Netgate) decried to shift from dnsmasq to unbound.

johnpoz

@gertjan said in website security problems:

I do not proclaiming knowing the real reasons why (Netgate) decried to shift from dnsmasq to unbound.

I don't either - but from an educated guess I would say that dnsmasq does not support resolving. And resolving is much better ;) from many different aspects.

Back in the day unbound was an addon package, it then became default and built in to pfsense.

Now not saying there is still not use for dnsmasq (forwarder).. One of the things it can do which some people might want is to forward to ALL listed forwarders at the same time and use the first response. There was a request to do this in unbound.. But AFAIK this has not been implemented, nor does it seem likely per the request thread
https://github.com/NLnetLabs/unbound/issues/167

It might be that at some future date dnsmasq is removed, but unless there is something specific wrong with it not working, or too much effort to keep it as an option. It will most likely be around as an "option" for awhile.

But off the top of my head the only reason I could see using dnsmasq vs unbound is you really want to use that forward to all NS option.. But not sure why anyone would want/need to do that.. Unbound when forwarding to multiple NS, will figure out which one responds faster and tend to use that one, etc.

jc1976

@johnpoz

i know the dhcp server doesn't 'have' to be running to have inter-device communication, it's just a preference. if my laptop is turned off, and i need to use it for whatever reason, and the dhcp server isn't up, then i have to statically assign an ip.. in my mind, having this sort of modularity makes things simpler, at least it does in my mind.

jc1976

@gertjan

regarding the ap/dhcp server:

The WHOLE reason why i used this device the way i did is for the same reason you mentioned:
-it has an 8 port Gb switch (not including WAN).. this thing was given to me by an old boss of mine, and considering that it was $450 at the time, who am i to say no? it has very powerful wifi (i live in a building that was constructed in the early 1800's, the walls are all brick and the signal is still strong all the way to my storage unit in the basement). so, until my office is completed, this consolidates things a bit.. ugly thing... looks like a face-hugger from Alien..

jc1976

Anywho,

i know DNSSEC is being tossed around a lot... however that wasn't the issue, because while the screen shots i had posted showed it as active, when i was having all these issues, as i whittled the firewall down to nothing, i had disabled dnssec.. whats more, i was even using comcasts dns! and i STILL had the issues..

not until I shut EVERYTHING down before going away did the problem seem to resolve itself.. and it was still wonky until last night when i changed the dns back to cloudflare.. quad9 was NOT the issue because it made no difference..

as of an hour ago, all is still working like a rolex.. even my trading apps are snapping open like they once did..

can any of you see how this could be caused by the isp? if it were to happen again, how do i even explain to them the problem?

johnpoz

@jc1976 said in website security problems:

the walls are all brick and the signal is still strong all the way to my storage unit in the basement)

Just because your see a strong single through walls, with some overpowered xmit power doesn't mean your little xmit in your device will be able to reach back through the walls ;)

This is common misconception with wifi.. And even if some wifi device can see the signal and even if the AP has great reception sensitivity.. Devices connecting at the "edge" of coverage is not good for all the other devices on the wifi..

For best wifi all around - it is almost always better to have multiple AP so that clients that are connected to any specific AP have both good xmit and recv signal in both directions. Also spreading your clients across multiple AP also helps for overall performance of all devices involved. While there have been great strides with stuff like mu-mimo and beamforming and ofdma. 1 AP sort of setups are not going to be best sort of wifi, especially as the amount of wifi devices explode in number.. Quite often all over the house.. I have like 30 some wifi devices connected to my wifi at any given time.. Splitting these connections across multiple AP is better for all clients overall performance.

If you feel running dhcp on this device of yours is best for you - then great, just make sure its not handing out info your not aware of, like pointing to itself as dns as well as maybe your pfsense.. Doesn't really matter where something like dns or dhcp runs in your network - as long as it works.. But a true AP would normally not have any way to be a dhcpd.