How my Apache server became a malicious free internet proxy(blog.atrament.net)
blog.atrament.net
How my Apache server became a malicious free internet proxy
http://blog.atrament.net/how-my-apache-server-became-a-malicious-free-internet-proxy/
7 comments
I've had similar issues with an open source project in which a simple proxy was established with FiddlerCore to tap traffic to a web browser, pretty tame stuff and nothing malicious.
Problem is that by default it was configured to listen on 0.0.0.0:80, making it an open HTTP proxy that everybody on the same LAN could connect to. The only real threat so far is that somebody could send in a large volume of traffic to crash the proxy, but wait and behold....
...some users were running it from hosts that are either a) directly connected to the public IP space without a firewall and b) behind NAT, but with lazy DMZ/port forwarding configuration that exposes their port 80 to the internet anyway. For about a year people have been obliviously hosting open HTTP proxies from home.
Eventually somebody found out and it took another couple of months of back and forth issue reporting and PR tugging battles to get it properly patched. Opsec is hard.
Problem is that by default it was configured to listen on 0.0.0.0:80, making it an open HTTP proxy that everybody on the same LAN could connect to. The only real threat so far is that somebody could send in a large volume of traffic to crash the proxy, but wait and behold....
...some users were running it from hosts that are either a) directly connected to the public IP space without a firewall and b) behind NAT, but with lazy DMZ/port forwarding configuration that exposes their port 80 to the internet anyway. For about a year people have been obliviously hosting open HTTP proxies from home.
Eventually somebody found out and it took another couple of months of back and forth issue reporting and PR tugging battles to get it properly patched. Opsec is hard.
Bonus TL;DR: By setting "ProxyRequests On", which is only required to use Apache as a forward web proxy. (There's even a big red warning in the documentation about this!)
(:
This is a perfect example of why most people should not run their own hardware. Don't get me wrong its really fun to build and configure your own server and I openly encourage people to learn but I also remind them that its extremely difficult (for a novice) to do securely.
Additionally connecting a misconfigured server to the internet doesn't just hurt the server owner but the entire network is affected, as you are providing another piece of hardware that malicious actors can use to execute their attacks.
Additionally connecting a misconfigured server to the internet doesn't just hurt the server owner but the entire network is affected, as you are providing another piece of hardware that malicious actors can use to execute their attacks.
I was going to say the opposite. It's awesome that we can spin up boxes and host our own servers, and on top of that, learn from our mistakes. I doubt there's a person here who's never been host to malware, spam or some other malady as a result of some of the experimentation they've done as they learned more about computer systems.
This is exactly my point. One of the major reasons that malware and malicious actors have been able to do as much as they have is because of the large number of misconfigured devices on the internet.
The internet has evolved beyond a network cobbled together by a bunch of academics and engineers -- its a critical piece of infrastructure.
The internet has evolved beyond a network cobbled together by a bunch of academics and engineers -- its a critical piece of infrastructure.
Seems like the problem is vulnerable by default options in software, not experimenting with it. More people have hosted malware by just running Windows than anyone has by experimenting with Apache, then fixing it and learning something useful that can now help other newbies.
I ran a machine in a colo for almost four years, public facing web server for a dedicated webapp. I managed to escape any attacks or infections, but I'm positive it was 80% of what I did and 20% that it's a low volume app that never got attention by malicious actors. And I've been in the industry for a long time, not a noob.
Everything is attacked. It's all automated, not personal.
Yup install something like fail2ban & setup email alerts. You'll get a new notice every 5 minutes or so for the first month from all the china based bots trying to login via common ssh credentials.
Well, true, we did get spam attacks on the app, so I wound up banning huge swaths of the world. I moved SSH to a very high port, only ran apache, sshd, and an SMTP agent (the machine never received email, inbound was handled by GMail). Still, had someone wanted to exploit the PHP app, I'd be surprised if they couldn't find a weakness. It was custom written, but nearly a decade age.
Elite attackers can compromise almost any target, but even they won't bother finding one-off vulnerabilities when the goal is botnet host acquisition. For that only widely deployed vulnerabilities are worth exploiting.
In practice that means you can get away with something as crazy as opening up a password-free root shell on some random high port, but you can't get away with weak SSH logins or unpatched Wordpress sites.
In practice that means you can get away with something as crazy as opening up a password-free root shell on some random high port, but you can't get away with weak SSH logins or unpatched Wordpress sites.
> should not run their own hardware.
Did you mean "should not run their own dedicated server"? The article doesn't mention anything related to hardware. It could have happened with a rented dedicated server, and even within a virtual machine.
Did you mean "should not run their own dedicated server"? The article doesn't mention anything related to hardware. It could have happened with a rented dedicated server, and even within a virtual machine.
Better question would be what, assumingly, LAMP stack configuration were they using.
Honest question from a developer perspective: Why there isn't any "best practice/hardened by default" wizard-style configuration, something people can do right after they install their OS? E.g.:
Welcome to Best Practice Linux. Click Next to continue. Which http server you want (httpd/lightttpd/...). Click Next to continue. (you get the idea).
Something like apt-get but with best-practice defaults.
Welcome to Best Practice Linux. Click Next to continue. Which http server you want (httpd/lightttpd/...). Click Next to continue. (you get the idea).
Something like apt-get but with best-practice defaults.
Apache doesn't default to acting as an open proxy. It already has safe defaults! He specifically configured it this way.
This would be a really really good idea.
However, in my experience (as an Apache noob), the Apache community consists of experts who are so far ahead of the noobs that they can't see the issue from the perspective of noobs.
When I configured my first web box, I couldn't believe that in 2 days it was hacked open and taken over (by some hackers in China apparently -- those guys are scary good). My host (DO) couldn't provide any advice / support on what exactly had happened. I reset everything and set it up again, and again, 2 days later, the box was completely taken over (again by peeps in cn).
Finally, I did a couple of tiny tweaks in how I logged in (I disabled root login, and configured SSH keys to log-in, and changed the log-in port), and I was never hacked again. If these 3 little tweaks could be made defaults, there'd be a whole lot less hacking going on.
However, in my experience (as an Apache noob), the Apache community consists of experts who are so far ahead of the noobs that they can't see the issue from the perspective of noobs.
When I configured my first web box, I couldn't believe that in 2 days it was hacked open and taken over (by some hackers in China apparently -- those guys are scary good). My host (DO) couldn't provide any advice / support on what exactly had happened. I reset everything and set it up again, and again, 2 days later, the box was completely taken over (again by peeps in cn).
Finally, I did a couple of tiny tweaks in how I logged in (I disabled root login, and configured SSH keys to log-in, and changed the log-in port), and I was never hacked again. If these 3 little tweaks could be made defaults, there'd be a whole lot less hacking going on.
Something link this might be a start:
https://github.com/hardening-io/ansible-os-hardening
https://github.com/hardening-io/ansible-os-hardening
This discussion about otto (from the makers of Vagrant) has some ideas about why people think a one-size-fits-all "default" is a bad/good idea.
https://news.ycombinator.com/item?id=10291778
https://news.ycombinator.com/item?id=10291778
Something that proper config management already solves, the default apache module for puppet places sane defaults on everything, from there it's your responsibility to know what you are doing.
As someone who's used open proxies to get around geo-IP-tracking/restrictions/censoring, I get the point about excessive bandwidth usage (you can apply per-IP ratelimiting for that), but it does make me a bit sad that open proxies are now considered "malicious"...
I used the word malicious because I saw people and have a list of credentials now from compromised accounts and spambots. Mainly from Russia. Also, all the sport betting websites that were being hit. I think there must have been something shady there. I was also used for ad-click fraud. :|
So you got to the end solution of... uninstalling fail2ban to fix it? You didn't bother to check WHY it was maxing out the cpu?
Glad you got the issue resolved though and didn't fork over the $10 because you would've just run into the same issue in the future if you didn't get to the root cause of it (misconfigured Apache).
Glad you got the issue resolved though and didn't fork over the $10 because you would've just run into the same issue in the future if you didn't get to the root cause of it (misconfigured Apache).
At this point fail2ban wasn't really needed anymore since the author installed it to stop the people using the server as an open proxy. After they solved the proxy issue fail2ban was just causing problems and wasn't needed.
I understand it wasn't needed after the fact. But the entire point of the original post/resolution was to understand what was causing the problem (page time outs) - yet when faced with a second problem, he chose the 'easy' route of just uninstalling it (unalike his resilience to pay for his IP change or wiping the server).
Any idea what the actual vulnerability was?
It's really, really easy to misconfigure mod_proxy and set yourself up as an open proxy. The ProxyRequests directive sounds like it should be needed for any sort of proxying, but is only really needed if you're allowing your apache instance to act as a forward proxy, not as a reverse proxy. For reverse proxying, which is what you want most of the time, you really want ProxyPass and ProxyPassReverse .
The phrase "[my blog] was being hosted on another port because apache was taking up the internet http port 80" sounds like the reason they were trying to set up a reverse-proxy.
Apache docs have an obvious warning about ProxyRequests and security: https://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxyre... .
This config snippet looks like it was copied/modified without understanding:
Above that, there is a comment "turning ProxyRequests on and allowing proxying from all may allow spammers to use your proxy to send email", so I guess it was somewhat safe originally, until ProxyRequests was changed to On without reading and understanding the comment.
Apache docs have an obvious warning about ProxyRequests and security: https://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxyre... .
This config snippet looks like it was copied/modified without understanding:
<Proxy *>
AddDefaultCharset off
Order deny,allow
Allow from .example.com
</Proxy>
Above that, there is a comment "turning ProxyRequests on and allowing proxying from all may allow spammers to use your proxy to send email", so I guess it was somewhat safe originally, until ProxyRequests was changed to On without reading and understanding the comment.
I made the mistake of thinking it was harmless to enable. Also, with the solutions I've found online for enabling 'ghost blog with apache virtualhosts'. I guess someone trolled me.
It's a good idea to always look up the docs on directives in apache configs you are copy-pasting from the internet, to make sure you know what they are doing.
For that matter, this probably applies to just about anything you copy paste on the internet. Understand what you're pasting, look up the docs if you don't or aren't sure or are using something you haven't seen before.
But apache httpd configs can be especially tricky. The accidental open proxy is definitely something that gets lots of people, you are not alone. The apache httpd directive names have a lot of 'legacy' in them, and probably should have been named more clearly in retrospect (i assume the apache httpd forward proxy feature came first, and reverse proxy was only added later; but in 2015 reverse proxy is a lot ore common a thing to want).
(But the solution to an accidental open proxy, if you didn't mean to be forward proxying at all.... is turning off the forward proxy in apache httpd, not other weird workarounds).
For that matter, this probably applies to just about anything you copy paste on the internet. Understand what you're pasting, look up the docs if you don't or aren't sure or are using something you haven't seen before.
But apache httpd configs can be especially tricky. The accidental open proxy is definitely something that gets lots of people, you are not alone. The apache httpd directive names have a lot of 'legacy' in them, and probably should have been named more clearly in retrospect (i assume the apache httpd forward proxy feature came first, and reverse proxy was only added later; but in 2015 reverse proxy is a lot ore common a thing to want).
(But the solution to an accidental open proxy, if you didn't mean to be forward proxying at all.... is turning off the forward proxy in apache httpd, not other weird workarounds).
> If you read the docs on Order
That's yet another example of apache config violating POLS (Principle Of Least Astonishment). You have a set of Allow rules and a set of Deny rules. If a request does not match a rule in either set, then what happens to the request depends on the ordering of these non-matching rulesets (!!) instead of a reasonable default with an explicitly configured alternate option.
It's also a bad name - there's no hint that this affects the default action; you just have to know ahead of time.
That's yet another example of apache config violating POLS (Principle Of Least Astonishment). You have a set of Allow rules and a set of Deny rules. If a request does not match a rule in either set, then what happens to the request depends on the ordering of these non-matching rulesets (!!) instead of a reasonable default with an explicitly configured alternate option.
It's also a bad name - there's no hint that this affects the default action; you just have to know ahead of time.
From part two[p2]: "After stumbling back into my custom Apache configurations directory, I found a file I made to redirect all the proxy settings to /etc/httpd/conf.d/proxy.conf. I can't believe I missed this file."
(...)
"I changed ProxyRequests On to ProxyRequests Off and restarted Apache sudo service httpd restart. My blog & my websites loaded. I finally came to the solution after a few hours of looking at configs."
(...)
"I ran top and noticed fail2ban was consuming 98-99% of my allocated CPU. [Note: As mentioned by the original author in part1, fail2ban was set up to track Apache httpd access logs, and that's (presumably) why it was consuming so much CPU. -e12e] Holy shit. This culprit was running in the background and I did not even know that it was such an intensive resource hog on my machine. I turned fail2ban's service off sudo service fail2ban stop and I removed it from2 auto-starting on system boots with chkconfig fail2ban off."
Apache is a bit of a complicated beast, and it probably doesn't help that way back when, one didn't set up proxies to web application servers, one ran code in the server (mod_php, mod_perl and even mod_python). Java/tomcat got their own proxy module (mod_jk), and after a while, as more (hw) resources became available, it started to make more sense for everyone to follow the good practice of breaking up services by user (either actual (human) user, or at least service user, like "php" or "cgi-bin" etc). And it became more common to use mod_proxy to forward requests to backends (like php-fpm).
For those new to Apache, it's still easy to miss that Apache can also work as a full http proxy -- and it's easier than it probably should be to set up an open http proxy without intending to. But you generally do have to type in a setting of "ProxyRequests On" -- which kind of does give a hint of what's going on.
[p2] http://blog.atrament.net/how-my-apache-server-became-a-malic...
(...)
"I changed ProxyRequests On to ProxyRequests Off and restarted Apache sudo service httpd restart. My blog & my websites loaded. I finally came to the solution after a few hours of looking at configs."
(...)
"I ran top and noticed fail2ban was consuming 98-99% of my allocated CPU. [Note: As mentioned by the original author in part1, fail2ban was set up to track Apache httpd access logs, and that's (presumably) why it was consuming so much CPU. -e12e] Holy shit. This culprit was running in the background and I did not even know that it was such an intensive resource hog on my machine. I turned fail2ban's service off sudo service fail2ban stop and I removed it from2 auto-starting on system boots with chkconfig fail2ban off."
Apache is a bit of a complicated beast, and it probably doesn't help that way back when, one didn't set up proxies to web application servers, one ran code in the server (mod_php, mod_perl and even mod_python). Java/tomcat got their own proxy module (mod_jk), and after a while, as more (hw) resources became available, it started to make more sense for everyone to follow the good practice of breaking up services by user (either actual (human) user, or at least service user, like "php" or "cgi-bin" etc). And it became more common to use mod_proxy to forward requests to backends (like php-fpm).
For those new to Apache, it's still easy to miss that Apache can also work as a full http proxy -- and it's easier than it probably should be to set up an open http proxy without intending to. But you generally do have to type in a setting of "ProxyRequests On" -- which kind of does give a hint of what's going on.
[p2] http://blog.atrament.net/how-my-apache-server-became-a-malic...
my guess would be mod_proxy that didn't explicitly only define a single ip port to proxy to (ala upstream) therefore allowing a http connect?
I know that they can spoof the referrer. I have mine set to allow '.atrament.net'. I was thinking of using my IP in the setting, but I did not have any problems with '.atrament.net' just yet.
It's hard to say with that mess of config fragments but having the mod_proxy_connect module loaded was probably the culprit.
As a long time Apache user I've never understood using its proxy modules for stuff like this. I've always felt like its much cleaner to just use a small daemon process built solely for the task of reverse proxy or balancing. e.g. haproxy, pound, etc.
tl;dr: Negligence, and failing to RTFM.
What really horrifies me is the author doesn't seem to understand the magnitude of their error. The final quip at the end illustrates this. "Ha! someone searched manslaughter over my proxy! I had a lot of fun reading my open proxy logs..."
I wonder how many stolen credit card transactions were done over his proxy, causing headaches for many innocent people? Or worse?