Recently in network forensics Category

There's a chance you could have a spy. Watching your every move, just waiting for the perfect time to attack and hijack your precious information.

 

A recent InfoWorld blog serves as a wake up call to those companies who have not taken the increasing threat of electronic espionage and network security seriously. According to the blog, a growing number of companies are being spied on electronically by sources in other countries. This isn't the first we've heard about this though, back in January, hackers from China had broken into several companies' computer networks including Google to steal information about Chinese dissidents as part of "Operation Aurora," which was one of the largest cyber-attacks ever.

 

These incidents keep occurring because companies believe that their current security software is good enough or they've just simply ignored the issue. The truth is that in order to have protection from these types of stealth spies you have to collect packet history within the network. And the only way to receive this information is by performing forensic analysis.

Network forensics is the capture, recording, and analysis of network events. All pertinent network traffic is collected in a single location, rather than scattered across the network. Data is captured in a common data format and does not need to be transferred or translated in any way for analysis. Using network forensics data mining tools, security teams can reconstruct the sequence of events that occurred at the time of a network breach or cyber attack and get the complete picture. Forensic analysis exposes attackers, methods, and damages. Lucky for us, new and more powerful network forensic products are out there to help defend against electronic spying threats. Even though there is a vast array of network forensic technologies to choose from, organizations should know that there are really only three basic elements to any general-purpose network forensic solution:

1. Data capture and record - This is the ability to capture and store multiple gigabytes of data at high network throughput (for example, 10 Gigabit) without dropping or missing any packets. Every network forensic solution has its limitations, including sustainable throughput, packets per second, data management, search functions, etc. These limitations can and should be determined through practical lab tests, and the results should be repeatable and documented. This includes both wired and wireless networks.

2. Data discovery - Once data are recorded on the storage media, the solution should provide a mechanism to filter particular items of interest, for example, by IP address, application, context, etc.

3. Data analysis - Finally, you want some built-in assistance for examining the patterns and anomalies found during the discovery process to help you determine what actions were recorded in the captured packets.

The information forensic analysis provides can lead to an informed and efficient security posture within an organization to deter similar attacks in the future. As criminals get smarter and savvier, being able to detect and characterize attacks is crucial. Information leakage not only results in monetary losses but also can be a serious threat to national security. Having the right network forensic solution in place can help to discover and eliminate possible threats in your network and to provide lawful interception capabilities when needed.

 

Before we address this question, we must address an even more basic question - "What is NetFlow"?  NetFlow, and other flow-based technologies like sFlow, JFlow, and IPFIX, are simply specifications for collecting certain types of network data for monitoring and reporting. The data sources are network devices themselves, like switches and routers, the idea being to leverage existing resources in the network to provide data that is for the most part already being processed by these devices. To that end, flow-based systems provide an economical source for network monitoring data.

All flow-based systems start with flows as their basic element. A flow is a sequence of packets that has the following seven identical characteristics: source IP address, destination IP address, source port, destination port, layer 3 protocol type, TOS byte, and input logical interface. By definition, a flow is unidirectional. Flows are processed and stored by supported network devices as flow records, and it is these flow records that vary from specification to specification -  i.e. a NetFlow flow record does not take quite the same form as an sFlow flow record. This requires different parsing and processing techniques for each flow-based specification. It is at this step where flow records are consumed and the term NetFlow Analyzer is introduced.

Basic flow analysis is a multistep process, requiring several different elements to be present. Packets enter a switch or router, just as they would as part of normal network operation. If the network device is flow-enabled and the feature is active, additional processing will take place to identify individual flows in the packet stream per the seven characteristics mentioned above. Depending on the configuration of the network device and how busy the network is at any given time, this processing may be done on every packet, or just a sampling of the packets. As flows are identified, flow records are created per the specification supported by the network device, for our purposes NetFlow, and the records are stored locally in the network device. As flows are completed, the records associated with those flows are exported to an external NetFlow Collector, where they are archived for further analysis and reporting. Once the flow record leaves the network device it is deleted from memory to make room for other flow records. Though efficient since the packets already must be processed by the network device, NetFlow does put an additional strain on the network device since it requires additional processing beyond that required for only switching or routing, and it requires additional storage on the switch for the flow records being processed and exported.

A NetFlow Analyzer includes the NetFlow Collector, which accepts and stores the completed flow records; a storage system to allow for long-term storage of large volumes of flow-based data; and analysis software to mine, aggregate, and report on the collected data per user requests through a customized UI, often web-based but sometimes client-server. The NetFlow Analyzer can be software-only or appliance-based, but most systems are appliance-based, and the system often includes multiple appliances.

So what are the advantages? NetFlow data comes "for free" from NetFlow-enabled network devices, eliminating the need for additional network probes to collect the flow-based data. But remember, it's not entirely free since it requires processing and storage resources on the network device thereby competing with the prime directive of the device - route packets. Given the 7 characteristics of a flow, NetFlow Analyzers can provide a relatively detailed set of network performance data, and given enough storage this data can be archived for quite a long time providing a long-term record of network behavior.

But there's no such thing as a free lunch. NetFlow Analyzers may not always be 100% accurate since the source of the flow data can be from sampling and not an analysis of each and every packet. NetFlow Analyzers also create additional network traffic moving flow records from the network device to the NetFlow Collector, possibly impacting performance on an already busy network. And NetFlow Analyzers can report on nothing more than the information they can interpolate from the 7 flow characteristics, making them excellent network monitors but poor network analysis solutions because they often lack the data to perform root-cause analysis once a network anomaly is detected.

Network analysis systems that derive data from independent interrogation of each an every packet, like the OmniPeek Distributed Analysis Solution, provide all the data necessary not only for detailed network reporting, but for advanced, root-cause analysis as well. No sampling, no need to move data across the network for storage and analysis. All analysis is done at the source, by tapping into a network device and processing all the data locally.

Each system has its place, but when the time comes for root-cause analysis, and it always does, a packet-based analysis solution like the OmniPeek Distributed Analysis Solution is what you need. 

While the cost for 10GbE is coming down and adoption is rapidly rising, there remain challenges in analyzing 10GbE traffic, most notably because the industry has yet to achieve real-time analysis at 10GbE line rates. However, 10GbE analysis is available and does not have to be limiting in terms of results. Below are six questions that will help determine if your organization is fully optimized for analyzing 10GbE traffic.

1. Are you being specific enough?

It's important to know exactly what you want to capture and what information is going to be most beneficial for your analysis. Your requirements will likely vary between each network segment and odds are you are going to have to capture data at several locations. An excellent way to analyze 10GbE traffic, especially when utilization is high, is to use post-capture analysis and only save the data to a disk in real-time. Trying to capture and analyze simultaneously, in real-time, on highly utilized network segments puts much more strain on the system than if you just save data to a disk for post-capture analysis.

2. Do you REALLY know your network?

Knowing how you expect the network to be performing is all the more critical when trying to analyze highly utilized 10GbE segments. If you're already embroiled in a complex network analysis firefight it's too late to realize that your ability to assess "normal" conditions on the network may be lacking. To get a sense of "normal" conditions before trouble arises, you should perform and archive baseline measurements across specific network traffic like HTTP and key business applications over typical cycles - like an hour, a day, and a week, for the network as a whole. Other metrics to consider include understanding packets size distribution as well as protocol and node usage over time, uncovering cycles in these metrics, which provide a "fingerprint" of your utilization. That way you will always have a clear view of the network for comparison when trouble arises. Only after convincing yourself that the basic data is in place and being collected and analyzed should you embark on detailed analysis and drill-down of packet-level data.

3.  Are you sticking to the essentials?

The temptation is to try to capture and analyze everything, especially when the source of the problem is not immediately known. But quite often certain conditions can be immediately ruled out, and using these clues to limit the collection and analysis to only what is necessary dramatically improves network analysis performance. You always have the option to customize analysis by turning off modules that are not important to the current exercise. Modules such as wireless network performance can be turned off, especially in 10GbE analysis, because odds are they are not relevant to the problem being investigated. The key is to customize your usage and take advantage of it.

4. Do you know your limits?

Even after analysis has been streamlined to only essential areas of the network, data capture for network analysis on 10GbE networks generates a great deal of data quickly, and managing the data becomes a significant challenge. Regardless of the system used, the data is typically stored for subsequent retrieval and post-capture analysis. The two most common formats are standard packet files and databases. In either case, two metrics to manage closely are file size and frequency of disk writes. Though intuition may lead you to think that the larger the file size the better, this is often not the case as very large files require very large memory footprints to open. If the files are too large they will be unworkable on the computer being used for analysis. Smaller files, however, typically lead to more frequent disk writes, and this can rob the system of precious resources for performing the actual packet capture. Optimum performance is achieved with a balance of these two demands, and this is different depending on the hardware resources available. One rule of thumb to keep in mind is that if files are being created every 30 seconds or less, it's going to increase strain on achieving the maximum packet capture rate significantly. Starting with reasonable sized buffers and files makes all the difference. We recommend that you start with 256MB buffer for packet capture and 128MB for files to be created. After a few captures you'll quickly determine if either of these parameters can be better optimized for your system. Also, try to use the lowest number of simultaneous captures as possible. In several systems, you're allowed to create as many captures as you want, but you need to remember that for each capture you open more memory is reserved for buffering and less is available for data processing.

5. Are you filtering and slicing?

Filtering is a way of limiting the overall number of packets captured and stored based upon user-specified criteria. Slicing captures and stores all of the packets, but it truncates the packets after a certain length, typically allowing you to store the header information but slice off the payloads. In both cases the same result is achieved, the overall amount of data to store is significantly reduced, freeing up more processing power for capture and analysis and more disk space for storing the data that's truly important to the current analysis task.

6. Are you being reasonable?

Most network analysis systems allow multiple users to connect to the hardware performing critical network data capture and analysis tasks. Put a limit on users. Nominate an owner for each system that will monitor filters and captures. Make sure it's understood who has the authority to go kill a capture. Too many users with too many options is a recipe for disaster. You can always scale with additional systems if needed.

The holy grail of effective network troubleshooting is the ability to pinpoint issues quickly so that they can be fixed. Any approaches to better optimize this particular network analytics process mean more uptime and healthy networks over the long run.

 

Here's a suggestion - instead of loading all packets, shave off time by using utilization statistics about network traffic to provide clues that answer questions like "What happened?" "When?" "Who did it?" Only then determine what slice of time you want to perform deeper network analysis on.   

 

To this end, WildPackets is releasing Compass, a freely available interactive forensics dashboard for the OmniPeek Network Analyzer. Compass' dashboard graph (see screenshot) allows users to select specific time periods for analysis, add and remove nodes and protocols to the same graph, and compare and correlate these for different periods of time, over long periods of time.  

 

In some cases, seeing the utilization in the Compass graph for the nodes and/or protocols in question may solve the problem. Otherwise, once a slice of time has been selected, the packets for just that slice of time can be loaded into OmniPeek by hitting the "Load Packets" button.  If that slice wasn't the problem, just go back to the graph, slide the time window, and load a different slice of packets.

 

Obviously, there are a number of considerations and best practices for troubleshooting a flakey network connection. That being said, here are three considerations that, in most cases, will expedite the process of identifying and pinpointing the problem and shorten the time to getting the network humming once again. 

Consideration #1: Can you record your network traffic and search though the data at the time the issue occurs?

 

This is also known as network forensics. Network forensics refers to the capture, storage and analysis of digital evidence that flows through your enterprise network. The most complete solutions record every single packet that is transmitted over your corporate networks. So, any emails, instant messages, FTP traffic or any other form of communication that takes place on the network can be reconstructed from the original transmissions. Forensics essentially allows you to reconstruct the history of your entire network.

 

With more businesses relying on the cloud for their IT infrastructure or to deliver their service/products to customers, it's crucial to be monitoring both operations and the infrastructure. While the network has become more reliable, reliance on web-based and cloud-served applications or storage has lead to more frequent outages of that infrastructure. By collecting digital evidence via a network recorder, the once laborious, time-consuming searches (including top talkers, most delays, application type, etc.) involving multiple tools and large transfers of data can be reduced to a quick, convenient search.

 

Consideration #2: Is the problem stemming from one user or many users on the same switch or segment?

 

Determining the scope the problem can point the administrator in the right direction of where to start the network analysis providing and what information is most useful determining and correcting the issue. There are several ways of determining whether or not a problem is stemming from one user or many users on the same switch. One of the more common, but least desirable ways is by monitoring the number of trouble tickets. Calls spike - most users are on the same subnet - this is a telltale sign of a possible hardware problem. A far more proactive approach is to use background analysis and monitor for conditions like non-responsive client or server, or low client-server or server to client throughput. You will quickly see if these issues are being reported for a single client, or across many clients. If for a single client, isolate this client for analysis. Determine what other network activities this client is engaged in, and examine these network flows. This will quickly shed light on the issue. If the problem is stemming from many users, is the problem isolated to a single application, or is the issue broadly affecting overall connectivity? If confined to a single application, that's the place to dig. If the issue is overall connectivity for many users, find the connectivity point common to these users and see check for hardware issues.

 

Consideration #3: Is the problem connectivity or utilization related?

Is the network traffic getting to the specified destination? Is a specific machine over-consuming its allocation of bandwidth and crippling other users connectivity while doing some action? On the utilization front, non-work related, "bandwidth sucking" download activities (music, videos, games, etc) are a common culprit. Utilization-related issues are typically intermittent in nature. One, or perhaps several, clients are over-utilizing a network segment, but that comes and goes. Even if the oversubscribing event is long in nature (like streaming video) the remaining utilization still goes up and down with normal network usage, creating intermittent periods of over-utilization. This can easily be monitored by graphing the network utilization in real-time. Connectivity-related issues are typically more binary - users either can or cannot connect to a particular network segment or a particular application. If the issue is utilization related, the next step is to determine if it is client or application driven. This is fairly easy to determine by looking at the top talkers on the network. If the top talkers are clients, drill down and see what protocols the client is using. This typically reveals the source of the problem quite readily. If the issue is connectivity related, the next step is to determine if connectivity is being affected by network congestion, or hardware problems. Network congestion is again easily seen by monitoring network utilization is real time. If not congestion, then the issue is likely to be with hardware within the user(s) connectivity path.

Yikes... This week Sega exposed some of Sony's highly sensitive future plans. Information regarding Sony Playstation 3 and motion controllers discussed in a meeting with Sega were leaked in a document that made its way onto Sega's press site.

 

So, who is responsible? How did this happen? If this happened in your company how can you find out? Enter network forensics.

 

Network forensics refers to the capture, storage and analysis of digital evidence that flows through your enterprise network. The most complete solutions record every single packet that is transmitted over your corporate networks. So, any emails, instant messages, FTP traffic or any other form of communication that takes place on the network can be reconstructed from the original transmissions. It doesn't get any more accurate than that. Network Forensics essentially allows you to reconstruct the history of your entire network.

 

IT personnel utilize network forensics to analyze historical network traffic to conduct or assist in many types of investigations. A few common applications for Network Forensics include HR compliance, intermittent issues, security cyber attacks and transaction analysis. This often starts with terabytes upon terabytes of data. Some tools, like OmniPeek, allow you to analyze data at the point of capture, thus eliminating the need for large data transfers (which are typically done) that consume time and bandwidth. OmniPeek also provides simple and intuitive means to drill down into the relevant data, making easy work out of finding the needle in the multi-terabyte haystack.

 

Using network forensics, you can track down the culprit. Of course, network forensics has many uses other than hunting down perpetrators, but it can be helpful in uncovering sensitive leaks. If they're not already, Sega should be using network forensics to get to the bottom of this snafu.

 

Network forensics is the capture, recording, and analysis of network events. Typically, network forensics' tools employ simple and complex filters to mine stored data to reveal anomalies (what caused them and what the results were on a network performance). The common perception is that network forensics is used to discover the source of security attacks. The recent denial-of-service attacks on Twitter is a recent headline example where network forensics was used to help identify the perpetrator. So while security attacks get the most attention, network forensics can be used for other problem incidents. Even beyond problem incidents, network forensics can even be used for things like business analysis. Below are three network forensics use cases, not including security attacks, for consideration.

 

1) Monitoring User Activity  

 

Social networking sites like Facebook and Twitter have been shown to sap productivity in the workplace. As a result, many organizations have user policies that prohibit, or at least curtail such activities. Recently,  the U.S. Marine Corp. banned marines from using Twitter for a year, as well as Facebook. Additionally, policies prohibiting non-work related "bandwidth sucking" download activities (music, videos, games, etc) are common. Lastly, users may not be going though a proxy server opening up the network to various malware. Network forensics allows all these "rogue" activities to be monitored revealing details as to who broke policy, what policy infraction was committed, and at what time it occurred.

 

2) Business transaction analysis

 

For transactions that take place in clear text like SQL, http request, FTP, or telnet, network forensics allows the network administrator to create the ultimate audit trail for business transactions. Not just server activity, but the business transactions enacted by clients and servers. Additionally, network forensics can serve to troubleshoot the transaction problems that server logs miss.

 

3) Pinpointing the source of intermittent performance issues 

 

On a practical level, here's where network forensics' tools really come in handy - the capturing and handling intermittent network problems, especially those problems that occurred hours or days ago. Traditional "reactive" ad hoc troubleshooting can miss patterns that indicate network problems, so network forensics can be used to catch things that were originally missed.

 

As the SANS Institute notes, "Network forensics can reveal who communicated with whom, when, how, and how often. It can uncover the low-level addresses of the systems communicating, which investigators can use to trace an action or conversation back to a physical device. The entire contents of e-mails, IM conversations, Web surfing activities and file transfers can be recovered and reconstructed to reveal the original transaction. More importantly, the protocol data that surrounded each conversation is often extremely valuable...."

 

Network forensics can be a powerful tool to unlock mysteries found within the network. Make sure you have a network forensics tool best suited for your organization's particular needs.

In the last few days, cyber attacks have infiltrated U.S. and South Korean government agencies. Some sites still remain down.

While this attack is highly sophisticated and far-reaching, it illustrates just how crucial network security is in a world where organized cyber-terrorism can bring down even the most prominent sites. Your website may not be the next target, but if it was, how would you go about protecting it?

For starters, an analysis tool that specializes in viewing and understanding what the network is doing can help. You need something that will:

   1. Analyze and characterize any attack.
   2. Apply filters to isolate malicious behavior. This will define what action is needed to mitigate the effect if an attack slips past network defense.
   3. Equip your network IT team with a powerful incident response tool that can be used in real time and visually represents attacks.

With the proper network tool -- something like a network security Swiss Army Knife -- IT personnel can zero-in on the problem and troubleshoot.

Network forensics works on analyzing historical network traffic in order to conduct investigations for security attacks. Using network forensics security teams can reconstruct the sequence of events that occur at the time of a breach and get the complete picture. The right network forensic solution in place enables IT managers and network engineers to discover and eliminate possible threats in the network and provide lawful interception capabilities when needed.

Our solution, OmniPeek, for example, helps IT personnel analyze data by capturing network traffic at key network points and minimizes traffic loads on the network that can be caused by polling devices this allows you find the data you're looking for quickly and easily. When dealing with network security breaches, time is of the essence.

We've seen quite a few network attacks - our solutions combat security vulnerabilities and our products are used by a number of government agencies. As these recent attacks demonstrate, the hackers are getting more sophisticated. It makes you wonder, if the most secure sites in the world are being compromised, what does that mean for enterprises?