5 Replies Latest reply on Oct 27, 2011 11:05 AM by PhilM

    Nettraffic with ACL:DENY ALL

      Hi ,

       

      I am experiencing many audit logs

       

       

      Oct 18 10:17:06 2011 SGT  f_http_proxy a_libproxycommon t_nettraffic p_major

      pid: 2225 ruid: 0 euid: 0 pgid: 2225 logid: 0 cmd: 'httpp'

      domain: htpp edomain: htpp hostname: xxxfw.agc.gov.sg 

      event: proxy traffic end service_name: All-TCP-UDP-Packet-Filter 

      netsessid: 4e9ce1a1000b1184 srcip: xxx.xxx.161.23 srcport: 63718 

      srcburb: external protocol: 6 dstip: xxx.xxx.6.222 dstport: 8111 

      dstburb: external bytes_written_to_client: 413 

      bytes_written_to_server: 0 acl_id: Deny All cache_hit: 0 

      request_status: 0 start_time: Tue Oct 18 10:17:05 2011

       

      I am wondering if this log indicates a blocked traffic.

       

       

      How do I interpret this log?

       

      Regards,

      Sam

        • 1. Re: Nettraffic with ACL:DENY ALL
          PhilM

          Sam,

           

          These audit logs can take a while to get used to and understand, but all of the information you need is present:-

           

          srcburb: external - The source burb

          srcip: xxx.xxx.161.23 - is the IP address of the source machine

          dstburb: external - The destination burb

          dstip: xxx.xxx.6.222 - is the destination it is trying to contact

          dstport: 8111 - is the port number

          service_name: All-TCP-UDP-Packet-Filter  - is the name of the Firewall service which is the best match to this port number

          acl_id: Deny All - is the name of the rule

           

          So the source host ending in 161.23 is trying to access port 8111 on the host ending in 6.222.

           

          As both source and destination burb values are "external" this would translate to someone on the Internet trying to access port 8111 on the external interface of your Firewall. This port is used by the "sso" server service on the Firewall which is normally enabled when Passport authentication is configured.

           

          If you are not actually using the Passport/SSO service, then one of the reasons why this port is visible to the outside world (you would see netprobe audit messages instead of acl deny ones) is the fact that the "All-TCP-UDP-Packet-Filter" service must be being used for an inbound rule.

           

          I hope that helps.

          Phil.

          • 2. Re: Nettraffic with ACL:DENY ALL

            Hi Phil,

             

            Thanks for your help. It does help to clarify a little. I have some questions.

             

            Yes. We have configured the firewall with Passport Authentication.

             

            I am puzzled by this log. It says the traffic hits the "Deny All" rule. But no one in my company complains about not being able to get authenticated.

             

            Does it mean as long as the traffic is from "external" to "external", it will hit the "Deny All" rule?

             

            I tried creating an Allow Rule. But it doesnt help.

             

            The traffic (source-dest) is legtimate. Does it mean this log is giving false alarm?

             

            Many Thanks,

            Sam

            • 3. Re: Nettraffic with ACL:DENY ALL
              PhilM

              If the passport service is working as you expect it to then that's good.

               

              Sometimes, audit records come in pairs, and while I am personally less familiar with the workings of Passport service maybe this is one case where there is actually another audot record appearing before the deny all which would complete the picture.

               

              I am seeing a scenario where someone has run a port scan, discovered that port 8111 is listening and is then trying to connect to it. The Passport service is responding to this and requesting login credentials. The login attempt fails, generating an audit message against the Passport rule you have created, but the connection then continues to be processed by the firewall rules, eventually hitting deny all and this is the audit record you have included in your original post.

               

              There are a couple of McAee guys lurking on this forum who may be able to offer greater insight into this situation. Otherwise, I'd recommend raising a ticket with McAfee support in order to get an answer to your question.

               

              Phil.

              • 4. Re: Nettraffic with ACL:DENY ALL

                Hi Phil,

                 

                There is actually a log after the Deny All traffic log.

                 

                1)

                Oct 26 11:11:55 2011 SGT  f_http_proxy a_libproxycommon t_nettraffic p_major

                pid: 2225 ruid: 0 euid: 0 pgid: 2225 logid: 0 cmd: 'httpp'

                domain: htpp edomain: htpp hostname: xxxxx.xxx.com.sg

                event: proxy traffic end service_name: All-TCP-UDP-Packet-Filter

                netsessid: 4ea77a7b00049877 srcip: xx.xxx.161.115 srcport: 55184

                srcburb: external protocol: 6 dstip: xx.xxx.6.222 dstport: 8111

                dstburb: external bytes_written_to_client: 413

                bytes_written_to_server: 0 acl_id: Deny All cache_hit: 0

                request_status: 0 start_time: Wed Oct 26 11:11:55 2011

                 

                2)

                Oct 26 11:12:29 2011 SGT  f_http_proxy a_libproxycommon t_nettraffic p_major

                pid: 2225 ruid: 0 euid: 0 pgid: 2225 logid: 0 cmd: 'httpp'

                domain: htpp edomain: htpp hostname: xxxxx.xxx.com.sg

                event: proxy traffic end service_name: ssod netsessid: 4ea77a9d000869f0

                srcip: xx.xxx.161.115 srcport: 55194 srcburb: external protocol: 6

                dstip: 127.0.0.1 dstport: 8080 dstburb: Firewall

                bytes_written_to_client: 956 bytes_written_to_server: 676

                acl_id: Passport cache_hit: 0 auth_method: LDAP user_name: xxxkc

                request_status: 0 start_time: Wed Oct 26 11:12:29 2011

                 

                Based on these, does this make better sense? I just couldn't comprehend why the traffic hits 'Deny All' rule and later goes to 'Passport' rule.

                 

                Hopefully someone can offer greater insights to this.

                 

                Thanks & Regards,

                Samuel Sim

                • 5. Re: Nettraffic with ACL:DENY ALL
                  PhilM

                  Samuel,

                   

                  As I mentioned previously , my own experience of the Passport service is minimal. Before you I've only encountered it (in a live customer environment) twice in the 10+ years I've been working with Sidewinder and both times have been within the past 6 months.

                   

                  I keep coming back to the fact that the "Deny All" audit record is referencing this "All-TCP-UDP-Packet-Filter" service.

                   

                  I'm hoping that you don't have the need to provide someone with completely transparent inbound access through your Firewall (I'd suggest using a VPN instead just to ensure the connection is at least encrypted), but if you do currently have a rule using this service, can I suggest that you temporarily disable it and see if this makes any difference to the behaviour of the audit when someone tries to log into the Passport service?

                   

                  If the Deny All audit entry disappears, this rule using this packet filter service is likely to be the reason. Try moving this rule below the one providing access to the passport server and see what happens.

                   

                  Phil.