Tourniquet iRule to detect, BLOCK, log, and count CVE-2016-9244 "Ticketbleed" attacks
Problem this snippet solves: This iApp installs the Tourniquet iRule ir-tourniquet which will detect, block, log, and count attempts to exploit CVE-2016-9244 "Ticketbleed". Attach the Tourniquet iRule to any TCP+TLS or UDP+DTLS virtual server with a Client SSL Profile. (The iRule works on BIG-IP TMOS v11.0 and above.) The Tourniquet iRule logs the source IP address and geolocation of each possible attack and counts attacks (per-virtual-server) using iStats. The Tourniquet iRule is for anyone (such as a honeypot operator) who wants to log the sources of Ticketbleed attacks and for BIG-IP users who want to utilize RFC-5077 TLS Session Tickets while still running vulnerable (older) versions of BIG-IP TMOS (by blocking Ticketbleed attacks, the Tourniquet iRule makes it safe to enable Session Tickets). NOTE: The best way to avoid the CVE-2016-9244 Ticketbleed vulnerability is to upgrade BIG-IP TMOS to a non-vulnerable version. See F5 Solution Note K05121675. The second-best way (imposing a modest performance cost) is to disable Session Tickets in your Client SSL Profile(s). The performance cost of the Tourniquet iRule is very small unless an attacker tries to flood your BIG-IP with Ticketbleed attacks. In that case, the Tourniquet iRule will at least help you track the attacker down. The Tourniquet iRule blocks Ticketbleed attacks on vulnerable versions of BIG-IP TMOS. It also has an option to log Ticketbleed attacks then allow them to proceed, if you really want to do that. How to use this snippet: Download the Tourniquet-iRule-v1.zip file (below). Extract (unzip) the Tourniquet-iRule-v1.tmpl file. In the BIG-IP Management GUI, navigate to iApps / Templates. Click Import, browse to select the template file, then click Upload. Navigate to iApps / Application Services. Click Create, then enter a unique name (for example, t ) and select the template Tourniquet_iRule . Click Finished. The Tourniquet iRule ir-tourniquet will be created (in an Application folder, for example as /Common/t.app/ir-tourniquet ). You may then navigate to Local Traffic / Virtual Servers, edit your virtual servers that have Client SSL Profiles, and add the Tourniquet iRule to each virtual server in the iRules section of the Resources tab. (If you really want to allow Ticketbleed attacks for some reason (making your BIG-IP insecure!), you can change the relevant setting in the iApp then click Finished to update the iRule.) Code : 73863DTLS v1.2 Availibility
I was looking at the ciphers available in v13 and I notice that none of them show DTLSv1.2 compatibility. Which seems odd since DTLSv1.2 is based on the same RFC as TLSv1.2 and there are plenty of ciphers to support TLSv1.2. I would expect to see some of the TLSv1.2 ciphers available to support DTLSv1.2. So I'm a little curious to know if we can use DTLSv1.2 and what the magic cipher is, or if anyone has heard about F5 putting out support for it in the near future.
Slow Speed through APM SSL VPN Even With DTLS
Hello everyone! So I'm currently troubleshooting slow speeds through my APM SSL VPN. I ran a bandwidth test for each scenario and got the following results: Client Local Site (No VPN): Down: 837,53 Mbit/s Up: 840,39 Mbit/s MS: 1,12 Client on remote site going through the same BIG-IP but through a forwarding VIP (No VPN) Down: 81,64 MBit/s Up: 76,24 Mbit/s MS: 13,26 Client using F5 APM SSL VPN Down: 20,01 MBit/s Up: 25,15 Mbit/s MS: 29,88 Determined through these tests, the ISP I'm connected to does not have any bandwidth limitation, the BIG-IP I'm sending the traffic through is not limited in bandwidth. I accept that there are some performance loss due to the encrypted tunnel, but these numbers indicate that I have lost: Down: 75% loss Up: 68% loss MS: 100% increase I read some threads on DC regarding this and the solution for many has been DTLS. So I configured it and ran some new tests: Down: 24,95 MBit/s Up: 23,04 Mbit/s MS: 29,88 So the results are pretty much the same. I disregarded the bandwidth test and tried a file download instead. Using my local connection I got 2-3MB/sec but on the VPN (using both TLS 1.2 and DTLS) I got 300KB/sec so around 2,4 Mbit/sec. The BIG-IP I'm using is a VE provisioned with 1Gig license and in that location I'm running a 100Mbit ISP line. Getting a 2,4 Mbit/sec download through the tunnel is really bad. I tried to tweak the TCP profiles and play with the compression settings but I still get the same results. I'm running version TMOS 12.1.3.4. Do you have any suggestions?
DTLS not getting any traffic
trying to figure out why in my APM - SSLVPN configuration no traffic is hitting DTLS virtual :: environment is as follows : First termination point : https virtual --> ssl offloading --> Access policy --> connectivity profile --> User connects succesfully --> establishes vpn tunnel interfaces - works fine second virtual server : listens on estabished vpn tunnel --> does IP forwarding for all vpn IPs through snatpool IP -> working fine. I see hits. 3rd virtual servers : dtls (udp 4433) virtual server -> basically terminates dtls forwarding. However for some reason the dtls is not getting any traffic. The connection profile has the DTLS checkbox already checked.
DTLS not working anymore after upgrade to 14.1.0.3 Build 0.0.6 Point Release 3
Hi, I have a F5 running in AWS. It was initially spun up with Version 14.0.0.1-0.0.2. I configured SSL VPN with DTLS. It was working fine till I updated to Version 14.1.0.3-0.0.6. I didn't change any config. It just falls back to TLSv1.2. I can't find anything in the logs. When I boot back into Version 14.0.0.1-0.0.2 DTLS is working again. I also spun up a new instance directly on 14.1.0.3-0.0.6. No DTLS working either. Anyone also experienced this issue with this Version?