From: "wickedsun" <wickedsun@phreaker.net>
To: afu@fugmann.dhs.org, rwideman@austin.rr.com
Cc: netfilter@lists.netfilter.org
Subject: Re: ftp server issue, trying to DL 1.2.7a
Date: Sat, 7 Sep 2002 08:38:08 -0400 (Eastern Daylight Time) [thread overview]
Message-ID: <3D79F330.000001.00620@athlon1000> (raw)
In-Reply-To: 3D7877D3.6040608@fugmann.dhs.org
[-- Attachment #1: Type: Text/Plain, Size: 3816 bytes --]
FTP Issues, round 2.
With further testing, I've noticed that it doesnt quite work. For some
unknown reason, it *seems* to work on port 21, but doesnt on other ports.
From what I understood in your post, you said it would work on any port.
(FTP, of course).
9/7/2002 8:31:12 AM PORT 192,168,0,1,4,131
9/7/2002 8:31:12 AM 200-FXP transfer: from 208.58.49.10 to 192.168.0.1
9/7/2002 8:31:12 AM 200 PORT command successful
9/7/2002 8:31:12 AM LIST
9/7/2002 8:31:13 AM 425 Could not open data connection to port 1155: No
route to host
The address does not get filtered (that FTP has automatic FXP detection.. if
the IP in the PORT command differs from the IP of the person that connected
to the FTP, it assumes its a FXP transfer.)
That was on port 8989.
On the other hand, port 21 is fine:
9/7/2002 8:35:11 AM PORT 192,168,0,1,4,137
9/7/2002 8:35:11 AM 200 PORT command successful.
9/7/2002 8:35:11 AM LIST
9/7/2002 8:35:11 AM Data Connection opened.
9/7/2002 8:35:11 AM 150 Opening ASCII mode data connection for file list.
9/7/2002 8:35:11 AM 226-Transfer complete.
9/7/2002 8:35:11 AM 370 bytes transferred in 00:00:00, 370 bytes/sec
Any ideas?
Charles
-------Original Message-------
From: Anders Fugmann
Date: Friday, September 06, 2002 6:30:59 AM
To: Rob
Cc: netfilter@lists.netfilter.org
Subject: Re: ftp server issue, trying to DL 1.2.7a
Rob wrote:
> ftp> dir
> 227 Entering Passive Mode (62,128,28,62,182,53).
>
As alot of others replies the problem is when ftp enters passive mode,
the server initiates a dataconnection to your machine.
Fortunatly, is a "port" command is send first over the command channel,
in order to let the client and server know how and where this new
connection will be established.
This can be caught by the netfilter code, and netfilter can allow this
connection to be accepted from the server in a quite clever way, because
netfilter is _statefull_. ipchans was not, and hence this was not possible.
The following gives an example of how netfilter can handle this:
Lets assume that you are sittin behind a iptables firewall doing nat,
and all you want is to allow users from the inside (eth0) to conenct to
the internet through the external link (ppp0)
# First load the heper modules for the ftp protocol connection tracking.
# Delete these lines, if the modules are compiled statically into the
# kernel.
modprobe ip_conntrack_ftp
# And the nat part for the ftp protocol.
modprobe ip_nat_ftp
# Set default policies.
iptables -P INPUT drop
iptables -P FORWARD drop
iptables -P OUTPUT accept
# NAT all connections
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUEADE
# Allow the mashine to make any kind of connections.
iptables -A INPUT -m state --state ESTABLISHED,RELATED \
-j ACCEPT
# Allow the same for machines located behind the firewall.
iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT
iptables -A FORWARD -o eth0 -i ppp0 -m state \
--state ESTABLISHED,RELATED -j ACCEPT
And we are all done. The trick is to use the 'state' match. The RELATED
state will match the first packet in the data-connection from the
ftp-server in passive mode. Any packets hereafter will be in the
ESTABLISHED state.
As you might have noticed, there is no protocol speicifer. So this also
works for e.g. DNS lookups (udp) and ICMP packets related to an already
esablished connection. Statefull firewalling is just sooo great.
There is no reason for you to patch the kernel in order to do this,
this has been possible for a long time.
Regards
Anders Fugmann
--
Author of FIAIF
FIAIF Is An Intelligent Firewall
http://fiaif.fugmann.dhs.org
.
[-- Attachment #2: Type: Text/HTML, Size: 5728 bytes --]
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="IncrediMail 1.0" name=GENERATOR>
<!--IncrdiXMLRemarkStart>
<IncrdiX-Info>
<X-FID>FLAVOR00-NONE-0000-0000-000000000000</X-FID>
<X-FVER></X-FVER>
<X-CNT>;</X-CNT>
</IncrdiX-Info>
<IncrdiXMLRemarkEnd-->
</HEAD>
<BODY style="BACKGROUND-POSITION: 0px 0px; FONT-SIZE: 12pt; MARGIN: 5px 10px 10px; FONT-FAMILY: Arial" bgColor=#ffffff background="" scroll=yes ORGYPOS="0" X-FVER="3.0">
<TABLE id=INCREDIMAINTABLE cellSpacing=0 cellPadding=2 width="100%" border=0>
<TBODY>
<TR>
<TD id=INCREDITEXTREGION style="FONT-SIZE: 12pt; CURSOR: auto; FONT-FAMILY: Arial" width="100%">
<DIV>FTP Issues, round 2.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>With further testing, I've noticed that it doesnt quite work. For some unknown reason, it *seems* to work on port 21, but doesnt on other ports. From what I understood in your post, you said it would work on any port. (FTP, of course).</DIV>
<DIV> </DIV>
<DIV>9/7/2002 8:31:12 AM PORT 192,168,0,1,4,131<BR>9/7/2002 8:31:12 AM 200-FXP transfer: from 208.58.49.10 to 192.168.0.1<BR>9/7/2002 8:31:12 AM 200 PORT command successful<BR>9/7/2002 8:31:12 AM LIST<BR>9/7/2002 8:31:13 AM 425 Could not open data connection to port 1155: No route to host<BR></DIV>
<DIV>The address does not get filtered (that FTP has automatic FXP detection.. if the IP in the PORT command differs from the IP of the person that connected to the FTP, it assumes its a FXP transfer.)</DIV>
<DIV> </DIV>
<DIV>That was on port 8989.</DIV>
<DIV> </DIV>
<DIV>On the other hand, port 21 is fine:</DIV>
<DIV> </DIV>
<DIV>9/7/2002 8:35:11 AM PORT 192,168,0,1,4,137<BR>9/7/2002 8:35:11 AM 200 PORT command successful.<BR>9/7/2002 8:35:11 AM LIST<BR>9/7/2002 8:35:11 AM Data Connection opened.<BR>9/7/2002 8:35:11 AM 150 Opening ASCII mode data connection for file list.<BR>9/7/2002 8:35:11 AM 226-Transfer complete.<BR>9/7/2002 8:35:11 AM 370 bytes transferred in 00:00:00, 370 bytes/sec<BR></DIV>
<DIV> </DIV>
<DIV>Any ideas?</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Charles</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV id=IncrediOriginalMessage><I>-------Original Message-------</I></DIV>
<DIV> </DIV>
<DIV id=receivestrings>
<DIV dir=ltr style="FONT-SIZE: 11pt" <i><B>From:</B></I> <A href="mailto:afu@fugmann.dhs.org">Anders Fugmann</A></DIV>
<DIV dir=ltr style="FONT-SIZE: 11pt" <i><B>Date:</B></I> Friday, September 06, 2002 6:30:59 AM</DIV>
<DIV dir=ltr style="FONT-SIZE: 11pt" <i><B>To:</B></I> <A href="mailto:rwideman@austin.rr.com">Rob</A></DIV>
<DIV dir=ltr style="FONT-SIZE: 11pt" <i><B>Cc:</B></I> <A href="mailto:netfilter@lists.netfilter.org">netfilter@lists.netfilter.org</A></DIV>
<DIV dir=ltr style="FONT-SIZE: 11pt" <i><B>Subject:</B></I> Re: ftp server issue, trying to DL 1.2.7a</DIV></DIV>
<DIV> </DIV>Rob wrote:<BR>> ftp> dir<BR>> 227 Entering Passive Mode (62,128,28,62,182,53).<BR>> <BR>As alot of others replies the problem is when ftp enters passive mode,<BR>the server initiates a dataconnection to your machine.<BR><BR>Fortunatly, is a "port" command is send first over the command channel,<BR>in order to let the client and server know how and where this new <BR>connection will be established.<BR><BR>This can be caught by the netfilter code, and netfilter can allow this <BR>connection to be accepted from the server in a quite clever way, because <BR>netfilter is _statefull_. ipchans was not, and hence this was not possible.<BR><BR>The following gives an example of how netfilter can handle this:<BR>Lets assume that you are sittin behind a iptables firewall doing nat,<BR>and all you want is to allow users from the inside (eth0) to conenct to <BR>the internet through the external link (ppp0)<BR><BR># First load the heper modules for the ftp protocol connection tracking.<BR># Delete these lines, if the modules are compiled statically into the<BR># kernel.<BR>modprobe ip_conntrack_ftp<BR># And the nat part for the ftp protocol.<BR>modprobe ip_nat_ftp<BR><BR># Set default policies.<BR>iptables -P INPUT drop<BR>iptables -P FORWARD drop<BR>iptables -P OUTPUT accept<BR><BR># NAT all connections<BR>iptables -t nat -A POSTROUTING -o ppp0 -j MASQUEADE<BR><BR># Allow the mashine to make any kind of connections.<BR>iptables -A INPUT -m state --state ESTABLISHED,RELATED \<BR>-j ACCEPT<BR><BR># Allow the same for machines located behind the firewall.<BR>iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT<BR>iptables -A FORWARD -o eth0 -i ppp0 -m state \<BR>--state ESTABLISHED,RELATED -j ACCEPT<BR><BR><BR>And we are all done. The trick is to use the 'state' match. The RELATED<BR>state will match the first packet in the data-connection from the <BR>ftp-server in passive mode. Any packets hereafter will be in the <BR>ESTABLISHED state.<BR><BR>As you might have noticed, there is no protocol speicifer. So this also <BR>works for e.g. DNS lookups (udp) and ICMP packets related to an already <BR>esablished connection. Statefull firewalling is just sooo great.<BR><BR>There is no reason for you to patch the kernel in order to do this,<BR>this has been possible for a long time.<BR><BR>Regards<BR>Anders Fugmann<BR><BR>-- <BR>Author of FIAIF<BR>FIAIF Is An Intelligent Firewall<BR><A href="http://fiaif.fugmann.dhs.org">http://fiaif.fugmann.dhs.org</A><BR><BR><BR><BR>. </TD></TR>
<TR>
<TD id=INCREDIFOOTER width="100%">
<TABLE cellSpacing=0 cellPadding=0 width="100%">
<TBODY>
<TR>
<TD width="100%"></TD>
<TD id=INCREDISOUND vAlign=bottom align=middle></TD>
<TD id=INCREDIANIM vAlign=bottom align=middle></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE></BODY></HTML>
next prev parent reply other threads:[~2002-09-07 12:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-05 17:29 ftp server issue, trying to DL 1.2.7a Rob
2002-09-05 18:30 ` Rob
2002-09-06 1:50 ` Fabrice MARIE
2002-09-05 18:32 ` Antony Stone
2002-09-05 22:00 ` wickedsun
2002-09-05 18:33 ` Ramin Alidousti
2002-09-05 19:57 ` Alistair Tonner
2002-09-06 9:39 ` Anders Fugmann
2002-09-07 12:38 ` wickedsun [this message]
2002-09-07 13:18 ` Anders Fugmann
2002-09-07 15:33 ` wickedsun
2002-09-07 15:40 ` Alistair Tonner
[not found] <002901c2551c$f5dd4700$3200a8c0@fcol.com>
2002-09-05 21:34 ` Rob
2002-09-05 22:37 ` R. Sterenborg
2002-09-06 3:49 ` Rob
2002-09-06 6:05 ` R. Sterenborg
-- strict thread matches above, loose matches on Subject: below --
2002-09-10 3:51 Rob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D79F330.000001.00620@athlon1000 \
--to=wickedsun@phreaker.net \
--cc=afu@fugmann.dhs.org \
--cc=netfilter@lists.netfilter.org \
--cc=rwideman@austin.rr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox