Why bother with attack detection?

Question

The question below goes from a wrong assumption that attacker is able to spoof IP when making HTTP connection. But attacker isn't able to spoof IP if he doesn't have direct access to connection between server and this client

---

Many security engineers advise setting up attack detection layer. The main suggested components are logging all security events and setting up IDS and SIEM.

Here are the main activities that are made possible after setting up attack detection using logging, IDS and SIEM. My comments why they seem not efficient are also below.

1. Block attacker
   We may block requests that look malicious. But request detection will likely to be error-prone and many malicious-like requests will still go through detection layer.
   We may block attacker's IP. But IMO it will be harmful. Attacker is able to spoof IP and send requests from IPs of legitimate users. Blocking those IPs will make IP DoS (like Account DoS, but IP).
   Edit: @schroeder said that blocking attacker's IP, even if spoofed, is a needed action. However, attacker is able to flood server with various malicious-like requests. I can't block all of them as they are too different and any IDS will have false negatives. I can't block IPs of those requests as after it legitimate users will be blocked. Also attacker may block a certain user if he knows his IP by sending malicious requests from spoofed IP. That's why I think that IPs shouldn't be blocked if requests look malicious. I think IPs should be blocked only in case of DDoS as I need to block someone to have app available to legitimate users.

2. Engage legal action after compromise
   In the case of a hack, the reputation of the app will be undermined. Legal action won't get back reputation and lost revenue. It may be hard to go into court if attacker is from another country. It won't give any profit except showing "Don't break us anymore".

3. Send report to attacker's ISP
   It has the same problems as item 1 as attacker is able to send requests from tons of spoofed IPs. Sending report is impossible as we don't know whether those requests came from actual IP or from spoofed one. It will be impossible to find actual attacker's IP from those

4. Review logs to find out attack vectors and close holes if they exist
   But I doubt that reviewing logs can help to find out security holes. Virtual patching is implemented using WAF, not IDS

5. Generating a lot of statistics and baselines. But IMO it won't help to secure app.

So IMO detecting attacks does not seem to be effective. What did I miss?

Answer 1

You would be surprised how common it is to detect an attack, send an attack report to the company whose IP address the attack comes from, and get a response back reporting that the compromised machine has been quarantined thanks to your report. Part of being a good network citizen is helping other administrators to detect and respond to compromised systems so that they don't continue to do harm.

Answer 2

IP Blocking

Blocking an IP based on pattern may not be as bad as you think. You can block the pattern without blocking the IP, for instance (block xmas tree scans, invalid packets, invalid states), which a benign host would never be sending. These patterns would not affect normal traffic to a site from the same IP.

If an attacker is attacking your application, and you can detect it, then you need to shut them down, and it does not matter if they have spoofed an IP or not. But, consider what types of attacks you are worried about. You might choose to permit probes, but interactive attacks need to be dealt with, and those are hard to spoof.

You also have to weigh the impact of blocking a few IPs against being able to serve many other IPs. A DoS from a dozen IPs, even if spoofed, needs to be blocked or no one will be able to access the application.

Error-prone Detection

There is a process of tuning your IDS to reduce false negatives and false positives, but that is normal.

More than Blocking

One of the other reasons to identify patterns is to determine ways in which the application and the server infrastructure needs to be improved in order to prevent compromise. Perhaps a new input filter needs to be installed or a logic flow needs to be strengthened. By reviewing IDS logs, you can identify and mitigate those kinds of things.

Not the Whole Story

Logs are the start of the story, not the end. You need to review, analyze and take action as a result of the info. And it is then that you get your long term benefits of logging and detecting attacks.

Answer 3

As David Schwartz says, all you really know about the attack (initially) is the IP address it came from - and that's usually going to be another victim of the same black hat.

Over the past couple of years I've seen an increase in the amount of probing for open HTTP proxies, to the point where it's now greater than ssh probes. Historically the problem was with mail relays - but fortunately most people have learnt to configure their MTAs properly and there are protocols and techniques in wide spread usage to prevent abuse.

So, yes, telling people thay've likely been hacked and are being used to proxy attacks is good practice.

(the extent to which people should be accountable for damage done by a third party using their computers is an interesting argument - but possibly a bit off-topic in reply to this post).

But you don't have to wait for everyone else to catch up to benefit from monitoring attacks. Shutting the door immediately on such attacks merely makes the attacker aware that you have detected them, if they are determined they'll just come back via a different route. There's also a risk of false-positives - losing legitimate customers. For some organisations this can be very important - far more important than just the loss of their business.

OTOH, one should not let an attacker do whatever they want with impunity. Having identified a potential attack, you then have the ability to identify how they compromised your defences, and more importantly what data they are changing. So, except in the case where the attacker's objective is to extract data from your systems, you should be able to undo the changes, stop payments / orders going out of the door, reverse defacements etc.

Yes, it's really difficult to pursue legal remedies across jurisdictions, but there's still benefits to managing your defences.