I am trying to upgrade my log4j version to 2.15.0. This should take me a while as I have to upgrade other stuff as well. My question is does dropping ldap callbacks on both 363 and 636 ports on my server will prevent the log4shell attack?
I am afraid not as the attacker can specify a different port in the attack string.
Related
Friendly Disclaimer: I am new to working with Keycloak and IdP in general. So it's likely that I use incorrect terminology and/or am more confused than I think I am. Corrections are gratefully accepted.
My question is conceptual.
I have a TLS certificate that is terminated on my host machine by my host company. My reverse proxy (Traefik) is picking up that certificate.
Which of the following proxy modes should I use now to be able to deploy Keycloak to production: edge, reencrypt or passthrough? (see here for relevant documentation)
I can pretty much rule out passthrough, because as I wrote, the TLS certificate is terminated on the server. But I am unsure if I have to bring my own certificate and reencrypt or if it is considered safe to go along with edge?
I have done my best to keep this question short and general. However, I am happy to share configurations or further details if needed.
As far as I know, most organizations consider a request to be safe when the proxy validated and terminated the TLS. It also removes the performance overhead (depends on your load). Unless your organization is going for Zero Trust for its internal network, using the edge should be totally acceptable.
We have an APache 2.4.6 version installed on Rhel 7.5 in production.
The security Audit team found few vulnerabilities lately which needs to be fixed.
1.) During audit ,it is observed that connect web server is vulnerable to Slowloris attack.
Mitigation suggested for this:
Rate limit incoming requests - Restricting access based on certain usage factors will help mitigate a Slowloris attack. Techniques such as limiting the maximum number of connections a single IP address is allowed to make, restricting slow transfer speeds, and limiting the maximum time a client is allowed to stay connected are all approaches for limiting the effectiveness of low and slow attacks.
2.)The lack of HSTS allows downgrade attacks, SSL-stripping man-in-the-middle attacks, and weakens cookie-hijacking protections.
Mitigation: Configure the remote web server to use HSTS response header.
3.) During the audit, it is observed that mod_security is not implemented which is an application security firewall for apache.
Mitigation:
Implement Mod_security to timely detect and prevent application security attacks.
I dont have much idea on how to configure these.
Please help me with the steps for getting the above issues fixed.
I can point you in the right direction, perhaps, but the full configuration/setup for two of these is not short-checklist-friendly.
1) mod_qos is a way to limit your exposure to slowloris. It's designed to be used in a reverse_proxy server. Not sure if it fits your situation, but it's a place for you to start looking. I'm not sure total immunity to slowloris can be achieved, at least not without the potential for spending lots of money on it.
http://mod-qos.sourceforge.net
2) This one is easy. For apache, put this in the site configuration file:
Header always set Strict-Transport-Security "max-age=15638400"
That essentially tells the user-agent to never even think about using http, only https, on this site for the next 6 months (roughly).
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security
3) mod_security should be available in one of the RHEL repos (probably EPEL) setup and configuration of that can get complex, so start here:
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)
(It's the manual for version 2.x, there's a 3.x but I suspect it's not made it into RHEL yet, so I'm posting the 2.x version)
The use of SSLv3.0/TLSv1.0 in combination with certain encryption techniques (CBC block
ciphers) may allow for an attacker to predict the so-called Initialization Vector of subsequent SSL packets. Using this information the attacker can access the secure session of another user. This attack, named BEAST (Browser Exploit Against SSL/TLS), is aimed at the user’s browser and not at the web server. Nevertheless, it is possible to take countermeasures at the server side as well to prevent a successful attack.
The complete solution to this problem is disabling or deprioritizing the support for
vulnerable encryption ciphers (CBC block ciphers) when using SSLv3.0/TLSv1.0. Commonly, this can be achieved by prioritizing RC4 ciphers in the cipher negotiation process.
For Apache web servers that support SSLv3.0/TLSv1.0 this can be configured by adding the
following configuration:
SSLProtocol All –SSlv2
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!ADH
For Apache web servers that support SSLv3.1/TLSv1.1 and higher, it is recommended to use the following configuration:
SSLProtocol All –SSlv2
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM
As far as I know, JBoss 7 is based on a version of Apache that supports SSLv3.1/TLSv1.1 (maybe I am wrong), so the second alternative can be applied to JBoss 7.
My question is: Where/How should I configure it?
Dont paranoid with beast attack. According to this Oracle fix the issue, its not related directly with JBoss its an JVM issue. As stated here its hard to apply beast attack in real world. Just make sure that your JVM and JBoss is up-to-date. If you have still question in your mind its best practice to run JBoss behind a reverse proxy such as apache or nginx.
Will it shut down & lock up after repeated false password tries, and/or will it add lags in-between retries? Or does this depend on which modules you or your provider install? Thanks!
default Apache installation does not do that.
usually this is better done by your web application (eg, PHP/JSP) for account attack.
for network attack, better not for web servers because it's hard to identify the source due to so many anonymous / transparent proxy / VPN / NAT stuff. once you've implement that, you'd usually get lots of "why I can't connect" complains...
I have an HTTP server which is in our internal network and accessible only from inside it. I would like to put another server that would listen to an HTTPS port accessible from outside, and forward the requests to that HTTP server (and send back the responses via HTTPS). I know that there are several ways to do this with some programming involved (and I myself made a temporary solution with Tomcat and a very simple servlet I wrote), but is there a way to do the same just plugging parts already made (like Apache + modules)?
This is the sort of use-case that stunnel is designed for. There is a specific example of using stunnel to wrap an HTTP server.
You should consider whether this is really a good idea, though. Web applications designed for use inside a corporate firewall are often fairly lax about security. Merely encrypting the connections prevents casual eavesdropping, but does not secure the site. If an attacker finds your outward facing server and starts connecting to it, they can still try to find exploitable flaws in the web service (SQL injection, cross-site scripting, etc).
With Apache look into mod_proxy.
Apache 2.2 mod_proxy docs
Apache 2.0 mod_proxy docs