PA SMB deny behaviour

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

PA SMB deny behaviour

L4 Transporter

Hi,

 

We have detected a atrange behaviour with SMB session.

 

We have created a rule for blocking wannacry (SMB) sessions 

Captura2.JPG

 

We can see sessions being blocked:

 

Captura3.jpg

 

So all sessions from trust to untrust should be blocked but we have done a tcpdump in our ISP router an we see 

 

2017-11-21 20:01:46: 8x.x.x.x => 213.187.106.86:445
2017-11-21 20:01:46: 8x.x.x.x => 213.187.106.87:445
2017-11-21 20:01:46: 8x.x.x.x  => 213.187.106.88:445
2017-11-21 20:01:46: 8x.x.x.x  => 213.187.106.92:445
2017-11-21 20:01:46: 8x.x.x.x  => 213.187.106.93:445
2017-11-21 20:01:46: 8x.x.x.x  => 213.187.106.94:445

 

Why ISP is receiving sessions in port445 to untrust if we have deny all session from inside to outside????

 

Regards

 

1 accepted solution

Accepted Solutions

I've also reproduced and I am not able to reproduce your issue.

 

BUT!, I think i may have found the issue... this is my policy

policy.png

 

You may notice I used 'drop' and I'm getting all my 445 discarded as expected

 

you used 'Deny'

deny vs drop.png

 

Deny requires an application to decide the appropriate 'reject' action for the application

 

if you need to actively reject i'd propose you use 'Reset Client' instead

 

 

 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

View solution in original post

13 REPLIES 13

Cyber Elite
Cyber Elite

try filtering your policy on "( action neq deny ) and ( port.dst eq 445 )" instead of your rule to see if there's anything allowed

 

also try one with ( addr.dst in 213.187.106.86 ) to see if it shows up in any other form

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

There is not any session being alloweb with neq deny.

I think PA is permitting the 3way handshake to detect the app (so these packets is ahwt we see in ISP router) but we have denied by service, i think PA shouldnt permit 3way handshake.

 

using this filter ( addr.dst in 213.187.106.86 ), we dont see any logs in PA. Weird......

 

Its a bit strange...

No, the 3way handshake is alowed through if you have a policy that includes applications. You have 'any' so the action is applied on the port.

 

Is it possible the connection could have originated from a different source zone? (the policy is only for trust). Could someone have connected a host on the outside network segment?

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

ammmmmm, i though that if i block using service 445 the 3way is not done. So how can i do in order to discard all connections in 445, so ISP router wont receive this traffic????

 

 

cap.JPGThis is the session browser right now. I think that the 445-SMB  traffic that we are seeing in ISP router is because of threeway-handshake. But how can discard this traffic in order to not see it in ISP??

if you use only ports, 3 way handshake is not allowed

 

can you do a > show running security-policy to verify the policies?

are the negated subnets necessary? can you try removing them?

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

This is the rule by CLI: 

 

"Block 445 Wannacry" {
from trust;
source any;
source-region none;
to untrust;
destination [ 0.0.0.0/5 8.0.0.0/7 11.0.0.0/8 12.0.0.0/6 16.0.0.0/4 32.0.0.0/3 64.0.0.0/4 80.0.0.0/6 ];
destination-region none;
user any;
category any;
application/service [ any/tcp/any/445 any/udp/any/445 ];
action deny;
icmp-unreachable: no
terminal no;
}

 

Ill create a first rule permiting the traffic in our networks, and below ill create another one denying.

 

I read SMBv3 is encrypted, it could be that 3way handshake should be done in order to know app????

the 3 way handshake is NOT allowed in this particular rule because you have 'any' in the application , 2 ports and deny. this means any packet matching destination port 445 will be dropped

 

it IS possible (since this is rule #3, the 3 way handshake is being allowed by rule #1 or #2 (if they allow port 445 and have an (different) application, because then we DO allow the handshake to be able to identify the application)

 

so maybe this rule needs to move up to #1

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Exactly, that what i think. Three-way is not enabled filtering by service.

 

Rules 1 y 2 are deployed by panorama, and the sources are specific hosts. So it shouldnt be the problem......

 

cappp.jpg

 

I tried to create a first rule permitting, and second one denying, but the problem is the same. 3way is done.

I have replicated this problem i my lab in version 8.0.5 and 3way is done fitlering by port 😞

it seems like normal behaviour in PA. Can someone confirm if you create a rule denying port 445, the 3way is done??

 

thanks alot

Ok I will admit this is weird

 

can you try setting up a flow basic to see what is happening exactly ?

 

 

 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Hi reaper,

 

I replicated the problem in my lab. I created a rule denying port 445 sessions and i can see this traffic in logs. It seems like 3way is done using SMB althoug you are denying by port445.

it seems like a bug or normal behaviour PA.

I've also reproduced and I am not able to reproduce your issue.

 

BUT!, I think i may have found the issue... this is my policy

policy.png

 

You may notice I used 'drop' and I'm getting all my 445 discarded as expected

 

you used 'Deny'

deny vs drop.png

 

Deny requires an application to decide the appropriate 'reject' action for the application

 

if you need to actively reject i'd propose you use 'Reset Client' instead

 

 

 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization
  • 1 accepted solution
  • 6849 Views
  • 13 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!