(cc'ing this mail to a couple of LUG mailing lists...) hey all, spawned from a recent discussion on this mailing list (suse-security), i would like to ask the following question: in a NAT'd LAN, how can one enable the use of genuine ftp clients (ncftp, wsftp) as well as netscape/ie that pretend to speak ftp, without allowing all connections to ports 1024+ on the firewall/masquerading host? 99% of all ftp traffic nowadays is passive, so the data transfer happens from port 21 of the server to port x {x | x >= 1024} of the client. our firewall is implemented with ipchains (subject to change sometime), so it's stateless. blocking all ports above 1024 disables not only ftp but a lot of services such as ssh that make use of the ports 1024+ for the client connection. philip snizek suggested closing ports 5000 and up, leaving only some 4000 ports for this usage, but that solution is not what i am looking for because it still leaves 4000 ports open for an attack, and what is more important in this situation, it is very possible that some client program tries to establish a connection to a server with the backward connect (server -> client) being something like x -> 5021. in that case then, the connect will mysteriously fail (i DENY packets rather than to REJECT them). so while it is perfectly understandable to me how and why and what ports under 1024 i have to block and open to secure the machine, the ports above 1024 are a mystery. a lot of networks i have worked in/with/for had firewall policies that allowed anything above 1024, but as philip pointed out, this is asking for trojans. so i am wondering if, besides the installation of a statefull firewall, there is a way to secure the machine without affecting the liberty of the users in the LAN. and do you guys know of free, open-source statefull firewalls for linux? thanks, martin [greetings from the heart of the sun]# echo madduck@!#:1:s@\@@@.net -- echo '[dO%O+38%O+PO/d0<0]Fi22os0CC4BA64E418CE7l0xAP'|dc
Hi Martin, Nice, that you're back again. Happy New Year to all list members.
99% of all ftp traffic nowadays is passive, so the data transfer happens from port 21 of the server to port x {x | x >= 1024} of the client. our firewall is implemented with ipchains (subject to change sometime), so it's stateless. blocking all ports above 1024 disables not only ftp but a lot of services such as ssh that make use of the ports 1024+ for the client connection.
philip snizek suggested closing ports 5000 and up, leaving only some 4000 ports for this usage, but that solution is not what i am looking for because it still leaves 4000 ports open for an attack, and what is more important in this situation, it is very possible that some client program tries to establish a connection to a server with the backward connect (server -> client) being something like x -> 5021. in that case then, the connect will mysteriously fail (i DENY packets rather than to REJECT them).
# POLICIES ipchains -P forward DENY # PROXY RULE WWW, FTP, SSL ipchains -A input -p tcp -s 10.0.0.0/24 1024:5000 -d 10.0.0.191/32 8008 -i eth1 -j ACCEPT ipchains -A input -p tcp -s ! 10.0.0.0/24 443 -d 212.232.168.183/32 1024:5000 -i eth0 -j ACCEPT ipchains -A input -p tcp -s ! 10.0.0.0/24 80 -d 212.232.168.183/32 1024:5000 -i eth0 -j ACCEPT ipchains -A input -p tcp -s 212.232.168.180/32 1024: -d 212.232.168.183/32 113 -i eth0 -j ACCEPT # Don't worry guys, there is no auth server running on 212.232.168.183, it's there because of sendmail. I still didn't find a suitable solution to make it faster although I'm sure there is one. ipchains -A input -p tcp -s ! 10.0.0.0/24 20:21 -d 212.232.168.183/32 1024:5000 -i eth0 -j ACCEPT ipchains -A input -p tcp -s ! 10.0.0.0/24 1024: -d 212.232.168.183/32 1024:5000 -i eth0 -j ACCEPT ipchains -A output -p tcp -s 10.0.0.191/32 8008 -d 10.0.0.0/24 1024:5000 -i eth1 -j ACCEPT # DENIALs ipchains -A input -i eth1 -j DENY -l ipchains -A output -i eth1 -j DENY -l ipchains -A input -i eth0 -j DENY -l You all may call me nuts that I post some of my chains of my inner sanctum to the list, but here again how I solved ftp-pasv access. Please don't forget that I run squid in pasv mode, so I can completely deny forward rule for www, ssl and pasv-ftp. Important for your questions are these chains here which are found in the #PROXY RULE WWW,FTP,SSL section. These chains define input from internet to my proxy. ipchains -A input -p tcp -s ! 10.0.0.0/24 20:21 -d 212.232.168.183/32 1024:5000 -i eth0 -j ACCEPT This rule here allows standard ftp as defined in some rfc I don't remember anymore accessing my proxy on ports 1024:5000. I would even reduce it more if I knew how deep I could set it without endangering my ftp life. ipchains -A input -p tcp -s ! 10.0.0.0/24 1024: -d 212.232.168.183/32 1024:5000 -i eth0 -j ACCEPT This rule here defines all stuff that deals with ftp from 1024:. I have only one machine making requests and this is the proxy itself. All other boxes (the internal network are totally 3 PCs) access through port 8008 as you might see above www, ftp and ssl. I can't tell you how this behaves if I had 100 PCs in the internal net. Whether Squid would use 1024: ports to satisfy all requests at once. Maybe it's better we ask somebody who is more experienced than me. CUL Philipp
On Jan 4 at 20:15, MaD dUCK (or reasonable facsimile) said: //snip
in a NAT'd LAN, how can one enable the use of genuine ftp clients (ncftp, wsftp) as well as netscape/ie that pretend to speak ftp, without allowing all connections to ports 1024+ on the firewall/masquerading host? //snip
One possible way to resolve the problem 1024+ is this (the idea comes from the SuSEfirewall script, but I forget how they did it... I think it is not carried through): # Which ports do programs use for unbound traffic: LOWPORT=10001 HIGHPORT=20000 # For the input chain (I jumped to server_i) echo "$LOWPORT $HIGHPORT" > /proc/sys/net/ipv4/ip_local_port_range ipchains --append server_i -p TCP --dport $LOWPORT:$HIGHPORT -j ACCEPT ipchains --append server_i -p UDP --dport $LOWPORT:$HIGHPORT -j ACCEPT # # other rules for services we expose go here (including ICMP's not shown) ipchains --append server_i -p TCP --dport 22 -j ACCEPT ipchains --append server_i -j DENY So, the server is allowed to make ANY outgoing connections it pleases, but there is no requirement to expose common services in the >1024 port range (e.g. mysql at 3306). It is a good idea to do this BEFORE starting services that make connections, since they will have the data denied if they use ports in the range 1024-4096 as is default. (I can't figure out if someone said this already among all the helpful ideas posted). &:-) -- This is joke number 92
hi, sorry it took me so long to reply, i was out of office for a while. with regards to your reply, i have a couple of questions... also sprach Andrew McGill (on Tue, 16 Jan 2001 02:12:52PM +0200):
# Which ports do programs use for unbound traffic: LOWPORT=10001 HIGHPORT=20000 # For the input chain (I jumped to server_i) echo "$LOWPORT $HIGHPORT" > /proc/sys/net/ipv4/ip_local_port_range ipchains --append server_i -p TCP --dport $LOWPORT:$HIGHPORT -j ACCEPT ipchains --append server_i -p UDP --dport $LOWPORT:$HIGHPORT -j ACCEPT # # other rules for services we expose go here (including ICMP's not shown) ipchains --append server_i -p TCP --dport 22 -j ACCEPT ipchains --append server_i -j DENY
So, the server is allowed to make ANY outgoing connections it pleases, but there is no requirement to expose common services in the >1024 port range (e.g. mysql at 3306). It is a good idea to do this BEFORE starting services that make connections, since they will have the data denied if they use ports in the range 1024-4096 as is default.
i don't think i understand how that works. what does /proc/sys/net/ipv4/ip_local_port_range control? and what is the idea behind this approach? thanks, martin [greetings from the heart of the sun]# echo madduck@!#:1:s@\@@@.net -- xerox does it again and again and again and ...
echo "$LOWPORT $HIGHPORT" > /proc/sys/net/ipv4/ip_local_port_range i don't think i understand how that works. what does /proc/sys/net/ipv4/ip_local_port_range control?
Hi, following your discussion I've got one single question: Is there - anywhere out in the net - a good, detailed explanation of all the /proc features? Regards, Ralf * * Ralf Koch * mailto:info@formel4.de *
look in the doc directory of the kernel sources for the version you are running. At 02:09 PM 21/01/2001 +0100, you wrote: >Hi, >following your discussion I've got one single question: Is there - >anywhere out >in the net - a good, detailed explanation of all the /proc features? > >Regards, > >Ralf > > >> echo "$LOWPORT $HIGHPORT" > /proc/sys/net/ipv4/ip_local_port_range > >i don't think i understand how that works. what does > >/proc/sys/net/ipv4/ip_local_port_range control? >* >* Ralf Koch >* mailto:info@formel4.de >* > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: suse-security-unsubscribe@suse.com >For additional commands, e-mail: suse-security-help@suse.com --- Nix - nix@susesecurity.com SuSE-Security FAQ Maintainer http://www.susesecurity.com
HiHO...
following your discussion I've got one single question: Is there - anywhere out in the net - a good, detailed explanation of all the /proc features?
http://www.bb-zone.com/Proc/chapter2.html#section2.8 stephan -- t="\$_='for(\$i=-2;\$_=substr(\"2720ab25409d2500f82310a6272\",\$i+=2,3);) .~. /V\ s.martin@odn.de /( )\ ^ ~ ^ {\$_=\$i++%2?hex:oct;\$_=chr(\$_%(2**2*22));\$_=\$i?lc:{};print; }';s/\( +\)|[\w\.]+\@[^ ]+|[.\/V~^\\\]+| {2,}//g;eval \$_;"&&echo $t|perl
echo "$LOWPORT $HIGHPORT" > /proc/sys/net/ipv4/ip_local_port_range i don't think i understand how that works. what does /proc/sys/net/ipv4/ip_local_port_range control?
proc has about a million features. For example a minor list of security related
features:
http://www.securityportal.com/closet/closet20001206.html
Kurt Seifried, seifried@securityportal.com
Securityportal - your focal point for security on the 'net
----- Original Message -----
From: "Ralf Koch"
Kurt Seifried wrote:
proc has about a million features. For example a minor list of security related features:
Who knows a more detailed list? Janto -- Janto Trappe - PGP key available upon request - Germany
Hi, At 17:54 22/01/01, Janto Trappe wrote:
Kurt Seifried wrote:
proc has about a million features. For example a minor list of security related features:
Who knows a more detailed list?
I think you'll find this more useful. http://www.bb-zone.com/Proc/index.html John
Read kernel sources/documentation. Kurt Seifried wrote:
proc has about a million features. For example a minor list of security related features:
Who knows a more detailed list? Janto -- Janto Trappe - PGP key available upon request - Germany --------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
On 22-Jan-01 Janto Trappe wrote:
Kurt Seifried wrote:
proc has about a million features. For example a minor list of security related features:
Who knows a more detailed list?
Take a look at www.bb-zone.com/Proc/index.html for a more complete description of the /proc filesystem. Boris
Janto
-- Janto Trappe - PGP key available upon request - Germany
---
Boris Lorenz
i don't think i understand how that works. what does /proc/sys/net/ipv4/ip_local_port_range control? Thus says /usr/src/linux/Documentation/proc.txt:
and what is the idea behind this approach? The idea is to make it possible to drop ALL incoming and outgoing packets
ip_local_port_range Range of ports used by TCP and UDP to choose the local port. Contains two numbers, the first number is the lowest port, the second number the highest local port. Default is 1024-4999. Should be changed to 32768-61000 for high-usage systems. directed at ports below 10000 on the incoming interface (except of course for the 3 services you choose to expose to the world). A program can still explicitly bind to a different port though (e.g. ssh using a reserved port for its outgoing connection). I take it from the absence of contradictions of the form "that won't work correctly because ..." that one can do this to limit the range of outgoing ports to something different without any severe problems. There are a few funnies -- like ssh doesn't work for root and for normal users if it is marked suid, since it makes its connection from a port <1024. (Solved by alias scp='scp -L'; alias ssh='ssh -P'; ) &:-) On Jan 20 at 21:55, my computer said MaD dUCK said:
hi, sorry it took me so long to reply, i was out of office for a while. with regards to your reply, i have a couple of questions... //snip
echo "$LOWPORT $HIGHPORT" > /proc/sys/net/ipv4/ip_local_port_range ipchains --append server_i -p TCP --dport $LOWPORT:$HIGHPORT -j ACCEPT ipchains --append server_i -p UDP --dport $LOWPORT:$HIGHPORT -j ACCEPT //snip ipchains --append server_i -j DENY //snip
There are a few funnies -- like ssh doesn't work for root and for normal users if it is marked suid, since it makes its connection from a port <1024. (Solved by alias scp='scp -L'; alias ssh='ssh -P'; )
you can simply remove the setuid bit, it's there to make ssh 100% drop in compatible replacement for braindead stuff like rsh/etc that rely on source port <1024. The following articles covers a lot of cool things you can do: http://www.securityportal.com/closet/closet20001101.html Kurt Seifried, seifried@securityportal.com Securityportal - your focal point for security on the 'net
participants (10)
-
Andrew McGill -
Boris Lorenz -
Janto Trappe -
John Trickey -
Kurt Seifried -
MaD dUCK -
Nix -
Philipp Snizek -
Ralf Koch -
Stephan Martin