Firehole and 192.168.0.0/16
-
I want to at Firehol_Level_1 to my IP list but they have 192.168.0.0/16 in there.
I did read people couldn't reach pfSense anymore after activating the list.I also use that range in a part of my network:
The firewall on the ISP modem is deactivated.
Then there is what they call DMZ and i did set it to 192.168.0.2.
So everything is forwarded to pfSense.In the deny alerts I see on WAN allot of:
192.168.0.2:80
192.168.0.2:22
192.168.0.2:50802
192.168.0.2:23It comes from CINSScore_CI_Army, AlienVault_Reputation and Turris_Greylist.
But this lists dont have any 192.168. ??There are also 192.168.0.2:80 deny alerts from Firehol_Level_2 that i don't see in this list?
1. Where do the alerts come from if the lists don't have the IPs
2. How can i activate Firehol_Level_1 without the risk that i can't reach the modem anymore.
-
That LV1 feed contains bogons and shouldn't be used for blocking outbound. You can also enable "Suppression" in the General tab which will remove any loopback and RFC1918 addresses. Will need a Force reload to take effect.
-
I focused on this setup/tutorial: http://supratim-sanyal.blogspot.de/2017/04/pfsense-pfblockerng-ultimate-list-of-ip.html
How do i know what lists should be "block outbound", "block inbound" or both?
Any drawbacks with the "Suppression" option on?
There is this Monster pfBlockerNG import script: https://forum.pfsense.org/index.php?topic=118424.0
He also does set "Deny_Outbound" and his list is made from the Firehole stuff.1. I wonder why the "Monster pfBlockerNG import script" is not just using Firehol Level_1 up to Level_4 and is using all the lists separately (more to download).
2. And the guy from the other tutorial is adding a lot of lists separately that are already in the Firehole levels… -
The next release of the package will have a Feeds Management Tab which will make this process easier…. But you need to do homework to see what a Feed is comprised of before using it.... I typically recommend to use the "Original" feed maintainer and not a compilation of other Feeds...
Suppression will remove loopback and RFC1918 addresses.... it will also show a "+" sign in the Alerts tab which can be used to suppress an IP (Not for large CIDRs tho..)
-
I understand technically what the "Suppression" option does. But does it have security or other drawbacks?
There must be a reason it is of by default?I did use all the github addresses from Firehole because I'm unsure what i can put into IPv4 and they contain only IPs.
If i look at original feeds i see stuff like:
5.9.73.226,IP used by banjori C&C,2017-08-11 16:04,http://osint.bambenekconsulting.com/manual/banjori.txt
Education Management Corporation:4.2.144.0-4.2.144.31There are also CSV files…
DNSBL is for feeds with just URLs?
But there are also feeds with "127.0.0.1 www.something.com"Is there a documentation what kind of feeds format IPv4 or DNSBL can handle?
I must be missing something... :( -
Its not enabled by default, as it will only remove RFC1918 and loopback addresses… So its a user choice... I would assume most would want it enabled, but have been hesitant to enable it by default...
IPv4/6/GeoIP are IP Based feeds only.
DNSBL has a parser for Domain based feeds.... It should parse most Domain based feeds as-is.... should you find a feed that the parser has issues with let me know and I can add a parser for that....Next version will have a Feeds Management Tab to help with this....
-
Am I correct that the "Suppression" setting in pfBlockerNG is only looking at outbound traffic?
Also, when the the alias pfBlockerNGSuppress is created it does not show any networks. Are the loopback and RFC1918 addresses hardcoded into the Suppression feature and therefore not displayed in the alias?
I'm sorry if this sounds very basic. I just want to make sure that by checking Suppression, if the firehol level 1 list is used for outbound traffic I will be able to access LAN resources and won't get locked out of the router GUI.
Thanks.
-
Am I correct that the "Suppression" setting in pfBlockerNG is only looking at outbound traffic?
Also, when the the alias pfBlockerNGSuppress is created it does not show any networks. Are the loopback and RFC1918 addresses hardcoded into the Suppression feature and therefore not displayed in the alias?
I'm sorry if this sounds very basic. I just want to make sure that by checking Suppression, if the firehol level 1 list is used for outbound traffic I will be able to access LAN resources and won't get locked out of the router GUI.
Thanks.
No, suppression is for all "Deny" aliases. Instead of added the Lvl1, just add the individual feeds instead and skip the Bogons completely…
See here:
https://forum.pfsense.org/index.php?topic=135257.0 -
Thank you. I've gone ahead and recreated the LVL1 with direct feeds without the bogons. Great idea.
Regarding the "Suppression" feature I'm wondering whether it applies to me. My router is set up as follows.
1. All traffic from our local lan (192.168.1.0) is routed through a commercial VPN provider for privacy.
2. The router has an OpenVPN server to provide a site-to-site connection with another LAN (192.168.2.0) which then has access to an Active Directory domain. All internet traffic from the remote LAN (192.168.2.0) is handled through the remote LAN's (192.168.2.0) local router.
3. The router has another OpenVPN server for "road warrior" access to the AD domain which also tunnels any internet traffic out through the commercial VPN in 1 above.
4. pfSense acts as the DHCP Server which routes all connected AD domain devices to the AD domain DNS Server which then has a Conditional Forwarder back to the pfSense router.
5. The router firewall has everything blocked on the WAN by default. There is an allow rule for the specific IP address for the remote site to the OpenVPN port. There are no pfBlockerNG rules applied to the WAN except for a GeoIP allow rule to the road warrior vpn port. (Any suggestion on locking this down farther is appreciated!)
6. All pfBlockerNG deny rules are being applied to the LAN and commercial VPN interfaces. (I'm not sure if this is redundant. I applied the rules to both interfaces out of caution. I have a hunch that I might only have to apply them to the LAN interface but need to research this farther to confirm my guess.)
Currently all DNS resolution is working perfectly. Both LANs can discover all resources on either side of the tunnel and the road warriors can access all AD resources on both LANs and access the internet as well.
Given the fact that we only have 1 specific LAN (192.168.1.0) that would be outbound would "Suppression" be advisable?
-
Thank you. I've gone ahead and recreated the LVL1 with direct feeds without the bogons. Great idea.
NP… I always recommend to use the original source of a feed.
Regarding the "Suppression" feature I'm wondering whether it applies to me.
Suppression, when enabled will remove RFC1918 and loopback addresses from a blocklist that are sometimes added incorrectly by a feed maintainer. Suppression will will also add a "+"icon to each blocked IP address (/32 and /24 only) in the Alerts tab Clicking that icon will allow removing the selected IP from the blocklists. Otherwise, to overcome an IP that is blocked, you will have to create a "Permit outbound" alias and add the Whitelisted IPs to the customlist. Then ensure that this permit rule is above the block/reject rules (rule order option).