Yet another question on iptables, firewall and, or net-filter

Hi friends!

If I set all my default policies to *DROP* for INPUT, FORWARD and, or
OUTPUT chains, do I still need to add the following rules?

## Anti-spoofing
iptables -A INPUT -m state --state INVALID -j DROP

## Watch for a basic packet crafting vulnerabilities, these are totally
## invalid and are not filtered with --state INVALID
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

## new tcp packet (not established) and no syn bit... must be trash
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

## drop reserved addresses, not valid on the open Internet
iptables -A INPUT -i ${WIFACE} -s 224.0.0.0/4 -j DROP
iptables -A INPUT -i ${WIFACE} -s 240.0.0.0/5 -j DROP

The above said WIFACE is interface (eth1) on the WAN side of this machine.

Thank you and thanks in anticipation for your valuable comments and, or
suggestions.

Regards,
--
Dr Balwinder S "bsd" Dheeman Registered Linux User: #229709
Anu's Linux@HOME Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India Distros: Ubuntu, Fedora, Knoppix
Home: http://cto.homelinux.net/~bsd/ Visit: http://counter.li.org/

On 2006-10-30, Balwinder S "bsd" Dheeman <(E-Mail Removed)> wrote:

> Thank you and thanks in anticipation for your valuable comments and, or
> suggestions.

You might take a look at Arno's iptables firewall. It's configured by
default for NAT and statefull outgoing connections only, all else blocked.
He uses a shell config script you edit to customize the actual iptables
rules. A great firewall and learning tool.

http://rocky.eld.leidenuniv.nl/

nb

On Mon, 30 Oct 2006 19:23:31 +0530, in comp.os.linux.networking "Balwinder S \"bsd\" Dheeman" <(E-Mail Removed)> wrote:
> If I set all my default policies to *DROP* for INPUT, FORWARD and, or
> OUTPUT chains, do I still need to add the following rules?

1. Individual rules will allow you to keep counts for special
cases. You can see the counts with:
iptables -vL

2. Individual rules which use -j DROP near the beginning of the
rules set can speed up the filtering, and also simplify the
rule set (once you've dropped a packet, later rules don't have
to consider it).

> ## Anti-spoofing
> iptables -A INPUT -m state --state INVALID -j DROP

> ## Watch for a basic packet crafting vulnerabilities, these are totally
> ## invalid and are not filtered with --state INVALID
> iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
> iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

What is your reference for the statement in the above comments that
these are "not filtered with --state INVALID"?

> ## new tcp packet (not established) and no syn bit... must be trash
> iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

> ## drop reserved addresses, not valid on the open Internet
> iptables -A INPUT -i ${WIFACE} -s 224.0.0.0/4 -j DROP
> iptables -A INPUT -i ${WIFACE} -s 240.0.0.0/5 -j DROP

> The above said WIFACE is interface (eth1) on the WAN side of this machine.

> Thank you and thanks in anticipation for your valuable comments and, or
> suggestions.

You're welcome.

--
Dale Dellutri <(E-Mail Removed)> (lose the Q's)

"Balwinder S \"bsd\" Dheeman" <(E-Mail Removed)> wrote:
> Hi friends!

> If I set all my default policies to *DROP* for INPUT, FORWARD and, or
> OUTPUT chains, do I still need to add the following rules?

I'm no expert but it's probably a good idea to put them before other
rules and get rid of the trash. And it has the potential to prevent
over-loading rules that may be looking to accept similar incoming.

> ## Anti-spoofing
> iptables -A INPUT -m state --state INVALID -j DROP

Take out the trash before it enters other rules.

> ## Watch for a basic packet crafting vulnerabilities, these are totally
> ## invalid and are not filtered with --state INVALID
> iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
> iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

These rules could be added before a rule such as

iptables -A INPUT -p tcp --tcp-flags SYN -j ACCEPT

in order to prevent SYN,{RST,FIN} floods from entering it.

> ## new tcp packet (not established) and no syn bit... must be trash
> iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

As the comment says, trash.

> ## drop reserved addresses, not valid on the open Internet
> iptables -A INPUT -i ${WIFACE} -s 224.0.0.0/4 -j DROP
> iptables -A INPUT -i ${WIFACE} -s 240.0.0.0/5 -j DROP

> The above said WIFACE is interface (eth1) on the WAN side of this machine.

More trash.

--
Clifford Kite

Hello,

Balwinder S "bsd" Dheeman a écrit :
>
> If I set all my default policies to *DROP* for INPUT, FORWARD and, or
> OUTPUT chains, do I still need to add the following rules?

Of course not. Since the default policies are already set to DROP, you
only need ACCEPT and REJECT rules.

> ## Anti-spoofing
> iptables -A INPUT -m state --state INVALID -j DROP

Why is this rule labelled "anti-spoofing" ?

> ## Watch for a basic packet crafting vulnerabilities, these are totally
> ## invalid and are not filtered with --state INVALID
> iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
> iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

Due to flag precedence, theses combinations are not invalid from a
receiver's point of view, otherwise --syn would have checked that the
FIN flag is cleared. "Be strict in what you send and tolerant in what
you accept". The only reason why you would want to drop them is a broken
TCP/IP stack implementation.

> ## new tcp packet (not established) and no syn bit... must be trash
> iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Or may be a late packet (according to the conntrack timers).

> ## drop reserved addresses, not valid on the open Internet
> iptables -A INPUT -i ${WIFACE} -s 224.0.0.0/4 -j DROP
> iptables -A INPUT -i ${WIFACE} -s 240.0.0.0/5 -j DROP

There are many other invalid address ranges on the internet.

Dear friends!

Thanks, for your comments.

I attempted is use Arno's firewall script; Although it is quite good,
but it slows down the network. So I have re-written one from scratch and
is working fine.

My script is logging a lot of un-wanted packets as follows:

$ tail /var/log/firwall.log
Nov 18 12:25:57 cto kernel: INPUT: IN=eth1 OUT=
MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=59.144.179.92
DST=192.168.1.2 LEN=48 TOS=0x00 PREC=0x00 TTL=126 ID=7816 DF PROTO=TCP
SPT=3335 DPT=135 WINDOW=16384 RES=0x00 SYN URGP=0
Nov 18 12:29:02 cto kernel: INPUT: IN=eth1 OUT=
MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=59.144.184.16
DST=192.168.1.2 LEN=64 TOS=0x00 PREC=0x00 TTL=46 ID=15456 DF PROTO=TCP
SPT=4408 DPT=135 WINDOW=53760 RES=0x00 SYN URGP=0
Nov 18 12:29:05 cto kernel: INPUT: IN=eth1 OUT=
MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=59.144.184.16
DST=192.168.1.2 LEN=64 TOS=0x00 PREC=0x00 TTL=46 ID=15833 DF PROTO=TCP
SPT=4408 DPT=135 WINDOW=53760 RES=0x00 SYN URGP=0
Nov 18 12:29:19 cto kernel: INPUT: IN=eth1 OUT=
MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=204.16.210.120
DST=192.168.1.2 LEN=434 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=UDP
SPT=34701 DPT=1026 LEN=414
Nov 18 12:29:19 cto kernel: INPUT: IN=eth1 OUT=
MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=204.16.210.120
DST=192.168.1.2 LEN=434 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=UDP
SPT=34701 DPT=1027 LEN=414
Nov 18 12:29:19 cto kernel: INPUT: IN=eth1 OUT=
MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=204.16.210.120
DST=192.168.1.2 LEN=434 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=UDP
SPT=34701 DPT=1026 LEN=414
Nov 18 12:30:42 cto kernel: INPUT: IN=eth1 OUT=
MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=59.144.254.91
DST=192.168.1.2 LEN=48 TOS=0x00 PREC=0x00 TTL=126 ID=16190 DF PROTO=TCP
SPT=3281 DPT=135 WINDOW=65535 RES=0x00 SYN URGP=0
Nov 18 12:30:45 cto kernel: INPUT: IN=eth1 OUT=
MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=59.144.254.91
DST=192.168.1.2 LEN=48 TOS=0x00 PREC=0x00 TTL=126 ID=16603 DF PROTO=TCP
SPT=3281 DPT=135 WINDOW=65535 RES=0x00 SYN URGP=0
Nov 18 12:32:38 cto kernel: INPUT: IN=eth1 OUT=
MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=59.144.242.130
DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 TTL=126 ID=60368 PROTO=ICMP
TYPE=8 CODE=0 ID=256 SEQ=45921
Nov 18 12:32:45 cto kernel: INPUT: IN=eth1 OUT=
MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=59.144.181.250
DST=192.168.1.2 LEN=64 TOS=0x00 PREC=0x00 TTL=46 ID=58860 DF PROTO=TCP
SPT=1717 DPT=135 WINDOW=53760 RES=0x00 SYN URGP=0

What kind of packets are these?

Is'nt the mac address logged above suspicious?

How do I drop these packets? I don't want to log these any more.

I also see a lot of failed intrusion attempts via ssh, do I need to
report these?

If yes, Is there a tool/script available to analyze iptables and, or
sshd logs which can generate such complaints automagically?

Thanking you in anticipation.

Regards,
--
Dr Balwinder S "bsd" Dheeman Registered Linux User: #229709
Anu's Linux@HOME Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India Distros: Ubuntu, Fedora, Knoppix
Home: http://cto.homelinux.net/~bsd/ Visit: http://counter.li.org/

Balwinder S "bsd" Dheeman wrote:
> Dear friends!
>
> Thanks, for your comments.
>
> I attempted is use Arno's firewall script; Although it is quite good,
> but it slows down the network. So I have re-written one from scratch and
> is working fine.
>
> My script is logging a lot of un-wanted packets as follows:
>
> $ tail /var/log/firwall.log
> Nov 18 12:25:57 cto kernel: INPUT: IN=eth1 OUT=
> MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=59.144.179.92
> DST=192.168.1.2 LEN=48 TOS=0x00 PREC=0x00 TTL=126 ID=7816 DF PROTO=TCP
> SPT=3335 DPT=135 WINDOW=16384 RES=0x00 SYN URGP=0
> Nov 18 12:29:02 cto kernel: INPUT: IN=eth1 OUT=
> MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=59.144.184.16
> DST=192.168.1.2 LEN=64 TOS=0x00 PREC=0x00 TTL=46 ID=15456 DF PROTO=TCP
> SPT=4408 DPT=135 WINDOW=53760 RES=0x00 SYN URGP=0
> Nov 18 12:29:05 cto kernel: INPUT: IN=eth1 OUT=
> MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=59.144.184.16
> DST=192.168.1.2 LEN=64 TOS=0x00 PREC=0x00 TTL=46 ID=15833 DF PROTO=TCP
> SPT=4408 DPT=135 WINDOW=53760 RES=0x00 SYN URGP=0
> Nov 18 12:29:19 cto kernel: INPUT: IN=eth1 OUT=
> MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=204.16.210.120
> DST=192.168.1.2 LEN=434 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=UDP
> SPT=34701 DPT=1026 LEN=414
> Nov 18 12:29:19 cto kernel: INPUT: IN=eth1 OUT=
> MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=204.16.210.120
> DST=192.168.1.2 LEN=434 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=UDP
> SPT=34701 DPT=1027 LEN=414
> Nov 18 12:29:19 cto kernel: INPUT: IN=eth1 OUT=
> MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=204.16.210.120
> DST=192.168.1.2 LEN=434 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=UDP
> SPT=34701 DPT=1026 LEN=414
> Nov 18 12:30:42 cto kernel: INPUT: IN=eth1 OUT=
> MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=59.144.254.91
> DST=192.168.1.2 LEN=48 TOS=0x00 PREC=0x00 TTL=126 ID=16190 DF PROTO=TCP
> SPT=3281 DPT=135 WINDOW=65535 RES=0x00 SYN URGP=0
> Nov 18 12:30:45 cto kernel: INPUT: IN=eth1 OUT=
> MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=59.144.254.91
> DST=192.168.1.2 LEN=48 TOS=0x00 PREC=0x00 TTL=126 ID=16603 DF PROTO=TCP
> SPT=3281 DPT=135 WINDOW=65535 RES=0x00 SYN URGP=0
> Nov 18 12:32:38 cto kernel: INPUT: IN=eth1 OUT=
> MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=59.144.242.130
> DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 TTL=126 ID=60368 PROTO=ICMP
> TYPE=8 CODE=0 ID=256 SEQ=45921
> Nov 18 12:32:45 cto kernel: INPUT: IN=eth1 OUT=
> MAC=00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 SRC=59.144.181.250
> DST=192.168.1.2 LEN=64 TOS=0x00 PREC=0x00 TTL=46 ID=58860 DF PROTO=TCP
> SPT=1717 DPT=135 WINDOW=53760 RES=0x00 SYN URGP=0
>
> What kind of packets are these?

Clueless Windows boxes hollering for company.

> Is'nt the mac address logged above suspicious?

It is the whole Ethernet header with two MAC's and a type/length
indicator.

The log data 00:08:74:48:23:bb:00:08:5c:00:00:01:08:00 is split:

00:08:74:48:23:bb destination MAC
00:08:5c:00:00:01 source MAC
08:00 type/length (here: IP)


> How do I drop these packets? I don't want to log these any more.

Create a filter to drop them quietly.

I have an extra chain, named ext-incoming, to drop them from
both INPUT and FORWARD chains. This kills any Windows native
networking (but not normal TCP/IP) via the router. There are
similar rules in the OUTPUT chain to prevent the internal
network Windowses from sending similar noise to the output
interface.

An excerpt from my iptables setup shell script:

# Silently drop packets from clueless Windows hosts

$IPT -A ext-incoming -p tcp --dport 135:139 -j DROP
$IPT -A ext-incoming -p tcp --dport 445 -j DROP

$IPT -A ext-incoming -p udp --dport 135:139 -j DROP
$IPT -A ext-incoming -p udp --dport 445 -j DROP

> I also see a lot of failed intrusion attempts via ssh, do I need to
> report these?

They are usually script kiddies / zombies running a break-in
script. If the log markings and the load of continually starting
and stoppping the SSH daemon annoys you, move SSH to an alternate
port. The scripts currently target port TCP/22 only.

HTH

--

Tauno Voipio
tauno voipio (at) iki fi