Firestarter in FC2

Alexander Dalloz alexander.dalloz at uni-bielefeld.de
Wed Oct 13 15:06:57 UTC 2004


Am Di, den 12.10.2004 schrieb Carlos Alberto Alves um 18:13:

> Firestarter 0.9.3 running under FC2 kernel 2.6.5-1.358
> 
> [root at localhost root]# iptables -vnL
> Chain INPUT (policy DROP 0 packets, 0 bytes)
>   pkts bytes target     prot opt in     out     source 
> destination
>      0     0 ACCEPT     tcp  --  *      *       200.227.128.20 
> 0.0.0.0/0           tcp flags:!0x16/0x02
>     25  4755 ACCEPT     udp  --  *      *       200.227.128.20 
> 0.0.0.0/0

allowing incoming tcp/udp from 200.227.128.20

>      0     0 ACCEPT     tcp  --  *      *       200.227.128.21 
> 0.0.0.0/0           tcp flags:!0x16/0x02
>      0     0 ACCEPT     udp  --  *      *       200.227.128.21 
> 0.0.0.0/0

allowing incoming tcp/udp from 200.227.128.21

>     32  2944 ACCEPT     all  --  lo     *       0.0.0.0/0 
> 0.0.0.0/0

allowing incoming localhost traffic

>      0     0 LR         all  --  *      *       224.0.0.0/8 
> 0.0.0.0/0
>      0     0 LR         all  --  *      *       0.0.0.0/0 
> 224.0.0.0/8
>      0     0 LR         all  --  *      *       255.255.255.255 
> 0.0.0.0/0

redirecting traffic from these nets or to these nets to the log+reject
chain

So far seems ok. (not knowing your situation behind the firewall)

>      0     0 LR         all  --  *      *       0.0.0.0/0            0.0.0.0

but now redirecting all further incoming traffic to log+reject? from
this point onwards the rest of the rules are ignored!

>      0     0 DROP       all  --  *      *       0.0.0.0/0 
> 0.0.0.0/0           state INVALID
>      0     0 LR         all  -f  *      *       0.0.0.0/0 
> 0.0.0.0/0           limit: avg 10/min burst 5
>      0     0 ACCEPT     47   --  *      *       0.0.0.0/0 
> 0.0.0.0/0
>      0     0 LR         tcp  --  *      *       0.0.0.0/0 
> 0.0.0.0/0           tcp flags:!0x16/0x02 state NEW
>     11   508 LR         all  --  *      *       0.0.0.0/0 
> 0.0.0.0/0
> 
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>   pkts bytes target     prot opt in     out     source 
> destination
> 
> Chain OUTPUT (policy DROP 552 packets, 24840 bytes)
>   pkts bytes target     prot opt in     out     source 
> destination
>     32  2944 ACCEPT     all  --  *      lo      0.0.0.0/0 
> 0.0.0.0/0
>      0     0 LR         all  --  *      *       224.0.0.0/8 
> 0.0.0.0/0
>      0     0 LR         all  --  *      *       0.0.0.0/0 
> 224.0.0.0/8
>      0     0 LR         all  --  *      *       255.255.255.255 
> 0.0.0.0/0

so far ok

>      0     0 LR         all  --  *      *       0.0.0.0/0            0.0.0.0

now again a rule which catches all outgoing traffic and redirecting it
to the log+reject chain, mean: rest is bypassed

>      0     0 DROP       tcp  --  *      *       0.0.0.0/0 
> 0.0.0.0/0           tcp flags:!0x16/0x02 state NEW
>      0     0 DROP       all  --  *      *       0.0.0.0/0 
> 0.0.0.0/0           state INVALID
>     29  2215            all  --  *      *       0.0.0.0/0 
> 0.0.0.0/0           TTL match TTL == 64
>     36  2851 ACCEPT     all  --  *      *       0.0.0.0/0 
> 0.0.0.0/0

wonder a bit why the counter of the 2 last rules have values, though no
traffic should come up to this point

> Chain LR (14 references)
>   pkts bytes target     prot opt in     out     source 
> destination
>     11   508 LOG        all  --  *      *       0.0.0.0/0 
> 0.0.0.0/0           LOG flags 0 level 6
>     11   508 REJECT     all  --  *      *       0.0.0.0/0 
> 0.0.0.0/0           reject-with icmp-port-unreachable
> 
> Chain NR (0 references)
>   pkts bytes target     prot opt in     out     source 
> destination

unused

> Chain SANITY (0 references)
>   pkts bytes target     prot opt in     out     source 
> destination
>      0     0 REJECT     tcp  --  *      *       0.0.0.0/0 
> 0.0.0.0/0           tcp flags:0x12/0x12 state NEW reject-with tcp-reset
>      0     0 LR         all  --  *      *       0.0.0.0/0 
> 0.0.0.0/0

unused

> Chain STATE (0 references)
>   pkts bytes target     prot opt in     out     source 
> destination
>      0     0 LR         all  --  !lo    *       0.0.0.0/0 
> 0.0.0.0/0           state NEW 
> 
>      0     0 ACCEPT     all  --  *      *       0.0.0.0/0 
> 0.0.0.0/0           state RELATED,ESTABLISHED
>      0     0 LR         all  --  *      *       0.0.0.0/0 
> 0.0.0.0/0

unused

> * Carlos Alberto Alves

You will have to rework over your firewall setup. The order of the rules
have a meaning. This is very fundamental. The rules are gone through
from first to last, until a rule matches and has a jump target to go out
to a different chain.

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.8-1.521smp 
Serendipity 16:55:57 up 13 days, 19:22, load average: 0.26, 0.32, 0.23 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20041013/fc3360f7/attachment-0001.sig>


More information about the fedora-list mailing list