Hot answers tagged nginx
16
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 ...
6
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 ...
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 ...
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 ...
2
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 ...
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
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 ...
1
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
1
You need to configure django to generate either
https://domain/path links with the https: scheme,
//domain/path links with no scheme (the browser will interpret these as having the same scheme as the page it's currently opened to), or
/path links with no scheme or domain (the browser will interpret these as having the same scheme and domain as the page ...
Only top voted, non community-wiki answers of a minimum length are eligible
