security
14334 TopicsBIG-IP HSB vulnerability CVE-2024-39778
When a stateless virtual server is configured on a BIG-IP system with a High-Speed Bridge (HSB), undisclosed requests can cause virtual servers to stop processing client connections and the Traffic Management Microkernel (TMM) to terminate.(CVE-2024-39778) https://my.f5.com/manage/s/article/K05710614 what does High-Speed Bridge (HSB) mean ? and from where i can check this ? also if HSB not enabled so does this mean i am not vulnerable ?0Views0likes0CommentsYubikey APM and AzureAD question
HEy I'm trying to add the ability to use yubikeys as hardware keys to my Saml/Azureid logins. I saw this doc for how to do it with okta. Application access using YubiKey Authentication with APM and Okta | DevCentral I was wondering if their were similar instructions for Azure AD. It seems like the okta integration relies on okta connecter supporting yubikey in v 16.0. We are currently running 16.1.5, but I don't see something similar in the Azure AD connector. I was wondering how other people have done this? Or if their was something I'm missing? We've been able to add yubikeys to ont eh Azure Ad side, but they never show up when we try to use them as a 2nd factor with The BIG IP Edge client.45Views0likes4CommentsBIGIP SHOW INOPERATIVE
i tried to upgrade my bigip from v 15.x.x to 16.x.x and i face an issue which is showing in cli BIGIP:INOPERATIVE and in GUI starting web server , and this take more than one day.. also in cli it show: load_config_files[10064]: "/usr/bin/tmsh -n -g -a load sys config partitions all base " - failed. -- Error: failed to reset strict operations; disconnecting from mcpd. Will reconnect on next command. so how i can go back to v 15 , i have the backup file saved locally. what should i do to stop the reboot and go back to the previous configration ?Solved62Views0likes12CommentsCookie not RFC-compliant - Cookie has no value
After upgrading the ASM to v16.1.5, applications are impacted due to this violation. Cookie: TS01e67e1b=01117c6e19857f90c59bf98aa78f99ae127e515a9e8b98b63394cb861749b60553d9deb146068ba33d4adc4809067c58864ec7a0a7; da9ec29c6b39e2b88e843f34fcc5c888=65d704e40287c7e10857d068a5c7e0e8; BIGipaaaaaaaaaaaaaaaa=!jg6d/hMU2jsserYjJogO6C4bpgnUbuxrViNJR0aXqUXe2HKAGIthD59Q0H/dwcVIrnAaJXJD1jpaAjDfbRxWeL0nv70gg6ZTvqjk6JeY; {}; bf73147a74759c67a3aeb25b4366db4b=c2f86fb44daf387390821d422f1e2128; c65f6ef4e400d09c0f0b01031bd4f543=922ff603468528d429baa6c55326993a; ce78ef2593547bf35a602fa87764cf66=ffc07f7c986d4b47f21881f4ced17bd8; f319c5d88cce600c230f6325ebd679da=ef9b4bae1258ba2df4dc3d462eb57fc6; bab5c74a20de5947515f788a66a1113d=1c975f92651ecbae9ce488302974ac6f; 5562f6b47d905c6971bd6205cd7a280f=4ebf40f732bea8170ece709b0bb26785; 580bbc8d2e73ba78a72fdc8852e084da=e1f990dbd9d7fdffff7a564ff5494f71; ecaab19faae5d2a3c391e04f443c7f00=390917dffad9a30a8b8ba039585e3870; 56269766768c8b4d9fa0a096871ef860=fa83211121101296d6c4963469ee910e; b08cac70fbebd894cc114a36d402393a=bacbc7745aebb8a56fb8479ebb6da69c; 1e9248c1ef07a284d0fdc6eac6fbb320=c9ef1cf6eaecda4b0268cbc818508627; 1ae1841113f8ed1046fed24bdbb209e7=56e403f6ee2b16da5526d29f89702617; JSESSIONID=7196FF8AF38E24CA3E94B359AEBD13EF; cfidsgbg-w-aabtestenv=J3cUWHklvHmPLynEsAFGqLPEmsHcFd2fQaLHlg0xhvu6qdNkrLUHHBCYcF4GlnVN3HA8HR9DSW1tdwEiEbTiqTvj0fFTsviMYVlhZbVvZ0qyEAN9AxKXFFdu5yyLPf2B5GYXjdptAaucmRnm09qYc6L85cj2oe031OBds+M=; TS01707b3f=017da02c37d17c78956026fa4cbd0ee1bbe7f19180822950b07f41cebabc61439b0c463077c6c4e56e4f3ed8f997ce4bf9c5a1b3c0 While we understand it's a known issue, the behavior in our case seems to be different. After upgrading to 17.1.1, 16.1.5, 15.1.10 , ASM blocking request with violation Cookie is not RFC compliant (cookie has no value) (f5.com) Would like to understand if this violation is triggered due to an empty segment on the cookie or for a different reason and how can this be fixed.Solved55Views0likes4CommentsPassword spray attacks through BIGIP
Hello community, Need some help here. Our MSSP observed and notified us of successful password spray behavior from one of the self-IPs on our BIG IP resulting in the lockout of a significant number of accounts. Where's the best place to start gathering information about this incident on the BIG IP? JRahm Regards,61Views0likes2CommentsBest Solution For Unencrypted Cookies
Unencrypted Cookies: The Hidden Gateway for Cyber Reconnaissance in F5 BIG-IP Systems. https://thehackernews.com/2024/10/cisa-warns-of-threat-actors-exploiting.html?m=1 https://www.infosecurity-magazine.com/news/cisa-urges-encryption-cookies-f?utm_source=twitterfeed&utm_medium=twitter https://www.bleepingcomputer.com/news/security/cisa-hackers-abuse-f5-big-ip-cookies-to-map-internal-servers/ https://www.security.nl/posting/861650/CISA+meldt+misbruik+onversleutelde+ cookies+F5+BIG-IP+Local+Traffic+Manager?channel=twitter https://www.cisa.gov/news-events/alerts/2024/10/10/best-practices-configure-big-ip-ltm-systems-encrypt-http-persistence-cookies Just want to ask the best solution. 1. Configuring cookie encryption within the HTTP profile :https://my.f5.com/manage/s/article/K14784 2. Configuring cookie encryption for BIG-IP persistence cookies from the cookie persistence profile :https://my.f5.com/manage/s/article/K23254150 If using HTTP profile. When applied to the virtual server. with HTTP Profile need to apply ? 1. HTTP Profile (Client) 2. HTTP Profile (Server) But Currently, we using HTTP Profile(Client) for x-forwarded-for. Can we using HTTP Profile(Server)? If using persistence cookies, we already have the default Persistence profile by "source_addr" so need to change to cookie encryption ? What other solution to solve this?31Views0likes0CommentsIrule to allow specific IPs
I have a site which is abc.com Trying to achieve below requirements- 1) If uri is / it should redirect to abc.com/xyz - open for all 2) If uri is /rdp_xyz_tshoot should accessible to internal network - (here we can use the datagroup list) As this site is migrated to akamai where they have requirement to use below irule- when HTTP_REQUEST { if { [HTTP::header exists True-Client-IP] } { set trueclientip [HTTP::header True-Client-IP] HTTP::header replace X-Forwarded-For $trueclientip } } Cause for above akamai irule= Normally the True-Client-IP header includes the real IP of the clients when requests are coming from Akamai. It will be unaffected and be sent as part of the request to the pool member. So, your backend servers could look for that header and do something with its value. However, if you want the F5 to translate it to the X-Forwarded-For header, you can use an iRule to convert the Akamai True-Client-IP header to the X-Forwarded-For header. we are trying with below irule which is not working- when HTTP_REQUEST { if { ([HTTP::uri] starts_with "/rdp_xyz_tshoot") && (not[class match [IP::client_addr] equals allowed_IPs])} { reject } if { [HTTP::uri] == "/" } { HTTP::redirect "https://[HTTP::host]/abc_login.jsp" } } Please help35Views0likes2Comments