- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
12-08-2013 01:05 PM
Hi,
I am trying to configure a rule on the PA2050 to allow SKYPE out of the network, and I am seeing a bit of a security hole in the app rule.
I have set it up using the document:
https://live.paloaltonetworks.com/docs/DOC-1505/controllingskype.pdf
I have:
From Zone: Trust
to Zone: Untrust
Address: <My Workstation>
Application: SKYPE, SKYPE-PROBE, UNKNOWN-UDP
Service: Application Default
If I do a telnet to an IP address on the internet on a random port, it gets through OK using this rule, in the logs I see:
From <My Workstation>, to <Internet Address>, <Port Numbers>, Application Incomplete, action ALLOW, Rule <Skype Allow Rule>
At the other end I can see the TCP connection establish correctly.
The firewall should be blocking the traffic, as the traffic is NOT skype traffic, but it seems using SKYPE as the application ID it will allow any other unwanted traffic out.
Have I done something wrong in setting up the rule, or is this a bug?
Thanks
12-08-2013 10:54 PM
jenkinsp,
Your rule appears to be configured correctly and the firewall is also acting as it should.
The PAN firewall will allow sessions to be created based on the 6-tuple key (source_address, destination_address, source_port, destination_port, protocol & security_zone) so that enough data (Layer7) packets can flow through, in order for the application engine to identify the application.
Once the app engine identifies your traffic as SKYPE or otherwise, then the firewall makes the decision to allow or deny the rest of the traffic based on the identified application.
For your test, when you telnet to the external IP and port, the firewall would first create a session with the application as 'undecided', which is enough to allow the SYN, SYN/ACK, ACK through, and that is why you see a successfully formed TCP session.
As soon as you try to pass other traffic in this telnet session, however, the app engine will detect the correct application and the firewall either permits or denies it based on the rest of your configured security rules.
You can use the CLI command 'show session all filter destination <dest_IP_address> destination-port <port_#>' to confirm how the firewall identifies the application of your (telnet) traffic.
Hope this helps.
Regards,
tasonibare
12-08-2013 10:54 PM
jenkinsp,
Your rule appears to be configured correctly and the firewall is also acting as it should.
The PAN firewall will allow sessions to be created based on the 6-tuple key (source_address, destination_address, source_port, destination_port, protocol & security_zone) so that enough data (Layer7) packets can flow through, in order for the application engine to identify the application.
Once the app engine identifies your traffic as SKYPE or otherwise, then the firewall makes the decision to allow or deny the rest of the traffic based on the identified application.
For your test, when you telnet to the external IP and port, the firewall would first create a session with the application as 'undecided', which is enough to allow the SYN, SYN/ACK, ACK through, and that is why you see a successfully formed TCP session.
As soon as you try to pass other traffic in this telnet session, however, the app engine will detect the correct application and the firewall either permits or denies it based on the rest of your configured security rules.
You can use the CLI command 'show session all filter destination <dest_IP_address> destination-port <port_#>' to confirm how the firewall identifies the application of your (telnet) traffic.
Hope this helps.
Regards,
tasonibare
09-15-2016 03:28 AM
Good morning, have you found the correct destination dns name (skype sistes) that must be trusted for allowing Skype the connection?
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!