Which appliance for Snort and pfSense in SMB?

---

Hello,

We are a small company of more or less 10 computers.
I would like to use the pfSense firewall on our network, but am also considering using Snort on the same appliance in the future.
On Netgate's website, there are four appliances recommended for pfSense for SMBs.
Considering the number of computers on our 1Gb network, do you think the SG-1100 is enough to support both Snort and pfSense.
I guess my question is, ok it will do pfSense, but will the SG-1100 be powerful enough to also do Snort?
How many applications can the SG-1100 support at the same time? If we also want to add a VPN in addition to Snort and pfSense, is it strong enough to support all three services on a 10 computers network?
Should you only choose an appliance depending the size of your company, and not how many services you want to use?

Thank you.

@Thomas-Pondant,

In our experience, issue is not of power but performance on these smaller devices. So for example, ARM CPUs are good and can do alot but they are not built around performance. Intel CPUs have performance in mind.

The same would be true for the NICs too...Intel NICs seem to be what the original pfSense was built on..but never know what is onboard.

As far as snort, if performance isn't an issue then it will do snort...but if you're planning on also doing everything else such as VPNS too...and to pass all traffic through then it's not just about power but performance as well.

We had 2 of their enterprise products when we upgraded, we were able to build our own hardware appliance for a cost saving with better CPU, more RAM and INTEL multiple NIC addon (which was an expensive add on) with M.2 storage than the Netgate.

Having said that, the SG-1100 is an improvement on the original SG-1000. So do a little research cost wise and hardware wise to see what you really need.

Thanks, Ronnie! I'll keep that in mind.

I have another question regarding pfSense.
Maybe you explain that in some pfSense episode, but I haven't watched them all yet.

On a network which has been operating for a long time without firewall, how do you know which ports need to be open?

I'll explain why I'm asking this.
Our ISP firewall has three levels: low (which allows all incoming WAN connections), medium (which allows only port-forwarded connections), and high (which blocks all connections except those allowed through the firewall).
When I set it to high, our electronic payment terminal (that little box you use at a store to pay with your credit card) wasn't working anymore. When I set it to low again, the terminal was again working. So I guess a port is open for the payment to be verified by a credit card entity or something.

How am I supposed to know which port is supposed to be kept open for this terminal or for any other application for that matter? Since the ISP router doesn't show which ports are commonly used, should I use Nmap maybe to find the IP address of that terminal first, and then find which ports it has open. Is this the common way to do this? Or is there some kind of tool to do that?

@Thomas-Pondant,

Great question.

On pfSense, the default setup is that on the WAN port, all traffic is denied unless explicit allowed. This allows for Whitelisting. Only opening port from the outside IF needed.

Most firewalls, including pfSense. They are stateful firewalls which means that only traffic that was requested from the inside to the destination will be allowed as well as the return traffic.

The only rules essentially that you must set then is if you want to block some type of traffic from going out and making a request. Thereby, also blocking returning traffic as well. E.g. blocking facebook during work hours.

You may have to gather a list of sites that you definitely want allowed...make sure those are not blocked. Then block only traffic you don't want someone to be able to make a request to.

You can use many different tools to do this but I would begin simply and see if the rules are enough. If not, then use additional tools as what you've mentioned.