| 1 |
The main requirement for an iptables configuration to be compatible with psad |
|---|
| 2 |
is simply that iptables logs packets. This is commonly accomplished by adding |
|---|
| 3 |
rules to the INPUT and FORWARD chains like so: |
|---|
| 4 |
|
|---|
| 5 |
iptables -A INPUT -j LOG |
|---|
| 6 |
iptables -A FORWARD -j LOG |
|---|
| 7 |
|
|---|
| 8 |
The rules above should be added at the end of the INPUT and FORWARD chains |
|---|
| 9 |
after all ACCEPT rules for legitimate traffic and just before a corresponding |
|---|
| 10 |
DROP rule for traffic that is not to be allowed through the policy. Note that |
|---|
| 11 |
iptables policies can be quite complex with protocol, network, port, and |
|---|
| 12 |
interface restrictions, user defined chains, connection tracking rules, and |
|---|
| 13 |
much more. There are many pieces of software such as Shorewall and Firewall |
|---|
| 14 |
Builder, that build iptables policies and take advantage of the advanced |
|---|
| 15 |
filtering and logging capabilities offered by iptables. Generally the policies |
|---|
| 16 |
built by such pieces of software are compatible with psad since they |
|---|
| 17 |
specifically add rules that instruct iptables to log packets that are not part |
|---|
| 18 |
of legitimate traffic. Psad can be configured to only analyze those iptables |
|---|
| 19 |
messages that contain specific log prefixes (which are added via the |
|---|
| 20 |
--log-prefix option), but the default as of version 1.3.2 is for psad to |
|---|
| 21 |
analyze all iptables log messages for port scans, probes for backdoor |
|---|
| 22 |
programs, and other suspect traffic. See the list of features offered by psad |
|---|
| 23 |
for more information (http://www.cipherdyne.org/psad/features.html). |
|---|
