Tag Info

Hot answers tagged

30

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


28

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


21

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


10

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


9

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


9

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


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.


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

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


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

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

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


3

As of today (August 2013), known weaknesses of MD5 have no impact whatsoever on the security of SSL/TLS. Issues with MD5 may induce problems with X.509 certificates, but this is a CA business and is unrelated to your choice of cipher suites. In that respect, RC4 is actually weaker than MD5. RC4 induces measurable biases, which very rarely have any ...


3

You can do this but the moment your app grows larger and needs ssl offloading it will break. Also take care about the length as you are exposing a part of the ssl session id which is responsible for protecting your CIA. If you would take a too large part of the Id or all of it and an attacker would be able to get it through xss, it could also break your ssl ...


3

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


3

A common setup will have you forwarding https traffic from your webserver (i.e. Nginx) to a local http server running the Django app. In this case it will be easier to use the SECURE_PROXY_SSL_HEADER setting (available since Django 1.4.) https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SECURE_PROXY_SSL_HEADER


3

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


3

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


3

There's no isolation (from a security perspective) between server blocks -- server blocks only exist as a namespace for related directives. Nginx can only have a single user configured, as it becomes that user just after binding to network sockets (which requires root to bind to ports < 1024). What you can do, and what I have done in the past, is run ...


3

Most browsers have a limit on how many cookies they'll store for a single TLD. So, if the server is configured to allow a sufficiently large request to include all these cookies, the requests won't be rejected anymore. Apache has options like LimitRequestFields, LimitRequestFieldSize, etc. Setting these sufficiently high should allow the request to be ...


2

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


2

It may have security implications if other users on the box have access to the box's tmp folder. If others have access they may read the tmp folder, extract a session id then hijack it. The tmp folder should be limited to only the webserver.


2

I think what you're looking for is a Django middleware that will rewrite http to https. Something similar to what is addressed in this question on SO, where one answer points to this middleware. You'll probably have to write your own middleware, but it should be straightforward. (A well-focused question on SO will get you pointed in the right direction if ...


2

Redirecting from any http:// to the corresponding https:// page is the wrong approach. Configure nginx to redirect port 80 to https://yourdomain.ext/ server { listen 80; rewrite ^/? https://$host/ permanent; } or similar (check the next nginx manual near you) and do not run your application at all on port 80 (http). So, other requests on ...


2

The Amazon Cloudfront documentation says that they only support the AES128-SHA1 and RC4-MD5 ciphers. Try enabling AES128-SHA1 - while not as good as AES256, it's better than RC4. http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html


2

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


2

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.



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