Need help with Design
-
Ok, so i try to be a clean as possible.
My setup is a little less then idea. I have a 4G WAN router that does not support bridge mode and setup as my upstream gateway.
My design as follows.
WAN4G 192.168.1.0/24 >> pfSense WAN 192.168.1.2/24
pfSense LAN 192.168.2.0/24 (DHCP, DNS etc)
Now, what I do not like about this is the fact that I have a full /24 subnet sitting there, with 2 hosts in it before my router (pfSense).
FYI - I cannot change my 4G routers subnet, its stuck at /24.
Also, I hate the fact that I have a WAN facing router after my pfSense router. This just means its another vulnerable device sitting on the WAN, with no logging capabilities to see what's actually going on on it.
What say, the 4G router was compromised and all traffic was VPNd (without my knowledge) through to a random IP and there they were eavesdropping on my data. Or, just all traffic going through it was being captured.
What are some things I could do to beef up security? My ideal setup would be a 4G router that I could just directly bridge through to pfSense and get a DHCP WAN IP in pfSense.
Thanks in advance!
-
I'll start out by saying that's very unlikely. Also all your traffic goes via the 4G provider anyway.
Almost everything is https these days anyway so actual data you can see by MITMing a connection is pretty limited.
But if you really want to you could setup your own VPN to some end point you control and send all your traffic via that.
Steve
-
@stephenw10 said in Need help with Design:
Almost everything is https these days anyway so actual data you can see by MITMing a connection is pretty limited.
Ugh. There's DNS, which is plaintext unless you're exclusively using one of the secure alteratives (e.g, DNS over TLS - https://developers.cloudflare.com/1.1.1.1/encrypted-dns/dns-over-tls/ ). Plaintext DNS is susceptible to both snooping and manipulation. If you're in the habit of ignoring cert errors [1], you can get rabies from this hack.
If all traffic is encrypted, an attacker can still get the SNI (server name information, which is plaintext during TLS handshake). Mozilla et al are working on a fix for this awful shortcoming, but it's not baked yet: https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14 .
[1] Please please don't do this. DNS manipulation and poisoning are real; hackers are trying to redirect your traffic to their servers.
-
@bpsdtzpw also, one other thing is when doing a network scan on my WAN interface, I am getting 192.168.1.1, which is my upstream gateway, but I am also getting WAN addresses. This is after NAT as pfSense is doing my NATting.
-
@deanfourie said in Need help with Design:
@bpsdtzpw also, one other thing is when doing a network scan on my WAN interface, I am getting 192.168.1.1, which is my upstream gateway, but I am also getting WAN addresses. This is after NAT as pfSense is doing my NATting.
Are you using nmap? I'd expect it to discover everything reachable via the specified interface, in this case both your modem's admin page and everything else on the WAN within the scope of the scan. You're seeing the destination address(es) of the reachable nodes, not the source address of the packets that the scanner is sending out (which is NATed to your WAN's internet-side address).
-
Yup that's true. But the risk of the local router being compromised and seeing your traffic is no different to anywhere else in the route really. And in both situations running all your traffic over a VPN removes that risk. Though it really only moves it to somewhere else.
Steve
-
@stephenw10 said in Need help with Design:
Yup that's true. But the risk of the local router being compromised and seeing your traffic is no different to anywhere else in the route really.
ISP routers tend to be on the crappier side, so I'd expect more vulnerabilities than in, e.g., pfSense.
And in both situations running all your traffic over a VPN removes that risk.
It doesn't remove the DNS risk unless you use a secure DNS solution (or potentially the VPN provider's DNS); unencrypted DNS queries will merely exit the VPN tunnel somewhere on the 'net, then potentially get read and/or the responses doctored on their way back into the tunnel.
-
Exactly it only moves it somewhere else.
-
Ok, sure but I don't understand why I am seeing traffic with External IPS on my WAN interface,
This is NATed, I should only see 192.168.1.1 and 192.168.1.2?
Its showing as a HOST on the WAN interface.
Thanks
-
Mmm, that's fun!
That's a Huawei MAC address. I would expect that to be the 4G routers WAN interface?
I would not expect to see that on the LAN side. Something buggy/poorly configured there.
pfSense doesn't care though it will just block it.
Steve
-
@stephenw10 that's on pfSense WAN interface.
I think something suspicious is going on tbh
-
Right it's on the internal side of the 4G router, where I would not expect to see the public IP.
-
@stephenw10 exactly. Should I be worried?
-
Not excessively because pfSense will just block it anyway. It implies that the 4G router is doing something it shouldn't. Hanlon's razor dictates it's probably just buggy firmware.
Steve
-
@stephenw10 but it's possible if the huwawei is compromised, then everything is going through it is vaulnarable to being intercepted?
Thus, why I don't like it being an upstream gateway rather then being in bridged mode, it's another node sitting on my WAN interface which I cannot intensively monitor.
-
@deanfourie said in Need help with Design:
@stephenw10 but it's possible if the huwawei is compromised, then everything is going through it is vaulnarable to being intercepted?
Sure. And modified if it's plaintext (e.g., DNS responses). This is why I suggest using some form of secure DNS (e.g., DNS over TLS) and a VPN.
Thus, why I don't like it being an upstream gateway rather then being in bridged mode, it's another node sitting on my WAN interface which I cannot intensively monitor.
Agree. Alas many ISPs won't let you use bridged mode and/or require you to use their equipment.
-
This was pulled from my logs today.
Mar 3 09:17:33 arpwatch 94050 bogon 0.0.0.0 b4:ae:2b:2d:f0:a9
Mar 3 09:17:34 arpwatch 94050 bogon 0.0.0.0 b4:ae:2b:2d:f0:a9
Mar 3 09:17:35 arpwatch 94050 bogon 0.0.0.0 b4:ae:2b:2d:f0:a9They are everywhere
Mar 3 14:17:34 arpwatch 94050 bogon 0.0.0.0 b4:ae:2b:2d:f0:a9
Mar 3 14:17:35 arpwatch 94050 bogon 0.0.0.0 b4:ae:2b:2d:f0:a9
Mar 3 14:18:00 sshguard 69810 Exiting on signal.Mar 3 15:11:05 arpwatch 94050 bogon 0.0.0.0 78:24:af:36:1a:08
Mar 3 15:11:06 arpwatch 94050 bogon 0.0.0.0 78:24:af:36:1a:08
Mar 3 15:11:07 arpwatch 94050 bogon 0.0.0.0 78:24:af:36:1a:08
Mar 3 15:11:08 arpwatch 94050 bogon 0.0.0.0 78:24:af:36:1a:08and the list goes on
Also, I cannot change the LAN subnet mask? What is up with this router? I've never seen that before.
-
This post is deleted! -
Ok, so this is starting to look a little bit strange. In ntopng I have devices that are appearing as ghost hosts, and this moves around between devices. This is not a simple network misconfiguration on a basic /24 network.
Now I'm seeing every time a host connects to the network, there is a ARP entry for that hosts MAC address to ip 0.0.0.0. These constantly change between hosts.
This looks very suspect to me.
-
Those are known MAC addresses though? Looks like hosts connecting and broadcasting for DHCP servers to me. Which would be totally normal.
