Tag Info

New answers tagged

0

As an addition to the awnser I list my practise: For the moment I would not allow direct communications with tomcat, but setup a Reverse Proxy Connection using nginx. And have nginx do all the SSL bits. The main advantages are that nginx can be setup with better DH keys and Cipher support. as a bonus if someone is trying to 'hack' my tomcat through ...


7

So I think I've interpreted your question correctly. If not, fire away in the comments. Confusingly there are several factors in diffie hellman: are you doing it over elliptic curves or not, what size group have you got (let's assume "strong" and "not strong") and whether you generate ephemeral private/public keypairs or not. The problem with logjam is ...


-2

Disable any CBC mode ciphers and SSL protocols, only enable TLS 1.1 & 1.2 protocols in your server.xml. Mozilla has a good guide for allowed ciphers as well. https://wiki.mozilla.org/Security/Server_Side_TLS


3

Disabling RC4 completely would be great in an ideal world, but unfortunately we don't live in an ideal world. If you do disable it, certain mobile and embedded devices may not be able to communicate with you. Keep in mind that IE on Windows XP can only use RC4 because the underlying cryptographic API (CAPI) on the system doesn't have AES. As for the risk, ...


2

I think you're asking the wrong question. To me, "How much will my users be inconvenienced?", is far less important than "How sensitive is the information on this server?", or "How much would I care if it got hacked?". Hardening a system usually leads to some inconvenience. The level of inconvenience you're willing to endure (and inflict on your users) ...


0

RC4 has been proven to be broken so is probably a sensible thing to disable it from a webserver. You shouldn't bother to keep it on just to provide access to obsolete web browsers - after all, they're called obsolete for a reason, and giving the visitor incentives to upgrade his old browser is good.


1

The answer seems quite simple to me. The final decision however, depending on the context, may not be as simple as it implies the notion of trust. SSL is a protocol allowing you to establish a secure connection over an untrusted network. The usefulness of SSL in your case therefore lies in this question: Do you trust the network between the web server and ...


1

This is an attempt to exploit CVE-2014-6271 (the “shellshock” vulnerability, if we must). Its appearance in this message is no indication that it was successful; any client can include any string in the Referer: header and have it included in logs here. The attempt didn't succeeded in this specific case, because the log message is telling you there was no ...


1

So it looks like someone is trying to use the shellshock vulnerability which was recently discovered in the bash shell. The key give-away is the part of the log which reads: referer: () { :;}; /bin/bash What the attacker (or unknowing participant) has done is to set their web browser's http referer header to everything you see after the word "referer" in ...


0

Apache httpd source: 2.4.12 I did a Source code Grep for 'GLIBC' and 'gethostbyname' I found Refrences to the GlibC Libraries (so Apache could be using them) I also found the following uses of 'gethostbyname' : httpd-2.4.12/support/logresolve.pl.in:213: $hostname = gethostbyaddr(gethostbyname($ip), AF_INET); ...


0

Apache is using Apache Portability Runtime and they implemented their own apr_gethostbyname, so the core server is not vulnerable. But over the time, some modules, apparently they didn't use APR gethostbyname function, so is very plausible to still find some modules using it. Also the apache is correctly validating all the inputs, so is a very low chance ...


8

You must check the version of your glibc first: using this command can help: ldd --version The end of the answer has a good things you can skip and go there According to this reference this vulnerability works on glibc version before 2.21-3. if your glibc is older than this version it is vulnerable. The problem has been fixed upstream but a new version ...


3

Spoofing an IP will not lead to being able to download the files, as the response for this request will be send back to the spoofed ip, which would have to be the servers ip in this case. However, if an attacker can upload his own php page through slqi or something else, they can send requests that originate from the server itself (so 127.0.0.1) and would ...



Top 50 recent answers are included