Ramifications of blocking SYN+FIN TCP packets

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Ramifications of blocking SYN+FIN TCP packets

Stuart VanZee
I understand that this might annoy a few of you, If it does
please accept my apologies.

The place I work is required to have an external security scan
from time to time and the latest scan says that we have failed
because the firewall responded to a TCP packet that has the SYN
and FIN flags set.  I know that OpenBSD isn't vulnerable to the
exploits that use this:

http://www.kb.cert.org/vuls/id/IAFY-5F8RWP

However, I don't see any reason to respond to a packet with SYN
and FIN set, AND, a firewall rule that drops said TCP packets
would fix the fact that we are now "non compliant" as far as
the security scan goes.  I think a pf rule such as:

block drop in quick proto tcp all flags SF/SF

would do it.

Does anyone see a way that this would come back to bite me on
the ass later?

Stuart van Zee
[hidden email]

Sage advise requested... fire retardant underwear in place...

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

fuzzyping
On Wed, Mar 11, 2009 at 10:42:38AM -0400, Stuart VanZee wrote:

> I understand that this might annoy a few of you, If it does
> please accept my apologies.
>
> The place I work is required to have an external security scan
> from time to time and the latest scan says that we have failed
> because the firewall responded to a TCP packet that has the SYN
> and FIN flags set.  I know that OpenBSD isn't vulnerable to the
> exploits that use this:
>
> http://www.kb.cert.org/vuls/id/IAFY-5F8RWP
>
> However, I don't see any reason to respond to a packet with SYN
> and FIN set, AND, a firewall rule that drops said TCP packets
> would fix the fact that we are now "non compliant" as far as
> the security scan goes.  I think a pf rule such as:
>
> block drop in quick proto tcp all flags SF/SF
>
> would do it.
>
> Does anyone see a way that this would come back to bite me on
> the ass later?

S/SAFR

I just had to deal with this on our customer's PCI scan.  Don't argue
with the logic, just do it.  :)

--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net/

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

fuzzyping
On Wed, Mar 11, 2009 at 10:54:18AM -0400, Jason Dixon wrote:

> On Wed, Mar 11, 2009 at 10:42:38AM -0400, Stuart VanZee wrote:
> > I understand that this might annoy a few of you, If it does
> > please accept my apologies.
> >
> > The place I work is required to have an external security scan
> > from time to time and the latest scan says that we have failed
> > because the firewall responded to a TCP packet that has the SYN
> > and FIN flags set.  I know that OpenBSD isn't vulnerable to the
> > exploits that use this:
> >
> > http://www.kb.cert.org/vuls/id/IAFY-5F8RWP
> >
> > However, I don't see any reason to respond to a packet with SYN
> > and FIN set, AND, a firewall rule that drops said TCP packets
> > would fix the fact that we are now "non compliant" as far as
> > the security scan goes.  I think a pf rule such as:
> >
> > block drop in quick proto tcp all flags SF/SF
> >
> > would do it.
> >
> > Does anyone see a way that this would come back to bite me on
> > the ass later?
>
> S/SAFR
>
> I just had to deal with this on our customer's PCI scan.  Don't argue
> with the logic, just do it.  :)

I should clarify, you want to use the above flags on your pass rule.
Don't bother with a block rule matching on flags.

--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net/

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

David Goldsmith
In reply to this post by fuzzyping
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason Dixon wrote:

> On Wed, Mar 11, 2009 at 10:42:38AM -0400, Stuart VanZee wrote:
>> I understand that this might annoy a few of you, If it does
>> please accept my apologies.
>>
>> The place I work is required to have an external security scan
>> from time to time and the latest scan says that we have failed
>> because the firewall responded to a TCP packet that has the SYN
>> and FIN flags set.  I know that OpenBSD isn't vulnerable to the
>> exploits that use this:
>>
>> http://www.kb.cert.org/vuls/id/IAFY-5F8RWP
>>
>> However, I don't see any reason to respond to a packet with SYN
>> and FIN set, AND, a firewall rule that drops said TCP packets
>> would fix the fact that we are now "non compliant" as far as
>> the security scan goes.  I think a pf rule such as:
>>
>> block drop in quick proto tcp all flags SF/SF
>>
>> would do it.
>>
>> Does anyone see a way that this would come back to bite me on
>> the ass later?
>
> S/SAFR
>
> I just had to deal with this on our customer's PCI scan.  Don't argue
> with the logic, just do it.  :)

Let me guess -- TrustKeeper?  We just had to deal with this as well.
Submit an appeal and they should accept it.

The "flags S/SAFR" will work unless you are being a good little pf admin
and also scrubbing all the traffic.  The problem is pf considers SYN-RST
packets to be illegal and drops them (good) but only considers SYN-FIN
packets to be ambiguous and so it "normalizes" them and clears the FIN
bit (in this case for the PCI scan - bad) Then your server behind the
firewall received what it thinks is a nice clean SYN packet and it sends
back SYN-ACK.

- --
David Goldsmith
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJt+8i417vU8/9QfkRAqwwAJ43XDgeEn/1E4npP/YjexqBEMF5DgCfahVN
8LcIW4mqp4WryCmZ5EN1phQ=
=pYPL
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

fuzzyping
On Wed, Mar 11, 2009 at 01:04:34PM -0400, David Goldsmith wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jason Dixon wrote:
> >
> > S/SAFR
> >
> > I just had to deal with this on our customer's PCI scan.  Don't argue
> > with the logic, just do it.  :)
>
> Let me guess -- TrustKeeper?  We just had to deal with this as well.
> Submit an appeal and they should accept it.

Yup.
 
> The "flags S/SAFR" will work unless you are being a good little pf admin
> and also scrubbing all the traffic.  The problem is pf considers SYN-RST
> packets to be illegal and drops them (good) but only considers SYN-FIN
> packets to be ambiguous and so it "normalizes" them and clears the FIN
> bit (in this case for the PCI scan - bad) Then your server behind the
> firewall received what it thinks is a nice clean SYN packet and it sends
> back SYN-ACK.

Yes, we have our own reasons not to scrub there.  Well, *someone* has
their reasons.  I have to deal with those reasons.  ;)

--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net/

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

J.C. Roberts-3
On Wed, 11 Mar 2009 13:07:22 -0400 Jason Dixon <[hidden email]>
wrote:

> On Wed, Mar 11, 2009 at 01:04:34PM -0400, David Goldsmith wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Jason Dixon wrote:
> > >
> > > S/SAFR
> > >
> > > I just had to deal with this on our customer's PCI scan.  Don't
> > > argue with the logic, just do it.  :)
> >
> > Let me guess -- TrustKeeper?  We just had to deal with this as well.
> > Submit an appeal and they should accept it.
>
> Yup.
>  
> > The "flags S/SAFR" will work unless you are being a good little pf
> > admin and also scrubbing all the traffic.  The problem is pf
> > considers SYN-RST packets to be illegal and drops them (good) but
> > only considers SYN-FIN packets to be ambiguous and so it
> > "normalizes" them and clears the FIN bit (in this case for the PCI
> > scan - bad) Then your server behind the firewall received what it
> > thinks is a nice clean SYN packet and it sends back SYN-ACK.
>
> Yes, we have our own reasons not to scrub there.  Well, *someone* has
> their reasons.  I have to deal with those reasons.  ;)
>

Ahhh my least favorite acronym name space conflict:

        PCI == Payment Card Industry

Their "security through ignorance" practices are nearly as illustrious
as their "business through abusive lending" practices. The thing to
remember is the security facade they require is almost entirely for the
sake of public confidence and litigation defense. --hmmm... I should
probably save the rest of this rant for a far more appropriate mailing
list, like /dev/null

Anyhow, back to the original question, "are there any ramifications to
blocking SYN+FIN completely?"

Some (Darren Reed, ipf author) think that pf unconditionally clearing
the FIN flag on scrub is a bug, And no, we don't need a flame war about
whether or not Darren is "right," but none the less, it's still good to
see how the RFC's and ideas about "correct" filtering are both subject
to lots of interpretation.
http://www.derkeiler.com/Mailing-Lists/FreeBSD-Security/2005-07/0011.html

I know SYN+FIN is a valid packet according to RFC 793 and 1644 (T/TCP),
but the more important question is, "what are the valuable *uses* for
SYN+FIN packets?"

Personally, I can't think of any valuable uses. Can you?

Just because SYN+FIN is a technically valid packet according to the
various RFC's doesn't mean we want or need such traffic, and doesn't
mean we consider it valuable and useful. Can you think of any RFC
valid traffic you're dropping when the RFC's tell you that you're
supposed to respond to it?  --Ya, I thought so.

Spammers? --Yep, RFC valid traffic.
DDOS? --Yep, RFC valid traffic.
Brute Force? --Yep, RFC valid traffic.
port scans --A lot of it is RFC valid traffic.

Though 'scrub' will drop the FIN flag off the SYN+FIN packets, the
bofhish instinct says without a proven and valuable *use* for SYN+FIN,
then just block it. If anyone complains about breakage, then just point
your (middle) finger at PCI/TrustKeeper compliance requirements, and
tell the user to take it up with them.

Call me overly pragmatic, but if something in a standard is not
providing valuable use (i.e. reward) and poses *any* type of risk or
cost (including the risk and cost of wasting my time filing and
maintaining some appeal), then the answer is painfully simple.

--
J.C. Roberts

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

Pete Vickers-2
Hi,

What about Postel's 'be liberal in what you accept' ?  What about  
peers/intermediate system that have for example bugs which  
accidentally set FIN flags (ISP's broken traffic shaping/limiting  
device anyone ?).  If pf can safely cleanse such legitimate traffic,  
then why block it ?

Blindly implementing 'orders' from PCI etc is just wrong - to do so is  
only encouraging such bad practices. Instead reject their demands,  
using whatever appeals process is available. Only when enough  
technical staff do so will it be fixed.

All such regulations should be of the style where both of these are  
permitted:
- "I am a stupid admin, so I'll just blindly follow them"
and
- "I am a competent admin, so I'll use my judgement to best protect my  
net"


How about this, for a fun response:  "We don't want to drop such  
'special' traffic, since if we do so, then an attacker can deduce that  
we have implemented PCI guidelines, which in turn implies we have CC  
details online, and thus are a more attractive target' ...




/Pete




On 12 Mar 2009, at 10:22, J.C. Roberts wrote:

> On Wed, 11 Mar 2009 13:07:22 -0400 Jason Dixon <[hidden email]>
> wrote:
>
>> On Wed, Mar 11, 2009 at 01:04:34PM -0400, David Goldsmith wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Jason Dixon wrote:
>>>>
>>>> S/SAFR
>>>>
>>>> I just had to deal with this on our customer's PCI scan.  Don't
>>>> argue with the logic, just do it.  :)
>>>
>>> Let me guess -- TrustKeeper?  We just had to deal with this as well.
>>> Submit an appeal and they should accept it.
>>
>> Yup.
>>
>>> The "flags S/SAFR" will work unless you are being a good little pf
>>> admin and also scrubbing all the traffic.  The problem is pf
>>> considers SYN-RST packets to be illegal and drops them (good) but
>>> only considers SYN-FIN packets to be ambiguous and so it
>>> "normalizes" them and clears the FIN bit (in this case for the PCI
>>> scan - bad) Then your server behind the firewall received what it
>>> thinks is a nice clean SYN packet and it sends back SYN-ACK.
>>
>> Yes, we have our own reasons not to scrub there.  Well, *someone* has
>> their reasons.  I have to deal with those reasons.  ;)
>>
>
> Ahhh my least favorite acronym name space conflict:
>
> PCI == Payment Card Industry
>
> Their "security through ignorance" practices are nearly as illustrious
> as their "business through abusive lending" practices. The thing to
> remember is the security facade they require is almost entirely for  
> the
> sake of public confidence and litigation defense. --hmmm... I should
> probably save the rest of this rant for a far more appropriate mailing
> list, like /dev/null
>
> Anyhow, back to the original question, "are there any ramifications to
> blocking SYN+FIN completely?"
>
> Some (Darren Reed, ipf author) think that pf unconditionally clearing
> the FIN flag on scrub is a bug, And no, we don't need a flame war  
> about
> whether or not Darren is "right," but none the less, it's still good  
> to
> see how the RFC's and ideas about "correct" filtering are both subject
> to lots of interpretation.
> http://www.derkeiler.com/Mailing-Lists/FreeBSD-Security/2005-07/0011.html
>
> I know SYN+FIN is a valid packet according to RFC 793 and 1644 (T/
> TCP),
> but the more important question is, "what are the valuable *uses* for
> SYN+FIN packets?"
>
> Personally, I can't think of any valuable uses. Can you?
>
> Just because SYN+FIN is a technically valid packet according to the
> various RFC's doesn't mean we want or need such traffic, and doesn't
> mean we consider it valuable and useful. Can you think of any RFC
> valid traffic you're dropping when the RFC's tell you that you're
> supposed to respond to it?  --Ya, I thought so.
>
> Spammers? --Yep, RFC valid traffic.
> DDOS? --Yep, RFC valid traffic.
> Brute Force? --Yep, RFC valid traffic.
> port scans --A lot of it is RFC valid traffic.
>
> Though 'scrub' will drop the FIN flag off the SYN+FIN packets, the
> bofhish instinct says without a proven and valuable *use* for SYN+FIN,
> then just block it. If anyone complains about breakage, then just  
> point
> your (middle) finger at PCI/TrustKeeper compliance requirements, and
> tell the user to take it up with them.
>
> Call me overly pragmatic, but if something in a standard is not
> providing valuable use (i.e. reward) and poses *any* type of risk or
> cost (including the risk and cost of wasting my time filing and
> maintaining some appeal), then the answer is painfully simple.
>
> --
> J.C. Roberts

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

Marcus Watts
In reply to this post by J.C. Roberts-3
 "J.C. Roberts" <[hidden email]> writes:
...
> I know SYN+FIN is a valid packet according to RFC 793 and 1644 (T/TCP),
> but the more important question is, "what are the valuable *uses* for
> SYN+FIN packets?"
>
> Personally, I can't think of any valuable uses. Can you?
...

There is a use actually.  If you want to do "minimal packet count
transactions", then you want this.  Here's a better description,
        http://www.sean.de/Solaris/ttcp.html
I don't know of anything that requires this, or even makes it possible
to do this in a rational way.

A "smart" tcp based rpc mechanism, or perhaps sort of "odd"
http application (embedded controllers on slow network segments?) might
be candidates for this kind of logic.

                                        -Marcus Watts

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

J.C. Roberts-3
On Thu, 12 Mar 2009 11:51:40 -0400 Marcus Watts <[hidden email]> wrote:

>  "J.C. Roberts" <[hidden email]> writes:
> ...
> > I know SYN+FIN is a valid packet according to RFC 793 and 1644
> > (T/TCP), but the more important question is, "what are the valuable
> > *uses* for SYN+FIN packets?"
> >
> > Personally, I can't think of any valuable uses. Can you?
> ...
>
> There is a use actually.  If you want to do "minimal packet count
> transactions", then you want this.  Here's a better description,
> http://www.sean.de/Solaris/ttcp.html
> I don't know of anything that requires this, or even makes it possible
> to do this in a rational way.
>
> A "smart" tcp based rpc mechanism, or perhaps sort of "odd"
> http application (embedded controllers on slow network segments?)
> might be candidates for this kind of logic.
>
> -Marcus Watts

Great Find! --I'll give it a full read later.
Thank You.

--
J.C. Roberts

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

J.C. Roberts-3
In reply to this post by Pete Vickers-2
On Thu, 12 Mar 2009 11:25:07 +0100 Pete Vickers <[hidden email]>
wrote:

> Hi,
>
> What about Postel's 'be liberal in what you accept' ?  What about  
> peers/intermediate system that have for example bugs which  
> accidentally set FIN flags (ISP's broken traffic shaping/limiting  
> device anyone ?).  If pf can safely cleanse such legitimate traffic,  
> then why block it ?
>

I have tremendous respect for the work of Jon Postel, but I also accept
the fact he was from a completely different age. If one blindly follows
his "be liberal in what you accept" mantra, you legitimize the ignorant
the malicious, and the lazy.

Times have changed, and the policy of accepting garbage *encourages*
even more garbage and even worse garbage. If you don't believe me, just
toss an open relay or vulnerable system on the net and watch what
happens. The days of being able to pick up the phone and politely call
the admin at the university where the dodgy traffic is originating are
long gone.

The ability of pf to cleanse the packets is kind of irrelevant to my
main question of whether or not such traffic has any useful value and
function?

If the only value I get by accepting and scrubbing the traffic is
encouraging the use of "broken" shaping/limiting devices, then in the
long run I'd be better off blocking them and suggesting others to do
the same. Eventually, the owners of such devices will get a clue or go
out of business. Or conversely, I'd isolate myself so much that I'd
either get a clue or go out of business.

The word "legitimate" is a tough one; you could mean compliant with the
RFC's or you could mean `well intended` such as someone trying to make
an honest purchase on your web site (but being fragged by some traffic
shaper device). There is obvious value in having another sale, so at
first glance scrubbing seems more profitable than blocking, but if the
risk is being dropped by your payment processor, the occasional added
sales to people at bad ISP's are not worth the risk of having no sales
at all.

The risk to reward analysis on the business level is one thing, but
the same methods should be applied on the technical level, all the way
down to the supposed standards. If the SYN+FIN packets do not provide
useful functionality but do pose unnecessary risk, then the RFC's
allowing this combination are wrong. --Of course, this gets us back to
the business question of, "What is the cost/benefit and risk/reward of
fixing this problem?" so we're now in an endless loop of sorts.

> Blindly implementing 'orders' from PCI etc is just wrong - to do so
> is only encouraging such bad practices. Instead reject their
> demands, using whatever appeals process is available. Only when
> enough technical staff do so will it be fixed.
>
> All such regulations should be of the style where both of these are  
> permitted:
> - "I am a stupid admin, so I'll just blindly follow them"
> and
> - "I am a competent admin, so I'll use my judgement to best protect
> my net"
>

Just as becoming competent cost you time, money and effort, to the
Payment Card Industry, being competent will cost you even more time,
effort and money. Why should you bear the cost to appeal their nonsense
when the idiots are not required to pay this expense?

The two things to remember about the PCI are, (1) they do not play nice
and (2) they believe in security by fiat (i.e. "it's secure because we
say so"). If you fail to keep them happy by jumping through their hoops,
they terminate your payment processing and flush your business down the
tubes. If you make the mistake of telling them that the Emperor is
naked, the same thing happens to your account. I agree with you that
blindly implementing their often whimsical demands is "just wrong" but
disagreeing with them is not worth the risks or costs, even when you
are completely right.

>
> How about this, for a fun response:  "We don't want to drop such  
> 'special' traffic, since if we do so, then an attacker can deduce
> that we have implemented PCI guidelines, which in turn implies we
> have CC details online, and thus are a more attractive target' ...

That is a fantastic response and I might just use a variation of it. But
it's actually a violation of PCI rules to store plain account details on
an Internet accessible machine (i.e. "online"), and in some places it's
also against the law. Unfortunately, there are plenty of really stupid
people who follow neither the rules, nor the laws, so full database
dumps for sale are a common sight in cracker/carder circles. From the
end user stand point, it's not obvious how sites like amazon comply
with the rules while still retaining credit card details, but often
it's done through custom message passing to isolated back-ends (i.e. no
direct end user access).

The Payment Card Industry is a real pain, and they have their head up
their ass most of the time when it comes to security, but they *are*
absolute masters of risk to reward modeling and cost to benefit
analysis. If you don't play by their rules, then you can neither have
nor accept credit cards. If they find out you're not playing by their
rules, then they have no hesitation about eliminating the risk you
pose. They can, and will, pull the plug on your business for the
smallest grievance, so Jason's advice of "Don't argue with the logic,
just do it," is well founded, and you will generally never see people
openly bitching and complaining as I have done. Let's just say I've
got a unique position where the PCI considers the risks and costs of me
occasionally bitching to be insignificant compared to the rewards and
benefits I provide to them. Then again, I might be pushing my luck.

--
J.C. Roberts

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

Stuart VanZee
In reply to this post by Stuart VanZee
Thank you all for the interesting discussion on this issue.
I can't prove it but I think I have gained at least one IQ
point just from the privilege of reading said responses.

In my case, I think the answer boils down to the fact that
it doesn't seem possible to implement a rule that blocks
these packets while still using packet normalization (scrub)
since scrub is the first thing that sees a packet and drops
the FIN on a packet that has SYN+FIN set (at least that is
how I understand it).

At this point, I don't think I want to stop using scrub just
to get a "fail" that doesn't apply to OpenBSD off of my
report.  Not when I can just as easily put in an appeal
along with proof that this particular "vulnerability"
doesn't apply to OpenBSD (see initial message for link if
you are interested).

Again, thanks to those who responded. I have learned a lot
from your efforts.  Also, a very special thank you to all
the developers of OpenBSD/OpenSSH for all the hard work that
you do.  I have said it before, and say it again; "OpenBSD
makes me look smart" (which is not always an easy task).

Stuart van Zee
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

Claudio Jeker
In reply to this post by J.C. Roberts-3
On Thu, Mar 12, 2009 at 09:46:07AM -0700, J.C. Roberts wrote:

> On Thu, 12 Mar 2009 11:51:40 -0400 Marcus Watts <[hidden email]> wrote:
>
> >  "J.C. Roberts" <[hidden email]> writes:
> > ...
> > > I know SYN+FIN is a valid packet according to RFC 793 and 1644
> > > (T/TCP), but the more important question is, "what are the valuable
> > > *uses* for SYN+FIN packets?"
> > >
> > > Personally, I can't think of any valuable uses. Can you?
> > ...
> >
> > There is a use actually.  If you want to do "minimal packet count
> > transactions", then you want this.  Here's a better description,
> > http://www.sean.de/Solaris/ttcp.html
> > I don't know of anything that requires this, or even makes it possible
> > to do this in a rational way.
> >
> > A "smart" tcp based rpc mechanism, or perhaps sort of "odd"
> > http application (embedded controllers on slow network segments?)
> > might be candidates for this kind of logic.
> >
> > -Marcus Watts
>
> Great Find! --I'll give it a full read later.
> Thank You.
>

We don't support TTCP and we will never support it. The thing is just
scary and easily attackable. On the other hand I wonder what stupid thing
the security scanners will check next.

--
:wq Claudio

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

ropers
In reply to this post by Stuart VanZee
2009/3/12 Stuart VanZee <[hidden email]>:
>
> it doesn't seem possible to implement a rule that blocks
> these packets while still using packet normalization (scrub)
> since scrub is the first thing that sees a packet and drops
> the FIN on a packet that has SYN+FIN set (at least that is
> how I understand it).

Suppose you use an OpenBSD bridge (=extra hardware) in front of your
firewall, like so:

Internet <==> OpenBSD bridge <==> OpenBSD firewall <==> intranet

You could have scrubbing turned off at the bride and block the SYN+FIN
packets at the bridge. Then, at the firewall, you have scrubbing
turned on and get those cutey packets all squeaky clean.

Now instead of calculating the risk of being dropped by the Payment
Card industry like a hot potato against the risk of not scrubbing or
otherwise making technical compromises to placate them, you get to
make an entirely different calculation:

Weighing the cost of (and possible latency introduced by) one extra
box against the cost of the aforementioned shenanigans.

OTOH, if this affects you, then maybe you could also weigh the cost of
hiring a major OpenBSD developer to implement a new feature that could
make it possible to configure your pf.conf to exempt SYN+FIN packets
from scrubbing and/or deal with them separately against the cost of
the said above shenanigans.

Well, those are just my 2 eurocents.

regards,
--ropers

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

Rod Whitworth-3
On Fri, 13 Mar 2009 03:17:30 +0100, ropers wrote:

>You could have scrubbing turned off at the bride

So what's she going to do? Just the dishes?
Why did he marry her anyway?

<Grinning, running and ducking>


*** NOTE *** Please DO NOT CC me. I <am> subscribed to the list.
Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou.

Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

SJP Lists
2009/3/13 Rod Whitworth <[hidden email]>:

>>You could have scrubbing turned off at the bride
>
> So what's she going to do? Just the dishes?
> Why did he marry her anyway?
>
> <Grinning, running and ducking>

Careful Rod, from memory Diana is a crack shot and packs!

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

Rod Whitworth-3
On Fri, 13 Mar 2009 17:30:38 +1100, SJP Lists wrote:

>2009/3/13 Rod Whitworth <[hidden email]>:
>
>>>You could have scrubbing turned off at the bride
>>
>> So what's she going to do? Just the dishes?
>> Why did he marry her anyway?
>>
>> <Grinning, running and ducking>
>
>Careful Rod, from memory Diana is a crack shot and packs!
>
Hey, I know Diana from many years of hanging out here (OBSD v 2.5
onwards) and I'm very sure he didn't marry her.

My bride, on the other hand, doesn't shop (except for jewellery,
clothes, travel etc) or cook or fix the roof or toilets or her computer
or .... I don't think she scrubs either except her back in the shower.

Rod/
---
*** NOTE *** Please DO NOT CC me. I <am> subscribed to the list.
Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou.

Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

Henning Brauer
In reply to this post by Stuart VanZee
not sure wether it wouldn't be smarter to just have pf scrub drop
these as well.

--- pf_norm.c Sat Mar 21 12:17:44 2009
+++ pf_norm.c.orig Sat Mar 21 12:16:56 2009
@@ -782,11 +782,8 @@
  flags = th->th_flags;
  if (flags & TH_SYN) {
  /* Illegal packet */
+ if (flags & (TH_RST|TH_FIN))
- if (flags & TH_RST)
  goto tcp_drop;
-
- if (flags & TH_FIN)
- flags &= ~TH_FIN;
  } else {
  /* Illegal packet */
  if (!(flags & (TH_ACK|TH_RST)))


--
Henning Brauer, [hidden email], [hidden email]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

Reply | Threaded
Open this post in threaded view
|

Re: Ramifications of blocking SYN+FIN TCP packets

Johan Linner
Henning Brauer skrev:

> not sure wether it wouldn't be smarter to just have pf scrub drop
> these as well.
>
> --- pf_norm.c Sat Mar 21 12:17:44 2009
> +++ pf_norm.c.orig Sat Mar 21 12:16:56 2009
> @@ -782,11 +782,8 @@
>   flags = th->th_flags;
>   if (flags & TH_SYN) {
>   /* Illegal packet */
> + if (flags & (TH_RST|TH_FIN))
> - if (flags & TH_RST)
>   goto tcp_drop;
> -
> - if (flags & TH_FIN)
> - flags &= ~TH_FIN;
>   } else {
>   /* Illegal packet */
>   if (!(flags & (TH_ACK|TH_RST)))
>
>

IMHO: Yes it is smarter.
Will save time spent on the "External Security Consultants".

/Johan