SSL Forward Proxy, iRules and Client Hello
Hi all, I am seeing odd behaviour using SSL fwd proxy (SSLO): My intention is to use the client hello (SNI) to influence SSSL profile selection. I have 2 SSSL profiles setup, let call them A and B For trusted connections (i.e. certs issuers in SSSL CA bundle) is am unable to extract the SNI from the initial CH, using the CLIENTSSL_CLIENTHELLO event and [SSL::extensions -type 0]. These are send to profile A based on SNI. I have pcaps showing the CH incoming to the F5. I assume this may have something to do with the 'verified handshake' functionality. It appears the test client browser keeps attempting connection and I see inconsistent results (some connections are reset, some succeed). In irule logs its apparent the SNI does eventually become available in the CLIENTSSL_CLIENTHELLO event. For untrusted/self signed etc this doesn't appear to happen, these are sent to Profile B (identical to A for testing purposes) so my assumption is the F5 is doing some kind of SNI processing (compare to CN's in trust store?) and then connecting to the server for 'verified handshake' before releasing the SNI into the CLIENTSSL_CLIENTHELLO event? I have seen an iRule that effectively disables SSL then parses the raw client hello for SNI, I expect this may work as it would intercept the raw CH so the F5 cannot interfere or do any server-side preamble, but I'd rather do this within the realms of defined events if possible... :-) Any suggestions or comments welcome! thanks
F5 ASM/AWAF – violations logged but no learning suggestions generated
Hey everyone, running into a strange behavior with F5 ASM and hoping someone has seen this before. Setup: - Explicit/closed parameter list (only allowed parameters defined, everything else triggers a violation) - "Illegal Parameter" violation has Learn + Alarm + Block all enabled - Parameter learning mode is set to Always - Violations are appearing correctly in the event logs - no blocked IP addresses exceptions The Problem: Despite all of the above, no learning suggestions are being generated for the illegal parameter violations except one on the Traffic Learning page. What I noticed: After digging through the logs, I found a pattern: - the one request that triggered only the illegal parameter violation (with a valid URL) → learning suggestion WAS generated - Requests that triggered illegal parameter + illegal URL or illegal file type simultaneously → no learning suggestion generated The vast majority of my traffic falls into the second category, which is why the suggestions page looks empty. My question: Is there any documented behavior in ASM/AWAF where requests triggering multiple severe violations (illegal URL + illegal file type + illegal parameter together) are suppressed from generating learning suggestions? Or is something else going on here? Has anyone run into this and found a workaround other than manually adding parameters from the event log? Thanks in advance.
syslog over tcp and define management IP as source
Hello I used following method to add syslog server ip with tcp port. can anyone help me how to define source IP (management IP) to send logs to syslog server. https://support.f5.com/csp/article/K13080 Configuring the BIG-IP system to log to the remote syslog server using TCP protocol Impact of procedure: Performing the following procedure should not have a negative impact on your system. 1.Log in to tmsh by typing the following command: tmsh 2.To log to the remote syslog server using the TCP protocol, use the following command syntax: modify /sys syslog include "destination remote_server {tcp(\"\" port (514));};filter f_alllogs {level (debug...emerg);};log source(local);filter(f_alllogs);destination(remote_server);};" For example, to log to the remote syslog server 172.28.68.42, type the following command: modify /sys syslog include "destination remote_server {tcp(\"172.28.68.42/" port (514));};filter f_alllogs {level (debug...emerg);};log {source(local);filter(f_alllogs);destination(remote_server);};"
Multiple DNS resolvers for root forward zone "."
I have a requirement for two sets of LTM services with different DNS requirements. The primary red secure service uses an internal DNS service but traffic can also be routed to the Internet. The second blue service uses a partner Internet Gateway. This has all worked with both services using the blue DNS resolver until recently one of the cloud apps needs to use 'microsoft.com' services. Because the Blue gateway uses public DNS to validate FQDNs and Microsoft frequently roll (like every 5mins) the public IP addresses in DNS responses we think the blue gateway is caching different IP addresses to the pink DNS server and so when the blue gateway validates the destination IP it can sometimes drop traffic
ssh: Common Criteria mode initialized
I setup a new F5 and I am trying to SSH to an existing F5 but from the new F5 I get " ssh: Common Criteria mode initialized" I ran the command "tmsh list sys db security.commoncriteria" and it is set to false on both F5. I checked the sshd properties and both F5 have the following description none fips-cipher-version 2 inactivity-timeout 6000 include "Ciphers aes256-ctr,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes128-ctr KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521 MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-256,hmac-sha2-512-etm@openssh.com,hmac-sha2-512" log-level info login enabled port 22 what am i missingManually add or remove IP address from IP Intelligence blacklist category
Hello, I'd like to know if it is possible to use a CLI command to add (or remove) an IP address to (from) an IPI category blacklist. I need to do this from a bash shell script... I know it is possible using the GUI: "Security >> Network Firewall : IP Intelligence : Black List Categories", then select the blacklist category and click "Add to Category" or "Remove from Category". I cannot find the CLI equivalent in the documentation/ASkF5/DevCentral... -FrankCatch Dynamic CRL Errors and Return Friendly Page
Hi all, I’ve implemented a TLS 1.3 mTLS HTTP virtual server, following the general instructions to support friendly HTTP errors as per Catch SSL Errors and return a friendly page... | DevCentral, with some slight adjustments. This has worked great and I’ve been able to catch errors through checks against the SSL::verify_result value. However, while this works using CRL File option, the behaviour is different when using Dynamic CRL. It appears that using the CRL File option, all validation performed prior to the CLIENTSSL_CLIENTCERT event with the outcome provided in the SSL::verify_result. When using CRL Validator all non CRL validation performed prior to CLIENTSSL_CLIENTCERT, then CRL Validator performs its operations after CLIENTSSL_CLIENTCERT and before the CLIENTSSL_HANDSHAKE event, where the SSL::verify_result value can change based on the CRL Validator outcome. However, on most errors (from testing it appears to be all errors except for revoked status) processing fails and the CLIENTSSL_HANDSHAKE event is never reached. Instead, a TLS protocol response returned directly to the calling client, removing the opportunity to catch and process the error and return an HTTP response. Has anyone configured catching SSL/TLS errors using Dynamic CRL and sending friendly HTTP responses? Any thoughts on how to address this? This is specifically to cover all the CRLDP failing scenarios, such as for all the “unknown” certificate status triggers and for certificates missing the CRLDP extension. Thanks for any help Andrew
