Project

General

Profile

Actions

Feature #2127

closed

Rate Limiting by Tracking Both Source & Destination IP Addresses

Added by David Lam over 7 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Target version:
-
Effort:
medium
Difficulty:
medium
Label:

Description

When using Suricata to monitor inline router traffic, the current rate limiting features are limited in usability when both the source and destinations are unknown identities.
For example, if one was to run a guest network in the 10.0.0.0/8 range and allow these users to access the Internet, it would be very difficult to detect and thwart brute force like activities coming from the guest network because one would have to compromise on how the matching is performed.

Let say someone was running a script to continuously make connections to a popular website in order to try stolen credit card numbers. The script makes 30 new connections per second to the site over port 443 in order to determine what card numbers are potentially valid. To discourage this behavior, one may put in a rule that only allows a client to have 25 SYNs to any particular IP at port 443 in a period of 2 seconds, with a timeout of 30 seconds. However, the current ability is to track either by src or dst, which means if doing it by src I would have to make an educated guess as far as how many SYNs are appropriate for a client to make to the global Internet on port 443 given a particular source regardless of the destination, which is difficult to guess and is much more prone to false positives since a user could be running a lot of applications on the system which is contributing to the SYN load to various IPs on the Internet. On the other hand, tracking by dst is not very helpful either because if the brute force activities were against a popular destination, it will cause the whole network to lose access to that resource (e.g. Gmail).

Hence it would be very helpful if one can track by_both, where both src-dst are used as a pair for the rule rate limits in order to accomplish what I mentioned above. The use case can also be applied to other types of activities, such as port scans, SSH brute force, SYN floods, etc., and the implementation could be used as an effective tool to reduce the number of abuse complaints to the network administrator.

Actions #1

Updated by Victor Julien over 7 years ago

  • Target version set to TBD

I think this would be useful. Implementation shouldn't be terrible hard either, as we already have the 'ip pair' table. It's very similar to how we already implemented the per 'host' support.

Any takers?

Actions #2

Updated by Andreas Herz over 7 years ago

  • Assignee set to Anonymous
Actions #3

Updated by Ruslan Usmanov about 7 years ago

I want to implement it, will create pull request soon.

Actions #6

Updated by Victor Julien over 6 years ago

  • Effort set to medium
  • Difficulty set to medium
Actions #7

Updated by Andreas Herz almost 6 years ago

  • Assignee set to Community Ticket
Actions #8

Updated by Victor Julien about 5 years ago

  • Status changed from New to Closed
  • Assignee changed from Community Ticket to Ruslan Usmanov
  • Target version deleted (TBD)
Actions #9

Updated by David Lam about 5 years ago

Is this now implemented somewhere?

Actions

Also available in: Atom PDF