We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now


Blocking Skype on ASA5510

Cobra25 asked
Medium Priority
Last Modified: 2012-05-06
We have an ASA 5510 firewall with no SSM and we want to block Skype using REGEX and Traffic Inspection. So far It hasn't been very successful because the fluid nature of SKYPE traffic. Cisco website doesnt document anything as far as blocking Skype using ASA is concerned. Any idea, comment, suggestion would be appreciated.  
Watch Question

If you can take a few small captures of the traffic, I will give it a go. Use a Network General Sniffer if possible, or wireshark would be another option too. fire up the capture, then light up skype on a known IP, nad make a few quickie calls in & out.
You could even use the capture function and an ACL on the ASA as long as you set the buffer to 1518 and the capture size to at least 1mb. Also, dump the cap off the appliance in pcap mode please


I have the capture in pcap form, but it wont let me upload it here.
you tried the attach file thing below? how large is the file, I think the filesize limit is 5 or 10m or so...


Yeah, i tried to attach it, but it doesnt support the pcap file extension.
doh. Maybe a zip or a rename to .txt? no matter which way you go, I'd like to see a trace of the traffic...

I spent some time looking into Skype network traffic. Wow, it's like a cancer. It's a peer to peer network model, it installs at a random port number for every install. Each install tries to operate on this random high port first. Failing that, it can use tcp 80 or 443. And there's not a hard set list of a few servers or a set domain name they try to lookup that I can find. Since its a proprietary protocol, Skype has not released any official information on the protocol and how it works, all the info found out there is third party reverse engineering. There is a hardcoded and encrypted list of "seed" servers in each install apparently, but many seem to think this list changes with versions, and I don't know how big this list might be. There are some fairly expensive "Skype blocking" technology products offered, using complex algorithms and with reportedly varying degrees of success.

or... if you have your firewall block all outbound protocols from your inside network except a few normally used ones ( generally just http & https & DNS & maybe ntp except for special exceptions like mailservers, ftp servers, etc.), which is a great security practice anyway, you will thereby force Skype to use only TCP 80 & 443 outbound. 80 (which should be http) should be stoppable by inspecting the traffic in the ASA and seeing if it's not properly formatted http and dropping it. Stopping the https attempt, however, will be more difficult. Perhaps inspecting traffic looking for a proper ssl handshake and dropping abnormals...

The simplest solution by far would be a combination of securing your outbound network ports as I mentioned above, and then using a content filtering solution with the firewall as well, like Cisco's plug in module, or Websense, or something similar. This would definitely work if the content policy was to block all traffic to unknown websites as well as any of the selected categories to block. Since the Skype supernodes, slots, and blocks will almost certainly not be known & approved website servers on port 80 or 443.

Here is what should be another effective way, but it would be a little legwork on your part.

Configure an INSIDE-OUTBOUND access list something like :
object-group service AllowedTcpOut tcp
 port-object eq 80
 port-object eq 443
object-group service AllowedUdpOut udp
 port-object eq 53
 port-object eq 123

access-list INSIDE-OUTBOUND extended permit udp any any object-group AllowedUdpOut
access-list INSIDE-OUTBOUND extended permit tcp any any object-group AllowedTcpOut
access-list INSIDE-OUTBOUND extended deny ip any any log 7

access-group INSIDE-OUTBOUND in interface inside

With the explicit "deny ip any any log 7" you will get log entries detailing who and what is being blocked. It helps troubleshoot stuff that should be working, and identify users doing things they should not be doing. You will need to add exceptions for known traffic sources as well, before the deny. The tighter you keep this, the more obvious your violaters will be & effective your hunt will be. Information security is enhanced if everyone cant FTP anything in or out to anywhere, or use any email or irc server anywhere over your pipe, for instance. Less viruses, less trojans, less data loss, etc. The other advantage is this will block most network games as well.

Do your syslog off-box (kiwi syslogd is a great solution) as well as the on box firewall log, dump them into a spreadsheet daily. Resolve each IP to a user/computer name each day and add it to your spreadsheet for the day. Just before lunch is the time I usually hit for this kinda thing, everyone is in and booted and checking their emails before leaving for lunch. Look through a week or three's logs, sort by username and then by port number (not tcp or udp, just the port number blocked) and it should point out very quickly who is using Skype. They will start each day and probably lunch returns (and maybe each call, im not sure) with a random UDP highport connection blocked, then a TCP highport to the same port number blocked, then a port 80 connection or connection attempt to that same IP, followed by a tcp 443 connect to that IP as well if the port 80 fails for any reason. These are their random highports from install, should be unique by user but randomness and a large user population doing this will increase chances of port dupes. No matter. You've tracked username or computer name to IP daily (sorting by user/computer name eliminates DHCP address shifts), and you have a log of all their traffic. At this point, you have hard evidence, and it's a management decision to discipline or dismiss the policy violators. If they are your pals, give em a heads-up prior to this inquisition, good people do dumb stuff sometimes, right?  :)

this was a pretty good wiki that led me to a lot of info--> http://en.wikipedia.org/wiki/Skype_Protocol

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts
Any luck out there Cobra25?


Still working on this.
If you still want to work on this, it's very interesting to me, i"ll help out...
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.