Block OPT1 from accessing DSL-Modem behind Firewall?
-
Hey there,
(actually) I am "the new Guy" in this forum as even as I am new to firewalling itself.
First of all, I've read a lot of stuff in this Forum. It is a really great ressource for reading, working around several issues and by that learning lots of stuff this way. So at first: thanks for that!
Let's go ahead. I'm just running into an issue with a several "need" (or want) for my home network...
My setup looks schematic like this:
DSL-Modem ----------> 192.168.1.1
............................................ |
............................................ |
pfSense Firewall ---> ..172.1.1.1
.................................... |.............|
.................................../...............\
................................/....................\
............................../........................\
..................... LAN NET.................OPT1
.......................10.1.1.1................10.2.2.1- outbound NATting (auto) / PPPoE by 192.168.1.1
Everything's working great after a lot of reading and several trial and error procedures.
OPT1 got great access to the internet but not to LAN NET or the "Firewall itself" (specific rule option)I guess, until here I can say I'm happy with my little learning Project :)
What I'd like to do next is to prevent (Block + LogAlert) OPT1 from accessing the DSL-Modem, I actually found out that this might be in real World Scenarios something of an issue... So I want to block access to the WebGUI as via SSH, for sure, for OPT1.
As I googled for it the last hour I found threads and articles describing how to allow access to a Modem through PfSense but not specifically how to deny it. Maybe I'm just tired or my head's full of newly learned procedures.
I thought about maybe adding a Block rule for it might solute it, but as I see it it would just block the whole access to the Internet?
I've read somewhere to open (so upside down in my case to block) access to the ports 80 (HTTP) and 22 (SSH), maybe even 8080?? (HTTP, too, if 8080 should have sth like a failover function for Port 80) but I just wanted to see if there could be a better solution?Any ideas? And how would you go on to solve this issue? I guess in real World scenarios it might not be desired that clients of any local Network being able to access a (then for sure just-) Modem or any other device?
Thanks in advance.
EDIT
I'm at my own home Network and not accessing through the Internet but here's an article maybe worth to read for folks new to the thematic as me.
https://www.netgate.com/blog/securely-managing-web-administered-devices.html -
Just add a block rule to the OPT1 interface rule tab with destination address = DSL-Modem IP.
Put this rule to the top of the rule set.pfSense applies the rules from the top to the bottom. If one matches, rules below are ignored.
Depending on your existing rules, there will also be other solutions, but we don't know them.
-
Hi Viragomann,
that really did it, thanks for that.My rules are kept quite easy. As I only want LAN having access to everywhere I want to keep OPT1 from getting access to anywhere instead of "the Internet", so namely the following Destinations:
LAN
Firewall
and now the Modem, too, for sure...
The Network behind the LAN Interface shall be my Home Network (TV, PC, Printer, Wifi and maybe later some other stuff).
Via OPT1 I just want to provide something like a "Just-Switch-it-On Guest Network" for granting Wifi without having to hand out the Key for the Network behind the LAN Interface.I recognized that you're from Germany so I guess you will know about FreiFunk. I just took my old FreiFunk TPLink WR841N Router and flashed it with OpenWRT for this purpose (that one's OPT1 for now).
In addition: I just changed the Block order on OPT1 (from top to bottom: Bogons - This FW - LAN net - Modem)
-
TV in the LAN? Do you really trust it?
A good advice to block access to internal networks is adding an alias in Firewall > Alias and add all RFC1918 networks to it. Then use this alias in a block rule.
Presupposed you use only RFC1918 networks, this way you only need one block rule to avoid any access to internal devices. This is save as well if you add an additional subnet or change one in the future.Consider, if you provide DNS on your pfSense to the OPT1 net you have add an additional pass rule to permit it.
-
When would a source on your own network ever be bogon? That rule is pretty pointless as well with the default deny rule and the use of specific source nets in your allow rule.
Since your allow rule only allows opt1 net, any and all bogon would be blocked anyway.
-
@viragomann You're absolutely right...
Would it be a "fine way" to create a VLAN for untrusted Devices in the LAN, eg in my case the TV? Or would it be better to create the Alias and block outgoing traffic for the specific Alias? I just don't want to block Netflix, Amazon or maybe even the Appstore. But I'll take your mention and put this Topic to my Research / Read List.I took your advice and tried it the supposed to be "easier way" and blocked all RFC1918 in the Interface Section. Result was that I got blocked from accessing via WebGUI and SSH...
The solution was to get on the Box via Serial and got it open again. Now it's all working fine again. And yes, the Anti Lockout Rule was activated and didn't worked it out. So I would say this was a Learning by Burning... :)I really have to state that I didn't got the Point of your Advice... Wouldn't this lock me out again?
Presupposed you use only RFC1918 networks, this way you only need one block rule to avoid any access to internal devices. This is save as well if you add an additional subnet or change one in the future.
At the moment I don't get your point. Wouldn't this lock for example even "PC on LAN" from accessing the LAN Interface in the Firewall again?
Consider, if you provide DNS on your pfSense to the OPT1 net you have add an additional pass rule to permit it.
DNS is being provided over pfSense via 8.8.8.8 / 8.8.4.4 for both Networks. There is no specific rule for permissioning it. The DNS Resolver is enabled and the two above mentioned Servers set in pfSense. Could it be that this depends on the "Default allow LAN / OPT1 to any rule"?
@johnpoz You're right. Blocking Bogons on WAN would surely be more effective than block them beneath of WAN on LAN, too. I'll change that shortly.
To be honest... As my DSL-Modem got a Firewall itself and is NATting (no DMZ / exposed Host at the moment) I guess even on WAN actually this shouldn't be as necessary as with just a pure Modem. Thanks for your point.And I guess I got your point with the source net in the allow rules...as there are no other clients instead of the LAN clients themself setting "LAN net" on source might really be unnecessary... And as I can rate it really sounds logic.
Wouldn't it than be better to let the Bogon Block active?
Or would it be better to let the source net set and take the Bogon rule off for that?
Or both off? Wouldn't that exposure a potential hack-in way, eg by a Worm or sth similar?.
.
.At both of you: Thank you for your points and ideas. I'm really just starting with the whole theme so sorry for maybe stupid questions / rules. All your mentions and point are always welcome as they give me the opportunity for re-thinking and learning more about networking.
-
@bsa66 said in Block OPT1 from accessing DSL-Modem behind Firewall?:
At the moment I don't get your point. Wouldn't this lock for example even "PC on LAN" from accessing the LAN Interface in the Firewall again?
We were talking about the OPT1 rules. Of course, if you add a RFC1918 block rule to the top of the LAN rule set and have the Anti-Lock-out diabled, you'll get locked out.
@bsa66 said in Block OPT1 from accessing DSL-Modem behind Firewall?:
Consider, if you provide DNS on your pfSense to the OPT1 net you have add an additional pass rule to permit it.
DNS is being provided over pfSense via 8.8.8.8 / 8.8.4.4 for both Networks. There is no specific rule for permissioning it. The DNS Resolver is enabled and the two above mentioned Servers set in pfSense. Could it be that this depends on the "Default allow LAN / OPT1 to any rule"?
The point is which DNS the clients use. If you have set external DNS servers in the general setup, but the DNS resolver and DHCP activated, but no DNS servers specified in the DHCP settings, pfSense provides its own interface address to the clients as DNS server via DHCP. In this case you need a pass rule to allow access to the interface address on TCP/UDP port 53.
-
@viragomann said in Block OPT1 from accessing DSL-Modem behind Firewall?:
We were talking about the OPT1 rules. Of course, if you add a RFC1918 block rule to the top of the LAN rule set and have the Anti-Lock-out diabled, you'll get locked out.
Okay, I guess I got it now. And I apologize. But yeah, I did it and got me locked out. (and it is confusing that the Anti Lockout Rule was definitely not disabled. I checked this out in the afterwards) But I'd say...Anyway "Layer 8 did it" :)
The point is which DNS the clients use. If you have set external DNS servers in the general setup, but the DNS resolver and DHCP activated, but no DNS servers specified in the DHCP settings, pfSense provides its own interface address to the clients as DNS server via DHCP. In this case you need a pass rule to allow access to the interface address on TCP/UDP port 53.
The pfSense got two public DNS Servers and the two router behind it (LAN & OPT1) got their pfSense Interface IPs for DNS forwardings. Both router got static IPs on pfSense and are just serving themselves DHCP for their Clients as well. I will shortly make two screenshots and load them up.
pfSense - General Setup
LAN Router (OpenWRT) - DNSMasq
 - DNSMasq
At the last Point on this Screenshot (DNS Forwardings) I put in the pfSense IP of LAN Interface
-
@bsa66 said in Block OPT1 from accessing DSL-Modem behind Firewall?:
I guess even on WAN actually this shouldn't be as necessary as with just a pure Modem
Even with pure modems to be honest its a kind of pointless.. Bogons do not route - so to be honest they should never be able to hit your wan, ever.. And since EVERYthing is blocked out of the box it would only matter if you had port forwards. So you would be blocking some IP as source that does not route on the internet from hitting your port forwards.. So to be honest - not really useful rule ;)
The whole idea of bogons is pretty outdated to be honest..
-
I just found some Sec related stuff out there. I blindly took the very first hits and either yet didn't digged deeper into it.
So I really don't know that much about this Sec related stuff yet but maybe you can get more out of it? So just FYIhttps://exchange.xforce.ibmcloud.com/vulnerabilities/112743
https://www.blackhat.com/presentations/bh-usa-03/bh-us-03-convery-franz-v3.pdf
(p. 51)It seems to me that there are several (known / published) possibilities...
-
Thanks dude - but been doing this for like 30 years.. I think I know the "possible"... Did you not get the part where I stated all ports are blocked out of the box..
Do you have port forwards? Are you running ntp? Have you not updated it.. Does your ntp server use 127.127.0.0/16 address as its reference ;)
Are you not keeping your ntp server up to date? The fix for that was released A month before the exploit was even reported - and it shows as unproven ;)
The default to block bogon is on by default on your wan anyway.. I didn't say you should uncheck it, just saying its really a old standard practice that doesn't really provide all that much protection. How many hits have you gotten on your wan bogon rule btw? ;)
To the other - are you running BGP? ;) The talk of filtering bogon in BGP is about not allowing routes to bogon in your BGP routing table - not that traffic would come from a bogon source IP which is what the wan rules do..
Normally bogon would be blocked at your border router before it even hit your firewall.. But with the case of pfsense it being the border router and firewall. But the block rules of rfc1918 and bogon that are default ONLY ever come into play if your forwarding traffic. It is much better practice to limit your source IPs on your forwards to the IPs and or Netbocks that you actually want to access your forwards in the first place.. If you are thinking of port forwarding, you should prob make sure you understand all the implications... Cuz I can for sure promise you there are way more concerns of traffic hitting your port forwards from actual valid IPs than bogons ;)
-
Okay, you got me. ;-D You doing this at least as long as I am on our beautiful Earth...
I got the part where you said "all ports are blocked by default on WAN" (I knew that even before...but to be honest: that doesnt really calm me. (that I know it I mean))
Nope, actually I dont have any port forwards. But my next Project might be a really tiny Website, I got an old Raspi 1 and would like to use it for this purpose...or use it anyway again. And for a little Hobby Project it might be...I hope...still "powerful" enough.
Nope (again :D) , I'm even not serving my own Network with NTP, et even pfSense does not, every router has its own NTP-Servers set up as even as the Firewall has their own.
Are you not keeping your ntp server up to date? The fix for that was released A month before the exploit was even reported - and it shows as unproven ;)
Okay Dude, (or El Duderino for those who dont like too short names :D ) I see you're really in this stuff, my propz! (I mean that truely!)
The default to block bogon is on by default on your wan anyway.. I didn't say you should uncheck it, just saying its really a old standard practice that doesn't really provide all that much protection. How many hits have you gotten on your wan bogon rule btw? ;)
If you'd now how I advanced the WAN Rules provided by the Balanced IPS Policy in Snort... I guess...head hits table
Actually, to be honest, not one.I actually don't even know what BGP is..I'd say a Service but to be honest I'd had to read about it to be able for stating sth about BGP.
Normally bogon would be blocked at your border router before it even hit your firewall.. But with the case of pfsense it being the border router and firewall. But the block rules of rfc1918 and bogon that are default ONLY ever come into play if your forwarding traffic. It is much better practice to limit your source IPs on your forwards to the IPs and or Netbocks that you actually want to access your forwards in the first place.. If you are thinking of port forwarding, you should prob make sure you understand all the implications... Cuz I can for sure promise you there are way more concerns of traffic hitting your port forwards from actual valid IPs than bogons ;)
Okay, I see. So if I got you right it would be okay to use the Bogon Block on WAN and I can disable it for locals, correct? Why it lets me sleep better running on WAN is that I just configured the only Client on my DSL-HomeUser-ModemRouter, pfSense, as an exposed host this night.
And yes, before I did that I enabled Blocking for snort and before I did that I worked out at least one very little wan- and one little lansuppress list over the last 4 days. Just, for sure, still learning. Google Search aint blocked anymore (for its permanent Port Scans...) but multiple CN and RU and "ZZ" (no country) Port Scan and EmergingThreading IPs remained and will remain onwards in the Blocked List.
Just wondering how big this one will become... For educational purposes (not for security as they will get blocked even at the first attempt by snort again) I set the "keep em blocked" on one Week at the moment. So I can work several IPs out and have a wider overwatch on how often same IPs coming back or Rules will get triggered.Actually everything's working fine (for me, as I use the network at the moment...anyway). Two Spotify IPs got blocked so I had to unblock them after it was clear to me where these IPs are coming from (at the moment I'm using virustotal & dnsstuff.com for better or more reliable reversed nameserver lookups for blocked IPs by hand)
Hm, wrote a lot of stuff I'd bet you ain't interested about.
I've unblocked Bogons on my local site but left in enabled on WAN (I know, you said they wont get routed...damn ;-D)
