Secure your cookies
In settings.py put the lines
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
and cookies will only be sent via HTTPS connections. Additionally, you probably also want SESSION_EXPIRE_AT_BROWSER_CLOSE=True. Note if you are using older versions of django (less than 1.4), there isn't a setting for secure CSRF cookies. As a quick ...
It looks to be trying to exploit some form of command injection. As DarkMatter mentioned in his answer, this was likely a broad attempt to find any vulnerable servers, rather than targeting you specifically. The payload itself just appears to just be testing to see if the server is vulnerable to command injection. It does not appear to have any additional ...
Every server that is connected to the Internet will receive hundreds of "weird requests". Most of them are from automatic botnets which try to replicate, by finding machines which feature a specific vulnerability. They try random IP addresses (there are only four billions of possible IP addresses, after all). So yes, someone is trying to enter into your ...
We are installing the same self-signed certificate into every development and prototype unit.
Installing the same certificate into every unit is about the worst security practice one could imagine when dealing with certificates. We now know not to release products with the default hard coded administrative credentials. We avoid default credentials because ...
First, let's go over how cipher suite negotiation works, very briefly. For example, we can use the TLS 1.2 document RFC 5246 starting at section 126.96.36.199 to see, in the short short form:
ClientHello: The client tells the server which cipher suites the client supports
Now the server picks one
I'll discuss how to control which one it picks next!
Some techniques for trying to find how your attacker got in:
Look at the timestamps on any files you know the attacker changed then look through all your logs for entries as close to each timestamp as possible. As others have said, the web access logs and web error logs are the most likely to hold the evidence of the original attack vector but other log ...
Since you have the logs I suggest that you look for usage of the login form. Did the try to login at all?
Most often this is just a scan that looks for interesting sites and stores them for later use. This behaviour is extremely common and is common place in almost every http log with a internet facing web service.
First of all you should look at the ...
It is probably nothing. It seems like the broad spam of a scanner looking across the web for any website that evaluates and returns that subtraction when it shouldn't. It is a pretty common thing to see.
I note that the executable code appears immediately after the first version parameter after Mozilla/. This means the ...
These are scans for proxy servers. The first one tests for a SOCKS4 proxy, the second one for a SOCKS5 proxy, and the third one tests if your server allows forwarding via a CONNECT request to "valuable" ports (SMTP in this case). You don't have to be worried about that, it's what you expect to see on public servers. Your server answers with return code of ...
BREACH is a vulnerability that is present when several conditions are met:
HTTP compression is used,
A part of the input is reflected,
A static secret is present in the HTTP body of the response,
The attacker can read the size of the encrypted response,
The attacker can forge requests to the site under attack.
Each of these conditions pose no threat in ...
I haven't tested this myself, but reading Nginx's source code, it seems to use libc's crypt() function directly. Depending on your OS, you may have a sane crypt() implementation available, either bcrypt or glibc's SHA-256/SHA-512 scheme. It's worth a shot to see if you can use it with Nginx.
I've solved it by generating a fake certificate that doesn't reveal domain name and adding it as a default one on the start of the config:
listen 443 default;
And yes, it requires a nginx with ...
According to nginx documentation the ssl_trusted_certificate parameter contains trusted CA certificates used to verify client certificates and OCSP responses if ssl_stapling is enabled and the list of these certificates will not be sent to clients.
Therefore I think that what ssllabs calls "Additional Certificates (if supplied)" are the certificates in the ...
Does it increase connection security if I regenerate the dhparam files
used with NGINX on our servers periodically e.g. every week?
No, not significantly.
DH parameters are really just a large prime that takes a lot of time to be generated (because it needs to be a safe prime). Additionally there's a so-called "generator", but this one is cheap to ...
Due to the nature of how SSL works, the SSL/TLS handshake is performed before the intended hostname is given to the web server. This means that the default (first) certificate is used when trying to access the site, regardless of the domain name used.
This is true with both Apache and nginx.
From the Apache Wiki:
As a rule, it is impossible to host ...
This looks like an open HTTP proxy scan to me. The HEAD or GET request is not normally followed by http://, but only by the local path.
If your server acts as an open HTTP proxy, the attacker is trying to hide behind it and you should close it. This will get your server blacklisted pretty soon.
Make sure your server is not acting as an open proxy, then ...
Mozilla has an online tool that will help you choose the correct cipher suite.
It will let you input your server version, software version, etc. and then choose between a balance of security and legacy support.
Make nginx drop requests to timeout client on purpose
It is not possible to drop HTTP requests to hide the server, no matter if using nginx or another server. The HTTP request will only be sent after establishing the TCP connection. This connection can then only be closed with or without a response. You could also keep it open so that the browser times out ...
The linked solution allows jenkins to run any command via sudo without a password.
A better solution is to allow jenkins to restart nginx without a password, but nothing else. This way you have root permission for the command you need to execute, but you're not granting blanket permission for jenkins to do anything and everything.
Use visudo to stick this ...
@Iszi is absolutely correct here. You need to completely wipe and rebuild, as a good rootkit will prevent you seeing any evidence of its existence.
Otherwise there is a strong likelihood that anything you do now is pointless. In any case, you can no longer trust the server.
Muhammad, in some cases I saw the attack was conducted by a bot that exploited a vulnerability on the system (Usually PhpMyAdmin) and uploaded files to the server (mainly /tmp). What happens is that those files stay there and admin won't notice until the attacker go over their bot logs and start building on the first compromised.
It is quite possible that a ...
This is an known attack, Shellshock. On servers with a vulnerable bash shell, the attacker can exploit an condition that executes shell commands by sending a special crafted URL.
Basically, the attacker is scanning your server to see if it is vulnerable to it. If your server was found to be vulnerable, probably you would see a few wget/curl being sent in ...
A late response, but this is a long-standing bug in Chrome. Chrome doesn't update the security indicator in the address bar before showing the basic auth dialog (though it does validate the security correctly, so an expired certificate is correctly marked).
Here are a few details that might help clarify the situation:
Ports less than 1024 are (in most OSes) privileged ports that require root to run anything on them. This is intended as a security feature to make it more difficult for an attacker to host services on important ports on a compromised server. As a result, root is required to run anything on port ...
Usually when people say that they can't afford to wipe a server, they mean that the time to reset the configuration will be too much. However, there's a way to go about this and not have to find the vulnerability immediately -- though you must replace compromised files. I suggest implementing security before exposing your clean files to the Internet. What ...
Just to add a couple of thoughts to the comments already provided. As @symcbean says, third party code is a likely source of issues.
If I was to hazard a guess, I'd look at the Wordpress application and associated plugins as being a likely source of your compromise. There have been a large number of security issues discovered in Wordpress plugins recently ...
1. 304 not modified answer. Most likely a perfectly legal request, especially considering the user-agent.
2. 404 on favico.ico means that your webserver does not have the favicon.ico file available and replies with "404 not found". This is normal and can be fixed by adding a favico.ico file to your webserver document root.
3. "400 Bad ...