3

On my website I added a little function, that logs IP, client/browser information, path, and a time stamp.

Today I checked my database, and I had a lot of weird requests.

Here are a few of them:

enter image description here enter image description here enter image description here

Does anybody else have similar issues, and should I be worried?

1
  • 4
    If you have a page on the internet, you must expect that some people are trying to hack you. There are many automated scripts around that are just probing for weaknesses.
    – Beat
    Nov 7, 2015 at 12:01

3 Answers 3

7

You don't need to be worried, unless your setup is insecure.

The first requests search for a proxy judge such as http://azenv.net/. The second table shows vulnerability scanners searching for incorrectly configured or outdated applications. This is quite normal "noise" and effects almost any dedicated server IP.

You could try to block them, but there are so many that it's not worth the effort. Just make sure that any login page has a reasonable limit on the maximum login attempts in a given time and that your software is uptodate. Also things like phpmyadmin shouldn't be publicly accessible.

1
  • All setups are potentially insecure, it just takes more time and money to find the vulnerabilities in some systems than others. It's a bad advise to assume security, or to neglect worrying on the basis of baseless confidence.
    – dig
    Apr 3, 2018 at 15:38
3

lot of bots are scanning for server breach, and lot of website are exposed to thoose kind of attacks, most of the time the solutions are simple :

  • using complex password (the best is to use spécial chars like ¥,§,À,±,..)
  • having a system up to date (and CMS too)
  • trying to avoid third component
  • using a firewall to open only used incoming port
  • closing database access to internet
  • using ip restriction for sensibles administration tool
  • using a log tool

Thoose are commons bots attacks:

brute force

this is method try to find login access by sending login request then testing the result, as long as result is not logged in, it retry another combinaison of login/password until access is granted

mainly aimed on internet:

  • FTP (usualy port 21)
  • SSH (usualy port 22)
  • TS (usualy port 3389)
  • Web site login pages (usualy port 80 & 443)

to prevent this kind of attacks:

  • (if possible) changing default port
  • having a complex password
  • trying to avoid use of basic login name (admin/root/administrator,...)
  • having a "fail attempt" temporizer, like that it will take too much time to find the good login/password combinaison.

you need to know the first phase of this kind of attacks on website, is to find which web tools you use (CMS name,phpmyadmin,...), once found brute force can start. For application it is easier a simple port scan find wich system tool are used.

Today most of system tool are enougth secure against this kind of attacks, that s why nowaday they focus on website.

known security breach

lot of people are using open sources CMS, as it is open source code can be exploited. All the time breach are found and securised by the dev, but not all server admin do updates. So once a breach is fixed, breach become known to the public (as Heartbleed, Poodler, ...). Each time Bots are updated with thoose new informations, looking for site exposed to vulnerability.

to prevent this kind of attacks:

  • having a (well) self made site
  • getting your system (and web tools) up to date
  • not using default folder names
  • reading doc on how to secure your CMS, your exposed content, and your code
  • blocking strange requests to prevent attacks before attemps with your server configuration.

this is an exemple of blocking rules for apache server:

<Directory />
#Block user agent empty or with suspicious values
RewriteCond %{HTTP_USER_AGENT} ^-?$|\\x.*?\\x|perl|python [NC,OR]
#Block default folders (optional, but prevent 404 logs)
RewriteCond %{REQUEST_URI} MyAdmin|\/pma\/|\/phpmyadmin| [NC,OR]
#Limit request to thoose requiered
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$ [OR]
#blocking request who not start by /
RewriteCond %{REQUEST_URI} !^/
#all thoose redirect to the error code you want, i like to use 406 in my case
RewriteRule .* - [END,R=406]
</Directory>

like that most of bots are blocked before being able to test your website breach.

By the way if you keep an eye on logs and security annoncement, you can update rules to increase your bots protections.

Bonus For coders

do not fear bots or hackers, most of the time there s only 4 main things to secure:

  • login pages
  • code injection
  • upload pages
  • cross server

don't forget backups, it can be helpfull !

2

Yes, it looks like somebody is rattling your website's metaphorical doorknobs. It's common on the modern Internet, there are many automated tools for doing it, and little you can do to prevent it besides blocking the bastards. In particular, it looks like an automated tool is checking whether your webspace might include certain administrative tools whose past versions have known vulnerabilities. Such tools are a common attack surface for future penetration attempts.

You should generally not presume the attack is specifically targeted against your website until there are specific reasons to think otherwise. It is also highly likely that you will not be able to make a good attribution by checking out the owner of the IP address (which you may nevertheless want to do); most automated vulnerability scanning comes from botnets running on zombified PCs (and IOT nodes) these days. If you feel polite, if the traffic is particularly high, or if you happen to know whoever is behind the IP addresses, you might want to send them a letter about it; oftentimes, the local system administrator doesn't even know that some of their computers have become zombies. But it's a bit of work and many people don't feel it's worth the hassle. Besides, there are many administrators who don't know about zombies on their network because they don't care.

You might want to consider mitigation techniques such as automated lock-out when bursts of unwanted activity seems to originate from a single IP address or network range. Consider, however, that in some cases, you might find strange bots trawling your website a good thing. A canonical example is ensuring that search engines know about the wondrous goods your e-commerce website might have to offer. Also consider the scenarios under which such lock-out rules might detect false positives and get in the way of legitimate traffic.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .