1

Assume there are two internet users (A and B) that connect to the internet from the same gateway by using NAT. That means they use same IP address while passing through our firewall. Now assume we detect illegal traffic (such as DDoS) from this gateway and the attacker is user A.

In this case, is it possible to block only user A so that innocent user B can continue to connect to servers behind our firewall? Surely we can not achieve this by IP blocking. If possible, which options do I have to do that?

To clarify, I added a network topology.

enter image description here

  • You need to mark on the diagram where you are standing... – Graham Hill Apr 25 '14 at 16:03
  • 1
    I am the firewall as I clearly mention in the question – ibrahim Apr 28 '14 at 6:11
1

In the general case, no.

In some specific cases, you can. For example, if you're running a webserver and the gateway's NAT modifies HTTP requests to include an "X-Forwarded-For" header, you can use the XFF header to distinguish and block individual computers (assuming, of course, that the gateway is honest).

  • ... I wouldn't recommend configs that include XFF being seen on the outside. I'm not sure anyone should, which may limit how common this is. – pacifist Apr 29 '14 at 1:47
0

If you could reliably detect the source port being used, you could block all traffic from that source port. Often, NAT differentiates between users by port. The problem is that the source ports can change, so you'd have to detect the attack traffic solely by a changing identifier.

  • dont think that's going to work; each session gets its own port. The user needs only start another session. – pacifist Apr 29 '14 at 1:45
  • As I mentioned. But if the unwanted traffic remains on a single port, you can filter by that port. – schroeder Apr 29 '14 at 14:13
  • ...that's just not even remotely a practical strategy. It'll be a new session for nearly every page someone visits. Figuring out which sessions are from user A or B would be problematic. – pacifist May 6 '14 at 1:35
  • @pacifist unless you could identify the unwanted traffic in real time, which is practical (called an IPS). – schroeder May 6 '14 at 5:06
  • ... and how are you going to use an IPS exactly to identify who's traffic it is, at server side?.. It seems that you don't understand the problem. If the user isn't doing anything authenticated (spoiler - it's not - he mentioned DDoS), and user A is able to spoof B's useragent/headers/whatever else there is no way systemically figure out which sessions are legitimate, whether you're a person or an IPS. That's what I meant by impractical. What magical rule were you going to use, pray tell? At best you can fight a losing arms race identifying key features of the attack. – pacifist May 6 '14 at 5:33
0

I agree with Mark; in the general case no.

You can 'try' to do it using features specific to a user (UserAgent differences/XFF/whatever else) but none of such features are reliable, and most are trivially changed by the user.

Depending on how you're doing it you might actually expose yourself to resource exhaustion attacks if people spoof a million XFF or UA strings etc to see what your system does.... and your system then tries to store & log all that.

0

There is one solution, but I do not know if it is viable in your case as I do not have the entire picture: client-side certificates.

Simply put, you'll need an application firewall and to move SSL validation on the perimeter. If the client is authorised, they have access. If not (and by default) they are blocked.

Obviously this opens up another can of worms as you'll have to manage certificates, keep your revocation list up to date, etc.

Also, as others have suggested, you risk to become a victim of a resource exhaustion attack. At this point it's worth considering if the cost of setting up an architecture like the one I described above might be more than just scaling your server or moving it to a more capable provider, perhaps one of those with DDoS "protection".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.