5 Replies Latest reply: Apr 2, 2013 11:01 PM by russel RSS

    Port/Application Authority


      Hello all, I have question concerning what's being identified as an attack in firewall enterprise 8.3. There is a rule that allows my SCCM server to talk to the clients over SMB on port TCP 445. The log is showing me traffic being denied by policy with the type as an attack when the SCCM server tries to talk to clients on TCP 445. The log shows the application as being NDMP, which uses a default port of TCP 1000. So in summary the firewall is identifying packets from my SCCM server to the clients as application NDMP using port TCP 445 and blocking the traffic. I have rules in place that allow SMB which uses TCP 445 and allows NDMP wich uses TCP 1000. Which has authority, the TCP port or the identified application? Should I create a custom application for NDMP on TCP 445 and remove my existing SMB and NDMP on standard ports from the rule? Thanks for your time.

        • 1. Re: Port/Application Authority

          What exact firewall version and patch level are you at?

          What version of the appdb signatures do you have installed?  It's 'cf appdb v' on the command-line, or under Maintenance -> Updates in the GUI.

          • 2. Re: Port/Application Authority

            Firewall version: 8.3.0

            Application signature: 3.101

            • 3. Re: Port/Application Authority

              This was fixed in sigset 3.148.  The current sigset is 3.188.  If you upgrade your app. signatures this will work correctly.

              • 4. Re: Port/Application Authority

                How are the deny records identifying the application?


                If the application listed is <Unknown TCP> you may well be seeing something which is a characteristic of version 8. When implementing rules that make use of the new signature-based application entries, the Firewall has to pass a packet or two through so that it can inspect the traffic flow, match the traffic signature to an application definition and then see if there is a rule in place to allow or deny it. These initial packets are denied and are identified as <Unknown TCP> or <Unknown UDP>.


                I have found on more than one occasion this is enough for the 'client' to decide that communication with the 'server' isn't possible and it gives up. There have been numerous discussions about this behaviour in other threads.


                My own experience concerned a customer who was replacing an old 210F appliance (running with an S1104 box. Because his configuration was quite simple, the decision was taken to install and configure the new system as if it were brand new. One of the rules I needed to create allowed a server on his DMZ to communicate back to the internal LAN using the Kerberos protocol. Knowing that v8 had a dedicated "Kerberos" application entry I chose to use this. At first it seemed that all was well, but the following day the customer contacted me to say that the service running on his DMZ wasn't working. When I looked at the audit I could see entries from this server on the correct port, but it was being identified as <Unknown TCP>. I logged a support call and they suggested that instead of using the "Kerberos" application create a user-defined application for the port number in question and substitute it in the rule. As soon as I did this the customer's DMZ service erupted into life. The weird thing was that I was watching the audit at the time and saw the moment when it started to work. The first couple of entries referenced the service by the user-defined name we had given it, and then (without warning) it started to report the traffic as being "Kerberos".


                When a rule is put in place that uses a user-defined application, the Firewall doesn't seem to go through this initial check - this results in a working connection, because those initial packets aren't treated as "Unknown", but it does seem that it is eventually able to work out what protocol it actually is.



                • 5. Re: Port/Application Authority

                  Thanks for the information. I tried upgrading to 8.3.1 from 8.3.0 and suffered an unrecoverable error. I ended up having to re-image the firewall. Luckily it was in the dev environment. I have not been allowed to upgrade in production yet, so I can't verify that the suggested application sigset will resolve the issue. I will update when possible.