blocking
11 TopicsBlocking multiple IPs with iRules
Hi, I am trying to block multiple IP's with iRules but unable to do so. Currently using the below command, but everytime there is a new ip, I need to create an iRule for that & bind it to the virtual server. when CLIENT_ACCEPTED { if { [IP::addr [IP::client_addr] equals 1.1.1.1/32] } { log local0. "Blocking [IP::client_addr]" reject } } Is there a way to create a group where all IP addresses can be added & automatically blocked? or what is the best way of doing so? probably a nested If statement. Thanks for the help. Chadi1KViews0likes5CommentsF5 ASM learning new parameters while being in blocking mode.
Hi, I have my ASM protecting many web applications. The problem is that some of the applications/websites, don´t have that much traffic, but some of the websites have a lot of Forms etc. Since the traffic is not to much, it didn´t learned all of the parameters of the website while it was on transparent mode, and even some of the parameters learned don´t have all the meta characters allowed. Question 1: If i disable the value meta character on the parameter itself, does it still block attacks like XSS, SQLi etc? Question 2: Is there a way to have my policies in block mode, but do not block new parameters that are added by developers as an example, and then accessed by users? Question 3: Do you guys keep the Wildcard * parameter in blocking state or leave it in staging ? Question 4: When policy is in automatic, i detected that if a parameter in the website that should allow alpha-numeric values, if it gets a lot of hits by users that just post numeric values ( lets say username) the policy change the parameter data type to integer itself, and after that if some user as a username that have letters in it, will get blocked. What is the better way to get over this. Manual (extensive work checking all the policies every day) or automatic ( some things stop working after some time so have to correct it mannually), or is there and alternative in the Learning and blocking settings that allow to loosen the policy keeping it secure and manageable?999Views0likes1CommentASM from blocking to transparent mode
Hello everyone, I apologize if this has already been asked here on this forum, but from the search I did I only found the opposite question, which is normal. Can anyone tell me what precautions or possible impacts there might be when changing the ASM from blocking to transparent? And will it just stop blocking all violations or will it keep the blocks it has cached from the previous (blocking) configuration? thank you all in advance for your time600Views0likes1CommentDoes BIG IP Ver. 12.X support automatic updates of the Geo Location Database?
Hi, We are using F5 BIG IP Ver 11.6.0 at the moment. We did employ Geo-blocking for a while however we found that we needed to manually update the DB or we were soon outdated and we saw some IPs being incorrectly identified as IP addresses are reissued. I have heard that F5 BIG IP Ver 12.0/12.1 allows to Geo Location databases to udpate automatically. I have tried to find official documentation on this however I have not been able to find any information at all. Is anyone able to confirm or point me in the right direction of the documentation that shows Ver 12.0/12.1 does support automatic updates of the Geo Locations databases? Thank You Kind Regards ChrisSolved576Views0likes6CommentsBlock HTTPS access from specific user agent
Dear community, I want to block HTTPS access from specific user agent(UA). I found this topic following, https://devcentral.f5.com/questions/block-a-user-agent-with-an-irule and I want some idea to arrange this iRule as following. -I want to show "404" to this access and reject to accessing our web server. -I sometime want to allow specific IP address using blocked UA. How can I make such exception? the original one is below. when HTTPS_REQUEST { log local0. "User-Agent:[HTTPS::header "User-Agent"]" if { [string tolower [HTTPS::header "User-Agent"]] == "mozilla/4.0"} { drop log local0. "Rejected request: [IP::remote_addr] User-Agent:[string tolower [HTTPS::header "User-Agent"]] requested [HTTPS::host][HTTP::uri]" } } Thanks in advance for your help, Naoki501Views0likes3CommentsiRule - HTTP::is_redirect failing
We have used this iRule for many years to block PDFs from being accessed directly, unless a user logs in and comes from an allowed domain. After upgrading from 10.2.4 to 11.2.1 and then to 11.6, the iRule fails to work and complains in the ltm log: TCL error: /Common/block-pdf-searches - Operation not supported (line 1) invoked from within "HTTP::is_redirect" I've done some testing and I've confirmed that I'm able to do a simple log local0. if the http response is HTTP::is_redirect, so it seems like the syntax is supported. Can anyone find what may be wrong here? when RULE_INIT { 0=disable checking paths 1=check referer if requested URL is in "referer_check_paths" (default allow) 2=check referer if requested URL is NOT in "referer_check_paths" (default deny) set ::setting_check_paths 0 0=exact match for path check 1=starts_with match of path check set ::setting_path_check_starts_with 0 0=disable filetype checking 1=enable filetype checking set ::setting_check_filetypes 1 Set appropriate URL to send the user to set static::error_url {https://[HTTP::host]} END OF CONFIGURABLE PARAMETERS if { $::setting_path_check_starts_with == 1 } { set ::match_with "starts_with" return } set ::match_with "equals" } when HTTP_REQUEST { set error 0 if { $error == 0 && $::setting_check_filetypes == 1 && [matchclass [HTTP::path] ends_with referer_check_filetypes] } { set error 1 } if { $error == 0 && $::setting_check_paths == 1 && [matchclass [HTTP::path] $::match_with referer_check_paths] } { set error 1 } if { $error == 0 && $::setting_check_paths == 2 && ( not [matchclass [HTTP::path] $::match_with referer_check_paths] ) } { set error 1 } if { $error == 0 } { return } set refer_host [string tolower [URI::host [HTTP::header Referer]]] if { $refer_host == "" || [matchclass $refer_host contains referer_allowed_hosts] } { return } set info " NOTICE: Entry point bypass detected from host: $refer_host" append info " client { [IP::client_addr]:[TCP::client_port] -> [clientside {IP::local_addr}]:[clientside {TCP::local_port}] }" append info " ethernet { [string range [LINK::lasthop] 0 16] -> [string range [LINK::nexthop] 0 16] tag [LINK::vlan_id] qos [LINK::qos] }" append info " - [HTTP::version] - REDIR [HTTP::is_redirect], Content-Length [HTTP::header Content-Length], Transfer-Encoding [HTTP::header Transfer-Encoding]" append info " *TCP MSS([TCP::mss]) BW([TCP::bandwidth]) RTT([TCP::rtt]) OFFSET([TCP::offset])" append info " *IP TOS [IP::tos], HOPS [IP::hops], TTL [IP::ttl]" append info " *HTTP HOST [HTTP::host], KEEPALIVE [HTTP::is_keepalive], REQ_NUM [HTTP::request_num]" log local0. $info Set cache control headers on the redirect to prevent proxies from caching the response. HTTP::respond 302 Location [subst $static::error_url] Cache-Control No-Cache Pragma No-Cache }452Views0likes8CommentsASM Signature Blocking, but not Enabled?
So I get a user ticket that says the user was blocked on the Application dir Access (\manage) signature. When I go to disable this attack signature on the parameter, it's not listed in the Global Security Policy Settings....So after some investigation I went to Manual Traffic Learning and found this signature listed, but not enforced yet... So my question is how did this user get blocked on a signature that hadn't been enforced or enabled yet? Granted the Policy itself is in Blocking Mode....??? Another Question is why did this signature not appear in the Global Security Policy Settings..??435Views0likes3CommentsASM 13.1.0.x Brute Force - how to configure?
Hi, I am not sure when this protection changed but for sure it is quite different in version 13.1.0.8. There is plenty of new settings there - problem is I can't figure out how to set it up for best protection. When only Username is set then only protection is CAPTCHA - you can attempt to guess password as many times as you wish (if you resolve CAPTCHA) - explanation is to protect user from being locked out when his account is under attack - so far so good. There is one issue here - Your support ID. It's shown each time CAPTCHA is displayed but there is no matching entry in Even Log (All request and responses logged). Even when requests are reported as Illegal (but of course not blocked) Support ID in such request do not match one displayed to user - so what is purpose for displaying Support ID below CAPTCHA? If no other setting will be configured (Device ID, IP) then attacker can repeat attack forever - or until security will notice it and block given user name. Only way to actually block login attempt is to configure either Device ID or IP Address failed logins setting. But if any of above will be configured to Alarm and Blocking page (or Drop) then real user that made mistake will be blocked as well - so not being able to block on username is a bit artificial here. Now there is a question how to unlock such blocked IP? I can't see any way. Another issue I noticed is that for some reason (even if Device ID Tracking is enabled in Session Tracking) no Device ID is reported - is there some minimal number of request necessary to identify given device? I wonder what is good mix of settings there to: Actually do not block real user that forgot password from being locked out Do not allow malicious user to continue guessing forever (if he can afford CAPTCHA solving solution) Only way to block login after given number of resolved CAPTCHA and failed attempts is to set CAPTCHA Bypass Mitigation - but it only works for IP Address and Device ID not Username. Assuming that real user will rather try to login from the same IP Address and/or Device ID then in the end real user will be locked out. Then again there should be some way to unlock - and I can't see it. If attack is distributed (different IPs and Device ID) then not being able to block based on Username looks to me as week spot. Attacker can limit number of attempts per IP to a small number and bypass protection. Based on default settings it is possible to perform up to 9 (4th attempt trigger CAPTCHA, then 5 attempts after solving CAPTCHA) attempts per IP without being locked out. New settings are for sure more powerful but it is not so easy to figure out relations between them and create optimal combination. Piotr370Views0likes0CommentsASM 13.1.0.x Brute Force - how to configure?
Hi, I am not sure when this protection changed but for sure it is quite different in version 13.1.0.8. There is plenty of new settings there - problem is I can't figure out how to set it up for best protection. When only Username is set then only protection is CAPTCHA - you can attempt to guess password as many times as you wish (if you resolve CAPTCHA) - explanation is to protect user from being locked out when his account is under attack - so far so good. There is one issue here - Your support ID. It's shown each time CAPTCHA is displayed but there is no matching entry in Even Log (All request and responses logged). Even when requests are reported as Illegal (but of course not blocked) Support ID in such request do not match one displayed to user - so what is purpose for displaying Support ID below CAPTCHA? If no other setting will be configured (Device ID, IP) then attacker can repeat attack forever - or until security will notice it and block given user name. Only way to actually block login attempt is to configure either Device ID or IP Address failed logins setting. But if any of above will be configured to Alarm and Blocking page (or Drop) then real user that made mistake will be blocked as well - so not being able to block on username is a bit artificial here. Now there is a question how to unlock such blocked IP? I can't see any way. Another issue I noticed is that for some reason (even if Device ID Tracking is enabled in Session Tracking) no Device ID is reported - is there some minimal number of request necessary to identify given device? I wonder what is good mix of settings there to: Actually do not block real user that forgot password from being locked out Do not allow malicious user to continue guessing forever (if he can afford CAPTCHA solving solution) Only way to block login after given number of resolved CAPTCHA and failed attempts is to set CAPTCHA Bypass Mitigation - but it only works for IP Address and Device ID not Username. Assuming that real user will rather try to login from the same IP Address and/or Device ID then in the end real user will be locked out. Then again there should be some way to unlock - and I can't see it. If attack is distributed (different IPs and Device ID) then not being able to block based on Username looks to me as week spot. Attacker can limit number of attempts per IP to a small number and bypass protection. Based on default settings it is possible to perform up to 9 (4th attempt trigger CAPTCHA, then 5 attempts after solving CAPTCHA) attempts per IP without being locked out. New settings are for sure more powerful but it is not so easy to figure out relations between them and create optimal combination. Piotr329Views0likes0CommentsF5 as gateway cannot connect on 2nd attempt
Hi Guys, We have an issue with the server 192.168.1.10 that is connected on F5 (F5 is its gateway). So the scenario is When we connect on the server 192.168.1.10 port 80 it is successful When we connect on the server 192.168.1.10 port 80 it is NOT successful We are using same source server. Is there any possible blocking on the f5 side? By the way the source server is also under the F5200Views0likes1Comment