Hacker News Reader

Comment by nxc18 | Hacker News Reader

I assume you are writing in an attempt to persuade.

Your message is being lost/ignored as a result of your delivery.

We want to understand your message, but you aren't giving enough background. I don't trust your message because there is no supporting background. If you're going to tell me to not do something, either:

A) provide a compelling alternative (not doing $it is not a compelling alternative to $it in nearly all cases) B) explain in detail why you shouldn't do $it. Provide more details if asked.

I want to believe what you are saying and be convinced by it, please help me. (Note: I'm not trying to be a dick, I've just known a lot of people who are perpetually ignored because of this communication style and take forever to learn that lesson because no one bothers to say anything)

View on HN

I think tptacek's implicit point is this: all the problems you're trying to address with the tools listed are the problems you shouldn't be having in the first place, so, to quote, "focus on removing attack surface, rather than continuously monitoring it".

In this instance, I'm just interested in getting the right answer written down and moving on.

tptacek is using an appeal to authority given his standing as a security expert on this forum. That's the only reason his comment containing no justification is being taken seriously.

It is also being taken seriously because 1) he is correct, and 2) those of us who do this for a living are literally sick to fucking death of having to explain to management, developers, and sysadmins that there is no silver bullet that you can buy that will fix the mistakes you should have cleaned up five years ago. You still have to do the work. If you need to hear this ("reduce attack surface rather than spend time/money on monitoring attack surface") more than once you are beyond help and it is time for us to move on to people for whom there is at least a possibility that they won't be p0wned in the next 12 months.

This isn't a religious/esoteric forum here. Technical statements should be backed by proper reasons regardless of who is stating something. If you are sick to tell technical reasons then why bothering posting on HN?

Because there are people who are willing to believe that something is good or bad without needing to understand the rationale behind it? Most people making the case for WAFs aren't posting detailed rationales of why WAFs are a good way to spend your resources either.

Example, same author: Cryptographic Right Answers.

(Disclaimer: I work with tptacek.)

You're relatively new, but after a while, you get to learn the credibility of some HN'ers by their usernames. Often, you can click their username to find previous comments from the same user where they expounded on the technical details, particularly for subjects that come up here a lot. I don't blame them for not wanting to go into detail each and every time, especially when their reputation gives their comments credibility in place of details.

I'd also like to add that you may want to work on the tone of your comments if you'd like to get enough karma to really participate in the community. Your comment history seems a bit confrontational and argumentative. There are better, friendlier ways to make the same points. I'll defer to the guidelines[0] to explain how you may improve your communication skills.

[0]https://news.ycombinator.com/newsguidelines.html

I'm quite aware of some credibility of some HN users. That doesn't give them the right to give arrogant or non-argument-backed answers. Besides that: There is no reason to base your argument on the age of my account.

You may have missed my edit to my previous comment regarding the tone of your comments. I suggest you go back and check it out. (Yet another sign of the age of your account, which is most definitely relevant.)

Nope. I upvoted it before even seeing who wrote it. The advice is absolutely spot on. Harden your servers, don't just install a load of tools that look for intrusions after-the-fact and call it a day. I'm not sure why some people aren't getting it.

It's not an appeal to authority when you're really an expert.

Or you go to the doctor and expect him to justify your treatment down to the minor detail? You sound like you talk to your doctor about $overpriced_drug.

And still there are doctors who are prescribing homeopathy and other effect-less "medicine".

It's just reasonable to ask for rational arguments. That's the whole point of the rants here.

Its not that he owes a justification or an explanation or that readers can legitimately feel entitled to one. Paid support is another matter.

If you think I'm wrong, rebut.

The fan boys came out to rep you, but they're wrong.

First of all - it takes less than an hour to set up a WAF, and it doesn't worsen your security position. Not only is it free, it's fast and easy and will demonstrably be better than no security at all.

Saying "don't put up a firewall because it isn't perfect" is stupid. You don't have to be a security guru to get that, which obviously several people have, or they wouldn't all be giving you crap about it.

Securing your application long term is a complex, expensive, time consuming process. Suggesting that spending a couple months to be "serious about security" is somehow better than first taking one hour to do the most bare minimum effort is ridiculous.

If I have a computer on the internet, I put a firewall up. Is it defense in depth? No. But that doesn't mean it won't stop the most basic, most common attacks, and it takes no time and no skill to apply it.

I don't know what weird thing you have against WAFs other than apparently they aren't cool or sophisticated enough, but 1) they remove attack surface, 2) they filter the most common drive-bys, 3) they can be both passive and active, 4) they're free, 5) they're easy, 6) they're quick to deploy.

How is it 2018 and I have to explain to you of all people that the web equivalent of iptables might be a good idea if you have zero security?

> WAFs (...) 1) they remove attack surface

They do what you configure them to do. Without knowledge of what's allowed and what's not, they're going to have either false positives or false negatives. And if you have that knowledge, you can fix those issues in the web app rather than hide them with the WAF. A lot of preconfigured WAFs will remove specific matches you don't care about anyway rather than attack surface.

> 2) they filter the most common drive-bys

Common as in known proxy or webapp exploits? If that's the case, why not patch them? (There's a reason to use WAF if you can't patch but that costs time/money to get right and test)

> 3) they can be both passive and active

I'm not even sure what passive WAF means... just logging?

> 4) they're free

Only for very small traffic.

> 5) they're easy 6) they're quick to deploy.

See point 1. If you can't put the right restrictions on the app, why do you think you can put them in WAF? If they're not in the app in the first place, why do you think this way is quicker? It's not a magic box will know your requirements. You need a proper setup or the only thing you achieve is removing obviously silly cgi-bin requests from your log files.

I'm not even against WAFs. Just think the gain from them is been none and minimal if you reduce it to "turn it on, it's cheap and easy". It's really similar to iptables - you can turn it on, but why are you doing it? (On a server anyway) If you have a specific reason/route to protect - great. If not, make sure you bind non-public services to local interfaces and you don't need iptables.

Nobody said "don't put up a firewall". By all means, set up the rules on your VPC so that only 80/443 hits your ALB and nothing else is routable. But don't futz with iptables on your hosts or god help you setting up a separate AMI for some 3rd party firewall.

I'm going to assume that whenever you say firewall you're talking about a WAF, since you mention "web equivalent of iptables". Disclaimer: I also work with 'tptacek, but opinions my own.

> it takes less than an hour to set up a WAF

Not if you want it to do anything useful. Default WAF rules are mostly useless and come with bypasses -- kinda like XSS filters in browsers, and browsers are in a way better position to judge if XSS is going on or not. You can sort-of get useful WAF rules if you encode most of the invariants of your system in your WAF -- but your app is in a strictly better position to do that sort of validation for you instead.

> and it doesn't worsen your security position.

Yes, except for the shiny new TLS MITM, the pathological parser performance cases, the new attack surface in that WAF itself (hands up if you've seen XSS in a WAF interface) and the continued operational cost of having new infrastructure that sees plaintext... Sure! And then I'm being generous in assuming we're not talking about a virtual appliance or as I like to call them "mystery *nix box you can't patch or audit".

> Securing your application long term is a complex, expensive, time consuming process. Suggesting that spending a couple months to be "serious about security" is somehow better than first taking one hour to do the most bare minimum effort is ridiculous.

Also, unlike WAFs, it's effective.

To be clear: I am not conceding your point about cost. It does not take "months" to identify systemic appsec issues. It also does not take an hour to configure a WAF and have it do something vaguely useful for your application.

Anecdotal evidence: Latacora literally does this systemic-discovery-and-remediation-plan thing for a living as a part of our engagement. "Months" is not our timeline for any kind of systemic appsec issue like SQLi or XSS.

> ... the web equivalent of iptables might be a good idea

Are you really sure you want to stand by that equivalence? How often does one come across iptables bypasses?

> Are you really sure you want to stand by that equivalence?

Yes. Both require some knowledge of how to use the tool and rules, but both are not difficult for even a novice to pick up quickly. Not to mention both can be done by either a dev or a sysadmin in the cloud right now, neither of them require in-depth knowledge of the code, and the scope of the change is simple enough that it can be tested and applied quickly.

> "Months" is not our timeline for any kind of systemic appsec issue like SQLi or XSS.

The discussion was about a dev or sysadmin fixing all this themselves ("taking appsec seriously" etc). Not just running Burp on their website. After they identify the vulns they have to have meetings to discuss fixes, figure out how to patch them and test that it works, go through QA and then roll into production. A fix may involve several systems and most people's deploy process is painful. I've never seen that take less than three weeks, and six is more reasonable. Can you do it in less time? Of course. Does that actually happen? Not without paying a consultancy $300k to hold your hand for two weeks.

It is completely plausible to get a WAF up and running and have it provide real protection immediately. CloudFlare's is probably the best example of this, considering the extensive add-ons they provide based on the intrusions they've seen. I don't like CloudFlare's TLS MITM either, but tens of thousands of their customers don't seem to mind.

Just like iptables, ModSecurity doesn't do anything at first. You have to actually make some decisions. Does that mean you shouldn't spend the extra 15 minutes to read a manual and enable some protection?

Earlier it was suggested that protecting against Drupal or Wordpress vulns is unnecessary. I disagree! There's no reason not to protect against drive-by vulns. Filters for XSS/SQLi, unnecessary HTTP features, malicious bots and scanners, directory traversal, RCE, etc are well worth preventing whenever possible.

As for false positives, they're not as bad as they used to be. There are thorough guides designed to help you identify and remove them from your site. https://www.netnea.com/cms/apache-tutorial-7_including-modse... https://www.netnea.com/cms/apache-tutorial-8_handling-false-... For a sysadmin this may take more time, just like it would if you were using iptables to secure a black box. A dev can change the filters immediately to suit their app.

But even if you don't do any active filtering, the passive filters can at least alert you that something is happening so you can go fix it. This is so standard that Kubernetes includes it as an option in their Nginx Ingress Controller. This guide can get you up and running on your existing K8s install in 10 minutes: https://karlstoney.com/2018/02/23/nginx-ingress-modsecurity-...

Might I suggest a little research, e.g., reading http://cs.unc.edu/~fabian/course_papers/PtacekNewsham98.pdf

This points out how WAF/NIDS is just a speed bump for a serious attacker.

You may conclude that they don't really 1) remove attack surface 2) Unclear if they really do this, and if they do what value there is 3) See the papers for detail on the differences 4) Zero cost to purchase, but what cost to maintain, run, keep up? 5) see #4 6) even if you have a large web farm?

This paper was writen 20 years ago.

I already addressed this. The WAF is a temporary solution. It is not targeted at "serious attackers", it is targeted at drive-by scans and generic exploits.

I don't. I was explaining why an comment lacking justifications wasn't being buried

I posted this elsewhere in the thread. To be convinced, read this frightening paper: http://cs.unc.edu/~fabian/course_papers/PtacekNewsham98.pdf

> We want

Please speak for yourself alone. tptacek's comments in the thread are quite clear.

I'm not trying to be a dick

You are succeeding without trying. You're essentially complaining some free advice does not fit your exact expectations and specifications. Which is fine, lots of free advice doesn't. Trying to pass this complaint off as some kind of favour to the person giving you free advice, though, is... less than great.

No, tptacek just doesn't give proper answers here because he thinks he can afford it with his status here. He could have just left links to further links/literature.

There's nothing 'improper' about the answers, you just don't like how they're presented. As I said, that's a totally fair objection. It's just that nobody owes you free advice in the precise format you find acceptable. That's usually a feature of paid advice.

Reply on news.ycombinator.com