Iptables script : last time (I hope so)

Greeetings,

After a long and tedious process of bothering people here, I managed to
get a much much better firewall.

But the problem is that I cannot log in via ssh nor ftp from outside :
(both daemons are running and reachable from the lan)

LOCAL_SERVICES="21,22"

$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P INPUT DROP
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -p tcp --syn --match multiport --dports
\$LOCAL_SERVICES -j ACCEPT

Everything in input is dropped excepted :
New connection on port 21 or 22
Connection established or related
All local input

According to what I understand and the help you provided, everything
should be okay.

Is there something wrong in this script that I did not understand or do
I have to look somewhere else ?


Thank you again !

Charly,
Why not let the response back out on the OUTPUT chain? Also ftp requires
port 20 for data and the ftp_nat helper module loaded if U want
statefull filters.

Example:

IFACEPUB="eth0"
IFACEDMZ="eth1"
FTP="192.168.59.25"

### Allow incoming SSH
iptables -A INPUT -i $IFACEPUB -p tcp --dport 22 -m state --state
NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $IFACEPUB -p tcp --sport 22 -m state --state
ESTABLISHED -j ACCEPT

### Allow incoming ftp to DMZ ftp server (I hope)
iptables -A FORWARD -i $IFACEPUB -o $IFACEDMZ -d $FTP -p tcp --dport 21
-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $IFACEDMZ -o $IFACEPUB -s $FTP -p tcp --sport 21
-m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $IFACEPUB -o $IFACEDMZ -d $FTP -p tcp --dport 20
-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $IFACEDMZ -o $IFACEPUB -s $FTP -p tcp --sport 20
-m state --state ESTABLISHED,RELATED -j ACCEPT

Hope that helps.
jsmith


charly wrote:

> Greeetings,
>
> After a long and tedious process of bothering people here, I managed to
> get a much much better firewall.
>
> But the problem is that I cannot log in via ssh nor ftp from outside :
> (both daemons are running and reachable from the lan)
>
> LOCAL_SERVICES="21,22"
>
> $IPTABLES -P FORWARD DROP
> $IPTABLES -P OUTPUT ACCEPT
> $IPTABLES -P INPUT DROP
> $IPTABLES -A INPUT -i lo -j ACCEPT
> $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A INPUT -p tcp --syn --match multiport --dports
> \$LOCAL_SERVICES -j ACCEPT
>
> Everything in input is dropped excepted :
> New connection on port 21 or 22
> Connection established or related
> All local input
>
> According to what I understand and the help you provided, everything
> should be okay.
>
> Is there something wrong in this script that I did not understand or do
> I have to look somewhere else ?
>
>
> Thank you again !

In article <400bca4f$0$7139$626a54ce@news.free.fr>, charly wrote:
> But the problem is that I cannot log in via ssh nor ftp from outside :
> (both daemons are running and reachable from the lan)

Then we weren't clear before. I thought there was no LAN.

> LOCAL_SERVICES="21,22"
> $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A INPUT -p tcp --syn --match multiport --dports
> \$LOCAL_SERVICES -j ACCEPT

If we are seeing what is really in the script, the \ will escape the
special character $ and prevent the shell from seeing "21,22". Instead
it will see "$LOCAL_SERVICES". Perhaps it's just another case of bad
word wrap.

Why --syn? That might be the problem. I'd just stick with --state NEW as
in most of the examples you might find. (Okay, that's not true. There
are many so-called iptables scripts which were converted from ipchains,
and did not use the state module at all.

For FTP ensure that you have the ip_conntrack_ftp kernel module loaded
(lsmod to see, modprobe to load, see man pages if you are not familiar
with these.) IIUC that is what allows the state module to see the
control connection on port 20 as a RELATED connection.

Are you seeing any errors when you run this? What do you get from
iptables-save and "iptables -vnL" after you run it? The -vnL will be of
particular interest after an external attempt to connect. Are the packet
counters incremented? If so, check your syslog files. Are the daemons
reporting any connection attempt?

If after all these suggestions there's still a problem, try adding in a
-j LOG rule before this one, which would match all the same packets, and
attempt an external connection. Then see the syslog again.
--
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply

/dev/rob0 wrote:
> In article <400bca4f$0$7139$626a54ce@news.free.fr>, charly wrote:
>
>>But the problem is that I cannot log in via ssh nor ftp from outside :
>>(both daemons are running and reachable from the lan)
>
>
> Then we weren't clear before. I thought there was no LAN.
> Sorry, I did not mention it :(, anyway, it works great on my lan
>
>>LOCAL_SERVICES="21,22"
>>$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>>$IPTABLES -A INPUT -p tcp --syn --match multiport --dports
>>\$LOCAL_SERVICES -j ACCEPT
>
>
> If we are seeing what is really in the script, the \ will escape the
> special character $ and prevent the shell from seeing "21,22". Instead
> it will see "$LOCAL_SERVICES". Perhaps it's just another case of bad
> word wrap.
> bad word wrap, it is on the same line in the script

> Why --syn? That might be the problem. I'd just stick with --state NEW as
> in most of the examples you might find. (Okay, that's not true. There
> are many so-called iptables scripts which were converted from ipchains,
> and did not use the state module at all.
Okay, I'll put NEW instead


> For FTP ensure that you have the ip_conntrack_ftp kernel module loaded
> (lsmod to see, modprobe to load, see man pages if you are not familiar
> with these.) IIUC that is what allows the state module to see the
> control connection on port 20 as a RELATED connection.
The modules is loaded : ./firewall does show something about ipconntrack


> Are you seeing any errors when you run this? What do you get from
> iptables-save and "iptables -vnL" after you run it? The -vnL will be of
> particular interest after an external attempt to connect. Are the packet
> counters incremented? If so, check your syslog files. Are the daemons
> reporting any connection attempt?
when I issue a iptables --list, I get my rules correctly listed but
I'll try the options you provided here

> If after all these suggestions there's still a problem, try adding in a
> -j LOG rule before this one, which would match all the same packets, and
> attempt an external connection. Then see the syslog again.

I'll try the Log rule.

The strange thing is that I got a client which updates my account at
dyndns it runs at interval times to update the ip and it says, in the
/var/log/messages: "ok, Updated adress ip to xx.xx.xx.xx".
From my machine, If i ping the public ip, i get a response -> the dns
forwarding works.

From the lan, if I access my machine, ftpd,sshd work and the firewall
rules are ok.
that's really strange. I'll continue my research : must be something
stupid I forgot along the way :(

I did run ethereal from my workplace to llok at things,

The syn is never answered.
I thought that maybe my machine went to sleep (acpi S1 in bios) but
never wakes up even if the network card rings. I'll check that as well :
another machine on the lan did the same and I had to plug a keyboard,
relaunch /etc/init.d/networks to have eth0 up again

On Mon, 19 Jan 2004 13:15:22 +0100, charly thoughtfully wrote:

> Greeetings,
>
> After a long and tedious process of bothering people here, I managed to
> get a much much better firewall.
>
> But the problem is that I cannot log in via ssh nor ftp from outside :
> (both daemons are running and reachable from the lan)
>
> LOCAL_SERVICES="21,22"
>
> $IPTABLES -P FORWARD DROP
> $IPTABLES -P OUTPUT ACCEPT
> $IPTABLES -P INPUT DROP
> $IPTABLES -A INPUT -i lo -j ACCEPT
> $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A INPUT -p tcp --syn --match multiport --dports
> \$LOCAL_SERVICES -j ACCEPT
>
> Everything in input is dropped excepted :
> New connection on port 21 or 22
> Connection established or related
> All local input
>
> According to what I understand and the help you provided, everything
> should be okay.
>
> Is there something wrong in this script that I did not understand or do
> I have to look somewhere else ?
>
>
> Thank you again !


I agree with "/dev/rob0" especially his catch of the escaped character
"\$". I think the --syn or --tcp-flags is nice but states are simpler.

INTRANET="192.168.0.0/24"
INTERNET="0.0.0.0/0"

$IPTABLES -A INPUT -p tcp -s $INTRANET -m state --state
NEW,RELATED,ESTABLISHED --match multiport --dports $LOCAL_SERVICES -j
ACCEPT

preceded by if you still want to log
$IPTABLES -A INPUT -p tcp --dports $LOCAL_SERVICES -j LOG



--
------------------------------------------------------
Linux registered user #302812
using Fedora Core 1 kernel 2.4.22-1.2149.nptl
------------------------------------------------------

/dev/rob0 <rob0@gmx.co.uk> said:
>Why --syn? That might be the problem. I'd just stick with --state NEW as
>in most of the examples you might find. (Okay, that's not true. There
>are many so-called iptables scripts which were converted from ipchains,
>and did not use the state module at all.

--syn is very different from --state NEW. The first is for establishing
a new TCP session, whereas the latter is for setting up a known session
at netfilter (iptables) level.

Allowing --state NEW without further checks will f.ex. make your host
scannable by FIN, ACK, or SYN-ACK scans. So, your host will elicit some
response when faced with packets of this type (and these packets get
handled by your kernel networking stack). With --syn, the only packet
that will cause a new netfilter session (and at the same time a new
TCP session) to be established, is a TCP SYN. So, --syn is a more strict
filter than --state NEW. Actually I use these two side-by-side, so
I only allow a SYN packet when it's establishing a new netfilter session
at the same time.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

> I agree with "/dev/rob0" especially his catch of the escaped character
> "\$". I think the --syn or --tcp-flags is nice but states are simpler.
>
> INTRANET="192.168.0.0/24"
> INTERNET="0.0.0.0/0"
>
> $IPTABLES -A INPUT -p tcp -s $INTRANET -m state --state
> NEW,RELATED,ESTABLISHED --match multiport --dports $LOCAL_SERVICES -j
> ACCEPT
>
> preceded by if you still want to log
> $IPTABLES -A INPUT -p tcp --dports $LOCAL_SERVICES -j LOG
>
>
I tried with new and --syn but the problem does lie on the fact that my
network card goes to the sleep and never wakes : I'll stop here and go
to linux.hardware to solve this problem...

Many many thx for everyone :)