Hot answers tagged

50

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 ...


48

It appears that your server is the target of an automated attack involving the ZmEu scanner. That first request appears to be from another automated attack involving the Morfeus Scanner. That last request appears to be an attempt to exploit vulnerabilities in the Home Network Administration Protocol (HNAP) implementations of D-Link routers. More ...


26

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 ...


22

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 7.4.1.2 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! ...


14

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 ...


10

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 ...


10

if you want to block known scanners you might want to use nginx-based WAF naxsi + doxi-rules; these scanners are widely known


8

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.


7

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 ...


7

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 ...


7

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 ...


6

@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.


6

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 ...


5

Access log 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 ...


5

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 ...


5

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 ...


5

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: server { listen 443 default; server_name _; ssl on; ssl_certificate /path/to/fake.crt; ssl_certificate_key /path/to/fake.key; return 403; } And yes, it requires a nginx ...


5

(Much of this is based on my answer here) There are techniques, such as memory guard pages and wiping of deallocated memory, that should have stopped Heartbleed or a similar attack in the future. OpenBSD, for example, uses them by default. Heartbleed was made worse because it uses its own memory allocator that actively works to defeat memory protection. ...


5

Those log entries look like normal scanning activity. You can also notice that the scanner did not target your setup specifically, because multiple versions and directories are tried. And as you said, none of those actually exist in your setup. What I don't understand is, why does he use // rather than / That's likely a bug in their scanning software ...


5

I see some sites have blocked there port 80 (or 443) to be accessed by IP. My guess is that you mean that access to http://hostname works while http://ip-adress/ does not work. At the TCP level the host is still accessed by IP address but the HTTP request looks different because the name given in the URL is contained in the HTTP request, e.g. GET ...


5

Someone sent a request asking your server to fetch that image from Amazon, and your server interpreted it as a local file which it then failed to find (which is a good thing). They were probing for an open proxy, which would return any requested URL to them. This would let them visit any web site and as far as the site could tell the traffic would all come ...


4

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 ...


4

The greatest concern is that an attacker can use a temporary directory to store executable code, which is a useful foothold when exploiting your system. Almost always the /tmp has very open privileges, such that any process can write to them (chmod 777). As an example, I took advantage of this property of /tmp when bypassing AppArmor to obtain remote ...


4

4 exe files on my server were replaced with renamed versions of the same virus...My web server is running Ubuntu 10.4.3 Implies that you've already got file upload functionality on your server - which would be a good place to start looking for holes. I know that server, once compromised, is pretty much "gone" forever Not so. If you make adequate ...


4

I would also recommend using: ngx_http_limit_req_module to limit RPS, and fallback to 503 on burst cap hit optionally. It does very well with exploited zombie browsers DDoS; agressive caching for anonymous users (with next bullet applied maybe) and for target location (in case it is not random) to eliminate FastCGI passes; use power of LUA module and ...


4

If you connect to this site with your Web browser, it will show you what protocol versions and cipher suites are supported by that browser. Notably, Firefox does not seem to support (yet) TLS 1.1 and 1.2, so this prevents it from using any cipher suite ending in "_SHA256" because these are for TLS-1.2 only. If your server is accessible from the Internet, ...


4

Once an attacker gains control of a computer, you cannot trust anything on that computer; inspecting the computer cannot tell you with certainty what happened or is happening. Your best bet is to watch for the attacker's efforts to get data off of your network and onto a computer under his control. Monitor outgoing connections at the firewall to see if ...


4

It is as secure as the machine - which is probably to say "not very". But I don't believe the issue stems from doing just HTTP internally, that is fine. The problem comes from having a single, internet-facing machine that does everything. So if you are happy with the security of the machine then you are fine. Any attacker would need to be able to run a ...


4

In general, $DEFAULT_BRANCH (with no surrounding quotes) is the “split+glob” operator. What it does is: Take the value of the variable DEFAULT_BRANCH (or the empty string if the variable is unset). This is a string. Split the string at each whitespace sequence (assuming the default value of IFS). This produces a list of strings. For every element in the ...



Only top voted, non community-wiki answers of a minimum length are eligible