CloudShark’s three key features - organizing, analyzing, and collaborating - all have their own ways of making packet capture analysis easier. In particular, organizing captures in a repository that can be tagged, sorted, and tracked can be made even more potent when you use it to centralize captures automatically from a variety of sources. Here’s three things you can do to build a packet capture network that pulls in captures from multiple locations:
Building remote packet capture
The CloudShark API upload function lets users push files to CloudShark using nearly any tool. We used this when building the CloudShark plug-in for Wireshark, and many others who have integrated their products with CloudShark have also done so.
Dyn, Inc. is one example of a CloudShark customer using tshark and the CloudShark plug-in to perform remote capture - it’s as simple as logging into a remote server running Wireshark, performing a capture, and having it directly upload to CloudShark. Alternatively, simple tools like tcpdump can be used in combination with an HTTP interface tool like cURL. When this is combined with some simple shell scripting, you can manually or automatically start remote captures and instantly have those captures upload to CloudShark.
Many existing networking products have built-in packet capture that can be modified to work with CloudShark. Cisco Meraki is probably the biggest example, as they have added CloudShark to their Cloud based management interface. Consumer and enterprise grade routers and switches also have internal packet capture capability - many products running Cisco IOS 12.1 or later contain Cisco Embedded Packet Capture.
Lastly, if you want to bypass the API, you can use CloudShark’s auto-import system. CloudShark will automatically index any capture files you place in a given directory.
Matching triggers with CloudShark tags
Both the upload API and auto-import feature let you automatically add tags to captures as you upload them. When building a packet capture network, this can be extremely useful in organizing based on capture location or source.
Additionally, if you are using any type of detection to trigger your packet capture script, it is helpful to include the trigger reason and other information in a tag that will be added for any captures created by that trigger. For example, you could trigger based on an activity level, or if there is evidence of intrusion detection, and then tag with both the trigger warning and location of the server.
Streaming captures to CloudShark
There are also rudimentary ways to set up continuous streaming of files to CloudShark. This is simple with auto-import, and the API Upload function can accept files without knowing the final size - when the file is completed, it will be indexed by Cloudshark.
This can also be helped along by using a ring buffer. We covered streaming live captures to CloudShark in an earlier blog post if you need a refresher.
CloudShark’s import ability is one of its most powerful features. Using it wisely can help you delve deeper into all kinds of security, application, and network problems no matter where they are occuring.