For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

hoolio's avatar
hoolio
Icon for Cirrostratus rankCirrostratus
Jun 14, 2007

TCP port logging/decision-making with a FastL4 profile

Hello,

Can someone provide more info on why MCP validation of iRules prevents using TCP:: commands with a forwarding IP virtual server/fastL4 profile?

The reason I ask, is that I'd like to give a customer a rule which allows them to selectively drop traffic through a 0.0.0.0:0 IP forwarding virtual server based on the source IP/network and/or the destination IP/network and ports. The current restriction on TCP::commands means we can only make IP level decisions. This reduces the value of the rule significantly.

There have been a few posts on this but I haven't seen a definitive answer:

http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&forumid=5&postid=7986

01070394:3: TCP::client_port in rule (tcp_test) requires an associated TCP profile on the virtual server (ipforward_test).

http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&forumid=5&postid=8701

port filtering for a forwarding IP virtual server that uses a fastL4 profile with Loose Initiation and Loose Close enabled

If you either disable MCP validation of rules in the db, or use a trick to bypass the validation, it seems like you can access the port information. This test on 9.2.5 logged the correct ports and the connection worked through the BIG-IP:


when CLIENT_ACCEPTED {
    log the client IP address:port -> destination IP address:port
   set src_port_cmd TCP::client_port
   set dest_port_cmd TCP::local_port
   set src_port [eval $src_port_cmd]
   set dest_port [eval $dest_port_cmd]
   log local0. "client: [IP::client_addr]:$src_port -> [IP::local_addr]:$dest_port"
}

: client: 192.168.101.10:34040 -> 192.168.101.149:80

So if the information is actually available, why does MCP prevent adding a TCP:: command? Is there any downside to accessing the info with a fastL4 virtual server?

Thanks,

Aaron

application delivery
dev
devops
iRules

3 Replies

  • spark_86682's avatar
    spark_86682
    Historic F5 Account
    Jun 14, 2007
    For a forwarding profile, your two choices are "Layer 2" or "IP", either of which can have non-TCP traffic on them, so the TCP::* commands might not be valid on any given packet.

     

     

    For a fastL4 profile, the TCP::* commands are accepted on v9.4.0 (as it seems like they should be), so that's probably a bug that was fixed.

     

     

    All that said, it seems like you have a good workaround.
  • Mark_Porter_979's avatar
    Mark_Porter_979
    Icon for Nimbostratus rankNimbostratus
    Dec 14, 2007
    I'm in the same predicament, but upgrading to 9.4 isn't likely to happen for several months. Luckily I only had 100 ports to lock down, so I used two really ugly packet filter rules.

     

     

    I would still like to be able to do it with an iRule attached to a forwarding vs, though. Aaron mentioned disabling MCP checking in the db - can anyone point me in the right direction on how to do that?
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Dec 14, 2007
    Hi,

    You can use the example workaround from above to get the TCP source and/or destination port, without disabling the MCP validation. The destination port is the port the client made the request to.

    
when CLIENT_ACCEPTED {
    log the client IP address:port -> destination IP address:port
   set src_port_cmd TCP::client_port
   set src_port [eval $src_port_cmd]
   set dest_port_cmd TCP::local_port
   set dest_port [eval $dest_port_cmd]
   log local0. "client: [IP::client_addr]:$src_port -> [IP::local_addr]:$dest_port"
   if {$dest_port > 1024}{
       requested port was over 1024, so drop it
      drop
   } elseif {$dest_port > 100 and $dest_port <= 1024}{
       port was over 100 and less than 1024 so forward the request
      forward
   } else {
       requested port was less than 100, send a RST
      reject
   }
}

    Aaron