Re: IPFW - Keep State
On Friday 31 August 2007 15:38:57 Grant Peel wrote: > I don't use NAT, so is there any other compelling reasons? Speed etc? Speed is one. The dynamic rules only evaluate protocol, IP addresses and ports. Whether this is noticeable, only you can tell. Also, if you're passing through traffic through other means (routing, bridging), that expects replies via the reverse route. So basically everything except local servers come to think of it. You may wanna look into: `sysctl net.inet.ip.fw | grep dyn_'. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW - Keep State
I don't use NAT, so is there any other compelling reasons? Speed etc? -Grant - Original Message - From: Mel To: freebsd-questions@freebsd.org Sent: Friday, August 31, 2007 9:21 AM Subject: Re: IPFW - Keep State On Friday 31 August 2007 14:34:51 Grant Peel wrote: > In a nutsheel, is it really necessary, or is thier a really compelling > reason to use keep-state for a normal web - email server? > > I sometimes see "Too many dynamic rules" and can see a correlation between > customer complaints and these log entries. > > My server all have about 200 rules, most of them counters for bandwidth > accounting. It is necessary for NAT, since it doesn't know what to do with replies from webservers otherwise (internet:80 => $ext_addr:high_port = what?) -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Total Control Panel Login To: [EMAIL PROTECTED] Block messages from this sender (blacklist) From: [EMAIL PROTECTED] Remove this sender from my whitelist You received this message because the sender is on your whitelist. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW - Keep State
On Friday 31 August 2007 14:34:51 Grant Peel wrote: > In a nutsheel, is it really necessary, or is thier a really compelling > reason to use keep-state for a normal web - email server? > > I sometimes see "Too many dynamic rules" and can see a correlation between > customer complaints and these log entries. > > My server all have about 200 rules, most of them counters for bandwidth > accounting. It is necessary for NAT, since it doesn't know what to do with replies from webservers otherwise (internet:80 => $ext_addr:high_port = what?) -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW 'keep state' & 'limit'
"fbsd_user" <[EMAIL PROTECTED]> writes: > The FBSD 5.2 man IPFW does not say anything different that the 4.9 > man IPFW. > Are you saying the man doc in 5.2 is wrong? > > 5.2 is using the ipfw2 code for IPFIREWALL I believe. > > Documenting the fact that 'limit' performs the same function as > 'keep state' in additional to 'limit' stated purpose is very > important information. Also that 'limit' and 'keep state' can not be > coded together is another very important piece information that need > to be documented in the man IPFW data. > > Should this be submitted as an problem report? > > > > -Original Message- > From: Dan Pelleg [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 14, 2004 9:47 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] ORG > Subject: Re: IPFW 'keep state' & 'limit' > > "fbsd_user" <[EMAIL PROTECTED]> writes: > >> Reading the man page on IPFW rule syntax, I get the impression > that >> the 'limit' option uses the stateful dynamic rules table. But it's >> unclear whether 'keep state' and limit can be used on the same > rule, >> or if the limit option performs the 'keep state' function in >> addition to the limit function. >> >> So as an example >> >> $cmd 00390 allow tcp from any to any 22 in via dc0 setup > keep-state >> limit src-addr 3 >> >> will this work? >> > > limit implies keep-state, and you should really specify one or the > other. If you specify both, ipfw won't complain, but ipfw2 will. So > it's > best to not do that. > > -- > > Dan Pelleg > > > Your rule, given to IPFW2 (on a 4.X system), yields: ipfw: only one of keep-state and limit is allowed I wouldn't say the man page hides the first fact; it is reasonably careful to say "keep-state or limit" in most places. It does, however, not mention that specifying both in the same rule is not accepted. In fact it says that "Zero or more" rule options are accepted, with both limit and keep-state listed as options (in the RULE OPTIONS section - this is on a man page from around 5.1). Given this might surprise people who move to 5.X and even lock them out, it might also be worth mentioning in one of migration guides. I suggest you bring this up to the doc@ list. -- Dan Pelleg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: IPFW 'keep state' & 'limit'
--- fbsd_user <[EMAIL PROTECTED]> wrote: > The FBSD 5.2 man IPFW does not say anything > different that the 4.9 > man IPFW. > Are you saying the man doc in 5.2 is wrong? > > 5.2 is using the ipfw2 code for IPFIREWALL I > believe. > > Documenting the fact that 'limit' performs the same > function as > 'keep state' in additional to 'limit' stated purpose > is very > important information. Also that 'limit' and 'keep > state' can not be > coded together is another very important piece > information that need > to be documented in the man IPFW data. > > Should this be submitted as an problem report? > > Snippits from IPFW(8) on FBSD 5.2 ---[begin snip]--- STATEFUL FIREWALL Stateful operation is a way for the firewall to dynamically create rules for specific flows when packets that match a given pattern are detected. Support for stateful operation comes through the check-state, keep-state and limit options of rules. [snip]- Dynamic rules will be checked at the first check-state, keep-state or limit occurrence, and the action performed upon a match will be the same as in the parent rule. ---[end snip--- There is also an occurence farther down under the "EXAMPLES" area in the "DYNAMIC RULES" area which doesn't mention the limit option. ---[begin snip}--- Dynamic rules are checked when encountering the first check-state or keep-state rule. ---[end snip] Granted it doesn't say anything about them not working if used together but, since it does say that they both create dynamic rules, it looks to be intuitively implied that they wouldn't be used together. __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: IPFW 'keep state' & 'limit'
The FBSD 5.2 man IPFW does not say anything different that the 4.9 man IPFW. Are you saying the man doc in 5.2 is wrong? 5.2 is using the ipfw2 code for IPFIREWALL I believe. Documenting the fact that 'limit' performs the same function as 'keep state' in additional to 'limit' stated purpose is very important information. Also that 'limit' and 'keep state' can not be coded together is another very important piece information that need to be documented in the man IPFW data. Should this be submitted as an problem report? -Original Message- From: Dan Pelleg [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 9:47 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] ORG Subject: Re: IPFW 'keep state' & 'limit' "fbsd_user" <[EMAIL PROTECTED]> writes: > Reading the man page on IPFW rule syntax, I get the impression that > the 'limit' option uses the stateful dynamic rules table. But it's > unclear whether 'keep state' and limit can be used on the same rule, > or if the limit option performs the 'keep state' function in > addition to the limit function. > > So as an example > > $cmd 00390 allow tcp from any to any 22 in via dc0 setup keep-state > limit src-addr 3 > > will this work? > limit implies keep-state, and you should really specify one or the other. If you specify both, ipfw won't complain, but ipfw2 will. So it's best to not do that. -- Dan Pelleg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW 'keep state' & 'limit'
"fbsd_user" <[EMAIL PROTECTED]> writes: > Reading the man page on IPFW rule syntax, I get the impression that > the 'limit' option uses the stateful dynamic rules table. But it's > unclear whether 'keep state' and limit can be used on the same rule, > or if the limit option performs the 'keep state' function in > addition to the limit function. > > So as an example > > $cmd 00390 allow tcp from any to any 22 in via dc0 setup keep-state > limit src-addr 3 > > will this work? > limit implies keep-state, and you should really specify one or the other. If you specify both, ipfw won't complain, but ipfw2 will. So it's best to not do that. -- Dan Pelleg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw keep-state (ASAP anwser need)
./[EMAIL PROTECTED] wrote:
> ${fwcmd} add allow udp from any 1024-65535,53 to any 53
> ${fwcmd} add allow udp from any 53 to any 1024-65535
That ruleset is a really bad idea. Imagine the following scenario: You
run a vulnerable service (bind, sendmail, you name it), Joe Haxor
launches a exploit against that service and creates a bindshell on port
1337. Now all he has to do is use port 53 as source and automagically
trespasses your firewall settings. Always use *stateful* firewalling,
and never allow anything not strictly necessary. Btw, zone transfers use
TCP, so you'd have to allow that as well.
Cheers,
--
Miguel Mendez <[EMAIL PROTECTED]>
http://www.energyhq.es.eu.org
PGP Key: 0xDC8514F1
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw keep-state (ASAP anwser need)
Have you perhaps deleted your rules? Check with ipfw list and make sure they are all there. Use /var/log/security to find which rule is denying the packets. If it's the default rule 65535, then your allow rules are somehow incorrect. - Original Message - From: "Gregory Edigarov" <[EMAIL PROTECTED]> Subject: Re: ipfw keep-state (ASAP anwser need) > On Tue, 09 Dec 2003, Rob wrote: > > > ipfw add 4100 allow udp from me to any 53 keep-state > > ipfw add 4200 allow udp from any to me 53 keep-state > It doesn't work. > > > What does /var/log/security show? > > it shows that all udp traffic to 53 port of any computer was denied. > > > It worked exactly like I've show for a very long time, but a week > ago something has broken. What is the other possibilities? > > -- > With best regards, > Gregory Edigarov > -- > profi.kharkov.uaSystems Administrator > -- > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw keep-state (ASAP anwser need)
I would suggest ipfw add 4100 allow udp from me to any 53 keep-state ipfw add 4200 allow udp from any to me 53 keep-state which allows either side to initiate the connection. You will also need TCP versions of these rules (DNS uses both). If you use ipfw2, which is the default in 5.x, you can combine them into the same rule like so: ipfw add 4100 allow ( tcp or udp ) from me to any 53 keep-state ipfw add 4200 allow ( tcp or udp ) from any to me 53 keep-state What does /var/log/security show? - Original Message - From: "Gregory Edigarov" <[EMAIL PROTECTED]> Subject: ipfw keep-state (ASAP anwser need) > Hello, > > The folowing is a fragment of my rc.firewall which must allow all > traffic in and out of my named. > > > ipfw add 4100 allow udp from me to any 53 keep-state > ipfw add 4200 allow udp from any to me 53 > ipfw add 4300 allow udp from me 53 to any > --- > This is a fragment from my kernel configuration: > --- > options IPFIREWALL #firewall > options IPFIREWALL_VERBOSE #enable logging to > syslogd(8) > options IPFIREWALL_FORWARD #enable transparent proxy > support > options IPFIREWALL_VERBOSE_LIMIT=100#limit verbosity > options IPDIVERT#divert sockets > options IPSTEALTH > options ICMP_BANDLIM > options DUMMYNET > options BRIDGE > options IPFW2 > --- > It doesn't work. What am I missing? > > -- > With best regards, > Gregory Edigarov > -- > profi.kharkov.uaSystems Administrator > -- > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw keep-state (ASAP anwser need)
${fwcmd} add allow udp from any 1024-65535,53 to any 53
${fwcmd} add allow udp from any 53 to any 1024-65535
- Original Message -
From: "Gregory Edigarov" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 09, 2003 5:32 PM
Subject: ipfw keep-state (ASAP anwser need)
> Hello,
>
> The folowing is a fragment of my rc.firewall which must allow all
> traffic in and out of my named.
>
>
> ipfw add 4100 allow udp from me to any 53 keep-state
> ipfw add 4200 allow udp from any to me 53
> ipfw add 4300 allow udp from me 53 to any
> ---
> This is a fragment from my kernel configuration:
> ---
> options IPFIREWALL #firewall
> options IPFIREWALL_VERBOSE #enable logging to
> syslogd(8)
> options IPFIREWALL_FORWARD #enable transparent proxy
> support
> options IPFIREWALL_VERBOSE_LIMIT=100#limit verbosity
> options IPDIVERT#divert sockets
> options IPSTEALTH
> options ICMP_BANDLIM
> options DUMMYNET
> options BRIDGE
> options IPFW2
> ---
> It doesn't work. What am I missing?
>
> --
> With best regards,
> Gregory Edigarov
> --
> profi.kharkov.uaSystems
Administrator
> --
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
>
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW - "keep-state/check-state" And "setup/established" Confusion
On 2003-03-20 11:56, James Long <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 20, 2003 at 06:52:32PM +0200, Giorgos Keramidas wrote:
> > > use "keep-state/check-state" for everything by adding my check-state
> > > rule near the top and then adding the following rule for incoming
> > > services:
> > >
> > > ipfw add allow ip from any to $inwr 21,22,25,80 keep-state
> >
> > As a matter of fact, you should. The 'established' keyword is not as
> > nice as a real, stateful firewall (which {keep,check}-state gives you).
>
> A learning question: First, I am working from the understanding that
> the keep-state flag results in _one_ rule from any to $inwr, but creates
> the complementary "$inwr to any" rules for the return traffic on an dynam-
> ic basis, and that there is one dynamic rule for each connection that is
> active at the time. I welcome enlightenment if I am mistaken in this.
>
> Given that one wants to run those four ports wide open to the world, won't
> "keep-state" result in the firewall creating N dynamic rules for the return
> traffic, where N is the number of connections open to those four ports?
> When N is large (i.e., when there are many connections to those ports),
> would it not result in fewer firewall rule comparisons to just run them
> wide open and be done with it?
>
> If one accepts traffic from anyone coming in to those ports, what is to
> be gained by restricting the IPs to which our server can send return
> traffic from those ports?
>
> ipfw add allow ip from any to $inwr 21,22,25,80
> ipfw add allow ip from $inwr 21,22,25,80 to any
>
> Wouldn't this result in a maximum of two rules, instead of N + 1?
True. This is probably a good way of avoiding the overhead associated
with dynamic rules. I was only comparing 'established' to '*-state' ;)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message
Re: IPFW - "keep-state/check-state" And "setup/established" Confusion
On 2003-03-20 09:22, Drew Tomlinson <[EMAIL PROTECTED]> wrote: > It does help. One other question I have is that I never see the > "check-state" packet count incrementing. However I vaguely recall > reading somewhere that it doesn't, even when packets pass via the > rule. Is this correct? I'm not sure if this is the way it works. I'd have to check the kernel side of ipfw to see if this works this way, and IPFW2's kernel part is far from understandable for a kernel newbie like me :) - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: IPFW - "keep-state/check-state" And "setup/established" Confusion
On Thu, Mar 20, 2003 at 06:52:32PM +0200, Giorgos Keramidas wrote:
> > use "keep-state/check-state" for everything by adding my check-state
> > rule near the top and then adding the following rule for incoming
> > services:
> >
> > ipfw add allow ip from any to $inwr 21,22,25,80 keep-state
>
> As a matter of fact, you should. The 'established' keyword is not as
> nice as a real, stateful firewall (which {keep,check}-state gives you).
A learning question: First, I am working from the understanding that
the keep-state flag results in _one_ rule from any to $inwr, but creates
the complementary "$inwr to any" rules for the return traffic on an dynam-
ic basis, and that there is one dynamic rule for each connection that is
active at the time. I welcome enlightenment if I am mistaken in this.
Given that one wants to run those four ports wide open to the world, won't
"keep-state" result in the firewall creating N dynamic rules for the return
traffic, where N is the number of connections open to those four ports?
When N is large (i.e., when there are many connections to those ports),
would it not result in fewer firewall rule comparisons to just run them
wide open and be done with it?
If one accepts traffic from anyone coming in to those ports, what is to
be gained by restricting the IPs to which our server can send return
traffic from those ports?
ipfw add allow ip from any to $inwr 21,22,25,80
ipfw add allow ip from $inwr 21,22,25,80 to any
Wouldn't this result in a maximum of two rules, instead of N + 1?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message
Re: IPFW - "keep-state/check-state" And "setup/established" Confusion
- Original Message -
From: "Giorgos Keramidas" <[EMAIL PROTECTED]>
To: "Drew Tomlinson" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, March 20, 2003 8:52 AM
> On 2003-03-19 15:19, Drew Tomlinson <[EMAIL PROTECTED]> wrote:
>> I'm using ipfw2 to setup a firewall on 4.8-RC for my home network.
>> I used the rule set at
>>
>> http://www.bsdtoday.com/2000/December/rc.firewall.current
>>
>> as an example but am confused regarding the differences between
>> setting rules using "setup/established" and "keep-state /
>> check-state". I've read the ipfw man page and understand that
>> "setup/established" matches syn/ack bits in a packet where
>> "keep-state/check-state" actually creates a dynamic rule.
>> But not being real knowledgeable about how IP packets are
>> constructed, I'm not sure what this means in the real world.
>
>It means that `established' uses a very simple test of packet contents
>to find out if this packet belongs to an existing connection. This
>simple test is "good enough" for some packets, but will match packets
>that are not part of a real, existing connection too.
>
>> If I understand it correctly, the example at BSDToday basically uses
>> "setup/established" to allow traffic in for services that I allow.
>> So in my case I would use it for FTP, SMTP, SSH, and HTTP. Then the
>> rule set uses "keep-state/check-state" for connections originating
>> from my internal network to the outside world. But why should I not
>> use "keep-state/check-state" for everything by adding my check-state
>> rule near the top and then adding the following rule for incoming
>> services:
>>
>> ipfw add allow ip from any to $inwr 21,22,25,80 keep-state
>
>As a matter of fact, you should. The 'established' keyword is not as
>nice as a real, stateful firewall (which {keep,check}-state gives you).
>
>> I've actually done this and it is working but I'd like to know if
>> this is a good or bad idea and why.
>
>In a reply to a private message, a few weeks ago, I tried to explain
>the different to someone. Here's the message, without any names.
>I hope this helps a bit :-)
Thank you for the explaination. It does help. One other question I have is
that I never see the "check-state" packet count incrementing. However I
vaguely recall reading somewhere that it doesn't, even when packets pass via
the rule. Is this correct?
I'm happy to know that the "keep/check-state" rules are the way to go. It
makes my rule set simpler too. Now on to traffic prioritization via
dummynet! :)
Thanks again,
Drew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message
Re: IPFW - "keep-state/check-state" And "setup/established" Confusion
On 2003-03-19 15:19, Drew Tomlinson <[EMAIL PROTECTED]> wrote:
> I'm using ipfw2 to setup a firewall on 4.8-RC for my home network.
> I used the rule set at
>
> http://www.bsdtoday.com/2000/December/rc.firewall.current
>
> as an example but am confused regarding the differences between
> setting rules using "setup/established" and "keep-state /
> check-state". I've read the ipfw man page and understand that
> "setup/established" matches syn/ack bits in a packet where
> "keep-state/check-state" actually creates a dynamic rule.
> But not being real knowledgeable about how IP packets are
> constructed, I'm not sure what this means in the real world.
It means that `established' uses a very simple test of packet contents
to find out if this packet belongs to an existing connection. This
simple test is "good enough" for some packets, but will match packets
that are not part of a real, existing connection too.
> If I understand it correctly, the example at BSDToday basically uses
> "setup/established" to allow traffic in for services that I allow.
> So in my case I would use it for FTP, SMTP, SSH, and HTTP. Then the
> rule set uses "keep-state/check-state" for connections originating
> from my internal network to the outside world. But why should I not
> use "keep-state/check-state" for everything by adding my check-state
> rule near the top and then adding the following rule for incoming
> services:
>
> ipfw add allow ip from any to $inwr 21,22,25,80 keep-state
As a matter of fact, you should. The 'established' keyword is not as
nice as a real, stateful firewall (which {keep,check}-state gives you).
> I've actually done this and it is working but I'd like to know if
> this is a good or bad idea and why.
In a reply to a private message, a few weeks ago, I tried to explain
the different to someone. Here's the message, without any names.
I hope this helps a bit :-)
From: Giorgos Keramidas <[EMAIL PROTECTED]>
Date: Wed, 26 Feb 2003 03:51:08 +0200
On 2003-02-25 17:15, you wrote:
>On Wed, 26 Feb 2003 02:36:18 Giorgos Keramidas wrote:
>>On 2003-02-25 16:29, you wrote:
>>> On Wed, 26 Feb 2003 02:25:12 Giorgos Keramidas wrote:
>>> >
>>> >The changes from your own set of rules are summarized below: [...]
>>>
>>> Indeed! I do have the variables listed defined, and have natd
>>> configured and working. Thank you very much--not only did you
>>> answer my question, but gave me a better understanding of ipfw!
>>
>>I did? Oh, cool :)))
>
> Just wondering, do I not need the 'established' rule to let existing
> connections persist?
The ipfw manpage contains this description of the 'established'
keyword, which means a lot to someone who knows how TCP handles
connections and what the bits RST and ACK are used for.
established
Matches TCP packets that have the RST or ACK bits set.
This is, alas, a very cryptic and strange thing for someone who
doesn't know the internals of the TCP protocol. Which is something
that I wouldn't expect the casual reader of the manpage to know. The
detailed explanation of how this keyword matches packets is very large
for me to include in a single email reply, and I won't even attempt to
do something like this.
For the moment, let's say that 'established' is a very simplistic way
of filtering packets that are part of an existing connection. The
keep-state and check-state combination that I used instead of your
initial established ruleset works a lot better and has a quite better
chance of blocking packets that are not part of a "real" TCP
connection. Bearing this in mind, you might find it easier to accept
the keep-state/check-state pair as a safer way of filtering. The
keep-state keyword creates a dynamic rule for ever successful
connection that matches, and check-state runs through the list of
dynamic rules looking for matches before passing a packet. It's safer
to use because the dynamic rules are created by keep-state to match
the existing connections and then deleted after the connection dies;
instead of allowing through any packet that is "possibly part of an
existing connection because it includes one of ACK or RST flags or
both".
When you use the 'established' keyword, your firewall is open to
attacks by ingenious hackers who know the way TCP works and create
their own 'custom' packets, including RST or ACK flags, in the hope
that their packet will pass through improperly configured firewalls
(such as those who depend on 'established' for their blocking rules).
Once a packet has been allowed through by an 'stablished' rule it will
probably have a chance to reach the internal network, going out
through a different interface, and let the attacker establish a
limited but nevertheless important "channel of information retrieval"
for your internal n
