Tag Info

Hot answers tagged

26

These types of spurious requests are very, very common. They are either looking to see if you are already compromised, or looking to get your server to throw an error to gather info about your server (from error messages). You aren't the only one: http://shadow.wolvesincalifornia.org/awstats/data/awstats092014.shadow.wolvesincalifornia.org.txt # URL with ...


12

The attacker tries to find out if you have certain premade web software installed by requesting files which are typical for them. When they find out you use, say, wordpress or phpbb or mediawiki, they can then try to use exploits specific to these applications to take over your site. The best countermeasure against this is to avoid installing too much ...


10

Yes, those are scans. If you Google those strings you will see that they show up in the web logs of numerous sites throughout the Internet, usually cheap webhost sites which put their logs up where Google can see them. This is sufficient indication that some tool is trolling for that URL. There is not enough information to indicate what the scan is ...


4

You seem to be asking: Is it possible to reverse engineer Javascript malware Yes. And you don't need acces to the server to do that. However it is possible for the malware author to make it more difficult to do so. I won't enumerate the potential methods here - they are (mostly) well described elsewhere. Most attackers don't bother with such sophistication ...


4

This virus alert is a scam. The goal is to get admins to download and execute special "removal tools", which are in fact the actual virus. Another note about how websites work and what you see in the access log: You can go to basically every website and append arbitrary parameters like ?cmd=foo&key=bar and the website will just load and ignore the ...


3

As freddyb said, this seems to be a scam. I looked at the "removal tool" for the virus - it contains an executable that forks off into the background, renames itself to udevd, connects to 95.215.44.195:443 (that server seems to be down atm), sends the string FOG\n\n# and gives the server a reverse shell (by dup()ing the socket to fds 0,1,2, then executing ...


3

The attacker had access to all other virtualhosts (what you call "domains") because they all run under the www-data user, once he got this user's privileges he could access all the other domains. To mitigate this you can use mod_privileges on Apache to run each virtualhost under a different user account, and make each virtualhost use a different PHP-FPM ...


3

As long as the machine in question has enough entropy to generate strongly random keys and nonces, that's totally correct. The key must never leave that server. Even more, if I were working on a critical application, I wouldn't even trust that machine and keep the key in a HSM. It might cost a lost, but it significantly enhances the security. There is a ...


3

Is your system publicly accessible? Yes: Someone is probably scanning it. No: Are you scanning the server? Yes: Well, you've just answered your own question now haven't you? No: It's probably not getting scanned. I don't know: Wait... what? I don't know: You've got bigger problems. And yes, you're probably getting scanned.


3

Your computer has been rooted if an unauthorized user (how defined? becomes difficult on systems with many accounts) has gained access to it. If JoeUser is an account with little access to anything of importance (how defined? by whom? how is importance level tracked?) nothing much might be lost, but any unauthorized (ie, hostile) access has the potential for ...


3

First point: Once your server is on-line, it will be found (even without any DNS name) by robots scanning all possible IP numbers. There are several possibilities to restrict access to your web server, including: Protect the web server with username and password (basic autentification) Configure the web server such that only trusted IP numbers (or IP ...


2

How about adding basic credentials to your webserver? So it's only accessible to people who have the credentials. Or maybe you can consider to use client side SSL certificate so only authorized user can access your webserver. At least you won't messing up with the network or firewall configurations, in case there will be some issue regarding it. This ...


2

L2 is also vulnerable if everyone can access your home server using public IP (if you have one). As long as you set up a home server only using private IP (NAT), it will be accessible only to people who connected to your network, but including people who use your wi-fi since they are in a same router. If it's your only option, just make sure that your wi-fi ...


2

Certificates establish authentication (tying a person to an identity), which is the wrong approach to limit access to b.example.com - a user is still themselves on both sites, and all authentication's concerned with is having them prove their identity. Limiting access is authorization, which you should do on your end by actually checking the ID contained in ...


1

As soon as you deploy your client to a device you cannot fully control, there is no way to be absolutely sure anyone can tamper with the requests. What you can do though is put some measures in place that will require work from the attacker, for example, you could encrypt and/or sign your data using embedded keys in the application. In order to send data ...


1

It looks like that's trying to communicate with a previously-installed program. I'd guess (from cmd=info) that it's trying to see if install was completed. ip=1.2.3.4 (which I assume is your IP anonymized) is telling it what IP it is trying to talk to, in case the traffic would come back from another IP. It's probably nothing, just a scanner for some bit ...


1

Either your web server is internet-accessible somehow or these are bogus-requests; you should check the access logs on your web server, if it doesn't show up there, then it's an issue with GA. BTW, we have some servers in a datacenter in $someplace in western europe that shows up on GeoIP-matches as russian IPs, which gave us a huge "YIKES!!!!!!!! ...


1

If you are running a web sever, you might also want to set up a honeypot in your web application and trap automated scans. This can be done by configuring a section of your site, and disallow it in robots.txt. Any automated scans will ignore this, and will actually try to scan it. Any IPs accessing the disallowed area can be blacklisted using fail2ban for ...


1

As new vulnerabilities are discovered and browsers are upgraded, the answers here can (will) become outdated. I'd suggest you rely on the Mozilla SSL Configuration Generator to check which configuration you should use.


1

For the scenario you have described in your question and comments, you would be completing PCI-DSS v3 self assessment SAQ A-EP. It does seem somewhat unfair if not poorly thought out that a 46 page form is required even when as in your case, the entire cardholder data environment is outsourced and all you do is redirect customers to the payment acceptance ...


1

The pro's: Encrypting the database will ensure that should the database files be leaked they will be inaccessible by the attacker or any other party they are shared with (given the attacker did not also obtain the key/password/user privileges). This means if the server is stolen or old backups are lost or the database files are obtained otherwise the data ...


1

If you have shown the stakeholders the risk and they have decided to accept the risk as "not likely", then the decision is out of your hands. You need to continue to educate, educate, educate, but you need to understand that it is management's job to manage the costs and risks to the company. InfoSec's job is to serve the company, even if the decisions the ...


1

If L1 becomes compromised then the attacker is inside your network, and yes any other device connected to the same network (be it via WiFi, Wired, whatever) is vulnerable to some sort of attack. What that attack may be is then dependent on what ports are open on L2, and what software versions it's using. But in general it's safe to assume that if L1 is ...


1

A common vector for this type of attack is to modify the .htaccess file to include a auto append statement for php. Otherwise I suspect it's located in your database as it appears to trigger after your content is loaded.



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