Network Forensic on Encrypted PeertoPeer VoIP Traffics and The Detection, Blocking, and Prioritizati

1
Network Forensic on Encrypted Peer-to-Peer VoIP
Traffics and The Detection, Blocking, and
Prioritization of Skype Traffics

• Chun-Ming Leung
• Yuen-Yan Chan

Department of Information Engineering The Chinese
University of Hong Kong
2
Agenda

• Abstract
• Introduction
• Our Results
• Detection and Blocking of Skype
• NAT Reversing Engineering
• Towards Skype Forensics
• Comparison between exist blocking tools and ours
• Further Development and Conclusions

3
Abstract

• Our Contribution
• Detection and Blocking of Skype
• Control the uncontrollable
• P2P Encrypted VoIP Traffic
• NAT Reversing Engineering
• Observation of STUN like NAT-T technique
• Formulate the unknown NAT-T type
• Towards Skype Forensics
• Induce Forensic idea in Network Access Policy
• Catch Evidence before take action

4
Abstract

• Our Contribution corresponding in
• Academic Research
• Enterprise Collaboration Social Impact

5
Introduction

• Skype
• A popular peer-to-peer (P2P) voice over IP (VoIP)
  application evolving quickly since its launch in
  2003.
• Skype considerably a threat to enterprise
  networks security and availability
• the ability to traverse network address
  translation (NAT) and bypass firewalls,
• the induced bandwidth burden due to the super
  node (SN) mechanism,
• its overlaying and encrypted natures,
• Detection and Blocking of Skype is nontrivial.

6
Introduction

• Skype
• Motivated by the work of Biondi and Desclauxs
  paper, we adopt the view of Skype as a backdoor
  and we take a forensics approach to analyze it.

3 P. Biondi and F. Desclaux. Silver needle in
the skype. In Black Hat 2006 Multimedia -
Presentation, Audio and Video Archives, Mar.
2006.
7
Introduction

• Enterprise and Skype
• China Telecom looking for Skype Killer.
• Reduce IDD Market lose
• Staff Regulation inside an enterprise.
• Reduce Man Power lose during working hour

Blogs and News VoIP Gadgets Blog, "Block
Skype" December 21, 2005 http//blog.tmcnet.com/b
log/tom-keating/skype/block-skype.asp CRN
Australia - The website for channel business
leaders 'Skype Killer' products to do battle in
marketplace By W. David Gardner 24 March
2006 http//www.crn.com.au/story.aspx?CIID36150
8
Introduction

• In our Project
• The Blocking
• Formulate a set of socket-based detection and
  control policies for Skype traffics.
• Our detection method is a hybrid between payload
  and non-payload inspections, with improved
  accuracy and version sustainability over the
  traditional payload-only approaches.
• Our solution is practicable both inside and
  outside the NAT firewalls.
• This breakthrough makes the detection, blocking,
  and prioritization of Skype traffics possible in
  both the enterprise internal networks and the
  Internet Services Providers (ISP) carrier
  networks.

9
Introduction

• In our Project
• NAT - Reversing Engineering
• We workout the Skype proprietary NAT Mechanism by
  Reverse Engineering.
• Forensics of Skype
• we identify a transport layer communication
  framework for Skype.
• Proofing the existence of Skype
• Drop the suspect traffic

10
Our Skype Experiment Network Topology
11
Situation Motivation

• The known techniques used for Blocking VoIP
  services cannot apply on Skype.
• E.g. The techniques in Blocking SIP
• Blocking the address and port of Logon-Server
  (LS)
• Detect and block the Application-Port of
  SIP-Client (SC)
• Detect and block UDP VoIP like traffic,
• Block all UDP traffic
• Detect and block VoIP Protocol base on it payload
  content by Packet-Inspection.
• However, None of its success on blocking Skype

12
Comparison between exist blocking tools and ours

• Description and explanation of the Failure
  techniques

13
Comparison between exist blocking tools and ours
Skip

• Introduction of the recent success techniques
• Recently, known detection methods is limited,
  most of it are under propriety of several
  vendors, and keep secret to public, even dont
  know the success rate of their techniques.
• By research on web, detection of Running Skype
  mainly base on its plaintext HTTP request of
  update check, and
• hence we got the idea of the Source and
  Destination IP.
• Below is the payload content of the HTTP request
  (Skype ver.2.5.0.151 , Dated 2006/11/27
  )E.g."GET/ui/0/2.5.0.151/en/getlatestversion?ver2
  .5.0.151uhash19c43b2dd0 83c0bb3c5abaf80fde1c9ca
  HTTP/1.1".
• Simply, after address detection of Running Skype,
  blocking can be done by IPS or access-rule issued
  by IDS to Firewall.
• However, it draw out another problem
• blocking by IP will affect the rest of host
  sharing the same IP address.
• Not accurate

14
Comparison between exist blocking tools and ours
.
The Communication stages analysis different.
2 S. A. Baset and H. Schulzrinne. An analysis
of the skype peer-to-peer internet telephony
protocol. In IEEE INFOCOM06, Apr. 2006.
15
Comparison between exist blocking tools and ours

• Our Solution
• Apply Non-payload identification
• Locate the Source UDP socket of Skype Client
• Block the VoIP traffic

16
Section 2-1

• Agenda
• Introduction
• Our Project Results
• Detection and Blocking of Skype
• NAT Reversing Engineering
• Towards Skype Forensics
• Comparison between exist blocking tools and ours
• Further Development and Conclusions

17
Section 2-1

• Agenda
• Our Project Results
• 1. Detection and Analysis of Skype
• Our Detection Mechanism and Skype Communication
  Framework
• 2. Blocking of Skype
• Our Blocking Mechanism
• Survey and compare existing block techniques
• 3. Practical Improvement
• Reduce False Positive

18
Section 2-1

• Sub - Rundown
• 1. Detection and Analysis of Skype
• Experiment Setup
• Experiment Procedure
• Event Path of Skype
• Identify the Entities
• Formulae Skype Communication Framework

19
Detection and Analysis of Skype
Skip

• Experiment Setup
• EtherealTM to capture and analyze the packets
• NetPeekerTM to control the network traffic and
  tune the network bandwidth so as to simulate
  different network congestion conditions.
• We repeated the experiment in five different NAT
  settings, including
• no NAT (the client uses a public IP address),
• full cone NAT,
• restricted cone NAT,
• port restricted cone NAT and
• symmetric NAT.
• We also repeated the experiments with hardware
  Netgear Skype WiFi Phone SPH101 clients at either
  client side.

20
Detection and Analysis of Skype

• Capture of Skype Packets using Ethereal

21
Detection and Analysis of Skype

• Event Path of Skype

22
Detection and Analysis of Skype

• Entities

23
Detection and Analysis of Skype

• Authentication super node (ASN)
• Uses to provide authentication services to SCs.
• Forensics notes Packets flows to ASN at fixed
  destination port 33033 were recorded, even when
  authentication was failed. Moreover, packets size
  and number of packets exchanged at this stage
  were constant. We compared with the application
  layer activity and deduced such traffics
  corresponded to routine information exchanges,
  such as the challenges of the authentication.

24
Detection and Analysis of Skype

• Neighbour super node (NSN)
• SNs that are logically near to an SC. An SC must
  establish connection to some SNs for Skype
  communications. The SC locates and then binds to
  its NSNs for such purpose. An SN can be the NSN
  of multiple SCs simultaneously.
• Forensics notes Activities corresponded to the
  NSN Binding stage were only detected after
  successful authentications. Corresponding packets
  exchanged were in fixed size of 388Bytes, and
  were sent to each NSNs, with a fixedsize 60Bytes
  ACK response from each NSNs. We deduced the
  388Bytes message contained SC self-information,
  which might be used for subsequent resource
  reservation.

25
Detection and Analysis of Skype

• Stages in Skype Conversation
• We have observed the following 15 stages of Skype
  phone conversations.
• For the descriptions below, the first statement
  of each stage corresponds to the application
  layer activity, followed by the description of
  the corresponding events observed at the
  transport layer.

26
Detection and Analysis of Skype
The 15 Stages in Skype Conversation

• 1. Startup.
• 2. Registration.
• 3. Authentication.
• 4. SN Handshaking.
• 5. NAT and Firewall Determination.
• 6. Skype Latest Version Checking.
• 7. NSNs Locating and Binding.

• 8. SC Peers Locating and Status Update.
• 9. Callee Searching.
• 10. Add Callee.
• 11. Call Setup.
• 12. Conversations.
• 13. Call Teardown.
• 14. Logout.
• 15. Quit Skype Program.

27
Detection and Analysis of Skype

• Stages in Skype Conversation
• 3. Authentication.
• Caller performs password authentication with the
  Skype server.
• TCP packets are sent to ASN with destination port
  33033 via SCA.T2.
• Challenge-andresponse authentication traffics
  between SCA and ASN with fixed packet size are
  recorded.
• 4. SN Handshaking.
• The Caller is authenticated to the Skype network.
  
• UDP packets are sent to multiple ( 3, by
  statistics) SNs rapidly and continuously, via SCA
  .U.
• This process is detected periodically along the
  conversation.
• At this stage, the handshaken SNs probably
  exchange their information about the known list
  of SNs.
• SCA may also prepare for the SN binding with the
  potential NSNSCA.

28
Detection and Analysis of Skype

• Stages in Skype Conversation
• 5. NAT and Firewall Determination.
• No application layer activity is performed or
  noticed (same for stage 6 and stage 7).
• At transport layer, Skype is performing NAT and
  Firewall detection.
• Multiple ( 2) UDP packets from SCA.U to the
  handshaken SNs are observed.
• NAT traversal is an important function of Skype,
  for determining what kind of NAT settings is the
  SC currently behind. This affects the procedures
  taken at later stages.
• 6. Skype Latest Version Checking.
• SCA sends an HTTP request to HS to determine if
  newer version is available.
• This is the only message sent in plaintext, with
  payload containing GET and getlatestversion.

29
Detection and Analysis of Skype

• 7. NSNs Locating and Binding.
• At transport layer, fixed-size UDP packets, each
  is 388 Bytes, are sent to m SNs via SCA.U, where
  m 9 from all experimental observations.
• Fixed-size responses of 464 Bytes are then
  detected.
• SCA initiates the next stage after m responses
  have been received.
• From our experiments, 3 m lt mfor all
  observations.
• At this stage, SCA is possibly locating the
  logically nearest SNs and binds itself to them
  which serves as the NSNSCAs.
• The NSNSCA may also be updated to HCSCA.
• The remainingm- m responses are also return at
  later stages and further NSNSCA bindings also
  happen.

30
Detection and Analysis of Skype

• 8. SC Peers Locating and Status Update.
• Status (online or offline) of Skype peer users on
  the Callers contact list is updated.
• We have also performed experiments in which the
  contact list is empty, and observed that this
  stage is skipped in such occasions.
• UDP packets from SCA.U to LSN and then to
  multiple destinations are recorded.
• We have performed further experiments and
  analysis and conjecture that the message flowing
  to LSN is a request about the information of the
  bound SNSCXs for every peers X on the contact
  list, while the subsequence flows are actually
  requests to these SNSCXs, asking the status
  information of each of the SCXs.
• This process continues to repeat regularly at
  later stages, with average time interval of 180
  seconds.

31
Detection and Analysis of Skype
Summary of Skype Traffics Detected at Caller

• Table above gives a summary of Skype traffics
  captured at the Caller host when both of the
  Caller and Callee hosts are not behind the
  restricted NAT.
• The notation X.Port denotes the socket at port
  Port of some host X.

32
Section 2-1

• Sub - Rundown
• 2. Blocking of Skype
• Abstract
• Hypothesis
• Procedure Rule
• Advantages of our Blocking mechanism
• Sample Code
• Demo

33
Blocking of Skype

• Our Blocking Mechanism
• Abstract of our Socket Level Blocking technique
• With understanding of VoIP and P2P protocol such
  as SIP, BitTorrent and e-Donkey, we are able to
  analyze an encrypted payload and unstructured P2P
  flows.
• we combine the both
• Payload-Identification and
• Non-payload identification
• More accurate detection and blocking.
• Reduce false-positive by matching distinct
  properties of Skype versus other P2P protocol,
  and
• Introducing verification of payload in form of
  packet format.

34
Blocking of Skype
Skip

• Hypothesis of our Socket Level Blocking technique
• Skype Client is a P2P VoIP application, which
  should have VoIP and P2P properties, even its
  traffic was encrypted.
• With knowledge from Flow Analysis in previous
  chapter,
• we can draw more specific rule on Skype-Protocol
  detection.
• Which the detection and blocking can more
  accurate, more efficiency and reduce false
  positive.
• Refer to the Flow Analysis in previous chapter,
• each stage of the 15 stages are depended on
  previous stages,
• it is because SNs bonding and selections are
  essential procedures for establishing a
  call-conservation.
• Given that inhibition of each stages will
  inhibition the Skype Protocol.

35
Blocking of Skype

• Hypothesis of our Socket Level Blocking technique
• In addition, each stage will keep trying to
  connect outside SNs until several trials.
• Meanwhile, the Client-Version-Checking stage is
  an independent stage to the others this stage is
  not related to other stage and vice versa.
• Where its feature is connect to HTTP server under
  domain of skype.com, and it is the only once
  socket traffic committed in plain text.
• The Well-Known payload detection and blocking of
  Skype

36
Blocking of Skype

• Hypothesis of our Socket Level Blocking technique
• In Non-payload identification for encrypted P2P
  traffic,
• the Stages 1,2,3,6,8,10,11,12,13,14,15 are less
  meaningful in matching multiple P2P flows,
• their flows mainly involved 1 pairs of nodes.
• Although stage-5 the NAT-Firewall-detection stage
  involved more then 1 pairs of nodes,
• but M2 gt2 number of flows wont be significant
  in determining the P2P multiple flows property.
• The rest Stages 4,7,9 show multiple flows from 1
  SC node to Mi number of SNs in a short time,
  which
• there are Mi gt3 sequential flows generated in
  less than 5ms (lt 0.005 second), where i
  3,9,6, refer to the Flow Analysis of Skype in
  paper Page 4, Table 1.
• Moreover, these stages existed and ended before
  the rapid UDP call conservation traffic which
  having an average interval of 45ms per packet
  between the SC-to-SC VoIP UDP voice conversation.

37
Blocking of Skype
Skip

• Hypothesis of our Socket Level Blocking technique
• Our objective
• to detect encrypted single to multiple UDP
  traffic flows generated in less than 5 ms,
• which can narrow the number of suspect source
  sockets, or even find out the target UDP socket.
• The UDP ports which are finally selected in the
  latest run of stage 7 will be the
  Voice-Conversation-Channel (VCC) of the SC-to-SC
  communication.
• And the VCC can be further recognized from its
  VoIP conversation properties we will discuss in
  later session.

38
Blocking of Skype

• Detecting, Blocking, and Prioritizing Skype
• With the detailed Communication framework of
  Skype
• we uniquely identified the UDP communication port
  of the Caller machine,
• which enables one to control the Skype traffics
  by
• blocking or
• prioritizing
• the corresponding sockets.

39
Blocking of Skype
Skip

• Before Blocking
• Detecting Skype Activities, by IDS
• Encrypted traffics are regarded as unknown
  protocol by IDS 14.
• For such traffics, non-payload oriented detection
  approach is more appropriate than the payload
  oriented counterpart.
• Non-payload detection methods mainly identify
  suspect traffics by analysis on packet flow
  patterns.
• One of our rules for detecting Skype traffics is
  to identify the special 1-to-m communication flow
  patterns of UDP packets with fixed size 388 Bytes
  during the NSNs Locating and Binding stage.

40
Blocking of Skype
Skip

• The Detection Rules.
• We are able to identify the exact sockets for
  active Skype traffics at the (T1, T2, T3, T4, and
  U). This enable us to formulate the following
  matching conditions for blocking behind the
  restricted-NAT firewall (i.e. the internal
  enterprise network)
• (1) TCP packets with destination Port 33033 are
  detected. Record the corresponding source IP and
  port number Src.T1 for a close monitoring.
• (2) Monitoring on traffics from source (Src).
  Continue the monitoring when the following
  activities are detected in sequence6
• (i) HTTP request with payload GET and
  getlatestversion at source port Src.T2 is
  detected,
• (ii) consecutive 1-to-many UDP packet patterns
  are detected at source port Src.U,
• (iii) about 9 consecutive packets with payload
  length 388 Bytes are detected at source port
  Src.U,
• (iv) multiple ( 4) packets with payload length
  464 Bytes with destination IP equals SrcIP are
  detected,
• (v) continuous bidirectional UDP traffics with
  VoIP characteristics7 are detected at port Src.U.

41
Blocking of Skype

• The Advantages of our Detection Rules.
• Most of the traceable Skype traffics are
  transmitted through Src.U.
• Therefore, detection of Skype activities is also
  feasible outside the restricted-NAT firewall (the
  external network or the ISP carrier network).
• As compare to block the IP and affect the rest of
  network.
• In particular, the 9 consecutive 388-Byte packets
  generated at the NSN Locating and Binding stage
  is unique and specific to Skype.
• Also, the detection is further supported by the
  subsequent UDP VoIP traffics detected at the same
  UDP port.

42
Blocking of Skype

• Blocking and Prioritizing Skype Traffics.
• As we can detect Skype activities at Transport
  layer by having accurately identified the source
  communication ports at each of the stages,
• we can control the Skype activities by
• close the exact sockets, or
• Set the Skype VoIP traffics at Src.U to a low
  priority.

43
Blocking of Skype

• Table of Three Major Detection rules

• The 3rd rules
• will be the target source UDP port for further
  Blocking and Prioritizing Skype traffic.
• The 1st and the 2nd rule
• are used for early detection of Skype Activity,
• which can make IDS focus on suspect IP address
  before further inspecting non-payload character
  of our target.

44
Blocking of Skype

• The IDS, SNORT is on the same network with the
  Skype Host,
• Monitor all the traffic inside the network.
• While the SNORT find out the matched case in the
  detection rules,
• It can send a message to the firewall asking for
  blocking the specify port,
• No more Skype

The interaction between the IDS and Firewall
45
Blocking of Skype
Detect Outgoing flows If (unknown protocol AND
packet size388Bytes) Record as one Stamp with
time record Per node basic Check
time-stamp If(time stamp out of 5ms) Drop
record Check Alert If(record gt 9) Alert as
Skype-stage-9

• Pseudo code for detecting 1-to-M flows in Stage-9

46
Blocking of Skype

• SNORT rule
• Following is the rule applies to the SNORT to
  monitor the channel and find out the matched the
  case.

47
Blocking of Skype - Demo
Screen Shot of Detection and Blocking Commands

• Notes
• SnortSam is the plugin of IDS (Snort),
• which can further issue Firewall iptables of
  the gateway
• To block or unblock traffic

48
Blocking of Skype - Demo
SNORT alert for the detection of Skype Client
during Stage 7

• Notes
• UDP source port of Skype Client (UDP56537)was
  also indicated.

49
Blocking of Skype - Demo

• Notes
• SnortSam has listened and followed Snort blocking
  command,
• It then issued the 1st set of command to block
  Skype Client (SC)
• Then count for 30 seconds
• Finally issue the 2nd command set to unblock the
  SC.

• Screen Shot of Successful Blocking by SNORTSAM

50
Section 2-1

• Sub - Rundown
• 3. Practical Improvement
• Combination of Techniques
• Payload Identification
• Non-payload Identification
• Reduce False Positive
• Protocol Discrimination

51
Blocking of Skype Combination of Techniques

• Improvement by Combination of Techniques
• While
• Non-payload identification offer detection of
  encrypted traffic by statistical method.
• On the Other Hand,
• Payload identification assist the detection by
  early discovery,
• Then
• A final verification of running Skype by
  Non-payload identification.
• Combination of these 2 identification methods can
  narrow the suspect flows at the early stage, and
• perform more specific flow analysis on remaining
  suspect flows,
• which also match the principle of packet
  inspection that reduce the load of inspecting
  engine.
• Also comparison and maintaining a database of
  non-P2P flows pairs can further reduce the false
  positive in the final result of the Skype
  Protocol detection.

52
Blocking of Skype Combination of Techniques
Skip

• Improvement by Combination of Techniques
• Practically, we suggest using Payload
  identification in Authentication Stage to detect
  existence of Skype,
• locate the suspect IP address running Skype
  Protocol.
• Also can be done by Payload of HTTP packets
• Then, further trigger up the Non-payload
  identification detection on 1-to-M flows
  detection and payload size matching
• to narrow the target UDP flows socket pairs.
• Finally, from the range of suspected flows, we
  can further detect the socket pairs for UDP VoIP
  conservation
• which show its UDP voice traffic properties of
• bidirectional, small size, and rapid packet rate.

53
Blocking of Skype Combination of Techniques

• Conclusion
• The source socket identified of Skype Protocol
• can further apply
• Blocking Policy or
• Traffic Prioritizing.
• The our finding is the 1st detection method allow
  further traffic prioritizing

54
Blocking of Skype

• Detection Procedure of Skype Protocol
• (Non-payload Detection)
• Here we match the characters of Skype flows,
• However,
• this concept induces False-Positive (Fve),
• that it may include other P2P application such as
• BitTorrent and E-Donkey
• Busy server.
• The Solution
• Protocols Discrimination is needed.

55
Blocking of Skype Protocols Discrimination
Skip

• Discriminate Protocols in Non-Payload
  identification
• Discrimination can be based on 2 categories,
• The situations and similarities
• P2P
• There are several P2P applications running around
  us, and all of them are mixed together when
  looking at carrier network.
• Busy-Server
• A busy server also response to its client with
  1-to-M flows manner just like a P2P protocol.

56
Blocking of Skype Protocols Discrimination
Skip

• Introduction of Distinguishing Skype Activities
  from Other Traffics.
• There can have many P2P applications other then
  Skype running simultaneously at the client host,
  all these produce traffics in a 1-to-many
  pattern.
• Nevertheless, P2P applications other than Skype,
  such as
• eMuleTM and BitTorrentTM
• are File-Transfer (FT) in nature.
• Skype traffics can be distinguished from general
  FT counterparts by its non-payload VoIP features
  such as
• bidirectional flows, packet rate and packet size
  4.

57
Blocking of Skype Protocols Discrimination

• For case of File Transfer Application,
• the FT applications usually show distinctive bit
  string in their payload,
• which can be identified by bit-matching at IDS.
• For case of Busy Server,
• Non P2P servers on a network (e.g. the DNS and
  the SMTP servers) also exhibit the 1-to-many flow
  pattern.
• Yet these traffics can be identified from the
  well known source and destination ports.

58
Blocking of Skype Protocols Discrimination

• Further discriminate Skype and FT traffic by
  their non-payload difference in 3 areas,
• flows direction,
• packet rate
• size
• Where Skype conversation is
• bidirectional, constant and high packet rate, and
  small size
• While FT conversation is mostly
• unidirectional, variable packet rate, and large
  packet size.

59
Blocking of Skype Protocols Discrimination

• Refer to previous chapter
• we have measured the UDP voice packet in Skype
  version 2.5.0.151 conversation,
• showed the average packet rate is
• 22packets/second with
• interval range from 20ms to 60ms,
• maximum packet size of 177Bytes.
• Skype voice payload
• packet rate is much frequent and
• the size is much smaller
• as compare to a P2P FT application definitely.

60
Section 2-2

• Agenda
• Introduction
• Our Project Results
• Detection and Blocking of Skype
• NAT Reversing Engineering
• Towards Skype Forensics
• Comparison between exist blocking tools and ours
• Further Development and Conclusions

61
NAT Traversal of Skype

• While several paper claiming Skype using a
  derivate form of STUN protocol for NAT and
  Firewall detection.
• We are the first to examine the NAT traversal of
  Skype by the Reverse Engineering.
• Finally, we formulae a Skype NAT detection
  mechanism in detail and proof..

62
NAT Traversal of Skype

• We have examined the NAT traversal mechanism of
  Skype by repeating the experiment in five
  different NAT settings, namely
• no NAT,
• full cone NAT,
• restricted cone NAT,
• port restricted cone NAT, as well as
• symmetric NAT.
• Skype calls succeeded in all of the five
  occasions.

63
NAT Traversal of Skype

• Skype NAT Transversal Types Definition

64
NAT Traversal of Skype

• v2

Skype NAT-T and its SN-Relaying Properties
65
NAT Traversal of Skype

• From our experiment and collected packet dump
  (over a hundred samples)
• SC form UDP binding requests to multiple SNs (act
  like the STUN servers),
• but from the UDP binding responses of each of the
  SNs, only one port is recorded.
• Address Port 1 1
• This is true even when we set the firewall at
  restricted cone NAT and the port restricted cone
  NAT.
• From this, we notice Skype does not test out all
  five NAT and firewall settings as in the full
  STUN protocol.
• In particular, Skype does not further distinguish
  the three restricted NAT cases (symmetric NAT,
  restricted cone NAT, and port restricted cone
  NAT)
• which requires UDP binding responses with same IP
  but different ports.
• This finding also agrees with the relaying
  property of Skype, that
• SN relaying can overcome the restrictions
  incurred by restricted cone NAT, restricted port
  NAT, as well as the symmetric NAT.

66
NAT Traversal of Skype

• Skype NAT Detection Logic

67
Section 2-3

• Agenda
• Introduction
• Our Project Results
• Detection and Blocking of Skype
• NAT Reversing Engineering
• Towards Skype Forensics
• Comparison between exist blocking tools and ours
• Further Development and Conclusions

68
Section 2-3

• Rundown
• Towards Skype Forensics
• Forensic Analysis of Skype
• Proof the existence of Skype Entries
• Proof the existence of Skype
• Collect Evidence of Using Skype

69
Towards Skype Forensics
Skip

• Forensics Analysis of Skype
• We reveal the proprietary Skype communication
  framework by performing forensics analysis on the
  network traffics generated by the encrypted Skype
  peer-to- peer VoIP activities.
• Forensics is the use of scientific or
  technological techniques to conduct an
  investigation or establish evidences in a
  criminal case.
• We can also draw evidence from number of packets
• Proofing the existence of attack, backdoor,
  Skype
• Network forensics often refer to the capture,
  recording, and analysis of network events in
  order to discover the network security problem
  incidents.
• Forensics analysis seeks answers for how an
  intrusion occurred and what the intruders did
  (see 18, 19, 20 for suggested approaches).

70
Towards Skype Forensics

• Forensics Analysis of Skype
• By adopting Skype as a backdoor,
• We performed
• Forensics Analysis on the Skype traffics and
• Quested
• how Skype activities have occurred and
• what Skype have done during these activities.
• To achieve this, we have performed the following
  steps in our research
• Model Construction.
• We began by formulating an application layer
  event graph for the Skype activities that we were
  going to analyze.
• The graph was constructed in a way that the
  number of Skype features being invoked was
  maximized.
• We had also defined alternative paths for the
  major events so that different scenarios that
  could happened along the Skype communication
  processes were covered.
• From this, we formulated the main experiment
  procedures (as described in our Paper Figure
  4.2.). Conditions in which the Skype activities
  took place were also specified.

71
Towards Skype Forensics

• Forensics Analysis of Skype
• Model Construction.

72
Towards Skype Forensics

• Forensics
• Collection,
• Preservation,
• Analysis, and
• Presentation

• Forensics Analysis of Skype
• 1. Collection of Evidence.
• We executed the experiment procedures to perform
  the Skype phone call activities at application
  layer.
• We have repeated our experiments in all possible
  routes along the event graph to collect evidence
  on Skype activities.
• The tool EtherealTM was used to capture all
  incoming and outgoing packets during the
  experiments, including their packet timestamps,
  IP addresses and port numbers of source and
  destination, protocols, packet sizes, as well as
  the packet payloads.
• 2. Analysis of Evidence.
• We then performed detail investigation and
  analysis on the digital evidence collected and
  compares the timestamps against those of the
  application-level activities.
• We further identified different roles of SNs by
  the patterns of the packets exchanged (as
  described in Chapter 5.2).
• 3. Presentation of Evidence.
• Finally, the analysis results were arranged and
  presented into the Skype communication framework
  (see Report Chapter 5) including the entities
  involved and the 15 stages in a generic Skype
  conversation.
• In each of the stages, corresponding evidence and
  recorded network traffics are also included.

73
Towards Skype Forensics

• Entities

74
Towards Skype Forensics

• Applying Forensics Analysis on Entries
  Identification
• In the Entries Identification, we further
  identify different role of SNs participated in
  Skype Protocol. Forensics Notes are given for
  each party. E.g.
• Skype HTTP Server (HS)
• The HTTP server of Skype.com. Skype client (SC)
  End client hosts who use Skype to place voice
  calls and send text messages. Each SC maintain a
  table Host Cache which contains IP address and
  port number of super nodes (to be defined below).
  In particular, we denote the SC hosts of the
  Caller and Callee by SCA and SCB respectively. We
  denote the host cache of some Skype client SCX by
  HCX.
• Forensics notes
• The HTTP content betwwen SC and Skype HTTP Server
  containing string of GET, getlatestversion.

75
Towards Skype Forensics

• Applying Forensics Analysis on Entries
  Identification
• Authentication super node (ASN)
• an SN that Skype uses to provide authentication
  services to SCs.
• Forensics notes
• Packets flows to ASN at fixed destination port
  33033 were recorded, even when authentication was
  failed.
• Moreover, packets size and number of packets
  exchanged at this stage were constant.
• We compared with the application layer activity
  and deduced such traffics corresponded to routine
  information exchanges, such as the challenges of
  the authentication.

76
Towards Skype Forensics

• Applying Forensics Analysis on Entries
  Identification
• Location super node (LSN)
• an SN that Skype uses to maintain network
  location information about peer SCs.
• Forensics notes
• Traffics to and from the corresponding SN was
  only detected at
• startup stage and
• callee searching stage.

77
Towards Skype Forensics

• Applying Forensics Analysis on Entries
  Identification
• Neighbour super node (NSN)
• SNs that are logically near to an SC. An SC must
  establish connection to some SNs for Skype
  communications. The SC locates and then binds to
  its NSNs for such purpose. An SN can be the NSN
  of multiple SCs simultaneously.
• Forensics notes
• Activities corresponded to the NSN Binding stage
  were only detected after successful
  authentications.
• Corresponding packets exchanged were in fixed
  size of 388Bytes, and were sent to each NSNs,
  with a fixedsize 60Bytes ACK response from each
  NSNs.
• We deduced the 388Bytes message contained SC
  self-information, which might be used for
  subsequent resource reservation.

78
Towards Skype Forensics
Skip

• Collect Evidence of Using Skype
• Identify the existence of Skype
• Identify which stages have passed
• TCP
• Authentication with ASN
• HTTP request to HS getlatestversion
• UDP
• Neighbors Binding 1-to-M flow to NSNs
• Proof the using of Skype
• Further manipulation refer to the source UDP
  socket

79
Towards Skype Forensics
80
Section 3-1

• Agenda
• Introduction
• Our Project Results
• Detection and Blocking of Skype
• NAT Reversing Engineering
• Towards Skype Forensics
• Comparison between exist blocking tools and ours
• Further Development and Conclusions

81
Section 3-1

• Rundown
• Comparison between exist blocking tools and ours
• Introduction of the recent success techniques
• Limitation and Problem of the exist techniques
• The Comparison between Transport Layer and
  Application Layer in OSI model

82
Comparison between exist blocking tools and ours

• Introduction of the recent success techniques
• Recently, known detection methods is limited,
  most of it are under propriety of several
  vendors, and keep secret to public, even dont
  know the success rate of their techniques.
• By research on web,
• detection of Running Skype mainly base on its
  plaintext HTTP request of update check, and
• hence we got the idea of the Source and
  Destination IP.
• Detection Failure
• Hardware Skype Client wont send HTTP request at
  regular startup.
• By 2InfoCom BS06
• detection of Running Skype can also base on
  traffic payload in Authentication Stage
• Get the idea of the Source and Destination IP.
• Blocking Failure
• Skype can change payload content after several
  failure.
• However, it draw out another problem that
• blocking by IP will affect the rest of host
  sharing the same IP address.

83
Comparison between exist blocking tools and ours

• The Comparison between Transport Layer and
  Application Layer in OSI model
• The Comparison can be divided into two level
• Network Level Detection and blocking
• Payload identification
• Non-payload identification
• System Level Detection and blocking

SkypeTips.com http//skypetips.internetvisitation.
org/index.html
84
Blocking of Skype

• System Level Detection and Blocking
• Detecting and Blocking Skype on the Application
  Layer
• cheaper and easier to do for the smaller
  organization networking.
• done on the assumption of the network admin has
  fully control on the organization network.

85
Blocking of Skype

• System Level Detection and Blocking
• They are done by
• Networking configuration management applications
  can use their build-in tools to detect the
  running Skype program.
• Microsoft SMS,
• LANDesk HP,
• OpenView Client Configuration Manager
• On Scripts
• GUI software
• SkypeKiller
• Windows XP firewall (Service Pack 2)
• Command netsh

86
Blocking of Skype

• network layer
• more wildly used
• more completely.
• The technique of network layer
• cost less
• sure the profit
• Blocking Skype on network layer is more
  considerable

• The comparison of the Network Level and the
  System Level

87
Section 4-1

• Agenda
• Introduction
• Our Project Results
• Detection and Blocking of Skype
• NAT Reversing Engineering
• Towards Skype Forensics
• Comparison between exist blocking tools and ours
• Further Development and Conclusions

88
Further Development and Conclusions
Skip

• Further Development
• Find out the communication pattern for different
  Skype.
• To adopt with high bandwidth busy traffic in ISP
  environment
• Making the system more detail, more accuracy in
  IDS rules.
• Improving the Detecting Mechanism
• Using the Binary Detection Algorithm

89
The need of the Technology

• Most ISP is the telephone services provider.
• long distance call will greatly decrease the
  profit
• For the large cooperation,
• Working performance of employee with Skype.
• Loss Crisis of opened port menhours on
  playing Skype decrease in efficiency of
  bandwidth any other crisis by Skype
• The network admin needs face to the large crisis
• The supernode will affect the bandwidth of the
  company, and also the crisis from the opened
  port.
• So, Blocking Skype is a new HOT technology

Blogs and News VoIP Gadgets Blog, "Block
Skype" December 21, 2005 http//blog.tmcnet.com/b
log/tom-keating/skype/block-skype.asp CRN
Australia - The website for channel business
leaders 'Skype Killer' products to do battle in
marketplace By W. David Gardner 24 March
2006 http//www.crn.com.au/story.aspx?CIID36150
90
Further Development and Conclusions

• Conclusions of our work
• Performed experiments and network forensics
  analysis on encrypted peer-to-peer VoIP traffics
  of Skype activities.
• Formulate a communication framework of Skype down
  to the transport layer.
• Able to identify the sockets associated to active
  Skype applications.
• Formulated the detection rules and recommended
  further actions such as prioritizing the
  corresponding UDP traffics or blocking them
  completely.

91
Further Development and Conclusions

• Conclusions of our work
• First to adopt a hybrid detection approach and is
  robust against version updates.
• The detection rules can be applied at both sides
  of the NAT firewalls.
• As the launch to the OEM Skype phones, which
  makes our results more robust against Skype
  version updates.
• After we analysis the communication pattern of
  Skype, we can conclude the pattern can be written
  in script.
• The script can be output as an IDS packet series
  signature. And then the IDS will issue the
  firewall to the blocking.
• That solve the problem of the in compatible with
  traffic monitoring, IDS.

92
References

• 1 S. A. Baset and H. Schulzrinne. An analysis
  of the skype
• peer-to-peer internet telephony protocol. In
  Columbia University
• Technical Report CUCS-039-04, Sept. 2004.
• 2 S. A. Baset and H. Schulzrinne. An analysis
  of the skype
• peer-to-peer internet telephony protocol. In IEEE
  INFOCOM
• 06, Apr. 2006.
• 3 P. Biondi and F. Desclaux. Silver needle in
  the skype. In
• Black Hat 2006 Multimedia - Presentation, Audio
  and Video
• Archives, Mar. 2006.
• 4 L. Deri. Open source voip traffic monitoring.
  In SANE 2006,
• May 2006.
• 5 B. F. et. al. Peer-to-peer communication
  across network address
• translators. In USENIX, pages 179192, 2005.
• 6 S. Guha, N. Daswani, and R. Jainn. An
  experimental study
• of the skype peer-to-peer voip system. In The 5th
  Int. Workshop
• on Peer-to-Peer Systems, pages 8191, Feb. 2006.
• 7 T. Karagiannis, A. Broido, M. Faloutsos, and
  K. C. Claffy.
• Transport layer identification of p2p traffic. In
  Internet Measurement
• Conference, pages 121134, 2004.

9 S. Peisert, M. Bishop, S. Karin, and K.
Marzullo. Toward models for forensic analysis. In
SADFE, pages 315, 2007. 10 B. Sat and B. W.
Wah. Analysis and evaluation of the skype and
google-talk voip systems. In IEEE ICME.,
2006. 11 Skype official website.
http//www.skype.com/. 12 K. Suh, D. R.
Figueiredo, J. Kurose, and D. Towsley.
Characterizing and detecting relayed traffic A
case study using skype. In IEEE INFOCOM06, Apr.
2006. 13 S. Templeton and K. Levitt. A
requires/provides model for computer attacks. In
NSPW, 2000. 14 C. I. et. al. A comparative
experimental evaluation study of intrusion
detection system performance in a gigabit
environment. Journal of Computer Security,
11(1)133, 2003. 15 X. Wang, S. Chen, and S.
Jajodia. Tracking anonymous peer-to-peer voip
calls on the internet. In ACM CCS, pages 8191,
2005. 16 Y. Yu, D. Liu, J. Li, and C. Shen.
Traffic identification and overlay measurement of
skype. In ICCIS, pages 10431048, Nov. 2006.
93

• Thank you
• QA section

94
QA

• Summary of Question
• Q1 Skype is good, why we block Skype?
• Q2 As Skype traffics are encrypted, how can we
  know which are them.
• Q3 Skype can be evolved refer to our
  publication, what can we do next?
• Q4 The Skype will not happy with this, and so
  the public
• Q5 Is this illegal to block Skype?

95
QA

• Q1 Skype is good, why we block Skype?
• A1
• For it negative nature
• Skype is a propriety application, even assuming
  it is 0 malicious, but its security cannot be
  ensured.
• Its P2P and NAT-Transversal ability can bypass
  enterprise firewall and bleaching security
  policy.
• Reference URL
• http//www.fiercewireless.com/story/spotlight-rese
  arch-firm-warns-enterprise-users-of-skype/2006-03-
  10
• The use of Skype causing lose of man-hour just
  like Instant Messager (e.g. ICQ, MSN, QQ).
• It is un-controllable
• It overlaying and encrypted nature make it very
  difficult to be controlled
• Before, we have no choice other then give-in or
  negotiate.
• We give an option to enforce and carryout the
  policy.

96
QA

• Q2 As Skype traffics are encrypted, how can we
  know which are them.
• A2
• We formulated 15 stages, and each stage have each
  signatures.
• (Refer to papers Page 4, Table 1)
• (Refer to PowerPoint Page 31, Table)
• Combining the significant signatures in Payload
  and Non-payload detection, it greatly reduce the
  False-Positive.

97
QA

• Q3 Skype can be evolved refer to our
  publication, what can we do next?
• A3
• Yes, they can.
• This is a game of Hack and Patch Patched and
  Hack again
• For our detection mechanisms are highly based on
  timing, they can counter us by simply induce a
  random delay in their next version update.
• However, they can never alternate their 1-to-M
  P2P nature.
• Nevertheless, there are Skype Hardware Phone
  massive manufacturing world wide. (Refer to
  papers Page 6, Conclusion)
• The hardware already released to the market will
  suffer by our blocking technique.
• If the hardware design without version update
  feature, it will possibly become a bulk of
  rubbish.
• What we sure is Skype Business is in trouble

98
QA

• Q4 The Skype will not happy with this, and so
  the public.
• A4
• This is a public issue!
• But for Academic, our contribution overcome 2
  problems
• Previous Techniques cannot block Skype anymore,
  and limited to IP blocking
• We can block Encrypted P2P VoIP Application in
  Socket Level.
• Even enable prioritization of Skype traffic.
• Control the P2P Application
• Furthermore,
• China Telecom recruit for Skype Killer. (In the
  end of 2005)
• This is a Million Business
• We can raise research funding ?
• Reference URL
• http//www.fiercewireless.com/story/spotlight-bann
  ing-skype-boosts-incumbents-revs/2006-10-25

99
QA

• Q5 Is this illegal to block Skype?
• A5
• It maybe illegal later.
• If Skype become licensed Voice Service Provider
  or Telecom service Provider.
• It is neither illegal service provider nor legal.
  
• Refer URL (A summary of Skype facing political
  aspect)
• http//en.wikipedia.org/wiki/SkypeLegal_and_polit
  ical_aspects
• Skype business is in a grey area.
• We can claim that, we are not illegal to block it.

100

• For Detail
• Pls visit
• Homepage of Chun-Ming Leung
• http//personal.ie.cuhk.edu.hk/lcm007/