Application level gateway and security?
We are running an application level gateway, currently only with squid (http proxy) to hide our intra net from the internet. All ports are denyed by the firewall, exept the necessary ones. Gateway |--Client --- | | | |--Client ----+ +---| | | |--Client Inter --- | Net |--Client Intranet To get all features from the ftp protocol, we plan to use the suse proxy-suite. - What ports have to be opened in addition for the ftp-proxy? Are there firewall examples available for suse-7.0 - We do not want access from the external world into our net. What's the best entry for the mandatory 'DestinationAddress' in ftp-proxy.conf? - Is there a common way, how to access an ftp-proxy from the client side? I could imagine an approach like the proxy entry for http browsers. - Which clients are recommended for use in conjunction with the ftp-proxy ( ncftp?, other unix clients, win32 clients?) - Should the standard ports (20/21) be used or other ones? - I do not understand the use of an LDAP server with an ftp-proxy. Is that one used to get access to the gateway itself or to authenticate users which want to get access to the outside world? - Suse-7.0 comes with an ssl-version of the ftp-proxy. Which clients/servers make use of ssl? - Any other experiences about security? Thanks in advance, Thomas PS: In case anybody in this list want's to use the ftp-proxy on the suse7.0 CDs: It seems their ftp-proxy do not work. I had to recompile the sources. -- Dr.-Ing. Thomas Ziegler Coding Technologies GmbH Deutscherrnstr. 15-19 Phone +49(911)92891-27 D-90429 Nürnberg FAX +49(911)92891-99
Hi! This are mostly RTFM questions - please read the docs. See also: ftp://ftp.suse.com/pub/projects/proxy-suite/src/TRANSPARENT_PROXY.txt or ftp://ftp.suse.com/pub/projects/proxy-suite/devel/TRANSPARENT_PROXY.txt On Mon, Jan 08, 2001 at 12:53:51AM +0100, Thomas Ziegler wrote:
We are running an application level gateway, currently only with squid (http proxy) to hide our intra net from the internet. All ports are denyed by the firewall, exept the necessary ones.
Gateway |--Client --- | | | |--Client ----+ +---| | | |--Client Inter --- | Net |--Client
Intranet
To get all features from the ftp protocol, we plan to use the suse proxy-suite.
- What ports have to be opened in addition for the ftp-proxy? Are there firewall examples available for suse-7.0
- We do not want access from the external world into our net. What's the best entry for the mandatory 'DestinationAddress' in ftp-proxy.conf?
Do not set DestinationAddress. Set only AllowTransProxy (and AllowMagicUser if you want it). Set Listen to the internal IP Address of the Gateway (connected to the Intranet) - see TRANSPARENT_PROXY.txt.
- Is there a common way, how to access an ftp-proxy from the client side?
Yes, sure, with a normal FTP-Client.
I could imagine an approach like the proxy entry for http browsers. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This are not FTP proxies, but HTTP proxies. You can't use our ftp-proxy in this way, because it is a ftp proxy.
- Which clients are recommended for use in conjunction with the ftp-proxy ( ncftp?, other unix clients, win32 clients?)
All FTP clients should work. ncftp is a nice unix ftp client.
- Should the standard ports (20/21) be used or other ones?
??
- I do not understand the use of an LDAP server with an ftp-proxy. Is that one used to get access to the gateway itself or to authenticate users which want to get access to the outside world?
No. It is used to provide/override a configuration depending on the users name that is connecting to the proxy (only inbound mode).
- Suse-7.0 comes with an ssl-version of the ftp-proxy. Which clients/servers make use of ssl?
It is not implemented in the fwproxys on 7.0; it only actively refuses SSL connections at the moment... it is some kind of a useless package and will be skipped on 7.1, because we have no time to implement any SSL support at the moment.
- Any other experiences about security?
Soure, you have to know hat you are doing.
PS: In case anybody in this list want's to use the ftp-proxy on the suse7.0 CDs: It seems their ftp-proxy do not work. I had to recompile the sources.
It works, but there are bugs, so do not use RPMs shipped with SuSE 7.0.
Use the sources/RPMs provided on
ftp://ftp.suse.com/pub/projects/proxy-suite/SuSE-7.0/
and not packages from CD (too old).
Gruesse,
Marius Tomaschewski
Thanks for your detailed response, Marius. On Thu, Jan 11, 2001 at 06:17:28PM +0100, Marius Tomaschewski wrote:
Hi!
This are mostly RTFM questions - please read the docs. See also:
I read the docs, but some items left unclear to me. Otherwise I wouldn't have posted.
ftp://ftp.suse.com/pub/projects/proxy-suite/src/TRANSPARENT_PROXY.txt or ftp://ftp.suse.com/pub/projects/proxy-suite/devel/TRANSPARENT_PROXY.txt
On Mon, Jan 08, 2001 at 12:53:51AM +0100, Thomas Ziegler wrote:
We are running an application level gateway, currently only with squid (http proxy) to hide our intra net from the internet. All ports are denyed by the firewall, exept the necessary ones.
Gateway |--Client --- | | | |--Client ----+ +---| | | |--Client Inter --- | Net |--Client
Intranet
To get all features from the ftp protocol, we plan to use the suse proxy-suite.
- What ports have to be opened in addition for the ftp-proxy? Are there firewall examples available for suse-7.0
- We do not want access from the external world into our net. What's the best entry for the mandatory 'DestinationAddress' in ftp-proxy.conf?
Do not set DestinationAddress. Set only AllowTransProxy (and
As I understood the documentation, the DestinationAddress is mandantory.
AllowMagicUser if you want it). Set Listen to the internal IP Address of the Gateway (connected to the Intranet) - see TRANSPARENT_PROXY.txt.
At the moment, we do not use the transparent option because - there's a clear statement not to use it in production systems - the suse7.0-Kernel doesnot support transparent proxy I have no problems with recompiling kernels, but it's not the best idea to experiment on our gateway. What's your experience with stability and security concerning the transparent proxy option?
- Is there a common way, how to access an ftp-proxy from the client side?
Yes, sure, with a normal FTP-Client.
I could imagine an approach like the proxy entry for http browsers. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This are not FTP proxies, but HTTP proxies. You can't use our ftp-proxy in this way, because it is a ftp proxy.
Sure, I know. What I meant is, that I could imagine a client which "knows", that it and how it has to transfer all ftp requests to the gateway. If that's the case, one can use the standard syntax ftp ftp.uni-erlangen.de to get anonymous access to the ftp server. If the client is ncftp or configured well, I do not need to provide the password for the anonymous access. With the proxy several steps are required: ftp gateway Name (gateway:zie): anonymous@ftp.uni-erlangen.de 331 Guest login ok, send your complete e-mail address as password. Password: xxx It works, but it's a bit uncomfortable. I just installed the latest version of ncftp (3.0.2 instead of the suse7.0, which is 2.4.3) and saw that it supports seven different types of firewalls. Maybe the win32-clients support the same type, maybe not. Therefore my question about a standard way how to access an ftp-proxy.
- Which clients are recommended for use in conjunction with the ftp-proxy ( ncftp?, other unix clients, win32 clients?)
All FTP clients should work. ncftp is a nice unix ftp client.
- Should the standard ports (20/21) be used or other ones?
I know of other firewalls, which changed the port from 21 to 2222. Does this increase security?
- I do not understand the use of an LDAP server with an ftp-proxy. Is that one used to get access to the gateway itself or to authenticate users which want to get access to the outside world?
No. It is used to provide/override a configuration depending on the users name that is connecting to the proxy (only inbound mode).
ok.
- Suse-7.0 comes with an ssl-version of the ftp-proxy. Which clients/servers make use of ssl?
It is not implemented in the fwproxys on 7.0; it only actively refuses SSL connections at the moment... it is some kind of a useless package and will be skipped on 7.1, because we have no time to implement any SSL support at the moment.
ok.
- Any other experiences about security?
Soure, you have to know hat you are doing.
PS: In case anybody in this list want's to use the ftp-proxy on the suse7.0 CDs: It seems their ftp-proxy do not work. I had to recompile the sources.
It works, but there are bugs, so do not use RPMs shipped with SuSE 7.0.
Use the sources/RPMs provided on ftp://ftp.suse.com/pub/projects/proxy-suite/SuSE-7.0/ and not packages from CD (too old).
Gruesse, Marius Tomaschewski
-- SuSE GmbH, Hamburg --- SuSE Labs, Product Developement GPG/PGP public key see: http://www.suse.de/~mt/mt.pgp Key-FP: DF17 271A AD15 006A 5BB9 6C96 CA2F F3F7 373A 1CC0
-- Dr.-Ing. Thomas Ziegler Coding Technologies GmbH Deutscherrnstr. 15-19 Phone +49(911)92891-27 D-90429 Nürnberg FAX +49(911)92891-99
On Fri, Jan 12, 2001 at 08:35:26PM +0100, Thomas Ziegler wrote:
Thanks for your detailed response, Marius.
Hi!
On Thu, Jan 11, 2001 at 06:17:28PM +0100, Marius Tomaschewski wrote:
ftp://ftp.suse.com/pub/projects/proxy-suite/src/TRANSPARENT_PROXY.txt or ftp://ftp.suse.com/pub/projects/proxy-suite/devel/TRANSPARENT_PROXY.txt
On Mon, Jan 08, 2001 at 12:53:51AM +0100, Thomas Ziegler wrote:
We are running an application level gateway, currently only with squid (http proxy) to hide our intra net from the internet. All ports are denyed by the firewall, exept the necessary ones.
Do not set DestinationAddress. Set only AllowTransProxy (and
As I understood the documentation, the DestinationAddress is mandantory.
Not since the transparent proxy patches. In the transparent proxy version it is allowed to leave DestinationAddress empty/unset, if you set "AllowTransProxy yes¨.
AllowMagicUser if you want it). Set Listen to the internal IP Address of the Gateway (connected to the Intranet) - see TRANSPARENT_PROXY.txt.
At the moment, we do not use the transparent option because
- there's a clear statement not to use it in production systems
It is my statement. I've removed it in the source for 7.1, because it IMHO is tested enough. I'll remove from the ftp (main) tree with the next update, too. Of course, you have to know what this option and also AllowMagicUser does and allows (override the destination). Both options are for outbound setups only - never use this, if you configure a inbound proxy ([¹] except you know what it does). [¹]: You can set AllowTransProxy (and DestinationAddress as a fallback; but NO AllowMagicUser) in a inbound setup, if you need a proxy, that filters all ftp connections to your ftp servers: ftp server 1 / clients (internet) ==> proxy --> ftp server 2 \ ftp server n In this setup, you have to take care, that your IP chains are set up propelly, because the proxy itself doeas not controll the destination in the transparent mode. It connects to all reachable (routing) destinations (proxy == gateway). The control about reachable/unreachable destinations is only your routing table on the gateway the proxy runs on and your IP filtering (redirection) rules.
- the suse7.0-Kernel doesnot support transparent proxy
I have no problems with recompiling kernels, but it's not the best idea to experiment on our gateway.
Sure, you need a test environment.
What's your experience with stability and security concerning the transparent proxy option?
In the first transparent proxy version were no checks if the IP address in getsockname(2) is i local adrees of the gateway, so I've written this warning and leaved it, so the people are warned, that this is a new feature. IMHO it is tested enough now.
- Is there a common way, how to access an ftp-proxy from the client side?
Yes, sure, with a normal FTP-Client.
I could imagine an approach like the proxy entry for http browsers. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This are not FTP proxies, but HTTP proxies. You can't use our ftp-proxy in this way, because it is a ftp proxy.
Sure, I know. What I meant is, that I could imagine a client which "knows", that it and how it has to transfer all ftp requests to the gateway. If that's the case, one can use the standard syntax
ftp ftp.uni-erlangen.de
to get anonymous access to the ftp server. If the client is ncftp or configured well, I do not need to provide the password for the anonymous access.
The proxy (in the transparent mode) connects transparently for the clients. The client doesn't know anything about, that it is using a proxy - we are not using any extended FTP commands the client has to use.
With the proxy several steps are required:
ftp gateway Name (gateway:zie): anonymous@ftp.uni-erlangen.de 331 Guest login ok, send your complete e-mail address as password. Password: xxx
It works, but it's a bit uncomfortable. I just installed the latest version of ncftp (3.0.2 instead of the suse7.0, which is 2.4.3) and saw that it supports seven different types of firewalls. Maybe the win32-clients support the same type, maybe not. Therefore my question about a standard way how to access an ftp-proxy.
If the proxy (transparent mode) is running on a gateway between your client host and the ftp servers (i.e. ftp.uni-erlangen.de), you can redirect all your client requests to the proxy ("-d 0/0 21 -j REDIRECT 21" with ipchains). The proxy checks the IP, your client wants to connect (i.e. the IP of ftp.uni-erlangen.de) and connects to this IP as destination. Sou you have only to do a "ftp ftp.uni-erlangen.de" to connect to ftp.uni-erlangen.de - the proxy + redirection rules handles the rest.
- Which clients are recommended for use in conjunction with the ftp-proxy ( ncftp?, other unix clients, win32 clients?)
All FTP clients should work. ncftp is a nice unix ftp client.
- Should the standard ports (20/21) be used or other ones?
I know of other firewalls, which changed the port from 21 to 2222. Does this increase security?
No. It does not. Of course, you can run the proxy on an different port. It is needed, if you want to start more than one proxy on one machine, i.e. "inbound" and "outbound" proxy, and bind them to the interface on the client's side. See TRANSPARENT_PROXY.txt: internal network - 192.168.0.0/16 (your clients) | | | eth0: 192.168.1.1 Firewall + Proxy | eth1: 2.2.2.2 | | I N T E R N E T # {¹}: redirect client FTP requests to the proxy ipchains -A input -i eth0 -s 0/0 -d 0/0 21 -p tcp -j REDIRECT 2222 # {²}: forbid all other FTP connections ipchains -A input -s 0/0 -d 0/0 21 -p tcp -j DENY # {³}: forbid direct connections to the proxy ipchains -A input -s 0/0 -d 0/0 2222 -p tcp -j DENY /etc/proxy-suite/ftp-proxy.conf: [-Global-] ServerType standalone LogDestination daemon DestinationTransferMode passive PortResetsPasv yes Listen 192.168.1.1 Port 2222 UseMagicChar % AllowMagicUser no AllowTransProxy yes In this scenario, all requests from your internal network (interface eth0) are redirected to the proxy that runs on 192.168.1.1:2222 (IP of interface eth0, port 2222). MagicUser is not allowed here. If a client (i.e. 192.168.0.1) does a "ftp ftp.uni-erlangen.de", the request maches the redirection rule {¹}: 192.168.0.1 -> 131.188.3.71:21 (=ftp.uni-erlangen.de) REDIRECT 192.168.1.1:2222 and the proxy opens a connection to the IP, the client needed 2.2.2.2 (external Proxy IP) -> 131.188.3.71:21 If you allow MagicUser, the client can also do: ftp ftp.uni-erlangen.de and override it in the USER command to i.e. ftp.suse.com, or also to ftpserver.domain.top:1234 and the proxy does not connect to ftp.uni-erlangen.de, but to the IP+Port set in the USER command. In this case, your users are able to use different ports than 21 (the port that is redirected). Instead of AllowMagicUser, you can also redirect requests to ftp servers that are not running on port 21, i.e.: ipchains -I input -i eth0 -s 0/0 -d ftpserver.domain.top 1234 -p tcp -j REDIRECT 2222 If the client does a "ftp ftpserver.domain.top 1234" the connection will also success, because the proxy checks both, the IP and Port the client want to connect to. It does not mater if your proxy runs on port 21 or 2222. Both is safe, because you are using a Listen to the IP of the internal inteface, so it is not reachable from the internet, EXCEPT, you have enabled forwarding between the interfaces (on SuSE IP_FORWARD=yes in the /etc/rc.config or a "echo 1 > /proc/sys/net/ipv4/ip_forward"). In this case you have allways to add explicit rule(s), that denys connects to the proxy from the internet: ipchains -I input -i eth1 -s 0/0 -d 0/0 2222 -p tcp -j DENY (or "-d 0/0 21" if the proxy runs on default port 21). This is also the reason, why I've added the rule {³} above.
- I do not understand the use of an LDAP server with an ftp-proxy. Is that one used to get access to the gateway itself or to authenticate users which want to get access to the outside world?
No. It is used to provide/override a configuration depending on the users name that is connecting to the proxy (only inbound mode).
ok.
- Suse-7.0 comes with an ssl-version of the ftp-proxy. Which clients/servers make use of ssl?
It is not implemented in the fwproxys on 7.0; it only actively refuses SSL connections at the moment... it is some kind of a useless package and will be skipped on 7.1, because we have no time to implement any SSL support at the moment.
ok.
- Any other experiences about security?
Soure, you have to know hat you are doing.
PS: In case anybody in this list want's to use the ftp-proxy on the suse7.0 CDs: It seems their ftp-proxy do not work. I had to recompile the sources.
It works, but there are bugs, so do not use RPMs shipped with SuSE 7.0.
Use the sources/RPMs provided on ftp://ftp.suse.com/pub/projects/proxy-suite/SuSE-7.0/ and not packages from CD (too old).
Gruesse,
Marius Tomaschewski
participants (2)
-
Marius Tomaschewski
-
Thomas Ziegler