On Thu, 12 Mar 2009 11:25:07 +0100 Pete Vickers <p...@systemnet.no> 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
