pfSense rules, Snort, pfBlokerNG. Tips, Notes, and Insights.

Firewall rules order:

Firewall rules work in orders from the top to bottom if a connection matched a rule no further checks will be made.
For example: if you have two rules, one to block all connections to 5358 TCP/UDP port on the top and another one to allow this port to a specified host down it, the host will be blocked because it will match the block all rule on the top.
But if you add the block to 5358 TCP/UDP down of the allow 5358 TCP/UDP to the host rule, the allow rule will match and allow the connection and no other rules get checked.
So it is better to keep the most restrictive rules down (you can drag rules up/down) and add allow rules on the top.

pfBlokerNG rules order:

pfBlokerNG by default adds its GeoIP and DNSBL rules on the top, even if you add an allow rule on the top the next Cron job will automatically place pfblockerNG rules on the top again and will make the allow connection blocked after the next cron.
So it is recommended to configure pfBlokerNG rule order option -from pfBlokerNG → General → Rule order- to the second option, where it will make the order:
pfSense pass/match followed by pfBlokerNG pass/match, then pfSense block/reject followed by pfBlokerNG block/reject.



A Handy button:

There is a time-saving button when using pfSense rules, where you can copy a certain rule, very helpful if you are creating similar rules with few modifications.

Trusting Alexa:

Be careful when allowing AlexaTop Domains to whitelist when using DNSBL, Amazon Alexa ranks domains by the number of users visited these domains while using Alexa PUP toolbar, some malware domains can become on the top of Alexa domains.

The ultimate security dilemma:

Blocking the world with pfblockerNG GeoIP will highly affect usability, more overhead on the system. Many Websites/Services uses CDN (like Amai Technologies) where blocking many nearby countries will affect your connection, also noticed some CDN uses "Undefined IPs" in continent countries list.

Free beers from Cisco Snort:

For improved Snort detection It is recommended to add registered users rules which are free.
If you registered a free account at Snort, simply copy your generated Oinkmaster code from your Snort account to Snort→ Global Settings.
The catch is that rules are delayed 30 days after they have been released to Vulnerability Research Team (VRT) paid subscribers https://www.snort.org/snort_license, they still a very good option for less targeted personal and SME use.

You don't have a backup yet?:

Pfsense has configurations backup option; it is a good practice to regularly backup configurations with encryption, especially after major changes and before upgrading pfSense.
The config files can be restored on new pfSense installation even if the config file is older than the newly installed pfSense version, and even work on other architectures!.
But for stability, it is recommended to use the same pfSense version of the config file and then upgrade the pfSense.
Restoring pfSense configuration file is very simple, it will automatically do all the dirty work with no single action required, like restoring all the rules, installing the same packages, restoring all configurations made.
You can also choose to restore a specific configuration like firewall rules only.
If you use pfblockerNG, it is recommended to run cron manually after restoration, because you may receive errors from pfblockerNG and misbehaviors.

WIFI:

Atheros hardware cards are recommended for pfSense and supported in FreeBSD 10.3 Release kernel ath(4) (Current pfSense release is based on FreeBSD 10.3). I have success with Tenda Ralink W311Ma run(4) for FreeBSD, OpenBSD, pfSense, Linux, and OSX, it is inexpensive (less than $10) and just does the job.

Troubleshooting wisdom:

Many complicated issues can be fixed with just a restart, restarting services (like restarting PHP-FPM from the console if you have issues accessing or browsing the GUI), or the system.

False alerts teach you:

Better to receive false positive or false alerts than having false negatives, you will be more sure that you don't miss an alert, and most importantly you will learn more about these alerts from diagnosing and researching them.

You don't have to Answer

It is recommended to use DROP than REJECT for the Internet, with REJECT you are telling the scanner/abuser that you have a firewall and the packet was rejected (Which the attacker might find this interesting!), with DROP no info sent to the abuser.
REJECT can be better for some applications to not wait long till timeout.
So REJECT better to be used in internal networks than DROP.


Learning from uncertainty:

When in doubt about an unknown connection to you, better to block it and see what is affected with the blocking, at least you will learn what this connection is related to.

-”If security were all that mattered, computers would never be turned on, let alone hooked into a network with literally millions of potential intruders.” — Dan Farmer, System Administrators Guide to Cracking.

-”Security is always excessive until it's not enough.” — Robbie Sinclair, Head of Security, Country Energy, NSW Australia.

-”Those who do not archive the past are condemned to retype it!” — Garfinkel and Spafford, Practical UNIX Security (first edition).

-”Only the paranoid survive.” — Andrew Grove, Former Intel CEO, TIME's 1997 Man of the Year.