Tag Info

Hot answers tagged

24

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


16

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


9

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


8

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


7

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


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


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


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


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

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


2

Re-purposing crypto datapoints for other purposes is one of the capital sins of data security. There is no logical reason to do what you are suggesting. And whether or not a specific vulnerability for what you are suggesting is immediately available, it's still a bad idea. Just use a random value, which is the known, vetted, accepted approach. Otherwise ...


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

The point about "destructive GET" is that attackers may make some victim users unwillingly send such "GET" requests. This is simple: the attacker just has to include, on his Web site, an <img> tag pointing at the target URL. The victim's browser will then perform the fateful GET. That normal requests come from an application, and not a browser, does ...


2

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


2

OpenSSL naturally will prefer newer MACs for otherwise-equivalent cipher suites. For example, the lengthy openssl ciphers -v output for your cipher string starts with: ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ...


1

for best compatibility the cloudflare-cipher-suite is not the best; i found the following better: # suggestion from sslabs / including PFS, good compatibility #ssl_ciphers ...


1

If you're worried about security you could use the naxsi module with nginx and catch such attempts a bit more explicitely with rules. I'm pretty happy with it - it's fast and lightweight. https://github.com/nbs-system/naxsi


1

First of, make sure that you have the mime.types properly setup in your config file (http://wiki.nginx.org/FullExample#mime_types), so a foo.php.jpg is still treated as an image. Also, use the tilde-asterisk (~*) instead of just the tilde (~), this will make your regex case insensitive (and thus prevent files like blah.pHP and evil.PHp, ...): location ~* ...


1

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


1

Just to add to Thomas Pornin's answer, GET requests are subject to caching by proxy servers so you can't 100% guarantee that a GET request will make it to the target server and not get the response from a proxy. Yes you can add headers to specify that there is to be no caching, but not every proxy abides by the rules. Isn't it easier to use best practise and ...


1

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


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