user alert on apm logs
I try to trigger a command when a specific log is written on /var/log/apm It works on 2 different non prod big-ip, but on a third one in production it only works with /var/log/ltm logs. user_alert.conf "failed" is commun in my ltm logs. "New session" is commun in apm logs. So this works (triggered from ltm logs): alert test "failed" { exec command="logger -p local0.notice 'test'" } This doesn't (not triggered from apm logs): alert test "New session" { exec command="logger -p local0.notice 'test'" } Do you have any idea why?
Test message is not present in the log file.
Hi, I would like to ask your support please. We are beginning of creating an iRule and at first we would write something into the log but for some reasons it is failing. The script what we used is the following: when HTTP_RESPONSE { HTTP::collect 1024 set response_data [HTTP::payload] log local0. "TEST HTTP RESPONSE: '$response_data'" set today [clock format [clock seconds] -format %Y-%m-%d] log local0. "TODAY: '$today'" } but the log shows no information for it using the command "tail /var/log/ltm" or "grep TEST /var/log/ltm". Thank you in advance. Best Regards Robert
Can BIG-IQ forward ASM event log which receive from BIG-IP to syslog server?
Hi Right now we have all BIG-IP send ASM event log to BIG-IQ. Question is Can BIG-IQ forward ASM event log which receive from BIG-IP to syslog server? or I need to config on each BIG-IP to send ASM event log to both (BIG-IQ and syslog server) instead.
APM - How to configure logging of snat addresses for network access and app tunnels
Hello everyone, we are using BIG-IP Access Policy Manager to enable administrative access to systems via App Tunnel and Network Access resources. For security reasons, we need to be able to map requests logged on backend resources/systems (e.g. in SSH audit logs) to the session or user accessing said backend resource via App Tunnel or Network Access in APM. Currently, the following request information is logged. Network Access: May 17 14:42:00 tmm0 tmm[22565]: 01580002:5: /APM/ap_rmgw:Common:c1237463: allow ACL: #app_tunnel_/APM/Some_App-Tunnel@c1237463:15 packet: tcp 192.168.12.18:58680 -> 10.0.0.1:22 App Tunnels: May 17 14:41:10 tmm1 tmm1[22565]: 01580002:5: /APM/ap_rmgw:Common:c6787463: allow ACL: #app_tunnel_/APM/Some_App-Tunnel@c6787463:0 packet: tcp 89.229.152.144:63252 -> 10.0.0.1:2 For Network Access requests, an IP address of the lease pool configured in the Network Access resource is logged as the client IP. For App Tunnel requests, the public IP of the client accessing APM is logged as the client IP. In our setup, both requests will be NATed by APM before hitting the target system (through a snat pool in case of a Network Access request, through the active appliances backend IP in case of App Tunnels). Therefore, the APM self IPs (snat pool/appliance backend) will be logged on the target host, leading to us not being able to correlate logs in APM with logs on the target systems. Is there any way to log the SNAT/NAT addresses and ports used to access target systems through APM? I've tried using ACCESS_ACL_ALLOWED in an iRule to log additional information, unfortunately this event only seems to trigger on Portal Access resources, not when using App Tunnels or Network Access resources. Thank you, Fabian
alertd high cpu usage
Hello, So we tried taxing the HSL logging of our 12.1.2 cluster with several (4) simple while true; do curl http://virtual-ip/; done curl loops. The virtual IP had a simple iRule that logged [HTTP::request] several times. Our logging is BSD syslog to HSL, to a logstash pool. During our testing, we saw alertd rising to 100% CPU and maxing out there. CPU usage on the dashboard increased aswell, as you see in the image below. sys log-config destination remote-high-speed-log elk-hsl-destination { pool-name syslog-pool } sys log-config destination remote-syslog rsyslog-to-hsl-elk { remote-high-speed-log elk-hsl-destination } sys log-config filter elk-hsl-filter { level info publisher elk-hsl-publisher } sys log-config publisher elk-hsl-publisher { destinations { rsyslog-to-hsl-elk { } } } Any idea how we can combat this? We would like to use HSL to reduce CPU consumption, but this seems like a lot of fuss for simple logging. Ideas? Thanks!Splunk Log Publisher with iRule HSL
Hi, I'm having some difficulty understanding the relationship between the HSL iRule commands and formatted log publishers (Splunk, in this case) in 11.5.1. Sorry if the formatting isn't what the community expects - I'm fairly new to this ecosystem. Setup One node called "splunk-universal-forwarder" running a Splunk universal forwarder listening on 9996/tcp. A pool called "remote-logging-pool" with the splunk-universal-forwarder node listening on 9996/tcp. Log Destination "splunk-rhsl" of type Remote HSL pointed at the remote-logging-pool over TCP. Log Destination "splunk-formatted" of type "Splunk" forwarding to "splunk-rhsl" Log Publisher "splunk-publisher" pointing at the splunk-formatted destination. Log Publisher "rhsl-publisher" pointing at the splunk-rhsl destination. A virtual server backed by a pool with a single node serving up content http://10.1.1.2 (the IP address is irrelevant for this question). Given the iRule: when CLIENT_ACCEPTED { set hsl [HSL::open -publisher /tst/splunk-publisher] set hsl [HSL::open -proto TCP -pool remote-logging-pool] set hsl [HSL::open -publisher /tst/Rhsl-publisher] } when HTTP_REQUEST { HSL::send $hsl "<190>|[IP::local_addr]|[HTTP::uri]\n" } The bottom two set statements in the when CLIENT_ACCEPTED command result in a messaging going successfully to the Splunk forwarder. The first set statement results in no messages going to the Splunk forwarder. Questions Are HSL commands in iRules unable to use formatted publishers? What exactly does a formatted publisher do? It seems like it would write data to the remote receiver in a format that particular receiver expects, but I haven't found a lot of documentation on this yet. Is there an interactive way to generate dummy log events to send to different destinations and publishers to see what the effect is on remote receiver? Thanks for your help!
iRule for HTTP::cookie creation works once on the first login. Any login after that no cookie is created
when HTTP_RESPONSE { # if table shoud be set then take record of the ClientIP and set encrytped cookie if { [ACCESS::session data get session.custom.suppressmfa.setauthtable] == 1 } { HTTP::cookie insert name $static::suppress_mfa(cookie) value $static::suppress_mfa(value) path "/" HTTP::cookie expires $static::suppress_mfa(cookie) $static::suppress_mfa(seconds) relative HTTP::cookie secure $static::suppress_mfa(cookie) enable HTTP::cookie httponly $static::suppress_mfa(cookie) enable HTTP::cookie encrypt $static::suppress_mfa(cookie) $static::suppress_mfa(passphrase) HTTP::header "Cache-Control" "max-age=$static::suppress_mfa(seconds)" } } } Hello, I have an iRule that creates a cookie on HTTP_Response, sets an expiratoin, and sets a Cache-Control. This worked perfectly for months, then we upgraded to 14.1.4 it stopped working. The access policy has 2 logins, the first is an MFA login (microsoft authenticator) and the second is a domain login (username/pw). When the cookie is created and while it is still valid any further logins will suppress the MFA portion of the access policy. In the iRule "when Rule_Init" an array is created. In the array there are 4 variables. This is used to set the cookie "when HTTP_RESPONSE". Upon the next login "when ACCESS_SESSION_STARTED" checks the cookie and sets a "hash" variable. Then "when ACCESS_POLICY_AGENT_EVENT" does a compare of the "hash" to the "value" if they match then it sets the bypass. If they do not then it continues with the "when HTTP_RESPONSE" portion and tries to create the cookie. Like I said it creates it one time for one person but never again until I flip over to the standby or reboot. I am thinking there has to be some sort of cache going on. I have been working on this since we upgraded and can not figure out why it is no longer working any help would be greatly appreciated. I modeled this after thishttps://devcentral.f5.com/s/articles/Suppress-MFA-for-a-period-of-time I just adapted it for my needs. Below is the portion that is not workingasm & apm in conjunction producing errors in apm log
apm log produces the following errors when vs is configured with asm policy and access policy. I suspect there are limitations on the types of access policies that can be used with asm. Does anybody know what these are? Access encountered error: ERR_NOT_SUPPORTED. File: ../modules/hudfilter/access/access.c, Function: access_enabled_asm, Line: 20577 Access encountered error: ERR_NOT_SUPPORTED. File: ../modules/hudfilter/access/access.c, Function: access_disable_plugins_for_access_control_requests, Line 24989 Access encountered error: ERR_NOT_SUPPORTED. File: ../modules/hudfilter/access/access.c, Function: access_forward_request_to_apd, Line: 15179 Access encountered error: ERR_NOT_SUPPORTED. File: ../modules/hudfilter/access/access.c, Function: access_process_state_client_wait_for_req_body, Line 3665 Access encountered error: ERR_NOT_SUPPORTED. File: ../modules/hudfilter/access/access.c, Function: hud_access_handler, Line: 2684
Large number of entries in WTMP file
Hi, I have been exploring a lack of disk space in the /var/log/filesystem. The biggest offender is the WTMP file. When look into the file using utmpdump I can see the login entries. I can see my connection as "root" to the device, but I also see there are entries every 10s even when no one is connected? Is this normal behaviour as it appears to be filling up the log file and taking disk space for not reason. The particular device is a virtual appliance running 12.1.2. Many thanks, Michael [6] [24081] [v/tt] [LOGIN ] [/dev/ttyS0 ] [ ] [0.0.0.0 ] [Wed Oct 11 09:16:39 2017 ] [8] [24081] [v/tt] [ ] [/dev/ttyS0 ] [ ] [0.0.0.0 ] [Wed Oct 11 09:16:49 2017 ] [8] [24082] [v/tt] [ ] [ ] [ ] [0.0.0.0 ] [Wed Oct 11 09:16:49 2017 ] [8] [24083] [v/tt] [ ] [ ] [ ] [0.0.0.0 ] [Wed Oct 11 09:16:49 2017 ] [6] [24084] [v/tt] [LOGIN ] [/dev/ttyS0 ] [ ] [0.0.0.0 ] [Wed Oct 11 09:16:49 2017 ] [8] [24084] [v/tt] [ ] [/dev/ttyS0 ] [ ] [0.0.0.0 ] [Wed Oct 11 09:16:59 2017 ] [8] [24085] [v/tt] [ ] [ ] [ ] [0.0.0.0 ] [Wed Oct 11 09:16:59 2017 ] [8] [24086] [v/tt] [ ] [ ] [ ] [0.0.0.0 ] [Wed Oct 11 09:16:59 2017 ] [6] [24087] [v/tt] [LOGIN ] [/dev/ttyS0 ] [ ] [0.0.0.0 ] [Wed Oct 11 09:16:59 2017 ] [8] [24087] [v/tt] [ ] [/dev/ttyS0 ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:09 2017 ] [8] [24092] [v/tt] [ ] [ ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:09 2017 ] [8] [24093] [v/tt] [ ] [ ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:09 2017 ] [6] [24095] [v/tt] [LOGIN ] [/dev/ttyS0 ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:09 2017 ] [8] [24095] [v/tt] [ ] [/dev/ttyS0 ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:19 2017 ] [8] [24101] [v/tt] [ ] [ ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:19 2017 ] [8] [24102] [v/tt] [ ] [ ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:19 2017 ] [6] [24103] [v/tt] [LOGIN ] [/dev/ttyS0 ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:19 2017 ] [7] [24106] [ts/0] [root ] [pts/0 ] [172.17.1.177 ] [172.17.1.177 ] [Wed Oct 11 09:17:19 2017 ] [8] [24103] [v/tt] [ ] [/dev/ttyS0 ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:29 2017 ] [8] [24132] [v/tt] [ ] [ ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:29 2017 ] [8] [24133] [v/tt] [ ] [ ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:29 2017 ] [6] [24134] [v/tt] [LOGIN ] [/dev/ttyS0 ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:29 2017 ] [8] [24134] [v/tt] [ ] [/dev/ttyS0 ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:39 2017 ] [8] [24136] [v/tt] [ ] [ ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:39 2017 ] [8] [24137] [v/tt] [ ] [ ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:39 2017 ] [6] [24138] [v/tt] [LOGIN ] [/dev/ttyS0 ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:39 2017 ] [8] [24138] [v/tt] [ ] [/dev/ttyS0 ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:49 2017 ] [8] [24301] [v/tt] [ ] [ ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:49 2017 ] [8] [24310] [v/tt] [ ] [ ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:49 2017 ] [6] [24314] [v/tt] [LOGIN ] [/dev/ttyS0 ] [ ] [0.0.0.0 ] [Wed Oct 11 09:17:49 2017 ]
