PSD module?

Which version of ASL are you using. PSD works fine for me (on my previous 3.2, and my current 4.002).

Cheers,

Karl 

I am not using ASl. But I want to have it's PSD module for my Router (if possible). 

I'm assuming your router is a linux box [:)]

You will need to parts.

1. you need to compile the PSD option in to your kernel, either into the kernel itself, or as a module that you can later modprobe/insmod.

2. you will need the latest version (I'm not sure what it is, or when psd was first included) of iptables. when you compile it, it will create the relevant shared library objects in somewhere like /lib/iptables (the relevant one is libipt_psd.so)

Hope this helps,

Karl 

Yes, my Router is running Linux. Where can I get thome modules?
Thx for your help. 

I'm assuming you already have a fairly up to date kernel? What kernal version and which distribution are you running?

You'll need to get the option compiled into the kernel, if it isn't already (if it's a module, take a peek around in 

/lib/modules/`uname -r`/kernel/net/ipv4/netfilter/

There will be a module summat like "ipt_psd.o"

Next you need to get iptables from  http://netfilter.org.

Depending on your distro, you maybe able to get it via RPM, gentoo will let you "emerge sync" and then "emerge net-firewall/iptables" otherwise you'll have to compile it.

The module will appear in somewhere like /lib/iptables/libipt_psd.so

You can then create rules that use it :


iptables -A INPUT -i eth0 -m psd -m limit --limit 1/h -j ULOG --ulog-prefix "PSD"
iptables -A INPUT -i eth0 -m psd -j REJECT


Here, I'm using ulogd, a userspace logging daemon, which allows me to a) log somewhere unique, rather than clutter up my kernel logs and b) log to a MySQL table  [:$])

Hope this helps,

Karl 

Hi Karl,
I'm runnung SuSE 8.1 at the moment (2.4.19). My iptables are running  
So, it is possible to use this module by setting a rule like you posted? When I set those rules in the INPUT and FORWARD chain, all portscan should be filtered? Can I also use "DROPW instead of "REJECT"?

Thanks for your help! I tried google, but there's not a lot of documentation. 

No, documentation seems a little short, however, there is a good example of using different modules here:

 http://the-devil.dnsalias.net/home/extremist 

As it says, it is a bit extreme!!

You can use rules like I posted, if you have the modules, and the relevant libraries (/lib/iptables). Just adapt what I posted for your needs. If you have a DROPW target, then just substitute it for REJECT in my rules.

My preference is for REJECT targets. There seems to be 2 main trains of thought:

1. If someone tries to connect to a service on your server, and they're not allowed, DROP the packets, or TARPIT them.

2. Same, but REJECT them.

(1) is fine, but it leaves a deliberate attacker with a view of "oooh, I wonder what they're protecting, I wonder if I can get at it another way around?.... whereas  (2) leaves them with the impression that the server isn't actually listening on that port.

After my ACCEPT rules, I generally finish a chain with something like:

ipt -A INPUT -p tcp -j REJECT --reject-with tcp-reset
ipt -A INPUT -j REJECT --reject-with icmp-port-unreachable

This will have the effect of rejecting packets as if the server protected by them wasn't listening anyway.

Just my 2p,

Hope it helps,

Karl 

No, documentation seems a little short, however, there is a good example of using different modules here:

 http://the-devil.dnsalias.net/home/extremist 

As it says, it is a bit extreme!!

You can use rules like I posted, if you have the modules, and the relevant libraries (/lib/iptables). Just adapt what I posted for your needs. If you have a DROPW target, then just substitute it for REJECT in my rules.

My preference is for REJECT targets. There seems to be 2 main trains of thought:

1. If someone tries to connect to a service on your server, and they're not allowed, DROP the packets, or TARPIT them.

2. Same, but REJECT them.

(1) is fine, but it leaves a deliberate attacker with a view of "oooh, I wonder what they're protecting, I wonder if I can get at it another way around?.... whereas  (2) leaves them with the impression that the server isn't actually listening on that port.

After my ACCEPT rules, I generally finish a chain with something like:

ipt -A INPUT -p tcp -j REJECT --reject-with tcp-reset
ipt -A INPUT -j REJECT --reject-with icmp-port-unreachable

This will have the effect of rejecting packets as if the server protected by them wasn't listening anyway.

Just my 2p,

Hope it helps,

Karl