Great Circle Associates Firewalls
(December 1992)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: packet filtering metalanguage
From: Brent Chapman <brent @ GreatCircle . COM>
Date: Mon, 14 Dec 92 08:44:08 -0800
To: Firewalls @ GreatCircle . COM
In-reply-to: Your message of Sat, 5 Dec 1992 14:41:00 -0800

# Atomic filters specs for IP/TCP/UDP need to encompass the following
# elements:
# 
# 1.  Interface
# 2.  Direction (inbound/outbound on interface)
# 3.  Source IP address
# 4.  Source IP address mask
# 5.  Destination IP address
# 6.  Destination IP address mask
# 7.  Protocol (UDP, TCP, ICMP, etc.)
# 8.  Source port [range]
# 9.  Destination port [range]
# 10. Pass/reject the packet if it matches the filter
# 
# For ICMP you need to substitute the following for 8 & 9 above:
# 
# 8'. ICMP message type
# 9'. ICMP message subtype

I would also like to add, for TCP, the ability to determine whether or
not this packet is part of an established TCP connection (Cisco's
"established" filtering keyword comes to mind) or not.  You can
determine this by examining the SYN and ACK bits in the TCP header of a
packet; your router doesn't need to keep a state table of established
connections or anything like that.

With just the filtering capability Brian describes above, you are still
vulnerable to attacks from well-known-ports on remote machines against
services on high-numbered-ports (>1023) on internal machines.

For example, say your filters allow outgoing SMTP connections.  Here's
what they'd look like (ignoring "interface" and "direction" for the
moment, since they're irrelevant to this discussion):

SrcAddr	DstAddr	Proto	SrcPort	DstPort	Action
=======	=======	=====	=======	=======	======
Intern	Extern	TCP	>1023	25	permit	# allows outbound packets
Extern	Intern	TCP	25	>1023	permit	# allows return packets
*	*	*	*	*	deny	# default rule; often implicit

If you have a service (say a database) living at port 1500 on an internal
machine, and somebody co-opts the SMTP port on a remote machine, they can
attack your database through the above filters.

You could avoid this vulnerability (small though it is) if you could
preclude start-of-connection packets from passing the second rule above.
The way to do that is to make the second rule apply only to "established"
connections.  I.e., if you could specify something like this:

SrcAddr	DstAddr	Proto	SrcPort	DstPort	Flags	Action
=======	=======	=====	=======	=======	=====	======
Intern	Extern	TCP	>1023	25		permit	
Extern	Intern	TCP	25	>1023	estab	permit	
*	*	*	*	*		deny


-Brent
--
Brent Chapman                                   Great Circle Associates
Brent @
 GreatCircle .
 COM                           1057 West Dana Street
+1 415 962 0841                                 Mountain View, CA  94041


Indexed By Date Previous: [no subject]
From: <LJI01%ALBNYDH2 . bitnet @ UACSC2 . ALBANY . EDU>
Next: Re: IP security labels
From: ggc @ lanl . gov (Gary G. Christoph)
Indexed By Thread Previous: [no subject]
From: <LJI01%ALBNYDH2 . bitnet @ UACSC2 . ALBANY . EDU>
Next: Re: IP security labels
From: ggc @ lanl . gov (Gary G. Christoph)

Google
 
Search Internet Search www.greatcircle.com