8

We've found a number of attempts to access non-existent pages in our IIS logs, specifically a lot of variations on phpMyAdmin URLs.

My kneejerk reaction would be to block these IPs, but I have a feeling this is not really a "solution" since the likelihood of multiple attacks from the same IP address are pretty low.

So, is there a best practice here? Should we just ignore them? Should we use some third party tool (I've seen Snort and OSSEC mentioned on this site) to prevent these attempts?

JNK
  • 183
  • 6

3 Answers3

20

I ignore them. There will always be compromised systems continually scanning the entire Internet for arbitrary vulnerabilities. Trying to block them is no more effective than spitting into the wind. You'll get far more value out of focusing on the security of your servers and applications, and keeping an eye out for attackers who seem to specifically target you. Chasing the bots and automated scanners will only waste your time.

Xander
  • 35,525
  • 27
  • 113
  • 141
  • 1
    The more I thought it through the more I thought this was the likely best course, but I'm not an expert so it made sense to ask. – JNK Dec 01 '14 at 16:10
  • 5
    I disagree - log those IPs at least. If they escalate, you'll have important recon phase data to help you understand the context of the later attack. Otherwise, yeah, there is no need to mount an active response. – schroeder Dec 01 '14 at 18:28
  • 4
    @schroeder Since the attempts are being discovered in logs, my take is that logging is a foregone conclusion. – Xander Dec 01 '14 at 19:51
  • I agree with Xander; keep your system up to date and ignore the hordes of automated vulnerability scans. Nonetheless, if you still wish to be proactive, you can install software that recognises vulnerability scans and deliberately blocks those requesting them at firewall level. On Unix/Linux systems, [fail2ban](https://en.wikipedia.org/wiki/Fail2ban) can do this. I'm not sure what software exists to do this in Windows. A quick search lists "RdpGuard" and "IPBan" as Windows alternatives, but I don't know if they have the same level of configurability as fail2ban. – Stuart Caie Dec 02 '14 at 12:31
3

TLDR: Scan your systems first and build & configure them to be secure. Then continue scanning your systems for vulns and signs of breaches, and build a secure lifecycle.

The scans demonstrate that someone, somewhere, is trying to learn about your systems ostensibly to break in. Assuming that you (and your organization) value the servers and/or what they host, you should find problems in your systems before the bad guys. Scanning is relatively cheap and easy, and will let you find low hanging fruit just like the bad guys. If you find and fix issues faster than they can use them against you, you're in good shape. If you can detect breaches, isolate and recover before the attacker gets sensitive info, you're still on good shape.

The thing is, scanners are all different, and no scanner is panacea. This means that (a) the attacker's scanner may find issues yours doesn't and (b) a dedicated attacker may use more advanced techniques to break into your systems. This means you need to balance the value of the assets against how much you need to spend protecting them. You will need to develop a lifecycle that ensures systems and software are sufficiently secure for your needs, and are maintained to remain sufficiently secure.

  • You may decide that your systems are entirely 3rd party provided, by a hosted provider and that you trust the provider to keep it secure. Make sure you have insurance and contracts that shift liability away from yourself.
  • you may exclusively use 3rd party software in your own environment, or your own systems within a hosted environment, and decide that you trust the manufacturers to announce and fix vulnerabilities. You may need an inventory of components and a way to monitor for new vulnerabilities, and a process to periodically push and test patches while maintaining your own up time. You may also need to introduce intrusion prevention and intrusion detection systems, malware scanning, audit processes, etc.
  • you may write your own software, in which case you may want a secure development lifecycle, including things like web app scanning, malware scanning, static code analysis, fuzzing, qa security testing, penetration testing, threat modeling, etc.
  • you may decide that you really don't care what happens to the system, even if the attacker takes it over, kicks you out, and starts serving content that could get you thrown in jail. In this case, you wouldn't need to do anything.
atk
  • 2,156
  • 14
  • 15
1

Make sure that these attempts won't become a DoS attack when you're under load. Attempting to access a phpMyAdmin page should fail quickly when it's obviously a vulnerability scan (especially if you don't actually use it). Some kind of blacklist of shady GET parameters would do the trick.

IslandUsurper
  • 11
  • 2