AFM 11.6.0 HF5 error after virtual rename
I have a pair of VE (BEST) in HA, that I'm using to test version 11.6.0 HF5, pending their use in a new datacenter we are setting up The system has LTM, AFM, ASM and APM provisioned at 'nominal' The current configuration has no policies in both ASM and AFM, I'm still testing LTM & APM. Then I did the following: root@(myhost01)(cfg-sync In Sync)(Active)(/Common)(tmos) modify /sys db mcpd.mvenabled value true root@(myhost01)(cfg-sync Changes Pending)(Active)(/Common)(tmos) save sys config Saving running configuration... /config/bigip.conf /config/bigip_base.conf /config/bigip_user.conf Saving Ethernet mapping...done root@(myhost01)(cfg-sync Changes Pending)(Active)(/Common)(tmos) mv ltm virtual ZSVR_TEST_SECURE_10443 VSVR_TEST_APM root@(myhost01)(cfg-sync Changes Pending)(Active)(/Common)(tmos) Jul 16 18:33:03 myhost01 emerg pccd[12228]: 015d0000:0: Transaction failed. root@(myhost01)(cfg-sync Changes Pending)(FIREWALL UPDATE FAILED)(/Common)(tmos) OOPS! Apparently the AFM broke. I can return it back to green by issuing the command: restart sys service pccd But I don't know if this error can have consequences for future operations... I know the rename function is in 'early access' mode, so little or no support can be expected, but do you think I need to reset the config from scratch? Thanks, Angelo.
Implementing Lightweight East-West Firewalls with F5
In 2005, perpetual diva Miss Piggy portrayed all four of the directional witches (North, South, East and West) in Jim Henson’s Muppet’s Wizard of Oz. Despite a vigorous and, occasionally violent, performance, she was snubbed at the Academy Awards, ultimately losing out to Reese Witherspoon (Walk the Line). Maybe the Academy Awards voters understood this key principle that escaped our porcine starlet: East and West are fundamentally different from North and South. This is certainly true for the modern enterprise datacenter architecture. When you look at an architectural diagram of a single datacenter, the Internet is at the top (North) and users at the bottom (South). In between are the DMZ and services. These services are applications, virtualized servers and databases and they communicate with each other laterally (often portrayed west to east). N-S networking is considered the traditional perimeter and the conventional home of giant firewalls. E-W is the home of virtualized services, and sometimes N-S security teams don’t get invited to play in the sandboxes. So E-W traffic can be left unguarded. But it shouldn’t be that way; network policy can be implemented quickly with the F5 load-balancers already in place. Let’s take a look at an example E-W layout. Security in an East-West Network Security Traffic is flowing from the web servers east-ward through a middleware cluster and ultimately to the database cluster at the east end. All good. There should never be traffic going from the web servers to the development network, right? Web servers are a huge threat surface: when they get hacked we don’t want the attackers to be able to get into the intellectual property in development. The same goes for the middleware network, it should only talk to the database cluster network. And connections from the database cluster should never go into the development network either. Let’s redraw the diagram with the red lines to indicate connections that we want to prevent. So how can we implement this in a way that doesn’t disrupt everything or require new hardware? Lightweight Firewall Rule for Web Apps Cluster via F5 In the example above, there is an F5 application delivery controller (ADC) in between the web applications and middleware and another in front of the database cluster. Suppose the ADCs are providing simple load balancing for the application traffic running west to east. The web servers are the most interesting section of the architecture. They accept traffic from the Internet (via the ADC) and are typically configured to use the ADC as their default gateway. About the default gateway: historically,the ADC has always passed the original client IP address to the web server for logging purposes. The web server then has to use the ADC as the default gateway when it replies back the client (otherwise the traffic would go around the ADC, and that doesn’t work for proxy and cache services). On the F5 we’ll create three VLANs and virtual server objects to represent the three types of flows that we’re looking for. web-app1 : inbound traffic to web application. middleware : eastbound requests into middleware web-gw : default gateway traffic (mostly traffic from web-pool) The web-app1 virtual server defines a single public address for inbound web traffic to our application. net vlan internet { } ltm virtual web-app1 { description "internet to web app" destination 71.237.39.99:http pool web-pool profiles { http { } tcp { } } vlans { internet } } Because the web servers are accepting routable IP addresses (see sidebar), they have their default gateways set to a wildcard virtual server at the F5. The return traffic will be matched to the incoming flows. net vlan web { } ltm virtual web-gw { description "gateway to middleware" destination 0.0.0.0:any fw-enforced-policy web-gw profiles { fastL4 { } } source 192.168.2.0/24 translate-address disabled translate-port disabled vlans { web } } Web Servers: 192.168.2.0/24 Middleware: 10. 0.0.0/8 Development: 20.0.0.0/8 Database Cluster:172.16.0.0/16 Notice the destination 0.0.0.0:any. This is necessary to allow the webservers to communicate to the outside world. But suppose that an attacker got a shell on the web-server. He could then use the wildcard server to tunnel through to the development network (20.0.0.0). Not what we want. So we define a lightweight firewall rule (fw-enforced-policy web-gw) to prevent packets from getting into the development network. security firewall policy web-gw { rules { w-to-m { action reject description "Disallow development" log yes destination { addresses { 20.0.0.0/8 { } } } } } } Here’s what that rule looks like in the GUI. We’re not specifying the source network because this is only enabled on the “web” VLAN anyway (and therefore wouldn’t be acting on other traffic). Lightweight Firewall Rule for Middleware Cluster via F5 The middleware virtual server defines a single address for the web servers to communicate to a pool of middleware servers. ltm virtual middleware { description "webapp to middleware" source 192.168.2.0/24 destination 192.168.2.202:7001 pool mid-pool profiles { tcp { } } vlans { web } } The middleware virtual server has a source network specification which will act as a firewall rule all by itself. Only traffic originating from the web network will be able to pass through to the middleware cluster. It doesn’t get much more lightweight than this. If we want to prevent connections originating from the middleware tier cluster westward to the web app cluster, we can define a global firewall rule to handle this. Note that we leave a “hole” for development to push to the web app cluster. Lightweight Firewall Rule for Database Cluster via F5 The right-hand F5 ADC will very similar to the left-hand ADC. For our simple example, we have a virtual server balancing to a single pool of database servers and they should only be accessed from the middleware. Just as we did for the web app cluster, we can use the source and destination attributes of the virtual server to create an east-bound flow. ltm virtual mid-to-db { description "middleware to database" source 10.0.0.0/8 destination 10.10.10.10:3306 pool db-pool profiles { tcp { } } vlans { middleware } } We’ll also add a global firewall rule to prevent connections originating from the database cluster back toward the middleware or development. Add one exception: every Saturday night from 8PM to midnight the database clusters will be allowed to access the Internet to pull down updates. Is that Lightweight enough for you Miss Piggy? “Hiiii-yaaah!” See how easy and lightweight that was? Much of the security enforcement is already bound into the definitions of the virtual server objects themselves, leaving us with just handful of global firewall rules. Full disclosure here: I simplified this configuration a little bit for clarity. The full configuration is larger and you’d probably have a SNAT pool in between the clusters where default gateways are used. But hopefully you get the gist that it is possible, with relatively little effort, to attach lightweight firewall rules to manage the east-west traffic in your datacenter.
Different file size and checksum for BIG-IP images
Hi, Is it normal that BIG-IP image files are different size on active and standby units in a cluster (same hardware platform): [jay@F5-4000-a:Active:In Sync] images ls -la | grep 11.4.1.608 -rw-r--r-- 1 root root 1484894208 Oct 30 02:59 BIGIP-11.4.1.608.0.iso [jay@F5-4000-b:Standby:In Sync] images ls -la | grep 11.4.1.608 -rw-r--r-- 1 tomcat tomcat 1575387136 Mar 11 2014 BIGIP-11.4.1.608.0.iso Both units are in active/standby cluster and failover works. Cheers, Jay
blocking port 80 with a policy at the global level not working
Hi, I am trying to block port 80 on bigip AFM using following rule. But some reason its not getting hit. curl -sk -u admin:admin https://192.168.6.158/mgmt/tm/security/firewall/policy/ocpolicy/rules -H 'Content-Type: application/json' -X POST -d '{"name": "dport80","action": "drop","ipProtocol": "tcp","place-before": "first","destination": {},"source": {"ports": [{"name": "80"}]}}' If I apply a rule saying block tcp protocol it just works fine. curl -sk -u admin:admin https://192.168.6.158/mgmt/tm/security/firewall/policy/ocpolicy/rules -H 'Content-Type: application/json' -X POST -d '{ "name":"dtcp","action":"drop","ipProtocol":"tcp","place-before":"first","destination":{},"source":{}}' I am using the BIG IP in a l2 bridge mode, I have 2 vlans and created a vlan group and added a self IP to vlan group.
F5 Viprion power supply log
Hi Guys, Currently, we are planning to install F5 VIPRION 4480N along with one Blade 4300 type. Because of limited number of source power, we are planning to use 2 power supplies per-chassis. Power supply 1 and 4. Today, we powered-up this VIPRION on our lab. And found out that the power supply alarm and led keep blinking though we had cleared it several time before. The system displayed below log continously: Jun 9 03:40:02 slot1/localhost emerg system_check[11423]: 010d0006:0: Chassis power supply 2 has experienced an issue. Status is as follows: STATUS=bad. Jun 9 03:40:02 slot1/localhost emerg system_check[11423]: 010d0006:0: Chassis power supply 3 has experienced an issue. Status is as follows: STATUS=bad my question: 1. Is it okay to use only 2 power supplies only out of total 4? 2. Is there any way to disable this alarm? Thank you for any input
After upgrading Symantec can not go through F5 SSL
Dear All Seeking support on after upgrading Symantec end point client can not go through F5; any idea why. Seems multiple error: [log_id2015011310152754b47fbf9fd55] => [detected_av] => Array ( [av_1] => Array ( [agent_id] => OPSWAT_AV [data_version] => 1.0 [protect] => [update] => [need_update] => [expression_id] => [name] => MicrosoftAS [features] => 2 [engine_version] => 1.1.10201.0 [database_version] => 1.165.1076.0 [database_signature] => [database_time] => 2014.01.03 08:02:19 [monitor] => disabled [last_scan] => undefined [gui_state] => hidden [description] => Windows%20Defender [database_age] => 375 [r_log_0] => Criteria failed - not an antivirus ) [av_2] => Array ( [agent_id] => OPSWAT_AV [data_version] => 1.0 [protect] => [update] => [need_update] => [expression_id] => [name] => NortonAV [features] => 3 [engine_version] => [database_version] => [database_signature] => [database_time] => undefined [monitor] => enabled [last_scan] => undefined [gui_state] => hidden [description] => Symantec%20Endpoint%20Protection [database_age] => unknown [r_log_0] => Criteria failed - older than 30 days: unknown ) [summary] => Array ( [count] => 2 ) ) Thanks SimonsciControlREST: issue with security DOS path
I see, when doing curl -k -u https:///mgmt/tm/security/dos/device-config { "items": [ { "dosDeviceVector": [ { "defaultInternalRateLimit": "100000", "detectionThresholdPercent": "500", "detectionThresholdPps": "10000", "name": "arp-flood" }, when doing curl -k -u https://localhost/mgmt/tm/security/dos/device-config/stats { "entries": { "https://localhost/mgmt/tm/security/dos/device-config/ARP%20flood/stats": { "nestedStats": { "entries": { "common.attackCount": { "value": 0 }, Note: "arp-flood" is now "ARP flood" Then calling curl -k -u https://localhost/mgmt/tm/security/dos/device-config/ARP%20flood/stats I get { "code": 404, "errorStack": [], "message": "01020036:3: The requested DoS Device configuration (/Common/ARP) was not found." }SMTP iApp Template - Early Release
Problem this snippet solves: INITIAL RELEASE Minimum required BIG-IP version: 11.4.0. Supported BIG-IP versions: 11.4.0-12.0 v1.0.0rc1 iApp template for configuring standard load balancing, monitoring, SSL offloading, and TCP optimization for Simple Mail Transfer Protocol (SMTP). The template also supports deploying F5's Advanced Firewall Manager (AFM), when AFM is licensed and provisioned. v1.0.0rc2 There were no changes to the functionality in this release. Minor changes to clarify some of the questions and answers. Added inline help entries. v1.0.0rc3 Fixed an issue with the associated cli script that could prevent users from importing iApp templates. v1.0.0rc4 Fixed an issue with selecting password-protected encryption keys. To use a password-protected encryption key, you must create an SSL profile that uses the key and specify that profile where indicated in the iApp template. v1.0.0rc5 Fixed an issue with incorrectly formatted external monitor scripts. v1.0.0rc7 Fixed an issue with monitors utilized in the server-side ssl scenarios, as a result the openssl eav monitor is used in the 'no msg submitted' monitor scenarios. A fifth monitor option was presented as well to break the 'auth/no msg' option into basic and ntlm so the iApp can use openssl if Basic(auth login) is selected. - This release also allows a custom receive string to be specified(advanced must be selected). v1.0.0rc8 Minor updates and enhancements to the monitor choices. For the associated deployment guide, see [http://www.f5.com/pdf/deployment-guides/f5-smtp-dg.pdf] Contributed by: F5 Code : 83126 Tested this on version: 12.0
