F5 BIG-IP iRule based TCL DNS server
Short Description This code is for the purpose if there is a need to return a custom DNS reply not from the main DNS server but from the F5 Virtual Server. Problem solved by this Code Snippet The code is meant for small lab or dev environments as F5 has F5 DNS/GTM for replying to DNS requests with Intelligent Load Balancing, DNS Express Memory cache etc. How to use this Code Snippet Modify the irule code to configure the custom domain you want replies from the irule code and not the real DNS server. Add the irule to a DNS UDP LB Code Snippet Meta Information Version: 17.1 Coding Language: TCL Code You can find the code and further documentation in my GitHub repository: irule_dns/irule1 at main · Nikoolayy1/irule_dns (github.com)DNS Query Name Parsing iRule
Problem this snippet solves: This iRule will extract the DNS Query Name in the absence of a DNS profile being applied to a Virtual Server. How to use this snippet: # This is a shameless rip from an old Devcentral post DNS Hostname Parsing iRule that, to the best of my knowledge, never made it to a Code Share. To use this code, simply apply this to a UDP Virtual Server that processes DNS traffic. (No DNS Profile necessary). Code : when FLOW_INIT { #extract QNAME from QUESTION header #${i} is a sanity check so this logic won't spin on invalid QNAMEs set i 0 #initialize our position in the QNAME parsing and the text QNAME set offset 12 set length 1 set endlength 1 set name "" #/extract QNAME from QUESTION header while {${length} > 0 && ${i} < 10} { #length contains the first part length binary scan [string range [DATAGRAM::udp payload] ${offset} ${offset}]] c foo #make the length an unsigned integer set length [expr {${foo} & 0xff}] if {${length} > 0} { #grab a part and put it in our text QNAME section append name [string range [DATAGRAM::udp payload] [expr {${offset} + 1}] [expr {${offset} + ${length}}]] #Watch the DNS QNAME get built during the loop. Remove the following line for production use. log local0.info "BUILDING DNS NAME: [IP::client_addr] queried ${name} offset ${offset} length ${length}" #grab a part and put it in our text QNAME section set offset [expr {${offset} + ${length} +1}] #endlength contains the Last part length binary scan [string range [DATAGRAM::udp payload] ${offset} ${offset}]] c foo #make the length an unsigned integer set endlength [expr {${foo} & 0xff}] if { ${endlength} > 0} { #put a dot between parts like a normal DNS name append name "." } incr i } } #/extract QNAME from QUESTION header #Input the required action here, where "${name}" is the variable that is reviewed for decision making. #Sample action would be a pool statement. The below log statement should be removed for production use. log local0.info "FINAL DNS NAME: [IP::client_addr] queried ${name}" } Tested this on version: 12.1Generate private key w/ CSR via iControl REST
Problem this snippet solves: Generate a private key w/ CSR How to use this snippet: To create a private key with a CSR via iControl REST: POST URL:https://10.1.1.165/mgmt/tm/sys/crypto/key Use the data below as your payload. For the name field, it must end in .key or you will get a false 404! Code : { "name":"www.testing.com.key", "commonName":"www.testing.com", "keySize":"4096", "keyType":"rsa-private", "options":[{"gen-csr":"www.testing.com"}], "organization":"Let It Snow Corp.", "ou":"Ice Engineering", "city":"Calhoun", "state":"AZ", "admin-email-address":"jerry@letit.snow", "email-address":"beth@letit.snow", "subject-alternative-name":"DNS:www.testing.com", "challenge-password":"myP4ssword" } Tested this on version: 13.0
GTM return LDNS IP to client
Problem this snippet solves: We do a lot of our load balancing based on topology rules, so it's often very useful to know where the DNS request is actually coming from rather than just the client's IP and the DNS servers they have configured. Especially if they're behind an ADSL router doing NAT or some other similar set up. This rule simply returns the IP address of the LDNS that eventually made the query to the GTM device in the response to a lookup for the WideIP using the rule, as well as logging the response and perceived location. Code : rule "DNS_debug" partition "Common" { when DNS_REQUEST { host [IP::client_addr] log local0.err "Debug address : [IP::client_addr] [whereis [IP::client_addr]]" } }Knowledge sharing: Velos and rSeries (F5OS) basic troubleshooting, logs and commands
This another part of my Knowledge sharing articles, where I will take a deeper look into Velos and rSeries investigation of issues, logs and command. 1. Velos HA controller and blade issues. As the Velos system is the one with two controllers in active/standby mode only with Velos it could be needed to check if there is an issue with the controller's HA. As the controller's HA order can be different for the system and the different partitions to check the HA for the system use the /var/log_controller/cc-confd file or for a partition HA issue look at the partition velos log at /var/F5/partition<ID>/log/velos.log . Also you can enable HA debug for the controllers with " system dbvars config debug confd ha-state-machine true ". Overview of HA: https://support.f5.com/csp/article/K19204400 Controller HA: https://support.f5.com/csp/article/K21130014 Partition HA: https://support.f5.com/csp/article/K58515297 2. Entering into F5OS objects. The rSeries and Velos tenants are like vCMP quests with VIPRION and sometimes if there are access issues with them it could be needed to open their console. For this the "virtctl" command can be used and as an example " /usr/share/omd/kubevirt/virtctl console<tenant_name>-<tenant_instance_ID> ". Also as velos uses blades and partitions it could be needed to ssh to a blade with " ssh slot<number> " or to enter a partition with " docker exec -it partition<ID>_cli su admin " as sometimes for example to see the GUI logs entering the GUI container for the partition could be needed but F5 support will for this in most cases and maybe this will be the way to enter the BIG-IP NEXT CLI. Overview of VELOS system architecture: https://support.f5.com/csp/article/K73364432 Overview of rSeries system architecture: https://support.f5.com/csp/article/K49918625 rSeries tanant access: https://support.f5.com/csp/article/K33373310 Velos blade and tenant access: https://support.f5.com/csp/article/K65442484 Velos partition access: https://support.f5.com/csp/article/K11206563 3. Usefull commands and logs. For Velos/rSeries as this is a system with a cluster the "show cluster" command is usefull to see any issues (look fo "cluster is NOT ready."). Also the velos.log for the controller and partitions is a great place to start and debug level can be enabled for it under " SYSTEM SETTINGS Log Settings " as this is also the place for rSeries logging to be set to debug. Also the /var/log/openshift.log is good be checked with velos if there are cluster issues or or ks3.log in rSeries. Also the confd logs are like mcpd logs, so they are really usefull for Velos or rSeries. Other nice commands are docker ps, oc get pod --all-namespaces -o wide, kubectl get pod --all-namespaces -o wide but the support will ask for them in most cases. Velos cluster status: https://support.f5.com/csp/article/K27427444 Velos debug: https://support.f5.com/csp/article/K51486849 Velos openshift example issue: https://support.f5.com/csp/article/K01030619 Monitoring Velos: https://clouddocs.f5.com/training/community/velos-training/html/monitoring_velos.html Monitoring rSeries: https://clouddocs.f5.com/training/community/rseries-training/html/monitoring_rseries.html 4. Velos and rSeries tcpdumps packet captures, file utility and qkview files. For Velos qkviews ca be created for controller or partition as they are seperate qkviews. Tcpdumps for client traffic are done a tcpdump utility from the F5OS (su - admin) and a tcpdump in the Linux kernel is just for the managment ip addresses of the appliance , controller (floating or local) , partition or tenant. The file utility allows for file transfers to remote servers or even downloading any log from the Velos/rSeries to your computer as this was not possible before with iSeries or Viprion. Also the file utility starts outbound session to the remote servers so this an extra security as no inbound sessions need to be allowed on the firewall/web proxy and it can be even triggered by API call and I may make a codeshare article for this. Velos tcpdump utility: https://support.f5.com/csp/article/K12313135 rSeries tcpdump utility: https://support.f5.com/csp/article/K80685750 Qkview Velos: https://support.f5.com/csp/article/K02521182 Qkview Velos CLI location: https://support.f5.com/csp/article/K79603072 Qkview rSeries: https://support.f5.com/csp/article/K04756153 SCP: https://support.f5.com/csp/article/K34776373 5. A final fast check could be to use ''kubectl get pods -o wide--all-namespaces'' (with Velos also ''oc get pods -o wide --all-namespaces'' should also work) to see that all pods are ok and running. Also ''docker ps'' or '' docker ps --format 'table {{.Names}}\t{{.RunningFor}}\t{{.Status}}' '' are usefull to see a container that could be going down and up and this can be correlated with issues seen with "show cluster" command. 6. The new F5OS has much better hardware diagnostics than the old devices, so no more the need to do EUD tests as all system hardware components and their health can be viewed from the GUI or CLI and also this is shown in F5 ihealth! https://techdocs.f5.com/en-us/velos-1-5-0/velos-systems-administration-configuration/title-system-settings.html Edit: For Velos and rSeries always keep the software up to date as for example I will give with the Velos 1.5.1 the cluster rebuild because of the openshift ssl cert being 1 year is much simpler or the F5 rSeries and the Cisco Nexus issues or the corrupt Qkview generation when the GUI not the CLI is used (the velos cluster rebuild with touch /var/omd/CLUSTER_REINSTALL can solve many issues but it will cause some timeout): http://cdn.f5.com/product/bugtracker/ID1135853.html https://my.f5.com/manage/s/article/K000092905 https://support.f5.com/csp/article/K79603072
F5 RHI Solution an alternative to GSLB load balancing between Datacenters
This article dives into F5 Route Health Injection (RHI) for load balancing traffic across two geographically dispersed data centers. RHI empowers F5 BIG-IP to leverage health information from various sources, including dynamic routing protocols like BGP (Border Gateway Protocol), for intelligent traffic distribution. This approach enhances application resiliency by directing traffic only to healthy backend servers in either data center. Understanding F5 Route Health Injection F5 RHI enables the BIG-IP system to integrate with routing protocols and advertise routes based on the health of backend servers. Here's how it works: Health Monitoring: F5 actively monitors backend servers using pre-configured health checks (e.g., HTTP, TCP). Route Advertisement: Based on health check results, F5 advertises routes for healthy servers through RHI. This can be achieved by integrating with a routing protocol like BGP or by directly manipulating the routing table. Traffic Distribution: The advertised routes are injected into the BIG-IP routing table. When a client sends a request, F5 consults the routing table and directs traffic only towards healthy servers, considering factors like path costs and priorities. Dynamic Updates: Any changes in server health are reflected through route updates. If a server becomes unhealthy, the corresponding route is withdrawn, ensuring traffic doesn't reach unavailable servers. Configuration Steps 1. F5 BIG-IP Configuration: Health Checks: Define comprehensive health checks for your backend servers. These checks determine server availability and responsiveness. Choose appropriate health check types (e.g., HTTP, TCP) based on your application requirements. Virtual Servers: Create virtual servers on the F5 that represent the services you want to load balance. These virtual servers will point to the pool of backend servers across both data centers. Route Health Injection Configuration: Enable RHI on the BIG-IP system. You can configure RHI to advertise routes directly into the routing table (tmm route add command) or integrate with a routing protocol like BGP. 2. BGP Configuration (Optional): If using BGP for RHI: Configure a BGP neighbor relationship between the BIG-IP and a border router in each data center. Define route attributes within BGP to advertise routes for healthy servers, including the next-hop IP address of the data center where the server resides. This allows F5 to determine the optimal path for reaching the server. 3. Verification: Test the health checks to ensure F5 accurately detects server health. Simulate a data center outage to verify F5 routes traffic to healthy servers in the remaining data center. Tools like F5 Traffic Management Shell (tmsh) can be used to view routing table entries and verify route updates.BIG-IP Report
Problem this snippet solves: Overview This is a script which will generate a report of the BIG-IP LTM configuration on all your load balancers making it easy to find information and get a comprehensive overview of virtual servers and pools connected to them. This information is used to relay information to NOC and developers to give them insight in where things are located and to be able to plan patching and deploys. I also use it myself as a quick way get information or gather data used as a foundation for RFC's, ie get a list of all external virtual servers without compression profiles. The script has been running on 13 pairs of load balancers, indexing over 1200 virtual servers for several years now and the report is widely used across the company and by many companies and governments across the world. It's easy to setup and use and only requires auditor (read-only) permissions on your devices. Demo/Preview Interactive demo http://loadbalancing.se/bigipreportdemo/ Screen shots The main report: The device overview: Certificate details: How to use this snippet: Installation instructions BigipReport REST This is the only branch we're updating since middle of 2020 and it supports 12.x and upwards (maybe even 11.6). Downloads (two latest versions): https://loadbalancing.se/downloads/bigipreport-v5.7.0.zip https://loadbalancing.se/downloads/bigipreport-v5.6.5.zip Documentation, installation instructions and troubleshooting:https://loadbalancing.se/bigipreport-rest/ Docker support https://loadbalancing.se/2021/01/05/running-bigipreport-on-docker/ Kubernetes support https://loadbalancing.se/2021/04/16/bigipreport-on-kubernetes/ BIG-IP Report (Legacy) Older version of the report that only runs on Windows and is depending on a Powershell plugin originally written by Joe Pruitt (F5) BIG-IP Report (only download this if you have v10 devices): https://loadbalancing.se/downloads/bigipreport-5.4.0-beta.zip iControl Snapin https://loadbalancing.se/downloads/f5-icontrol.zip Documentation and Installation Instructions https://loadbalancing.se/bigip-report/ Upgrade instructions Protect the report using APM and active directory Written by DevCentral member Shann_P: https://loadbalancing.se/2018/04/08/protecting-bigip-report-behind-an-apm-by-shannon-poole/ Got issues/problems/feedback? Still have issues? Drop a comment below. We usually reply quite fast. Any bugs found, issues detected or ideas contributed makes the report better for everyone, so it's always appreciated. --- Join us on Discord: https://discord.gg/7JJvPMYahA Code : BigIP Report Tested this on version: 12, 13, 14, 15, 16
SFTP file existence monitor
Problem this snippet solves: SFTP file existence monitor How to use this snippet: This monitor definition allows for a monitor to connect to a SFTP server and check for the existence of a file using username/password. Written for a specific implementation where they wouldn't use key pairs, plus it turns out that curl on F5's was compiled with sftp support disabled, so I had to use expect instead. It's based off of the default sample_monitor. Create a monitor definition with 3 variables: $monitor_sftp_USER = Username of SFTP server $monitor_sftp_PASS = Password for $monitor_sftp_USER $monitor_sftp_STRING` = String/Filename to search for I have also written a modified version whereby you can encrypt the password manually using the unit master-key and add that as the password variable, which I can post if wanted. Code : #!/bin/sh # # (c) Copyright 1996-2006, 2010-2013 F5 Networks, Inc. # # This software is confidential and may contain trade secrets that are the # property of F5 Networks, Inc. No part of the software may be disclosed # to other parties without the express written consent of F5 Networks, Inc. # It is against the law to copy the software. No part of the software may # be reproduced, transmitted, or distributed in any form or by any means, # electronic or mechanical, including photocopying, recording, or information # storage and retrieval systems, for any purpose without the express written # permission of F5 Networks, Inc. Our services are only available for legal # users of the program, for instance in the event that we extend our services # by offering the updating of files via the Internet. # # @(#) $Id: //depot/maint/bigip12.1.1/tm_daemon/monitors/sample_monitor#1 $ # # # these arguments supplied automatically for all external pingers: # $1 = IP (::ffff:nnn.nnn.nnn.nnn notation or hostname) # $2 = port (decimal, host byte order) # # The following must all be set as variables in the monitor definition # $monitor_sftp_USER = Username of SFTP server # $monitor_sftp_PASS = Password for $monitor_sftp_USER # $monitor_sftp_STRING` = String/Filename to search for # # $MONITOR_NAME = name of the monitor # # In this sample script, $3 is the regular expression # # Name of the pidfile pidfile="/var/run/$MONITOR_NAME.$1..$2.pid" # Send signal to the process group to kill our former self and any children # as external monitors are run with SIGHUP blocked if [ -f $pidfile ] then kill -9 -`cat $pidfile` > /dev/null 2>&1 fi echo "$$" > $pidfile # Remove the IPv6/IPv4 compatibility prefix node_ip=`echo $1 | sed 's/::ffff://'` # Using expect and sftp to get directory listing from the server. # Search the data received for the expected string. expect -c " spawn sftp -oStrictHostKeyChecking=no -oPort=$2 $monitor_sftp_USER@$node_ip; expect \"password:\"; send $monitor_sftp_PASS\r; expect \"sftp>\"; send \"ls -l\r\"; expect \"sftp>\"; send \"exit\r\" " | grep $monitor_sftp_STRING > /dev/null status=$? if [ $status -eq 0 ] then # Remove the pidfile before the script echoes anything to stdout and is killed by bigd rm -f $pidfile echo "up" fi # Remove the pidfile before the script ends rm -f $pidfile Tested this on version: 12.1
CitrixBleed Mitigation CVE-2023-4966
Code is community submitted, community supported, and recognized as ‘Use At Your Own Risk’. Short Description The Citrix Bleed exploit https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4966against Netscaler ADC and Netscaler Gateway is being seen in the wild and impacting many organisations https://www.malwarebytes.com/blog/news/2023/11/citrix-bleed-widely-exploitated-warn-government-agencies. If you have a BIG-IP providing access to your Citrix platform, you can gain visibility of this explit and potentially mitigate malicious requests. Problem solved by this Code Snippet This iRule will catch requests to the exploit URL and create a log and iStat, and potentially drop malicious requests where the Host header is set to be a large length. How to use this Code Snippet Create the iRule and assign it to the virtual server in front of the Citrix device. Code Snippet Meta Information Version: TMOS v11+ Coding Language: iRule Full Code Snippet when RULE_INIT priority 500 { # This is an iRule to be used to capture and possibly mitigate against known Citrix Bleed attacks # https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4966 # There is no support implied in using this iRule, you use it at your own risk # Version 1 Peter White # Note that all requests to /oauth/idp/.well-known/openid-configuration will be logged in /var/log/ltm for later checking of source address etc # and all requests with a hostname of more than 100 characters will be assumed to be malicious # Set the variable below to 1 or 0 to turn on blocking of known malicious requests set static::cb_block 1 # Set the host header max length. Note that the PoC uses a length of 24576 set static::cb_host_max_length 100 # Log prefix - set the log prefix for the warning logs for this iRule set static::cb_log_prefix "CB" } when HTTP_REQUEST priority 100 { if { [HTTP::path] equals "/oauth/idp/.well-known/openid-configuration" } { log local0.warn "$static::cb_log_prefix [virtual name] [IP::client_addr] [TCP::client_port] [whereis [IP::client_addr] continent] [whereis [IP::client_addr] country]" # Note that you can see the iStat using the command 'tmsh show ltm virtual <virtual server name>' and look at User-defined stats at the bottom ISTATS::incr "ltm.virtual [virtual name] counter CB_log" 1 if { $static::cb_block && ([string length [HTTP::header Host]] > $static::cb_host_max_length) } { drop } } }
