What security measures do you have in place at PFSense?
-
pfSense is like a Boeing 737-800 : flying comfort and safety rely mostly on the pilot's skill.
The 'risk' attributed by plane the is close to none.( No MAX jokes please )
No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
@yet_learningpfsense said in What security measures do you have in place at PFSense?:
am studying Suricata a bit but feel it is inadequate
Inadequate for what? What are you trying to achieve?
-
@gertjan
Thank you, I was fantasizing that a great hacker could break through PFSense from a global IP address. But I am relieved to hear that I don't have to worry about that. -
@stephenw10
I am trying to prevent or detect attacks from crackers. I am looking for systems that can detect port scans, such as Nmap, by inbound connections, etc. I'm also hoping to find something that would allow Fortigate to resolve names from IP addresses and write them together, etc. -
pfSense blocks all incoming connections by default so that's extremely unlikely.
If you have any pass rules on WAN to allow access those should be locked down as far as possible.
Outgoing connections can be restricted but that's always a security vs convenience trade-off.
Steve
-
Suricata running on WAN will detect connection attempts if you're only trying to log them. They are still blocked by default.
@yet_learningpfsense said in What security measures do you have in place at PFSense?:
something that would allow Fortigate to resolve names from IP addresses and write them together, etc.
Not really sure what you mean there. Like pass alert lists to some Fortigate device for analysis?
-
It depends on what you want to achieve. If you are talking about hardening the firewall itself then it's all about updates+patches and don't open anything up. If you are talking about protecting the users then Suricata (and Snort) have a robust free ruleset to use but can use the same rulesets that Cisco devices use if you pay. There is DNS filtering and GEO-IP Blocking through pfBlocker. I use the GEO-IP to match anything in the pfBlocker North America list as an allow list for Port Forwards. Mobile VPN users either connect from within the USA or they need to give us the IP if they are remote. Remote access isn't even available to be exploited unless you want it to be. For us, remote access is a port forward to the LAN IP from a specific remote IP on an off port.
Suricata can detect port scans and block them. Can you simulate an attack that isn't detected? Reverse DNS would resolve names from IP addresses but I'm not sure how you would have pfSense giving that information to the Fortigate. Why have pfSense in that mix?
-
@stephenw10
Thank you very much. Previously, every Linux device connected to a router with a global IP address would display an error screen after about a minute of inserting the LAN cable, so I had thought that it might be susceptible to inbound attacks. However, it seems that the likelihood of this is very low, and it was probably just a flaw in the Linux system. It is also said that outbound connections could potentially allow packets through if timed correctly, but again, the likelihood of this is very low. This was very helpful. -
Thank you very much. I have also tried installing pfBlocker and GEO-IP blocking. Is the Cisco rule set a paid license for ETPro? I was not aware of the Cisco rule set, so I will consider implementing it.
I do not use remote access due to the associated risks, but I would like to use it if there is an opportunity because I think I will receive immediate notifications if there is access to the port.
Regarding reverse DNS name resolution, it was implemented in Fortigate. I hope that PFSense will have such a feature as well (Fortigate's reverse DNS was very legible and easy to understand
-
@yet_learningpfsense said in What security measures do you have in place at PFSense?:
every Linux device connected to a router with a global IP address would display an error screen
What error were they getting? What has the global IP address? (I'm assuming that's a Public IP address?) The firewall is just routing the traffic. It shouldn't cause a specific error on the Linux boxes unless it's something like a remote server being blocked in Suricata or Unbound failing to resolve DNS.
@yet_learningpfsense said in What security measures do you have in place at PFSense?:
It is also said that outbound connections could potentially allow packets through if timed correctly,
What said that where? I guess technically it could be possible but only because an outbound connection creates a state in the firewall table that would allow data to come back. That's how your machine is able to make a request from a remote site AND receive back the response. That's just how networks operate. Other than that I don't know what that is referencing.
@yet_learningpfsense said in What security measures do you have in place at PFSense?:
Is the Cisco rule set a paid license for ETPro? I was not aware of the Cisco rule set, so I will consider implementing it.
Look for the Cisco Talos brand. It's been a while so I could be off a bit but I believe Cisco purchased Snort and use their technology in Talos. You have the option in Suricata's Global Settings to Install Snort Rules. You can see there that the paid rules are "by Talos". I believe the free rules are the same as the paid rules, just not the latest. You would need the paid ruleset for the rules to be the most up to date. I don't know about the ETPro ruleset.
Where would you want to see the rDNS in pfSense? The Firewall log allows you to see it if you click the bold black i next to the blocked IP.
-
@yet_learningpfsense I would use the snort package that can be installed on pfSense.
It can be set up to detect and block nmap scans and many other attacks. Yes pfSense has IPS/IDS options.
(IPS/IDS Snort blocking nmap scans)
(Snort has many options for scan blocks can be used depending on what rule sets you use)
(Snort has a wide range of categories you can use with each ruleset) -
This post is deleted! -
@stewart
Thank you. I used a minor distribution of Linux and it was almost 10 years ago, so I didn't take a screenshot of the error message. However, I have confirmed several times that it occurred after connecting the Linux machine with a clean installation to the router using a LAN cable.I am copying and pasting this reply, which I translated using ChatGPT, so the meaning of the sentence may be difficult to convey. I also asked the same question on other websites, and what I meant is that even in outbound communication, if the timing and conditions are right, a cracker's packet can pass through the router. Although it is technically possible, I do not know if it can actually be done.
I did not know that Cisco had acquired Snort... If the free rules are only slightly behind, I would prefer to use the free ones. As for name resolution on pfsense, it is indeed visible by clicking on "i," but on Fortigate, name resolution is auto performed for all IP addresses without the need to click on something like "i," and the company name is displayed
-
@jonathanlee
Thank you. I did not know that Suricata can be configured to block Nmap attacks. The image you provided is very helpful. Crackers are said to "taste" the target router,and when they attack the same target again (the victim notices an anomaly and resets the entire network), they use Nmap to investigate the manufacturer and model of the router. If such a thing happens, knowing whether the attacker came to "taste" with Nmap could be a clue to record the attacker's footsteps.
