Post by Pete VickersHi,
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.
Post by Pete VickersBlindly 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
- "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.
Post by Pete VickersHow 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