Pass list with fqdn aliases not resolved?

[Urbaman75]

When using Aliases to define a Pass List, some aliases (mostly fqdn ones) are not resolved in the Pass List (View List in Networks Suricata should inspect and Protect is blank or only partially completed, even if the Alias tables are fully completed).

How to whitelist by fqdn?

Thank you very much.

[bmeeks]

Not sure I understand your question.

When you click the View List button on the INTERFACE SETTINGS page to view the contents of a Pass List, it will show you the IP addresses and subnets that were entered and the names of any FQDN aliases. But it will not show the resolved IP addresses for those FQDN aliases. The simple PHP code that displays that popup modal dialog does not do any DNS calls to resolve the name to IP. If you want to see the actual IP address or addresses the FQDN alias resolved to, then look under DIAGNOSTICS > TABLES and choose the FQDN alias name in the Table drop-down selector.

By their nature, FQDN aliases are somewhat dynamic as their IP addresses are expected to change. The blocking module makes a system call into the pf firewall engine in FreeBSD to check if the IP address pulled from a packet being inspected is contained in the pf table corresponding to the FQDN alias entered. A process called filterdns runs inside of pfSense that resolves FQDN aliases to an IP address. The filterdns process kicks off by default every 5 minutes. So, aliases are resolved every 5 minutes and the corresponding IP addresses stored in the appropriate pf tables.

[Urbaman75]

Hi,

I'll share the Alias with fdqn's (1), the corresponding firewall table with resolved IPs (2), and the blank popup (3, 4, 5) .

I do not know if the list is properly used by suricata or not (the popup shows IPs if the alias is made up of IPs).

1. 

2. 

3. 

4. 

5. 

[bmeeks]

@urbaman75:
You are doing this completely wrong. You should never need to edit the content of the EXTERNAL_NET variable. And doing so incorrectly will render nearly all of your configured rules useless. And, in fact, the settings you are currently attempting will do just that. None of your configured rules with $EXTERNAL_NET as a conditional will trigger (because EXTERNAL_NET is empty).

EXTERNAL_NET should, in almost all cases, be set to "!HOME_NET" (meaning it is the negated content of the $HOME_NET variable). This setting is handled automatically for you by the package code. Do NOT edit EXTERNAL_NET or change its setting from "default" without a very good reason and without fully understanding the ramifications of changing it.

I thought you were talking about putting an FQDN in a custom Pass List. What are you trying to accomplish here?

[Urbaman75]

@bmeeks I'm not editing the content, just checking the content is filled with the alias defined in the alias and in the Pass list.

I create the alias, I associate it in pass list, I associate the pass list in the External Network, and just open the "View List" popup, but it is empty.
When I use IPs instead of fqdns in the first alias definition, the popup is properly filled.

[bmeeks]

@urbaman75 said in Pass list with fqdn aliases not resolved?:

@bmeeks I'm not editing the content, just checking the content is filled with the alias defined in the alias and in the Pass list.

I create the alias, I associate it in pass list, I associate the pass list in the External Network, and just open the "View List" popup, but it is empty.
When I use IPs instead of fqdns in the first alias definition, the popup is properly filled.

You are totally missing my point. You should pretty much NEVER edit or otherwise change the EXTERNAL_NET setting in the IDS/IPS packages on pfSense. It's not working because an FQDN is never expected in EXTERNAL_NET and it is wrong to try and put one there.

Why are you trying to put a FQDN alias in EXTERNAL_NET in the first place?

[Urbaman75]

I'm trying to whitelist some IPs defined by those FQDNs from the rules.

[SteveITS]

@urbaman75 Pass List is here:

Are you using Inline Mode by chance? That removes the Pass List option.

[bmeeks]

@urbaman75 said in Pass list with fqdn aliases not resolved?:

I'm trying to whitelist some IPs defined by those FQDNs from the rules.

That is what a Pass List is for. Set the custom Pass List under the Pass List option under INTERFACE SETTINGS (if using Legacy Blocking Mode). Never change the External Net setting from "default". I don't think you understand what those variables are actually for. You need to do some research on Google so that you understand the role of EXTERNAL_NET and HOME_NET in the Suricata and Snort IDS/IPS products. These are not unique to pfSense. The same principles apply no matter where you use Suricata or Snort.

If you are using Inline IPS Mode, then there is no pass list logic needed. With Inline IPS Mode, if you want to whitelist an IP using Inline IPS Mode, you must do so with a custom PASS rule on the RULES tab. Just be aware that doing so will cause that host to bypass all rules as the "pass" action is checked first and results in no further inspections for traffic on that IP address. I will say that due to the ability of Inline IPS Mode to selectively drop individual packet streams, implementing a pass list via whitelisting a particular host with a custom PASS rule is generally not necessary. If a particular rule is dropping traffic, then tune that rule or remove it from the host in question using thresholding (a suppress list entry based on source or destination IP, for example).

[Urbaman75]

Thanks guys, it begins to make much more sense.
I'll check home_net and external_net variables, also check if going inline or not, and whitelisting or not.
Always used cfs with its IDS before and getting used to Suricata.

[bmeeks]

@urbaman75:
Generally speaking, HOME_NET contains the IP addresses of hosts on your internal networks that you want to protect. EXTERNAL_NET contains the IP addresses of the "bad guys", or hosts outside your local networks. Most rules for Suricata and Snort look similar to this:

alert tcp $EXTERNAL_NET any -> $HOME_NET any ....

The first part is the action for the rule. In this example that action is ALERT. Other valid actions are PASS, DROP, or REJECT.

The next part is the protocol. In this example, the rule will only trigger when the protocol is TCP. There are many other valid protocols rules may use.

The next two parts are the Source IP address and Port that must match. In this example, the source of the traffic must be an IP address that is within the EXTERNAL_NET variable. As I mentioned in an earlier post, that variable is typically given the value "!HOME_NET" which means any IP address not in the HOME_NET variable is considered to exist in EXTERNAL_NET. The "any" is the source port. It may be a specific port or "any" - which of course matches any source port.

The final two parts are the destination IP address and port. As described above for EXTERNAL_NET, this example rule requires the destination IP to be an IP address contained in the HOME_NET variable. Again, the destination port in this example is "any".

Taken together the parts I outlined above constitute the first "conditional criteria" that must all be true for the rule to trigger. If any of the conditions I described above are not met, then the rule will never trigger. For example, if the source IP is not within $EXTERNAL_NET, then the rule will not fire. Or if the target or destination IP is not within $HOME_NET, the rule will not fire. This is why I lecture folks on the dangers of modifying either EXTERNAL_NET or HOME_NET without understanding what they are for and the consequences of getting them configured wrong. Putting the wrong thing in either of these two variables can render the IDS/IPS powerless to detect threats.