iptables problem
I have three machines on our private network that need unrestricted
access to and from FTP. These are little photo kiosks that periodically connect to the master service machine elsewhere through ftp to send files and then receives information back.
The machine running iptables has eth0 with our public ip and eth2
with the internal (192.168.x.x) ip (where the three machines are on.)
Help anyone?
what's your problem or what do you mean?
2005/11/2, Ashley M. Kirchner <[email protected]>:
Quoted 13 lines
I have three machines on our private network that need unrestricted
access to and from FTP. These are little photo kiosks that periodically connect to the master service machine elsewhere through ftp to send files and then receives information back.The machine running iptables has eth0 with our public ip and eth2
with the internal (192.168.x.x) ip (where the three machines are on.)Help anyone?
Quoted 3 lines · Buddy wu
what's your problem or what do you mean?
Problem is that while they can connect OUT, nothing from the outside
can connect to them.
Signature · 6 lines
H | I haven't lost my mind; it's backed up on tape somewhere. +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:[email protected]> . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Imaging . 3550 Arapahoe Ave. #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
Quoted 2 lines
Problem is that while they can connect OUT, nothing from the outside
can connect to them.
I think you should load the ip_nat_ftp and ip_conntrack_ftp moudles. do you load them?
Quoted 5 lines
Quoted 3 lines
what's your problem or what do you mean?
Problem is that while they can connect OUT, nothing from
the outside can connect to them.
If you don't let us know what you have already done, we don't know what's wrong.
Gr,
Rob
Quoted 8 lines · Ashley M. Kirchner
Quoted 3 lines · Buddy wu
what's your problem or what do you mean?
Problem is that while they can connect OUT, nothing from the
outside can connect to them.
Hello there, i think this should do
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT --dst $YOUR_IP -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT --src $YOUR_IP -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Quoted 10 lines · Nikolai Georgiev
Quoted 3 lines
Problem is that while they can connect OUT, nothing from the
outside can connect to them.Hello there, i think this should do
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT --dst $YOUR_IP -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT --src $YOUR_IP -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
The INPUT and OUTPUT chains are for local traffic. These kiosk hosts are probably *behind* iptables, so traffic will travel through the FORWARD chain.
If you need external connections forwarded to hosts behind the firewall, you need DNAT rules to make it happen.
In this case, the OP has 3 hosts to wich he wants to connect ("nothing from the outside can connect to them", outgoing connections are already working).
FTP only uses port 21/tcp (and 20). It's to my knowledge not possible to forward 1 port to 3 hosts simultaneously (if that would do any good), so he'll need to assign different ports for the second and third host.
Something like :
21/tcp -> host 1
41/tcp -> host 2
61/tcp -> host 3
(if these ports are free).
Gr,
Rob
Quoted 8 lines · Rob Sterenborg
The INPUT and OUTPUT chains are for local traffic. These kiosk hosts are probably *behind* iptables, so traffic will travel through the FORWARD chain.
If you need external connections forwarded to hosts behind the firewall, you need DNAT rules to make it happen.
Yes, the kiosks are behind the firewall (iptables) and need
unrestricted access to and from the internet, but only for FTP.
Quoted 4 lines
In this case, the OP has 3 hosts to wich he wants to connect ("nothing from the outside can connect to them", outgoing connections are already working).
FTP only uses port 21/tcp (and 20). It's to my knowledge not possible
Quoted 10 lines
to forward 1 port to 3 hosts simultaneously (if that would do any good), so he'll need to assign different ports for the second and third host.
Something like :
21/tcp -> host 1
41/tcp -> host 2
61/tcp -> host 3
(if these ports are free).
All right, so this is what I currently have in my iptables rules:
-A PREROUTING -i eth0 -p tcp -m tcp --dport 21 -j DNAT --to-destination 192.168.1.xxx -A PREROUTING -i eth0 -p tcp -m tcp --dport 20 -j DNAT --to-destination 192.168.1.xxx
...and further down:
-A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp --dport 21 --tcp-flags SYN,RST,ACK SYN -j ACCEPT -A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp --dport 20 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
In my logs, I see this:
kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1587 DF PROTO=TCP SPT=1186 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0
kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1588 DF PROTO=TCP SPT=1181 DPT=21 WINDOW=65196 RES=0x00 ACK PSH URGP=0
kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1589 DF PROTO=TCP SPT=1184 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0
The other problem is that, while I can change the FTP port on the
kiosks, I can't change it on the other end (the receiving and sending) so I'm not sure how to handle that part. They will always attempt to connect on the standard FTP port, which two of these machines won't be listening to since I would've changed them so they don't conflict with one another. Or is that not so?
Signature · 6 lines
W | It's not a bug - it's an undocumented feature. +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:[email protected]> . 303.442.6410 x130 IT Director / SysAdmin / Websmith . 800.441.3873 x130 Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave. #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
Quoted 2 lines
Yes, the kiosks are behind the firewall (iptables) and need
unrestricted access to and from the internet, but only for FTP.
...
Review
Quoted 13 lines
All right, so this is what I currently have in my iptables rules:
(quoted diff) +0
-8-A PREROUTING -i eth0 -p tcp -m tcp --dport 21 -j DNAT --to-destination 192.168.1.xxx -A PREROUTING -i eth0 -p tcp -m tcp --dport 20 -j DNAT --to-destination 192.168.1.xxx ...and further down: -A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp --dport 21 --tcp-flags SYN,RST,ACK SYN -j ACCEPT -A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp --dport 20 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
I assume your FORWARD policy is DROP ?
If you use RELATED,ESTABLISHED, you only need to allow port 21. Port 20 is then RELATED to the connection. So, do you also have (something like) :
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
You *do* load the ftp conntack helpers, do you ?
Quoted 6 lines
In my logs, I see this:
kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1587 DF PROTO=TCP SPT=1186 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0
Quoted 7 lines
kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1588 DF PROTO=TCP SPT=1181 DPT=21 WINDOW=65196 RES=0x00 ACK PSH URGP=0
kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1589 DF PROTO=TCP SPT=1184 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0
This looks like an ACK to me. Not sure why such packet would be in the NEW state on port 21, where a ftp-client would connect to at first so I would think it would be in the ESTABLISHED state. (Also not sure what the logging rule looks like.)
Maybe someone else who has better knowledge of this can help here.
You could skip the tcp-flags at first and see if that works.
Quoted 6 lines
The other problem is that, while I can change the FTP port on the
kiosks, I can't change it on the other end (the receiving and sending) so I'm not sure how to handle that part. They will always attempt to connect on the standard FTP port, which two of these machines won't be listening to since I would've changed them so they don't conflict with one another. Or is that not so?
You don't have to run the ftp service of the kiosk hosts on different ports : just forward the external ports, let's say (40/)41 and (60/)61, to ports (20/)21 on the kiosk hosts. But that is no solution to your problem I suppose, because of the serverside problem.
Maybe you can let the kiosk hosts connect to the server and perform GET and PUT commands. The server then only has to put the needed updates in a specific directory where the kiosk hosts can download them from. This way the hosts themselves don't have to be reachable on the internet which would be better from a security point of view.
Gr,
Rob
Quoted 8 lines
Maybe you can let the kiosk hosts connect to the server and perform GET and PUT commands. The server then only has to put the needed updates in a specific directory where the kiosk hosts can download them from. This way the hosts themselves don't have to be reachable on the internet which would be better from a security point of view.
Thanks for the explanation Rob.
I can't control what happens on the serverside. That's a third
party company. I figured regardless of me being able to forward port 21 to one of these machines without a problem, I can't do it for all three. So I think I'm screwed either way. Grrr...
Signature · 6 lines
H | I haven't lost my mind; it's backed up on tape somewhere. +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:[email protected]> . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Imaging . 3550 Arapahoe Ave. #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
Re: Re: iptables problem (nfcan: addressed to exclusive sender for this address)
Quoted 11 lines · On 2005.11.03 01:45, Ashley M. Kirchner - [email protected] wrote:
Quoted 7 lines
Maybe you can let the kiosk hosts connect to the server and perform GET and PUT commands. The server then only has to put the needed updates in a specific directory where the kiosk hosts can download them from. This way the hosts themselves don't have to be reachable on the internet which would be better from a security point of view.
Thanks for the explanation Rob.
I can't control what happens on the serverside. That's a third party
company. I figured regardless of me being able to forward port 21 to one of these machines without a problem, I can't do it for all three. So I think I'm screwed either way. Grrr...
OK, here is how I understand your situation:
Each kiosk must have a distinct identity to the outside service. A kiosk must play the role of an ftp server.
A server has to listen on a well known port.
The outside system can only use the standard ftp port. (This does seem a rather inflexible design, but ...) The only other way to distinguish servers is the IP address.
So, maybe you can get more IP addresses.
Some ISP's allow you to have more than one public IP. (Sometimes they want a few bucks extra rent :-)
You can arrange to have the firewall in question respond to 3 IP addresses on the outside interface and forward the now distinct traffic to the 3 kiosks. If this is possible, it might be better than being screwed.
HTH
Signature · 4 lines
Jim Laurino [email protected] Please reply to the list. Only mail from the listserver reaches this address.
Re: Re: iptables problem (nfcan: addressed to exclusive sender for this address)
Quoted 4 lines · Jim Laurino
You can arrange to have the firewall in question respond to 3 IP addresses on the outside interface and forward the now distinct traffic to the 3 kiosks. If this is possible, it might be better than being screwed.
That would be nice, but no can do. Remember, the server end, or
receiving end, is a third party company. They have hundreds, if not thousands of these little kiosks scattered across the country. We are but a tiny little company with three of those kiosks. Each kiosk makes an outbound FTP connection to the server. Then the server makes an inbound connection back to the kiosk. This is where it fails because it doesn't know where it came from since the kiosks are behind the firewall.
Putting the kiosks OUTSIDE the firewall (with different IPs) also
won't work because they also need to communicate (via windows shares) to internal machines, again, same scenario...they contact a print station, and the print station contacts them. So you see, being screwed is the only option I see here. Unless I'm overlooking something.
And I can't tell the other company to send data to separate IPs
either because their system works based on the packet they first receive when the kiosk contacts them. Which goes back to my point above (about putting the kiosks outside the firewall.)
Signature · 6 lines
H | I haven't lost my mind; it's backed up on tape somewhere. +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:[email protected]> . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Imaging . 3550 Arapahoe Ave. #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
Re: Re: iptables problem (nfcan: addressed to exclusive sender for this address)
Hi Ashley,
On Thu, Nov 03, 2005 at 09:02:58AM -0700, Ashley M. Kirchner told us:
Quoted 4 lines
And I can't tell the other company to send data to separate IPs
either because their system works based on the packet they first receive when the kiosk contacts them. Which goes back to my point above (about putting the kiosks outside the firewall.)
you say "their" system works based on the packet they first receive when contacting them. So with multiple IPs, wouldn't it work to let each kiosk contact the server via its own IP address via SNAT?? E.g. kiosk 1 which is internally 1.2.3.4 gets natted to the public ip 5.6.7.8, so when it contacts the server it will establish a connection back to 5.6.7.8 which will in turn be DNATted to 1.2.3.4. kiosk 2 (1.2.3.5) --> 5.6.7.9
and so on...
I haven't read the whole thread, so it might be that I missed something :-)
Wouldn't this work??
HTH
Sven
Signature · 2 lines
Linux zion.homelinux.com 2.6.14-rc5-mm1_14 #14 Wed Nov 2 11:36:18 CET 2005 i686 athlon i386 GNU/Linux 17:19:16 up 1 day, 5:25, 2 users, load average: 0.38, 0.18, 0.07
RE: Re: iptables problem (nfcan: addressed to exclusivesender for this address)
Quoted 10 lines
you say "their" system works based on the packet they first receive when contacting them. So with multiple IPs, wouldn't it work to let each kiosk contact the server via its own IP address via SNAT??
E.g. kiosk 1 which is internally 1.2.3.4 gets natted to the public ip 5.6.7.8, so when it contacts the server it will establish a connection back to 5.6.7.8 which will in turn be DNATted to 1.2.3.4.
kiosk 2 (1.2.3.5) --> 5.6.7.9
and so on...
Yes this could work. Stupid I didn't think of it.
Ext_ip1 -(DNAT)-> Int_ip1Ext_ip2 -(DNAT)-> Int_ip2Ext_ip3 -(DNAT)-> Int_ip3
But then (reading OP's other post : "And I can't tell the other company to send data to separate IPs either because their system works based on the packet they first receive when the kiosk contacts them") you should also SNAT to different externals IP's :
Int_ip1 -(SNAT)-> Ext_ip1Int_ip2 -(SNAT)-> Ext_ip2Int_ip3 -(SNAT)-> Ext_ip3
Quoted 2 lines
I haven't read the whole thread, so it might be that I missed something :-)
I think not ;^)
Gr,
Rob
Re: Re: iptables problem (nfcan: addressed to exclusive (nfcan: addressed to exclusive sender for this address) sender for this address)
In reply to Ashley M. KirchnerQuoted 9 lines · On 2005.11.03 11:02, Ashley M. Kirchner - [email protected] wrote:
Quoted 4 lines · Jim Laurino
You can arrange to have the firewall in question respond to 3 IP addresses on the outside interface and forward the now distinct traffic to the 3 kiosks. If this is possible, it might be better than being screwed.
That would be nice, but no can do. Remember, the server end, or
receiving end, is a third party company. They have hundreds, if not thousands of these little kiosks scattered across the country. We are but a tiny little company with three of those kiosks. Each kiosk makes an outbound FTP connection to the server. Then the server makes an inbound connection back to the kiosk. This is where it fails because it doesn't know where it came from since the kiosks are behind the firewall.
Perhaps I am confused,
I thought that the kiosks in question were acting as ftp servers.
If the kiosks are ftp clients, the situation is entirely different. This should not be a problem.
Quoted 3 lines
Putting the kiosks OUTSIDE the firewall (with different IPs) also won't
work because they also need to communicate (via windows shares) to internal machines, again, same scenario...they contact a print station, and the print station contacts them.
Exactly what do you mean when you say "contacts". Do you mean that the kiosk also must act as an ftp server? Or do you mean contact as in a passive ftp transfer? Passive ftp you can support via ftp helpers and RELATED.
Quoted 17 lines
So you see, being screwed is the only option I see here. Unless I'm overlooking something.
And I can't tell the other company to send data to separate IPs either
because their system works based on the packet they first receive when the kiosk contacts them. Which goes back to my point above (about putting the kiosks outside the firewall.)Signature · 6 lines
H | I haven't lost my mind; it's backed up on tape somewhere. +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:[email protected]> . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Imaging . 3550 Arapahoe Ave. #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
Signature · 4 lines
Jim Laurino [email protected] Please reply to the list. Only mail from the listserver reaches this address.
Re: Re: iptables problem (nfcan: addressed to exclusive (nfcan: addressed to exclusive sender for this address) sender for this address)
Quoted 2 lines · Jim Laurino
If the kiosks are ftp clients, the situation is entirely different. This should not be a problem.
They are clients. But...keep reading... Something changed today.
Quoted 4 lines
Exactly what do you mean when you say "contacts". Do you mean that the kiosk also must act as an ftp server? Or do you mean contact as in a passive ftp transfer? Passive ftp you can support via ftp helpers and RELATED.
Neither. It's through windows network shares. The kiosk puts the
order on it's local drive which is shared to the network, and the print station comes and fetches the info periodically. Keep reading...
I just got off the phone with the company and they made a small
change in our config. Now, all the kiosks have to do is connect via FTP to their server and drop a file. That's it. Nothing comes back, no inbound connections to the kiosks. Just going out.
So, just out of curiosity, I decided to try doing a manual FTP
transfer from a completely different machine on the network. One that CAN connect to external ftp sites just fine and transfer files. And this is what I see:
- Open DOS window
- Connect to FTP server
- enter 'PUT file.xml' command
...and that's where it hangs.
Now, looking in the firewall logs, I see this:
Nov 3 13:47:19 serpico kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.253 DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=43803 DF PROTO=TCP SPT=4100 DPT=21 WINDOW=65420 RES=0x00 ACK PSH URGP=0
Nov 3 13:47:49 serpico kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.253 DST=206.112.90.196 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=43949 DF PROTO=TCP SPT=4100 DPT=21 WINDOW=0 RES=0x00 ACK RST URGP=0
Nov 3 13:47:55 serpico kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.253 DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=43987 DF PROTO=TCP SPT=4117 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0
In my DOS window, I see this (while those errors are popping up in
syslog):
ftp> put 2008701033.xml
... pause ... first error in syslog
... pause ... second line in syslog
Connection closed by remote host.
... third line in syslog
ftp>
Please remember that this is a machine onto which I CAN open an ftp
connection to anywhere in the world and be able to send and receive files just fine. So then why is it not working when going to these people?
---- FIVE MINUTES LATER ----
I just tried directly from the firewall machine and found out they
don't allow PASSIVE mode ON... As soon as I turn passive mode off, the transfer, FROM THE FIREWALL MACHINE, works. (firewall machine has an external IP)
So now I wonder, is it because of the passive mode setting they
have? Could that be why ftp transfers from within the firewall fails?
Signature · 6 lines
W | It's not a bug - it's an undocumented feature. +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:[email protected]> . 303.442.6410 x130 IT Director / SysAdmin / Websmith . 800.441.3873 x130 Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave. #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
Re: Re: iptables problem (nfcan: addressed to exclusive (nfcan: addressed to exclusive sender for this address) (nfcan: addressed to exclusive sender for this address) sender for this address)
Quoted 2 lines · On 2005.11.03 14:57, Ashley M. Kirchner - [email protected] wrote:
Jim Laurino wrote:
...
Quoted 11 lines
I just got off the phone with the company and they made a small change in
our config. Now, all the kiosks have to do is connect via FTP to their server and drop a file. That's it. Nothing comes back, no inbound connections to the kiosks. Just going out.So, just out of curiosity, I decided to try doing a manual FTP transfer
from a completely different machine on the network. One that CAN connect to external ftp sites just fine and transfer files. And this is what I see:- Open DOS window
- Connect to FTP server
- enter 'PUT file.xml' command
...and that's where it hangs.
....
Quoted 4 lines
Please remember that this is a machine onto which I CAN open an ftp
connection to anywhere in the world and be able to send and receive files just fine. So then why is it not working when going to these people?
Quoted 8 lines
---- FIVE MINUTES LATER ----
I just tried directly from the firewall machine and found out they don't
allow PASSIVE mode ON... As soon as I turn passive mode off, the transfer, FROM THE FIREWALL MACHINE, works. (firewall machine has an external IP)So now I wonder, is it because of the passive mode setting they have?
Could that be why ftp transfers from within the firewall fails?
non-passive (active) FTP requires that
the outside ftp server be able to open
a secondary connection to the client.
That is why passive mode is so popular
when the ftp client is behind a firewall - both of the connections are originated from the client, and no ports have to be opened on the firewall for the incoming secondary connection.
I was confused about this earlier,
and may have contributed to the confusion.
A clear explanation is here http://slacksite.com/other/ftp.html
So, it is possible that your firewall is not configured to allow active mode ftp connections. (But it can be done).
HTH
Signature · 4 lines
Jim Laurino [email protected] Please reply to the list. Only mail from the listserver reaches this address.
Re: Re: iptables problem (nfcan: addressed to exclusive (nfcan: addressed to exclusive sender for this address) (nfcan: addressed to exclusive sender for this address) sender for this address)
Quoted 2 lines · Jim Laurino
So, it is possible that your firewall is not configured to allow active mode ftp connections. (But it can be done).
Okay, so what am I supposed to do to "fix" this? Thanks for the
link by the way. Helped clear up some things...
Signature · 6 lines
H | I haven't lost my mind; it's backed up on tape somewhere. +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:[email protected]> . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Imaging . 3550 Arapahoe Ave. #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
RE: Re: iptables problem (nfcan: addressed to exclusive (nfcan: addressed to exclusive sender for this address) (nfcan: addressed to exclusive sender for this address) sender for this address)
Quoted 4 lines
Quoted 2 lines
So, it is possible that your firewall is not configured to allow active mode ftp connections. (But it can be done).
Okay, so what am I supposed to do to "fix" this? Thanks for the
Check out section "Connection tracking and ftp" on this page :
http://kalamazoolinux.org/presentations/20010417/conntrack.html
Gr,
Rob
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Why not have one system that reaches out for the files, and brings them inside, then point the kiosks at that one system? Far easier to maintain and troubleshoot and far less FW coding.
Thanks,
Ron DuFresne
Quoted 69 lines · Rob Sterenborg
Quoted 2 lines
Yes, the kiosks are behind the firewall (iptables) and need
unrestricted access to and from the internet, but only for FTP....
Review
Quoted 13 lines
All right, so this is what I currently have in my iptables rules:
(quoted diff) +0
-8-A PREROUTING -i eth0 -p tcp -m tcp --dport 21 -j DNAT --to-destination 192.168.1.xxx -A PREROUTING -i eth0 -p tcp -m tcp --dport 20 -j DNAT --to-destination 192.168.1.xxx ...and further down: -A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp --dport 21 --tcp-flags SYN,RST,ACK SYN -j ACCEPT -A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp --dport 20 --tcp-flags SYN,RST,ACK SYN -j ACCEPTI assume your FORWARD policy is DROP ?
If you use RELATED,ESTABLISHED, you only need to allow port 21. Port 20 is then RELATED to the connection. So, do you also have (something like) :
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPTYou *do* load the ftp conntack helpers, do you ?
Quoted 6 lines
In my logs, I see this:
kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1587 DF PROTO=TCP SPT=1186 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0
Quoted 7 lines
kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1588 DF PROTO=TCP SPT=1181 DPT=21 WINDOW=65196 RES=0x00 ACK PSH URGP=0
kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1589 DF PROTO=TCP SPT=1184 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0
This looks like an ACK to me. Not sure why such packet would be in the NEW state on port 21, where a ftp-client would connect to at first so I would think it would be in the ESTABLISHED state. (Also not sure what the logging rule looks like.)
Maybe someone else who has better knowledge of this can help here.You could skip the tcp-flags at first and see if that works.
Quoted 6 lines
The other problem is that, while I can change the FTP port on the
kiosks, I can't change it on the other end (the receiving and sending) so I'm not sure how to handle that part. They will always attempt to connect on the standard FTP port, which two of these machines won't be listening to since I would've changed them so they don't conflict with one another. Or is that not so?You don't have to run the ftp service of the kiosk hosts on different ports : just forward the external ports, let's say (40/)41 and (60/)61, to ports (20/)21 on the kiosk hosts. But that is no solution to your problem I suppose, because of the serverside problem.
Maybe you can let the kiosk hosts connect to the server and perform GET and PUT commands. The server then only has to put the needed updates in a specific directory where the kiosk hosts can download them from. This way the hosts themselves don't have to be reachable on the internet which would be better from a security point of view.
Quoted 4 lines
Gr,
Rob
- -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
admin & senior security consultant: sysinfo.com
http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A E838 B2DF AFCC 94B0 6629
...We waste time looking for the perfect lover
instead of creating the perfect love.
-Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFDaob8st+vzJSwZikRAqYCAKDUUlIYj/Kc10C/NxsnEpRxRb4jjQCfTBU3 RYixAO5DstCZTr9QMCqXygI=
=hj6F
-----END PGP SIGNATURE-----
Quoted 1 line · R. DuFresne
Why not have one system that reaches out for the files, and brings them inside, then point the kiosks at that one system? Far easier to maintain and troubleshoot and far less FW coding.
Because I didn't code these machines. They are proprietary and
third party to us.
Signature · 6 lines
H | I haven't lost my mind; it's backed up on tape somewhere. +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:[email protected]> . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Imaging . 3550 Arapahoe Ave. #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 8 lines · Ashley M. Kirchner
Quoted 1 line · R. DuFresne
Why not have one system that reaches out for the files, and brings them inside, then point the kiosks at that one system? Far easier to maintain and troubleshoot and far less FW coding.
Because I didn't code these machines. They are proprietary and third
party to us.
Interesting, and that means I suspect that you have no ability to tune or config them as well? Could one put in a request the third parties config them to look at one trusted host you could setup to pull the files from?
Have they been "tested" for their security? Seems a tad risky, depending upon placement, hopefully they are in a dmz and not the soft chewy center....
Thanks,
Ron DuFresne
- -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
admin & senior security consultant: sysinfo.com
http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A E838 B2DF AFCC 94B0 6629
...We waste time looking for the perfect lover
instead of creating the perfect love.
-Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFDatL0st+vzJSwZikRArWLAKDA/urNj4sEruwm7KU8ezInKPLpJQCeJk+R MFr5oi+c3stQZx0mqQJgqmE=
=Z32v
-----END PGP SIGNATURE-----
Quoted 3 lines · R. DuFresne
Interesting, and that means I suspect that you have no ability to tune or config them as well? Could one put in a request the third parties config them to look at one trusted host you could setup to pull the files from?
Have they been "tested" for their security? Seems a tad risky, depending upon placement, hopefully they are in a dmz and not the soft chewy center....
Tested for security? Does the fact that they transmit order details
(including plain text client information and an encrypted CC string within the same file) via plain old FTP tell you anything? Do I, personally, trust this system? Oh HELL NO. Would I, personally, use them to place any orders? Oh HELL NO. Do I have a choice in not using them? Nope. I'm merely the one that has to make them work...the big guys paid the money.
Signature · 6 lines
H | I haven't lost my mind; it's backed up on tape somewhere. +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:[email protected]> . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Imaging . 3550 Arapahoe Ave. #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.