Bypass SSL TMM ERR on SWG Explicit mode
Hi guys I have an issue when I had configured for Bypass SSL log return like below Aug 10 14:23:20 bigip4 err tmm[18992]: 01870029:3: /Common/swg_explicit_auth:Common:7cc2ccbf: [C] 10.55.55.85:56516 -> 203.131.212.198:443:ERR_VAL: SSL action will not take effect, the handshake has alreadybeen processed. Aug 10 14:23:20 bigip4 notice tmm1[18992]: 01870023:5: /Common/swg_explicit_auth:Common:7cc2ccbf: education match Aug 10 14:23:20 bigip4 err tmm1[18992]: 01870029:3: /Common/swg_explicit_auth:Common:7cc2ccbf: [C] 10.55.55.85:56517 -> 203.131.212.198:443:ERR_VAL: SSL action will not take effect, the handshake has alreadybeen processed. Aug 10 14:23:43 bigip4 notice tmm1[18992]: 01870023:5: /Common/swg_explicit_auth:Common:7cc2ccbf: education match Aug 10 14:23:43 bigip4 err tmm1[18992]: 01870029:3: /Common/swg_explicit_auth:Common:7cc2ccbf: [C] 10.55.55.85:56523 -> 203.131.212.198:443:ERR_VAL: SSL action will not take effect, the handshake has alreadybeen processed. Then traffic never bypass SSL. Flow for Per-Request Policy is Start -> L7 Protocol Lookup -> Logging -> SSL Bypass > allow
NTLM Configuration error
Hi, I'm trying to configure NTLM, and for the machine account i face the following error, domain join for 'HAZA' failed: Operations error, base: CN=Computers,dc=LDAP-IBRAHIM,dc=TEST, scope: 0, filter: (objectClass=*) (1) I the below the last few packets before F5 (192.168.5.99) closes the connection with LDAP (192.168.5.155), I really don't know what i missed.....
Enabling Azure Active Directory Tenant Restrictions with F5
Microsoft’s Azure Active Directory(Azure AD) is the largest cloud-based enterprise directory in the world. According to the data presented at the Microsoft Ignite conference, it has more than 750 million user accounts and handles more than 1.3 billion authentications per day. Azure AD is the heart that powers access to Microsoft’s Office 365 application suite, so every customer that uses Office 365 or Azure cloud is using Azure AD. Of course, with adoption of SaaS apps such as Office 365, enterprises face challenge with data security and access restrictions. For example, many customers from various compliance-intensive verticals need to have stricter controls over which Azure AD identities can access Office 365 from with the boundaries of the corporate network(or even outside of it from corporate-owned assets). For many years, customers struggled with that challenge, as Microsoft did not have a native solution to address it. For example, take a look at how one of the Office 365 customers frames the question about their needs to restrict access to Office 365 from their network: Fortunately, Microsoft has listened to their customer needs, and has recently released the Tenant Restriction option for Azure AD. Microsoft says that they have developed this feature with extensive input from their customers, especially those in financial, healthcare, and pharmaceutical industries. From the description that Microsoft provides, their implementation is similar to Google's, but they actually require two headers: Restrict-Access-To-Tenants: and Restrict-Access-Context: This approach appears to be more sophisticated, because it not only ensures a variety of tenants to be customized to meet the organizational access needs, but it also specifies the Azure AD anchor - the tenant that is setting these restrictions. Since the directory id is not commonly accessible to anyone but the tenant admin, this feature provides greater security against abuse and/or misuse by unauthorized parties. Below, you can find a sample Microsoft diagram and flow of how the Tenant Restriction options works, where I took liberty of placing an F5 device in place of a generic proxy that handles header insertion. Of course, your deployment of proxies or F5 devices on your network might differ, but this is just a start to explain how F5 helps facilitate the implementation of this feature. F5 already provides a broad range of unique solutions forenhancing securityto Office 365. In addition, the need for overall SSL visibility and dynamic service chaining of the outbound traffic are driving rapid adoption of new F5 solutions such asSSL OrchestratorandSecure Web Gateway. All this aligns really well with enabling customers to implement new Azure AD Tenant Restrictions using their F5 investment by making a small change to existing configuration. For example, in order to implement Azure AD Tenant Restrictions in my Secure Web Gateway demo environment, I added a simple macro to take care of identifying traffic destined to Microsoft’s authentication service and insert the required headers. And here’s how I am inserting the required headers: Of course, if you’re running SSL Orchestrator, you can implement similar functionality in the construct of that configuration. I’m really excited about Microsoft’s release of the Tenant Restrictions feature, as it will drive increased adoption and better security for enterprises using Office 365, and I hope that many of our existing and future customers will leverage the appropriate F5 product to help them easily achieve better security posture with using Office 365.iRule TCL error - no such variable
Hey everyone! I have a previous thread regarding an iRule used to exclude TLS 1.3 cipher suites and certain FQDNs and IP addresses. In that thread we managed to get the iRule fully functioning. The complete iRule is posted in the comment below. Now though, we are seeing the following in the LTM log: err tmm[20996]: 01220001:3: TCL error: /SWG_Proxy/TLS_Exclusion_Clients_v2 - can't read "content": no such variable while executing "class match $content contains "DG_TLS_1_3_Hex_List"" I understand that the content variable, which is created by the following lines: Exclude tls 1.3 ciphers binary scan [TCP::payload] H300 content is for some reason not present in some occasions. First I thought it was because we matched the IP address against the Datagroup list DG_SWG_SSL_Passthrough_Clients_IP in the following part: if { [class match [IP::local_addr] equals DG_SWG_SSL_Passthrough_Clients_IP] } { if {$static::tls_iR_debug and [IP::client_addr] equals $static::tls_iR_sourceIP}{log local0. "ir181017-1 - Client IP: {[IP::client_addr]} Server IP: {[IP::local_addr]} - Match DataGroup IP!!"} If Destination IP address matches Data Group - turn off HTTP and SSL Profiles } else { Collect TCP DATA for SNI analysis in the CLIENT_DATA event if {$static::tls_iR_debug and [IP::client_addr] equals $static::tls_iR_sourceIP}{log local0. "ir181017-2 - Client IP: {[IP::client_addr]} Server IP: {[IP::local_addr]} - No Match DataGroup IP"} TCP::collect Which should mean we do not run the TCP::collect command and this will cause the binary scan to fail? Or am I wrong about that? I tried to replicate that by adding some IP addresses to the exclude list but the TCL error never shows. In fact, I have never been able to replicate the error message. I also tried to lower my SSL handshake down to SSLv3 but that did not trigger it either. Do you guys have any idea?
iRules appending after url
Hello F5 !!! I am newbie in the world of load balancing, apologies if I am posting a silly question. Recently I have published a https website, created a iRule to redirect from http to https using below when HTTP_REQUEST { if {[HTTP::host] equals "abc.com"} { HTTP::redirect https://[HTTP::host][HTTP::uri] } else { HTTP::redirect "https://abc.com/[HTTP::uri]" } } Now I have a requirement to append a string after the url, example if some user is visiting abc.com, he should be redirected to https://abc.com/something. Thanks in advance.Insert header to control google account login
I've been asked to set up our F5 SWG Gateways to prevent users from signing into Google services using their private accounts. Google provide instructions for this here, based on which I've put the following iRule together: when HTTP_REQUEST { if { [HTTP:host] equals "*.google.com"}{ HTTP::header insert "X-GoogApps-Allowed-Domains" ".com" } } I don't have much experience with iRules (or a DEV environment), does this look correct? There's a good chance I'll need to create other 'website specific' iRules in the future. In terms of performance, am I best creating them all in the same iRule with different conditions, or should each one have it's one iRule? Many thanksPerforming SSL Bypass for Forward Proxy Traffic based using an iRule capturing the SNI
Hey everyone! I'm currently developing an iRule to exclude certain traffic from the "Full Proxy" Architecture by turning off the HTTP Profile and Client/Server SSL Profile for our SSL Forward Proxy. We are using the built in function in SWG but for some banking applications it still does not seem to work and the SWG's intelligence is getting in the way. We have been hit with a few bugs which we are currently resolving but in the mean time we need to have this iRule in place to create a workaround. We would like a clean cut for some of the applications they have by adding them to a Data Group and building an iRule for this purpose. Here is the current iRule: when RULE_INIT { set 1 to enable logging, 0 to disable set static::debug 0 } when CLIENT_ACCEPTED { This iRule is meant to Passthrough SSL Connections for SWG in order to solve SSL issue. Based on Data Group List of IP addresses. if { [class match [IP::local_addr] equals DG_SWG_SSL_Passthrough_IP] } { SSL::disable clientside SSL::disable serverside HTTP::disable if {$static::debug}{log local0. "ir181017-1 - Client IP: {[IP::client_addr]} Server IP: {[IP::local_addr]}: - Match DataGroup DG_SWG_SSL_Passthrough_IP! Disabling SSL"} } } when CLIENTSSL_CLIENTHELLO { This iRule is meant to Passthrough SSL Connections for SWG in order to solve SSL issues. Based on Data Group List of FQDNs. if {$static::debug}{log local0. "ir181017-2 - Client IP: {[IP::client_addr]} - Client Request Server SSL SNI: {[SSL::sni name]}"} if { [class match [string tolower [SSL::sni name]] contains DG_SWG_SSL_Passthrough_FQDN] } { SSL::disable clientside SSL::disable serverside HTTP::disable if {$static::debug}{log local0. "ir181017-3 - Client IP: {[IP::client_addr]} - Server SSL SNI: {[SSL::sni name]} - Match DataGroup DG_SWG_SSL_Passthrough_FQDN! Disabling SSL"} } } The most relevant part of the iRule is the CLIENTSSL_CLIENTHELLO section. When logging the entries, we cannot see any SSL::sni in the logs. But when tcpdumping we can clearly see that there is Server Name Indication fields in the traffic. Perhaps we are using the SSL::sni command wrong. Perhaps we can use the SSL::extension and have it return the SNI from there and we match against that instead?
Redis Server Unprotected by Password Authentication
Solution : Enable the 'requirepass' directive in the redis.conf configuration file.check if Redis is working on the servers.$ redis-cli ping PONG #requirepass "xxxxxxxx"-- change the password of the user and uncomment it. /etc/init.d/redis-server status /etc/init.d/redis-server stop /etc/init.d/redis-server start The above solution provided are for single server What is the solution for the clusters of Linux and there are multiple configuration files given below? config/redis/redis_121.conf config/redis/redis_122.conf config/redis/redis_123.conf config/redis/redis_124.conf config/redis/redis_125.confSWG iRule reading session variable
We are using Secure Web Gateway as a forward proxy server. One of the iRules we have in place is passing data to another iRule via the Query String in the URL, which is causing problems. I'm trying to change this so that the variables we need to send are saved in session variables instead, but have only had partial success, I was hoping someone could shed some light on where I'm going wrong. The first iRule is successfully storing the data into session variables: set host [HTTP::host] set uri [HTTP::uri] if {[ACCESS::session data get session.custom.initialhost] != "$host"} { ACCESS::session data set session.custom.initialhost "$host" ACCESS::session data set session.custom.initialurl "$uri" } But the second iRule doesn't seem to be reading the data from these variables. I changed the lines: set uri_list [split [HTTP::uri] &] set new_uri [join [lrange $uri_list 3 end] "/"] set full_redirect "[lindex $uri_list 1]://[lindex $uri_list 2]/$new_uri" HTTP::redirect "$full_redirect" to set uri_list [split [HTTP::uri] &] set new_uri [join [lrange $uri_list 3 end] "/"] set full_redirect "[ACCESS::session data get server.network.protocol]://[ACCESS::session data get session.custom.initialhost][ACCESS::session data get session.custom.initialurl]" HTTP::redirect "$full_redirect" but it doesn't seem to have made any difference, the second iRule is still using the variables from the Query String rather than the session variables. I had planned to tidy up the now unnecessary lines of code (i.e. to read the Query String data) after confirming the rule was working as expected. To troubleshoot, I did remove the extra lines including changing the first rule to not add the values to the Query String. The second iRule just behaved as if it had been passed blank variables. I even attempted to add extra plain text to the end of the set full_redirect string, but it didn't appear, almost as if the changes to the iRule hadn't been saved. Is there something wrong with my code, or is there something wrong on the F5 causing it to fail to read the variables, or to execute the old (cached?) version of the iRule instead? Many thanks
