Right now, there is no known weakness with MD5 or CBC encryption or 96-bit MAC as they are used in SSH. So there is, stricto sensu, no security benefit in enacting the configuration modifications that your are proposing. It could be argued that removing support for some algorithms might lead to security issues because it may prevent some clients from ...
There is a very extensive article at Wikipedia and it does not make sense to reiterate everything here. But to give you some highlights:
It replaces OpenSSL on OpenBSD, OS X since 10.11 and on some other systems.
It started with throwing away lots of stuff which was considered useless for the target platforms or insecure by design and it also added some ...
Any program written in Java
to the command line invocation used to start the Java process. (Without this, Java uses /dev/random to seed its SecureRandom class, which can cause Java code to block unexpectedly.)
Alternatively, in the $JAVA_HOME/...
As root, just do this:
mknod /dev/random c 1 9
Now /dev/random will actually access the same underlying logic as /dev/urandom.
After this change, both /dev/random and /dev/urandom will draw from the non-blocking pool. The non-blocking pool will draw from the blocking pool, which the system will still fill.
The main ones are:
Use SSL sitewide. Don't offer anything over http. Instead, any connection via http should immediately redirect to the main site's landing page via https.
Use HTTPS Strict Transport Security. This will tell users' browsers: please, only connect to me over https. This defends against sslstrip and similar man-in-the-middle attacks.
Set the ...
The option names are not part of the SSH protocol; they are specific to a given implementation. I suppose you are talking about OpenSSH.
As per the documentation:
Specifies whether pure RSA authentication is allowed. The default is
“yes”. This option applies to protocol version 1 only.
So this does not apply to your case, since ...
When you use an SSH tunnel, as far as the target server is concerned, its client is the SSH server, not the actual client connecting to the SSH tunnel.
For example, if you have an SSH client running on 10.1.1.1, connecting to an SSH server on 10.2.2.2 and establishing a tunnel to 10.3.3.3, when a client (possibly from 10.4.4.4 or anywhere else) connects to ...
I will first dispute your reasons for deactivating DSA and ECDSA:
There is no known weakness in either which makes them "more vulnerable" than plain RSA.
There has been badly made implementations of DSA or ECDSA; however, there has also been badly made implementations of RSA, and in some case it resulted in RSA key leakage (e.g. Bleichenbacher's attack).
While this is true, that is true for many applications. If the attacker already has access to the file system it is far too late to worry about your database server. In unix-type operating systems, the configuration file should be accessible only as root (as it is in /etc/mongodb/mongodb.conf). If the attacker has root privileges to change that file, you're ...
Use SSH key based logins
Disable phpMyAdmin, webmin, etc
Close all ports/process's that are not needed
Use a file integrity checker
Set the proper permissions/groups
This is a good guide:
Basic guide for hardening:
From the IETF draft [ http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-06 ]:
10.1 HSTS Policy expiration time considerations
Server implementations and deploying web sites need to consider whether they are setting an expiry time that is a constant value into the future, e.g., by constantly sending the same max-age value to UAs.
There may be harm in divulging your .htaccess file. This is usually one of the reasons why there's a rule to block access to .htaccess, like this:
Deny from all
The contents of this file may tell users about your configuration, such as where passwords, certificates, and so on reside in the system, and ...
You cannot really hide the domain name, because if someone connects to the port 443 of your server and begins initiating a SSL connection, your server will respond by sending his certificate... which contains the server name.
Actually, the client may send the intended client name as part of a Server Name Indication, which is a rather recent extension which ...
One reason is that older algorithms are likely to have wider support. Such defaults probably ensure that the software runs on a wide variety of platforms out of the box. The software itself might also be old.
It may be assumed by the developers that you will configure the software to meet your expectations after installation. It may be arguable that this is ...
Stricto sensu, you cannot really have a generic test. In HTTP, the client announces whether it supports compression with an Accept-Encoding header line. The server will then feel allowed to use these compression schemes. @Adnan points to this blog post which describes how one can manually send a HTTP request to a server and see what the server responds with. ...
Absolutely absolutely pick up the Web Application Hackers Handbook by Portswigger (author of Burp), which is written as both an introduction to the concepts relevant to Web App reversing / hacking, but also as a step-by-step guide for applying those concepts with Burp Suite.
Note that the Second Edition is now available.
Great initiative by D.W. to list different software configurations (I am a die-out fan of D.W. already)
BUT - As I mentioned on my previous comment, On my VPS servers I personally still prefer to install one single component (haveged) that gets everything running smoothly.
Perhaps @DavidSchwartz's suggestion is the only one that could be even easier, but ...
In general, DISA STIGs are more stringent than CIS Benchmarks. Keep in mind that with STIGs, what exact configurations are required depends on the classification of the system based on Mission Assurance Category (I-III) and Confidentiality Level (Public-Classified), giving you nine different possible combinations of configuration requirements. CIS usually ...
It is very good advice to not use the web browser for Internet traffic on the server.
It's our policy (I work in cyber security for a federal agency) to never use a web browser (for Internet, or external websites) for any sort of Internet traffic even if it's to download a file that will be used on the server. As another user mentioned in their answer, it ...
The originally highly voted answer to this question that was accepted was deleted because it was a direct plagiarism of 20 ways to secure your Apache configuration. That page is a fantastic resource.
@RoryMcCune also posted this as a link on that answer: There's an OWASP project to develop a ModSecurity Core Rule Set here which could be of use.
The message you are seeing is from the default apache "400 error page". You can override the 400 error page via:
ErrorDocument 400 /error-docs/400.shtml
in the appropriate location in your config file. Replace the default text with a generic message that doesn't include the host name.
Everyone who is really worried about security of SSH probably wants to read this page:
It goes through all key exchanges, server authentications, ciphers and MACs that OpenSSH supports and then throws out whatever cannot really be considered secure anymore, giving valid justification for ...
No, when you encrypt a web.config section, you specify which application and site the configuration belongs to. The container is going to be specific to that site and application, and will not be accessible to other applications.
If you control the system, then you can do whatever you want, including just decrypting the section. There is no protection ...
The answer to this comes down to a risk-management decision that the organization makes. There are best practices, but even the bestest of practices can be compromised by risk-management decisions. There are no absolutes, even patch broken stuff is not an absolute.
You had a clue in their response:
This phrase is used to justify ...
Here is an explanation of what this "renegotiation hack" is all about.
An SSL/TLS session begins by a procedure called the "handshake": right after connecting, the client and the server exchange a few administrative messages in which cryptography happens, and afterwards client and server have a shared session-specific secret with which subsequent data is ...
Has anyone encountered this kind of policy before?
And does anyone know what the security benefits are supposed to be?
The security benefit is that the devices exposure is greatly reduced with little cost in terms of availability.
In security the risk to a given asset is described by three factors: threats, vulnerabilities and exposure.
There's lots of good advice here, so I won't repeat things already mentioned. But what I will say is:
Don't forget to replace the default error pages with things that don't give away your Web Server release or kernel revision. I tend to replace each default html with 1 liners that are something like "Error 400." It gives very little about the system away. ...
And what about the Grsecurity/PAX kernel patches, these include very nice features for hardening the server at kernel level.
Protect heap and stack overflows
Hide other users processes
Role based access control list
/proc, FIFO and dmesg restrictions
Advanced logging capabilities
All of these configurations should be default from your distribution and most of them don't have a security impact if read. If an attacker could modify .bashrc then they could pull off a sudo hijack, but just being able to read the .bashrc isn't a problem.
Sometimes the .bash_history file will contain passwords. Sometimes passwords are an argument to a ...
TCP forwarding allows users to use SSH to set up a VPN which they can use to tunnel into a network. This could allow an attacker to circumvent network security measures like firewalls. SSH tunneling can be an extremely useful tool, but it is also a security risk, so it should be disabled unless it is explicitly required.