very strange / bad issue

[Luca]

Got a call from a customer saying that people can access their site on port 80 which they have not request to be opened.  It should only be 443.  So i checked the firewall to see why this was happening.  I couldn't see any policy that was allowing port 80 to that customer. 

I did a 'show security flow session ........ ' command to find the policy that was permitting the traffic; see below:

show security flow session destination-prefix 125.xx.xx.44 destination-port 80
node0:
--------------------------------------------------------------------------

Session ID: 272175, Policy name: staticnat-untrust-trust-10-52-10-93/91, State: Active, Timeout: 1798, Valid
  In: 203.xx.xx.100/51545 --> 125.xx.xx.44/80;tcp, If: reth0.301, Pkts: 16, Bytes: 4727
  Out: 10.52.10.93/80 --> 203.xx.xx.100/51545;tcp, If: reth0.1933, Pkts: 10, Bytes: 2293
Total sessions: 1

So from that you can see the policy that us permitting the traffic is: staticnat-untrust-trust-10-52-10-93

So i checked the policy:

show configuration security policies from-zone untrust to-zone trust policy staticnat-untrust-trust-10-52-10-93
match {
    source-address any;
    destination-address 10-52-10-93;
    application [ tcp-3389-3389 tcp-443-443 tcp-444-444 ];
}
then {
    permit;
    count;

There us nothing in that policy that is permitting port 80.  I checked the applictions just to make sure they were not configured wrong but there is nothing permitting port 80 to that customer.

What is going on here?  Is the info in the 'show security flow session destination-prefix 125.xx.xx.44 destination-port 80' command wrong?  Could there be another policy?

To fix this i just put a deny at the top of the conifg but this worries me a bit.  Any thoughts?  Is there any other way to find out what policy is permitting the traffic?  I can't see it anywhere in security flow traceoption either but that also shows the traffic is being permited.

Thanks.

[motd]

Check for errors in the definitions of those custom applications.They may allow more than their name suggests.

An easy way to check this is using the following command:

show security policies from-zone untrust to-zone trust policy staticnat-untrust-trust-10-52-10-93 detail

the detail output also includes all of the applications (and corresponding port ranges).

[Luca]

The applciations are configured correctly.

'show security policies from-zone untrust to-zone trust policy staticnat-untrust-trust-10-52-10-93 detail'

Destination addresses:
    10-52-10-93: 10.52.10.93/32
  Application: tcp-3389-3389
    IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
      Source port range: [0-0]
      Destination port range: [3389-3389]
  Application: tcp-443-443
    IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
      Source port range: [0-0]
      Destination port range: [443-443]
  Application: tcp-444-444
    IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
      Source port range: [0-0]
      Destination port range: [444-444]

[motd]

So much for my first guess

Next, see if there isn't any destination-nat configured on the device that changes the destination-port.

Also, make sure this stll occurs with new sessions created now. If that policy allowed any in the past and the session is still open, that would still be permitted. Changing policies does not re-evaluate existing sessions by default.

Finally, i would run a "commit full" just to be safe. Never had a problem with firewall policies not being pushed correctly, but there is a first time for everything.

[Luca]

So this has happened again on the same firewall.  It is permitting traffic when there is no policy permitting it.

For example - it is allowing traffic to port 80, as shown below:

firewall> show security flow session destination-prefix 202.xxx.xxx.xxx destination-port 80    
node0:
--------------------------------------------------------------------------

Session ID: 41867, Policy name: staticnat-untrust-trust-10-0-253-171/279, State: Active, Timeout: 1800, Valid
  In: 121.xxx.xxx.xxx/9681 --> 202.xxx.xxx.xxx/80;tcp, If: reth4.302, Pkts: 2, Bytes: 92
  Out: 10.0.253.171/80 --> 121.xxx.xxx.xxx/9681;tcp, If: reth0.1116, Pkts: 1, Bytes: 52
Total sessions: 1

So i look at the policy mentioned above:

firewall>show configuration security policies from-zone untrust to-zone trust policy staticnat-untrust-trust-10-0-253-171 
match {
    source-address any;
    destination-address 10-0-253-171;
    application tcp-3389-3389;
}
then {
    permit;

 the application tcp-3389-3389 is configured correcrtly:

firewall> show configuration applications application tcp-3389-3389           
protocol tcp;
destination-port 3389;

So as you see, the policy that is telling me is permitting the traffic, actually has no port 80 configured.  If i deactivate this policy then port 80 gets stopped, but if I activate it again port 80 is allowed.

This is an SRX650 cluster running  10.4R1.9.

The last time this happened i logged a JTAC ticket but they were unable to find the problem, it ended up getting fixed when I did a routing-engine failover between the nodes.

Anyone got any thoughts on this?  I will log it with JTAC again.

[pk]

Hi

Looks really strange. But maybe you should try an upgrade. Using R1 in 

production is generally not a good idea.

[Luca]

Yea i'm thinking its some type of bug....

very worrying though