- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
11-22-2017 06:10 AM
Hi,
We have detected a atrange behaviour with SMB session.
We have created a rule for blocking wannacry (SMB) sessions
We can see sessions being blocked:
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
11-23-2017 01:44 AM
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
You may notice I used 'drop' and I'm getting all my 445 discarded as expected
you used 'Deny'
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
11-22-2017 06:19 AM
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
11-22-2017 06:36 AM
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...
11-22-2017 06:43 AM
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?
11-22-2017 06:46 AM
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????
11-22-2017 06:53 AM
This 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??
11-22-2017 07:24 AM
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?
11-22-2017 07:38 AM - edited 11-22-2017 08:41 AM
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????
11-22-2017 07:49 AM - edited 11-22-2017 07:49 AM
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
11-22-2017 07:56 AM
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......
11-22-2017 08:30 AM - edited 11-22-2017 08:37 AM
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
11-22-2017 08:37 AM
Ok I will admit this is weird
can you try setting up a flow basic to see what is happening exactly ?
11-22-2017 08:41 AM
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.
11-23-2017 01:44 AM
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
You may notice I used 'drop' and I'm getting all my 445 discarded as expected
you used 'Deny'
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
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!