Project phase 4 Solution

Phase 4 overview



    • Implement an on-line classifier for encrypted traffic

        ◦ Put phases 2 and 3 together

        ◦ Phase 2: online traffic logging

        ◦ Phase 3: offline traffic classification

        ◦ Phase 4: online traffic classification

        ◦ In a nutshell, incorporate the classification model you create for phase 3 into the traffic analysis tool you created for phase 2
Traffic analysis process



    • 1 – Traffic burstification

        ◦ Packet burst definition:










Taylor et al., EuroSP 2016


A packet burst includes all packets transmitted and received between the end of the previous burst, and a period of time when no packet is transmitted/received for 1s

    • In other words, segment the flow of captured packets in sections separated by 1s of silence
Traffic analysis process



    • 2 – flow generation

        ◦ Extract all flows from a given burst

        ◦ Flows can be defined in different ways:

            ▪ All packets in a burst part of the same TCP connection

            ▪ All packets in a burst part of the same direction within a TCP connection
            ▪ Different notions of source and destination (Android VM, connection originator, etc.)

            ▪ Design choice does not matter as long as you describe it
Traffic analysis process



    • 3 – flow classification

        ◦ At the end of each burst, apply classifier you developed in phase 3 to each flow

        ◦ If flow matches any action defined in phase 3 (e.g. ”start app X” etc.), label the flow
Deliverable specifications



        ◦ Upload a copy of the gateway VM with the following files in /home/tc:

            ▪ A Python script named analyzeFlows. When executed, the script must print out a list of bursts, flows in every burst, and the label of each flow that originated a certain action (if any). Output example:


    • ./analyzeFlows


Burst 1:

<timestamp> <src addr> <dst addr> <src port> <dst port> <proto>\ <#packets sent> <#packets rcvd> <#bytes send> <#bytes rcvd> <label>
Deliverable specifications/2



    • Upload a copy of the gateway VM with the following files in /home/tc:

        ◦ A file named readme.txt describing:

            ▪ The specific definition of flow that you used

            ▪ A brief description of the features that you used

            ▪ Anything we need to know in order to run and grade your work

            ▪ Anything else you want us to be aware of (limitations, problems, etc.)
Phase 4 evaluation



    • What we will do:

        ◦ Execute actions on the Android VM

        ◦ Observe if:

            ▪ Actions that are part of the evaluation set (ref. phase 3) are identified correctly (true positives evaluation)

            ▪ Actions that are not part of the evaluation set do not get labeled (true negative evaluation)
Some suggestions



    • TinyCore has better support for Python 2 than Python 3

        ◦ Models exported from Python 2 won’t work with Python 3 (in general) and vice-versa

        ◦ If you have a Python 2 model, you are probably good to go

        ◦ If you have a Python 3 model, you will need to either re-create in Python 2, or install Python 3 in TinyCore (clunky, but not impossible)
Some suggestions/2



    • The default TinyCore VM is configured with a fairly low amount of RAM

    • If you find this create issues, feel free to change the configuration
Some suggestions/3



    • Do not start at the last minute

    • Most people got through the previous phases fine, but the combination VirtualBox+TinyCore is finnicky

        ◦ If you run into issues due to specific configurations, Python versions, etc. we can try to help but only if you contact us early