TUCoPS :: Linux :: Apps N-Z

TUCoPS :: Linux :: Apps N-Z :: lnx5548.htm
Pyramid BenHur Firewall active FTP portfilter ruleset results in a firewall leak
23th Jul 2002 [SBWID-5548]
COMMAND

	Pyramid BenHur Firewall active  FTP  portfilter  ruleset  results  in  a
	firewall leak

SYSTEMS AFFECTED

	BenHur Firewall release 3 with update 066 fix 2, and earlier release

PROBLEM

	In Dr. Peter Bieringer of AERAsec Network Services  and  Security  GmbH,
	advisory [ae-200207-028] :
	

	http://www.aerasec.de/security/advisories/txt/ae-200207-028-BenHur-activeFTPruleset.txt

	

	

	In short, Source port 20 on a client can be used to connect to  services
	on ports between 1024 and 65096 (release "Update 066  fix  2")  or  1024
	and 65535 (initial installed release)
	

	One can connect to the ports  using  e.g.  netcat:  "nc  -p  20  $benhur
	$remoteport"
	

	This makes it possible  to  connect  to  several  active  TCP  ports  on
	BenHur:
	

	tcp        0      0 0.0.0.0:3128            0.0.0.0:*               LISTEN

	 -> Squid

	     protected by Squid-ACL against misuse from outside

	tcp        0      0 0.0.0.0:8888            0.0.0.0:*               LISTEN

	 -> BenHur Webadministration

	     not protected by IPv4-ACL, see below

	tcp        0      0 0.0.0.0:4557            0.0.0.0:*               LISTEN

	 -> HylaFAX client server

	     (possible access not tested)

	tcp        0      0 0.0.0.0:4559            0.0.0.0:*               LISTEN

	 -> HylaFAX client server

	     (possible access not tested)

	tcp        0      0 0.0.0.0:6105            0.0.0.0:*               LISTEN

	 -> ISDN client server monitor and connection trigger program

	     (possible access not tested)

	

	

	Especially the BenHur Web administration port is interesting:
	

	# nc -p 20 ***.***.***.*** 8888

	GET / HTTP/1.0

	

	HTTP/1.1 401 Authorization Required

	Date: Tue, 09 Jul 2002 09:53:51 GMT

	Server: Apache/1.3.0 (Unix) Debian/GNU

	WWW-Authenticate: Basic realm="Ben-Hur Administration"

	Connection: close

	Content-Type: text/html

	

	<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

	<HTML><HEAD>

	<TITLE>401 Authorization Required</TITLE>

	</HEAD><BODY>

	<H1>Authorization Required</H1>

	This server could not verify that you

	are authorized to access the document you

	requested.  Either you supplied the wrong

	credentials (e.g., bad password), or your

	browser doesn't understand how to supply

	the credentials required.<P>

	</BODY></HTML>

	

	Two issues:
	

	  a) Information disclosure about Apache Version, OS and Firewall software.

	  b) Dictionary or brute-force attack on password is possible.

	

SOLUTION

	At the moment only experimental update 067 (19 Jul 2002)
	

	 Patch

	 =====

	

	Update hints, select experimental updates by change of setting:
	

	"configuration->admin->update-host-einstellungen->url-pfad"

	to "updates_experimental"

	

	Or dedicated download for customers at
	

	https://www.ben-hur.de/updates_experimental

	

	

	

	 Workaround

	 ==========

	

	There are several solutions to close such holes in general:
	

	1) For masqueraded active FTP connection, the destination  port  on  the
	firewall is always mapped to a port in  the  range  61000-65095  by  the
	module "ip_masq_ftp". Therefore a rule like chain:
	

	input ACCEPT  tcp ------ 0xFF 0x00ppp0 0.0.0.0/00.0.0.0/0   20 -> 61000:65095

	

	would be more appropriate. The above translates to the  following  lines
	replacing the corresponding lines  in  the  /etc/init.d/ben-hur.ipchains
	in script quoted above:
	

	$IPCHAINS -A input  --source-port 20 -d $WORLD 61000:65095 -p tcp \

	  -i $IFACE_WWW -j ACCEPT

	$IPCHAINS -A output --source-port 20 -d $HOME  1024:65535  -p tcp \

	  -i $IFACE_LAN -j ACCEPT

	

	Note1: in the original  setup,  the  script  contains  a  (not  security
	related) bug in the port range for the  output  chain  on  the  internal
	interface.
	

	Note2: this improvement is also done in BenHur software update 067.
	

	2) If the firewall itself uses active  FTP,  then  the  local  portrange
	should be generally moved to a less dangerous region,  e.g.  32768-60999
	by using:
	

	sysctl -w net.ipv4.ip_local_port_range="32768 60099"

	or equivalently:

	echo "32768 60099" >/proc/sys/net/ipv4/ip_local_port_range

	

	You are advised to ensure that the range  used  for  ip_local_port_range
	does not conflict with any LISTENING ports on the firewall itself
	

	

	If not able to move the local port range for now, you  should  at  least
	reduce the impact by a second more selective rule for the input chain:
	

	LOCALPORTRANGE="`cat /proc/sys/net/ipv4/ip_local_port_range | awk '{ print $1 ":" $2 }'`"

	$IPCHAINS -A input  --source-port 20 -d $WORLD $LOCALPORTRANGE -p tcp -i $IFACE_WWW -j ACCEPT

	

	Normally this results in following ruleset chain:
	

	input ACCEPT  tcp ------ 0xFF 0x00ppp0 0.0.0.0/00.0.0.0/0   20 -> 1024:4999

	

	BTW: RPC  services  (using  portmapper  for  registration)  always  uses
	dynamic ports, which are requested by asking the kernel for a free  port
	out   of   local   port   range   first.   Therefore,   modifying    the
	ip_local_port_range parameter  does  not  ensure  a  protection  of  RPC
	services behind the firewall.
	

	Note: BenHur firewall don't need filter rules for  outgoing  active  FTP
	in general, software update 067 doesn't contain such rule.
	

	

	3) Restrict the LISTENING socket bindings of  the  daemons  as  much  as
	possible (making them listen  only  on  the  local  interface  and  thus
	making connections from the outside impossible), and/or  employ  an  ACL
	system:
	

	     * Daemon-built-in-ACLs

	     * tcp_wrapper (if possible)

	     * creating dedicated block rules for active server ports >= 1024