I've been reading the document on Application DDoS mitigation techniques using vulnerability signatures ( Application DDoS Mitigation ). I've been experimenting with the concept of "session limiting" bittorrent connections in this manner. I can't get my signature to match though. Guessing it is because I need to use a p2p context in the signature and not unknown? Is there any way to get this to work?
Or maybe some other technique that can be used to "session limit" bittorrent connections, not QoS using bandwidth statements.
From an ISP perspective it would be advantageous to be able to "session limit" bittorrent connections using PAN - i.e. limit amount of active bittorrent sessions per ISP customer source IP. Bittorrent connections from a hundred odd customers each with couple Mbps per WAN link floods the session table on the PAN at very very low throughput. Almost 90% of the time the session table is filled with 80% bittorrent connections ("show session all filter count yes application bittorrent").
Couple of thoughts for you:
You can reduce the session timeout values for the application "bittorrent"
You can assign a QOS tag value to the application and limit the amount of bandwith you want to allocate to it.
Since bittorrent uses a huge variety of ports it is hard if not impossible to use DOS protection rules to limit the number of concurrent sessions you would wish to allow. We do this for incoming smtp connections from high spamming countries, limiting how many smtp connections they collectively have. (works well.)
Thanks Phil. What about only allowing bittorrent on a set amount of ports (<customer src ip>:[50000-55000]) and then do DOS on that? Kinda forces the torrent clients into a manageable "space"? QoS will work to a certain extent. You can still hit extremely high session counts on very little bandwidth. For example I can saturate the session table on a PA3020 with a 100 x 1Mbps customers all running bittorrent. Even if you QoS it down to 50Mbps or less on the PAN. QoS will drop individual packets in a session, but the sessions will stay open which is the problem. I'll check into caching out the bittorrent sessions quicker. Very seldom that a session idles in bittorrent. Caching out the sessions earlier might increase the TCP chatter of the bittorrent protocol trying to reestablish closed sessions.
If I'm not mistaken, technically a custom vulnerability signature should work regardless of source and/or destination ports. Key variable here is source IP which is constant (customer). Basically a security rule is created with the application specified as "bittorrent". The packets are handed over for content checking (vulnerability profile) once the rule matches a bittorrent session. So the custom vulnerability signature only checks the packets for the pattern specified in the custom vulnerability signature. It does not look at ports at all in the signature. So the action of the custom vulnerability filter (combination) is based on how many times the pattern was seen in x amount of time. The missing ingredient is access to the p2p context in the pattern match criteria in the PAN Web interface.
Good idea on limiting bittorrent to a port range (outside your other outbound traffic). You can then define a custom service bittorrent-outbound which you can DOS limit per user. The other approach (vulnerability signature) may mean tinkering with packet captures to get the pattern that PAN OS uses to identify the App. You may want to put a ticket into support as the pattern we are looking for is the signature of the app. The other DOS approach would be to limit a user to "X" amount of concurrent connections regardless of the application. Normal users would be below the threshold so only the bittorrent users would be impacted. I am glad I don't have this issue to deal with as it presents some challenges.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!