Developers fix multitude of vulnerabilities in Apache HTTP Server
portswigger.net
portswigger.net
https://www.mail-archive.com/fedora-list@redhat.com/msg06924...
>On Jul 16, 2008, Les Mikesell wrote:
>> Alexandre Oliva wrote:
>> Apache wasn't the original name.
>It was and it wasn't. It was indeed a bunch of patches on top of the (also younger) NCSA http server. That's where "a patchy http server" came from. But that was '90s already, some ten years after GNU started.
Half a day later with no resolution in research a new patch [1] was available and problem resolved.
[1] https://github.com/apache/httpd/commit/8720881b0634383145e87...
5 is a very good number but I don’t know if I’d go so far as to call it “great”.
Did the fixes not land in Debian yet?
The WSL version of Ubuntu is reporting 2.4.41 for me still. I don't know about the real version.
Example:
https://security-tracker.debian.org/tracker/CVE-2021-30521
"Heap buffer overflow in Autofill in Google Chrome on Android prior to 91.0.4472.77 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page."
https://security-tracker.debian.org/tracker/status/release/s... is one place to look through in the past I think there was a better link I used to use to find all vulnerable packages which were awaiting a fix - but I can’t seem to find it now.
Decent privacy, questionable security vs stability if you're serious about it.
An Apache compiled with the exact options that you'll need shines, like an Nginx well done.
Web servers have historically been pretty conservative as far as software goes.
A lot of people still retain the notion that nginx is "just faster" or "just better" which is not necessarily the case. Apache with mpm-event is just fine for most applications.
There are other reasons to use nginx, and there are other reasons to use Apache. Both are fine, and I hear https://caddyserver.com/ is coming in hot!
At the expense of the memory footprint because developed with Go. Hi Caddy creator!
Makes sense to me that something built in a language with more memory safety than C would use more memory, but is it really significant in practice? I use go every day and memory usage has not been a significant issue for many applications.
There are other performance concerns of course, e.g. GC latencies, and at times the GC may bite you. See e.g. the "taming Go memory usage" story from a few days ago[1], but this usually isn't a huge concern for many use cases.
cmon now
terminal systems engineer brain is everywhere
$ apt-get install python3-certbot-nginx
$ sudo certbot --nginx -d example.com -d www.example.com
https://www.nginx.com/blog/using-free-ssltls-certificates-fr...
On the other hand, caddy seems to auto renew them as well - one less cron job:
> Automatic HTTPS provisions TLS certificates for all your sites and keeps them renewed.
https://caddyserver.com/docs/automatic-https
Neat, but still not sold.
Overall, the entire thing seems very complex automagic black box last time I tried it (already years ago). Sometimes trying to make something easier can make it harder.
Smaller web servers have been event based since they first showed up, it is the natural way to build them. There was no epoll() available, but a select() loop is pretty much the same thing. The super useful thttpd had been around a long time at that time.
What caused people to start using non-forking web servers for regular public web applications was probably that PHP finally got a stable FastCGI mode going about ten years ago. Because, honestly, most of the web is PHP and it was even more dominant back them.
And when people posted their web server configs in forums at that time, nginx configs were much more readable and concise. The easier config format is what caused its popularity to soar, not that it used a particular syscall half a decade earlier.
Before nginx, lighttpd was a thing. It also comes with `spawn-fcgi` to handle fastcgi, but it's a little complex to set up. Back then people were also using `spawn-fcgi` with nginx, too. I remembered reading some tutorial and decided that I will continue to use Apache with mod_php due to complexity. When php-fpm come, I immediately switched.
Edit: specific to your request, I would probably set up a container pointing to the latest apache build, and write a script to pull the latest image then roll over the container... Don't need to wait for your OS of choice to have the fixed versions... Your never more than a day behind
darkhttpd is an option
Shared hosting is still huge for small sites, and the major control panels for that (cPanel, Plesk, DirectAdmin, vDeck) still support Apache as the primary web server.
There are some downsides with .htaccess files though; since it can change you need to at least check if it was modified since the last request, and since it's recursive (i.e. /foo/.htaccess applies to /foo/bar/file.txt) you may need to check several locations. Basically, it's a lot of stat() calls for every request.
The upside is that it's convenient; i.e. "tar xf somephpapp.tar.gz" and it "just works" without mucking about with configuration to disallow certain files, but this convenience comes with a fairly hefty performance impact, and it's only certain types of PHP apps that really take advantage of this.
The main upside is that it is possible for sysadmin to allow 3rd party users to change parts of http server config via ftp (!). And last I checked, php was dominating web landscape - I would argue that the convenience of deploying plays a large part in this.
Plugins... If it is not part of original app, can I trust it will stay available? I might as well use Apache instead.
Surely this decade they've squashed the last bugs that nginx or anything newer won't have...
But Apache is not a legacy system and still a completely valid choice, next to alternatives like nginx and caddy that have their own advantages and disadvantages. There is no reason to swap Apache out by default, apart from maybe sometimes in specific situations.
https://news.netcraft.com/archives/category/web-server-surve...
Unlike nginx or Caddy^H^H^H^H^H, the Apache design and community encouraged writing modules (roughly akin to "middleware" in the modern server-side web stack) that hooked directly into the web server, rather than just using it as a static host + L7 proxy.
Furthermore, these modules could themselves expose language-specific APIs; ergo `mod_perl` and its ilk, which provide a bunch of useful building blocks for a full-stack webapp but are entirely specific to Apache's module API (vs. something more standard like FCGI, WSGI, etc.)
I've worked at some shops with heavy investments in Apache-based application servers and the cost of moving away from HTTPD modules and towards a more standalone, Apache-free implementation was generally quite high. Usually you need some other forcing function (rewrite in a new language, microservice decomposition, etc.) to justify the investment.
Huh? I must be misunderstanding, because everything in Caddy is a module, even its HTTP server, and all its middleware handlers are equally modules that you can plug in as much as any other module you could write and publish.
Some Caddy modules also expose dynamic scripting / language interpretation capabilities as well. Caddy is used for well more than just static files and HTTP reverse proxying.
Now if someone asks me if I also still use the same laptop as when Apache had >6 times the market share of Nginx (https://news.netcraft.com/archives/category/web-server-surve...), I will need to find more hands.
A similar number of folks as are using nginx[0]
For example, Nginx's standpoint on htaccess is basically "find yourself another web server" (https://www.nginx.com/resources/wiki/start/topics/examples/l...). I don't fancy giving users access to /etc/nginx and the power to reload the config just to add aliases on their own subdomains. Much better if they can add password protection to a directory by themselves. It also breaks that each site can live in its own project directory: without htaccess, if I copy over a project I would also have to modify my global nginx config to set per-directory (or at least per vhost) aliases, error pages, etc. Right now, I can say that deploying a project is "download the directory into the desired location and configure your database credentials and a pepper in the config.php". No global configuration changes are ever needed, the global config only does global stuff: tls ciphers, fallback error pages, compression, log files, and more such things.
And that's ignoring the fact that, even if there was some objectively better web server, I'd have the task of rewriting a decade of htaccess files into their fancy new format while Apache2 is still alive and properly supported.
I thought I was so cool ...
It's very stable, supports that one special thing many sites need (special headers, stripping file extensions, caching etc) and has excellent documentation.
It's not fashionable, but it will still be unfashionable in another 10 years, and we won't have needed to update the configurations in that time.
Lots of security holes in your custom write? Yes! But the hacker needs to be dedicated to exploiting your one server specifically to find it.
In exchange you are safe from of all those : vulnerabilities in the wild => script kiddies => mass exploitation => your are now hacked type of situations.
Not sure about that... You might commit some of the same mistakes that they did
The market for security skills tends to be more interested in protecting targets that can draw high-effort attacks, or low-effort attacks at scale, so there's good reason for the "security through obscurity = bad" meme. You won't get in trouble by incorrectly assuming "security through obscurity = bad," but you can definitely get in trouble by incorrectly generalizing "security through obscurity = good enough." It makes sense to err in the direction of least damage.
We like exposing our private B2B web services in such a way that an attacker would be led to think the web server is totally fucked up or otherwise mis-configured if they don't understand the proprietary protocol. It's not that they could never understand it, but it would take a significant, targeted effort to even begin attacking our system in a direct fashion. Even if they figure out the obfuscation, they are still going to have to fight through a moat of PBKDF2 & hardware tokens.
To me, obfuscation is all about minimizing the impact of automated, mass, 0-day assaults. Some person will always be able to walk back something another person built. You can mitigate legions of scripts by cleverly dropping TCP connections when a resource isn't requested in just the right way.
Another fun option is to build a honey pot around your web service which has the ability to ferret naughty TCP pipes off to the hacker matrix where you then simulate all manner of PII-rich data sources for them to worry about (instead of your actual business).
It's the infosec equivalent of not needing to outrun the bear, just your friend.
Make your stack annoying enough to attack and attackers will move on to other targets.