I had the same problem...
You have to include SSLProtocol all -SSLv2 -SSLv3 within every VirtualHost stanza in httpd.conf
The VirtualHost stanzas are generally towards the end of the httpd.conf file. So for example:
Probably you do not load the ssl module. You should have a LoadModule directive somewhere in your apache configuration files.
LoadModule ssl_module /usr/lib64/apache2-prefork/mod_ssl.so
Usually apache configuration template has (on any distribution) a file called (something like) loadmodule.conf in which you should find a LoadModule ...
The file to edit:
Command to edit file:
sudo nano /etc/apache2/apache2.conf
For a global servername you can put it at the top of the file (outside of virtual host tags).
The first line looks like:
Then save and test the configuration with the following command:
The reason that apache needs a reload is that once it's opened a file, it gets a filehandle to it, and it will keep writing to that filehandle. When you move the file, it doesn't see that, it just keeps writing to the same handle. When you do a reload, it'll open the file again and get a new handle.
To avoid the reload, instead of moving the file, you can ...
None of them, at least not by itself. You must either give the directory structure a context of httpd_sys_rw_content_t, or give them a context of public_content_rw_t and enable allow_httpd_anon_write and/or allow_httpd_sys_script_anon_write. See the httpd_selinux(8) man page for details.
The fact that netstat shows only tcp6 here is not the problem. If you don't specify an address to listen on, apache will listen on all supported address families using a single socket (for design reasons, sshd uses a unique socket per address & address family, hence showing up twice in your netstat output).
Here's one of my systems, showing apache ...
Do not manually upgrade Apache.
Manual upgrading for security is unnecessary and probably harmful.
How Debian releases software
To see why this is, you must understand how Debian deals with packaging, versions, and security issues. Because Debian values stability over changes, the policy is to freeze the software versions in the packages of a stable ...
Rather than key the rules in manually you can use iptables to add the rules to the appropriate chains and then save them. This will allow you to debug the rules live, confirming they're correct, rather than having to add them to the file like you appear to be doing.
To open port 80 I do this:
$ sudo iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
From the output you've given, you are trying to compile a 32-bit build of apache on a 64 bit system. This is from the intput to configure here:
--host=x86_32-unknown-linux-gnu host_alias=x86_32-unknown-linux-gnu CFLAGS=-m32 LDFLAGS=-m32
Also see the output lines confirming this:
configure:3629: checking build system type
configure:3643: result: x86_64-...
mod_security is great, but you don't really need it to achieve your goal.
after all mods have been included in httpd.conf you can simply unset the headers of your choosing.
Header unset Server
I'm going to use Firefox as an example, because its open source and easy to find the information for, but this applies (probably with slightly different lists of ports) to other browsers, too.
In August 2001, CERT issued a vulnerability note about how a web browser could be used to send near-arbitrary data to TCP ports chosen by an attacker, on any ...
The logs are causing the errors because apache cannot write to the root of your website. Even if you were to fix the file permissions, you'd still be blocked by SELinux; which only allows apache to write logs to /var/log/httpd. The easiest solution would be to change your website to log to this directory - maybe with a filename that contains the website ...
Depends. 644 for files and 755 for folders are a safeish default.
Don't change ownership of anything to www-data unless you want php to be able to edit the contents of that file/folder
Irrespective of anything else you do: folders need read and execute permissions for the user to find files; files need read permissions for the user ...
Here's how to permanently change the context of a directory:
# install semanage if you don't already have it:
yum install policycoreutils-python
# give the directory a new default context. The part at the end is a regex.
semanage fcontext -a -t httpd_sys_rw_content_t "/path/to/directory(/.*)?"
# apply the default context to the directory
restorecon -R /...
Make sure you do not have illegal characters in your virtual hosts' ServerName.
I ran into this issue while migrating "sub_domain.test.com" from Apache 2.2 to 2.4.
The underscore in "sub_domain" caused Apache 2.4 to respond with 400 (Bad Request) but no further hint in the error log.
Also have a look at https://stackoverflow.com/questions/2180465/can-...
I don't know anything about Amazon EC2, but you should be able to:
Retrieve the name of the user running Apache with a command similar to this:
ps aux | grep apache # The username should be in the first column.
Retrieve the groups this user is part of with the groups(1) command:
Here we see evidence of a problem:
tail: inotify resources exhausted
By default, Linux only allocates 8192 watches for inotify, which is ridiculously low. And when it runs out, the error is also No space left on device, which may be confusing if you aren't explicitly looking for this issue.
Raise this value with the appropriate sysctl:
If a file has been deleted but is still open, that means the file still exists in the filesystem (it has an inode) but has a hard link count of 0. Since there is no link to the file, you cannot open it by name. There is no facility to open a file by inode either.
There is no way to discover the file through its filesystem, and especially no way to look for ...
Just updating this for people who are still looking. I was having trouble getting the Server line in the HTTP header changed. This advice should work for Debian branch distros with systemd and Apache 2.4.7. Specifically, I am using Ubuntu Server LTS 14.04.03. Some advice I found was to do
grep -Ri servertokens /etc/apache2
This led me to /etc/apache2/conf-...
June 2019 Update
It's here! Apache 2.4.37 (released 22-October-2018) adds support for OpenSSL 1.1.1 and TLSv1.3 . Make sure you use at least 2.4.39 though due to security issues.
March 2018 Update
TLS 1.3 draft is up to v26. There is general support in the main SSL libraries for varying versions of the Draft. It doesn't look like Chrome and Firefox have ...
If you are using apache2, then you have to do the following:
Step 1: Use OpenSSL to produce the keys that are used to secure your site. These keys are used when encrypting and decrypting the traffic to your secure site.
$ openssl genrsa -out mydomain.key 1024
This command will create a 1024 bit private key and puts it in the file mydomain.key.
Step 2: ...
CentOS 6.x does not provide 2.4.x, only 2.2.x versions of Apache. CentOS like the Red Hat OS it derives from, RHEL are geared towards stability and so tend to lag behind what's cutting edge. So you'll need to either:
compile it yourself
find source RPMs and rebuild/recompile them
find a repository that already has it pre-built in RPM form
find pre-built ...