Linux Firewalls - Michael Rash [87]
[2-32787] SYN tcp=237 udp=0 icmp=0 dangerlevel: 3
The blocking rules can be trumped by explicitly ignoring any IP address that has a danger level of zero within the /etc/psad/auto_dl file, but it is impossible to list all of the important IP addresses in this manner. The TCP Idle scan also (see Chapter 3 for a detailed explanation) requires that the source address of a scan is spoofed, so not only can spoofed source addresses be used just to trigger the active response machinery on the target, but they can also be used to accomplish real scans, as well.
This example provides a strong motivation against configuring psad to respond to port scans, and for instead configuring it to respond only to malicious traffic that must travel over established TCP connections.
Integrating psad Active Response with Third-Party Tools
Many software vendors build in APIs to facilitate the ability of third-party software to manage or otherwise interact with their applications. This can increase the user and installation base of an application because it provides a degree of flexibility, plugability, and scriptability that is otherwise unattainable. An example from the world of commercial security products is the OPSEC API from Check Point, which allows third-party applications to manage Check Point firewalls from remote systems (see http://www.opsec.com). Given that commercial products sometimes open APIs to allow other applications to easily integrate, it follows that open source projects would adhere to this practice to an even greater degree, and psad is no exception to this rule.
Command-Line Interface
psad offers more than just the ability to block offending IP addresses with dynamically added (and deleted) iptables rules. The active response features can also be easily integrated with third-party tools through a command-line interface (which makes the response features easily scriptable) or, more directly, by communicating with the running psad daemon over a Unix domain socket. The following are some of the advantages of using psad to manage the iptables ruleset instead of building this functionality directly into a third-party application:
The ability to expire rules based on a timer is built in to psad, and therefore would not have to be independently developed.
psad manages the insertion and deletion of dynamically generated rules within its own custom chains. This guarantees the separation of psad rules from any existing iptables policy.
psad does not add duplicate rules against an IP address or network if blocking rules already exist in the psad chains.
psad consults the /etc/psad/auto_dl file to make sure that it doesn't block whitelisted IP addresses or networks.
Status information on currently blocked IP addresses can easily be viewed with the psad --Status command.
A listing of the custom psad chains can be viewed with the psad --fw-list command. This makes it easy to distinguish iptables rules that are created by psad from other rules within a complex filtering policy.
Note
All active response capabilities available via a command-line invocation of psad require that an instance of psad is running on the system as a daemon. If one is not, an error is generated to inform you that psad is not currently running.
Adding Blocking Rules
You can use the --fw-block-ip command-line argument to manually add blocking rules for a specific IP address or network to the custom psad chains. For example:
[iptablesfw]# psad --fw-block-ip 144.202.X.X
[+] Writing 144.202.X.X to socket. psad will add the IP address within 5 seconds.
Once the CHECK_INTERVAL timer expires in the running psad daemon, the IP address is added to the blocking chains, with the duration set by the variable AUTO_BLOCK_TIMEOUT:
Mar 6 01:30:40 iptablesfw psad: added iptables auto-block against 144.202.X.X for
3600 seconds
Removing Blocking Rules
To remove all blocking rules for a specific IP address or network, you can use the --fw-rm-block-ip command-line argument:
[iptablesfw]# psad