Date: Thu, 07 Jun 2001 16:52:03 -0400 From: Bill Moran <wmoran@iowna.com> To: Josh Thomas <jdt2101@ksu.edu> Cc: freebsd-questions@freebsd.org Subject: Re: IPFW rules and outward connections Message-ID: <3B1FE973.AE494B0D@iowna.com> References: <Pine.GSO.4.21L.0106071523270.15125-100000@unix1.cc.ksu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Josh Thomas wrote: > > For awhile I was looking at check-state and keep-state for connections > to keep open. However, maybe I'm a little confused here. Where > check-state and keep-state will create a dynamic ruleset for allowing > outward connections to keep a port on my local machine open for response > packets from the remote machines ip and port for a limited amount of time, > how does the 'established' ruleset differ significantly from this? From > what I understand, 'established' will do the same thing? I think I may > have been vague in my initial post. If I send a http request from > some random high-up port, say 12000, has the connection with a > remote host on 80 been established, and that port 12000 open for > responses? And if that is true, does the established connection get lost > after the same period of time (of network inactivity) that check-state > and keep-state do? Again, please cc: responses. First, I want to apologize for a somewhat inaccurate, off-the-cuff response. I'll now try to clarify my misinformation: "established" only works with tcp (not udp) The established rule checks the various header information in the TCP packet to see if the packet belongs to an already established tcp connection, if so the rule fires. If the packet header indicates that the packet is an attempt to establish a tcp connection, the rule does not fire and (assuming the rest of your rule logic is sound) the packet catches a "deny" rule somewhere down the line and is dealt with dropped/rejected/smacked/beaten/raped/whatever. Basically, if some other rule in your ruleset allows an internal machine to establish a connection, this rule will allow the machines that are part of the connection to continue to communicate. The opposite of established is setup, for example: allow tcp from 192.168.5.73 to any 22 setup allow tcp from any to 192.168.5.73 22 setup allow tcp from any to any established deny tcp from any to any Will allow the IP listed to initiate a ssh connection to anyone or receive a ssh connection from anyone, while the second rule ensures that the connection can continue to communicate and the final rule blocks anything that doesn't fit into the first category. tcp communications must establish themselves, therefore anything that is not specifically allowed to "setup" will never get to the "established" state. (it's probably best, for speed, to always put the "established" rule near the beginning of your ruleset) So my answer is probably only a partial solution to your problem. Unless, of course, there is no udp traffic that you want to allow, in which case, the established condition will handle your problem. See the man page for ipfw for more details on using that rule. Also, the rc.firewall that ships with the system has some excellent examples of usage. -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B1FE973.AE494B0D>