Network security experts have long cautioned about the risk posed by the use of peer-to-peer file sharing by individuals working in corporations, warning that the practice creates holes that let malware in and sensitive data out. Their message may be having an impact in the P2P development community.

A trade group representing peer-to-peer file sharing providers next week will publish a report that finds P2P software companies are modifying their programs in an effort to make it harder for users to inadvertently share sensitive information.

Elinor Mills(Cnet news editor) said:

For corporate IT administrators, that shift can’t come soon enough. The problem was highlighted by the recent news that avionics blueprints of President Obama’s helicopter had leaked through a peer-to-peer network used by a defense contractor to an IP (Internet Protocol) address in Iran.

This isn’t the first time sensitive data has trickled out via popular file sharing networks. Last summer, personal information of some 1,000 former patients of the Walter Reed Army Medical Center was believed to have been leaked via a peer-to-peer network. Sensitive health care and financial data has also been found on file sharing networks, according to studies from Dartmouth College and P2P network monitoring service provider Tiversa, which also uncovered the leaked presidential helicopter data.

Peer-to-peer use at ABN Amro and Pfizer led to the exposure of personally identifiable information of more than 20,000 consumers in 2007. And then there was the symbolic slap in the face when politicians called P2P networks a potential “national security threat” at a congressional hearing that summer.

Minimizing the risk

IT administrators need to have a written policy that specifies whether or not employees are allowed to use file sharing. And they need to use perimeter security software, including firewall and intrusion detection, “to lock down the ports used by P2P or to look for specific P2P network traffic,” said Tony Bradley, director of security at Evangelyze Communications, a unified communications software and service provider.

Corporations also might consider encrypting sensitive information and using data loss prevention tools to block data leakage, experts said. And if they want to see if any of their data has found its way onto a P2P network, they can hire Tiversa to probe Gnutella, eDonkey and FastTrack file-sharing networks.

Tiversa probes the networks, searching for specific terms and lets customers know when it finds any data out there specific to that firm and helps pinpoint the source of the leak and stop it.

After lawmakers accused them of being part of the problem nearly two years ago, P2P providers and their trade group–the Distributed Computing Industry Association (DCIA)–formed a working group to figure out ways to minimize the risk for P2P users and their networks. The DCIA prepared a report dated Thursday on the Inadvertent Sharing Protection Compliance that lists guidelines for better protecting P2P users and percentages of its members who are following them.

The latest version of popular file sharing software, released earlier this year, LimeWire 5, includes a number of the suggested changes and served as a “poster child for compliance,” said Marty Lafferty, chief executive of the DCIA.

The report shows 100 percent compliance with the guideline that recommends that default settings prohibit the sharing of user-originated files, while 57 percent of the respondents said they were complying with the guideline to offer a simple way for the user to disable the file-sharing functionality.

Other guidelines, with compliance percentages ranging from 29 percent to 71 percent, included requiring users to select individual files within a folder to share rather than sharing the entire folder, requiring the user to take affirmative steps to share sensitive folders and preventing the sharing of a complete network or external drive or user-specific system folder, such as “Documents and Settings.” Among the guidelines are requirements for warnings to the user when particular settings might jeopardize security.

we(Colasoft) are focus on providing all-in-one and easy-to-use software solutions for users to monitor network activities, analyze network performance, enhance network security, and troubleshoot network problems.

Art…Network Troubleshooting are seemingly unrelated phenotypic effects, so how can we associate them with your imagination? The following case(from Thom, thommitchell.com) will show you:

I recently helped solve an intermittent network/server problem for a client. This problem had been confounding the IT staff of this firm for quite a while and although this wasn’t why I was on site it was impacting my ability to complete my specific consulting work. So I stepped in and started troubleshooting the problem in hopes of getting it fixed so I could get back to work.

Thom described network troubleshooting as art, cause he can solve the problem smoothly, rapidly and lightly, and that’s something like appreciate artist. [click here] to view the full story.

A new worm whose payload includes the SDBot trojan tries to install a “sniffer,” seeking to use infected computers to capture login and banking information for other computers on the same network. While sniffers are hardly new, the bundling of a sniffer with an auto-propagating worm is a new wrinkle, according to security firms.

Sniffers are devices that monitor network traffic, and are a useful network administration tool. They can also be useful to hackers, who install them on compromised computers to monitor and intercept packets flowing through a network. This in turn enables the attacker to capture unencrypted usernames and passwords, which can be used to compromise additional machines on the network.

The sniffing capabilities of the new Worm-SDBot were documented by Trend Micro, and include a list of phrases associated with logins for network administration or Paypal accounts. “If the trojans described by Trend can successfully transmit the filter’s packet captures back to the owner, they are going to cause problems well beyond typical bot infestation issues,” according to the Internet Storm Center.

Malicious sniffers can be difficult to detect because their activity involves collecting packets, rather than transmitting them. Checking to see whether a network card is set in promiscuous (sniffing) mode is a common approach for users concerend about their own machines. Tools for detecting snifffers elsewhere on a network include WireShark, Capsa.

Every network administrator has their own set of tools that they like to use on a daily basis to help them do their job. Here I list 5 tools I like
most.

Network Analyzer – There are actually to sniffer applications that I keep in my toolbox, WireShark and Capsa Network Analyzer. Each program can satisfy my different needs,the difference is that Wireshark has more functionality when it comes to filters. But Capsa Network Analyzer, from my point of view, is the user interface. It presents the data in an extremely easy-to-read way, such that you don’t need to be a hard-core network engineer to see what’s happening. and the pretty graphs will make me happy.

PuTTY – PuTTY is a very versatile telnet application for use when you spend a lot of your day working on Cisco equipment. PuTTY allows a number of different ways to connect to a piece of equipment including Raw, Telnet, Rlogin, SSH, and with the newest version of PuTTY Serial connection. The newest Serial option becomes very handy for network administrators since HyperTerm is no longer available with Windows Vista and you still need a serial connection for new routers and switches. PuTTY is also very customizable and can be run from a USB drive without installing anything onto the computer.

PumpKIN – PumpKIN is a free FTP server program that you can download and use to host your computer as an FTP server. I use this program main for transferring Cisco images back and forth from the switch or router to my computer. This program become very valuable when you have a switch or router down that you need to get back up quick.

MAC Scanner Pro – Colasoft MAC Scanner Pro has some advanced
features,apart from scanning MAC addresses and IP addresses, the most pratical feature is that it allows users to export or print the scanning results.

NetStumbler – NetStumbler was one of the first "Wardriving" programs you could get to pick up other people’s wireless networks. I use this tool on a regular basis for the opposite reason, I want to be able to check for rouge access points on my network. I simply use this little tool and walk around all of my offices and see what wireless devices pop up. I have found a couple of employees who wanted to work out side or away from their office and added a wireless AP so they could.

So those are 5 tools I believe every network administrator should have in their toolkit. For their ease of use, small size, and versatility they made my top 5 tools.

1) Over-Believing the Software’s”Intelligence” without understanding how it makes determinations.

Software default settings are very seldom correct for YOU. For example, a device may say that a SQL server should respond in 50ms. But, if that device is across a WAN with a 200ms ping time–that is highly unlikely. This causes false SLOW SQL messages. This is only an example, but there are many such alerts and messages based on default “thresholds” within this type of software tool’s configuration.

Particulars of your environment may create false alerts or other messages. The definitions of what is an “excessive” delay–latency–broadcasts, etc, are up to you–not the tool.

It’s important for you to know the default settings driving alerts and messages. Then, ignore or alter those alerts that are not set best–for your enterprise. Altering them to make the appropriate settings for your enterprise is the best strategy. Too many false flags or alerts numb you into ignoring important ones or–cause you to make serious errors and incorrect decisions that can be Very Very expensive.

Properly used, those features can save enormous amounts of time and show things your own eye would likely miss.

2) Not understanding the Protocols used, such as TCP, HTTP, etc.

What good is a tool that tells you information about how a protocol is behaving if you do not understand the underlying technology? By this I mean the RFC’s for the protocols that are relevent to your concerns.

—What is the impact of various protocols working differently for the same application doing the same transaction–in different locations?

—What is expected according to specs–and how is your trace file showing different–or less optimal behavior?

—Why would there be 2 TCP connections from one location and 10 from another–for the same application doing the same transaction?

This short article cannot answer all these questions–but it can show you the types of information that you will need to understand in order to make sense out of the data a trace file will show you. Know the protocols well. Deep understanding of TCP is the basic price of admission. While you may consider this a matter of skill sets, my point is that attempting to troubleshooting a problem with a packet-sniffer while not understanding the protocols is a mistake–and a common one. If you add this point to the first one listed–about not believing all the standard settings on tools–you find that the tool cannot answer anything for you by itself. You need to know what you are looking at. You are the analyst–the tool is just an aid.

3) Not understanding the layer 1 and layer 2 aspects of the topology you are sniffing.

Ethernet and all other topologies have many different specifications, which are altered or outright ignored by many switch or other network device manufactures. You must know the specs and how the hardware you are working with applies those specs–or doesn’t apply them. A classic example is Spanning Tree. There are IEEE specifications for Spanning-Tree but those specifications are just a model…not a law. Each manufacturer has tweaked it in order to create some proprietary advancement to give them a competitive advantage. Sometimes, those advances become the new spec. However, you need to know what is standard and how your equipment varies on that theme. What good is seeing the BPDU’s in a trace file if you don’t understand what they contain or how it relates to the problem at hand? Again, this may be looked at as a skill set issue but–expecting to solve critical problems with a packet-sniffer while not knowing this about your network is a mistake.

4) Uni-directional SPANs or Port Mirroring & Single-sided trace files.

Often the switch port used by a server you need to monitor is incapable of providing a bi-directional SPAN (Port Mirror). If so, you cannot get answers from such a trace as it will miss critical information. It can be an oversight by the Engineer doing the trace but sometimes it is simply not understood to be such a critical concern–and ignored. Either way, when you have a situation like this you need to bite the bullet and put in a Change Order to get it moved to a fully bi-directionally mirror-able port before any serious analysis can be done.

Here is a good example of why this is so. Picture a Client and a Server. The Server wants to end a specific TCP connection and keeps sending FIN’s. Yet, we never see the Client send back a FIN ACK. We do see other traffic between them and know that there is connectivity. So, here are the questions:

–Are the FINs not arriving at the Client–or–is the Client receiving them and appropriately sending back the FIN ACK–which are not getting back successfully?

—-If so, then it is most likely a network issue.

–Are the FINs arriving successfully–but being ignored by the Client?

—If so, then it is mostly likely a Server or OS or Data Center issue.

These questions can not be answered with a trace file that only sees one side of the conversation. Two traces, sychronized, are needed to determine the answer to these questions.

5) Incorrect filters–either Capture or Display

An important concept here is that filters add nothing–they only remove–they only filter out. When you say that you are “filtering for” what you mean is that you are “filtering out” everything else. This isn’t just semantics as understanding this perspective is critical to success.

Capture Filters:

Capture Filters are irreversible. If you filtered out something that you need to see–you just aren’t going to see it. There is no second chance without running the test again.

Capture Filters determine what is allowed in the Capture Buffer. If the data is there to see–great. If you filtered what you need out–you can’t change the filter after the fact. A very experienced Protocol Analyst may notice the problem by seeing anomalies that amount to the shadow of the missing data–but most will not be able to tell. And, of course, even if you can tell–you still have to re-test.

This might lead you to think that you should not use Capture Filters–and that is half true. If you don’t really need them–don’t use them. However, if you are drinking your packets out of the Fire Hydrant–you have no choice. Under those conditions the data will fill up your Capture Buffer is less than a single second.

Another point is that they should be consistent within a Test Design. If they vary too much, they will create false differences that can easily lead the Network and Application Performance Analyst or Protocol Analyst astray.

Monitor Filters:

Monitor Filters are forgiving. They work the same way–in that they filter out, not in. However, you can change your mind. The data is in the can (trace file) and it is only a matter of changing the filter to see what was filtered out the last time. Many times I am stumped and then have an idea–go back and change my Capture Filters–and bam! There is the answer. The point is–incorrect Monitor Filters will just as easily lead you astray–but you still have the opportunity to find your way back since the data is still there.

Again, this might leave you thinking to avoid Monitor Filters. Don’t even consider it. Removing irrelevant packets is required to properly measure distinct conversations and search for anomalies. In fact, understanding proper filtering is what using the packet-sniffer software is all about.

6) Lack of understanding the Network-Analyzer‘s CURRENT settings.

Monday, you created a Capture Filter and left it as the default. Friday you need to capture a trace file and click on Capture. Various people perform their roles in the test and you save the trace file. Everyone goes home, back to their main job function or to bed. Then you look at it and discover that you didn’t realize that the old Capture Filter was still in effect! Why? You altered the Default Capture File instead of creating a new one. Your Trace File is useless.

Always remember to review ALL settings before beginning a test. Additionally, run a practice test to make sure all filters and setting are as they should be.

Sometimes the error you discover is that you were given an incorrect IP address and that you never would find what you are looking for from the IP address from which you are capturing packets. That is a GOOD finding. It means someone’s diagram is incorrect. It also means you prevented a useless round of testing.

7) Lack of test controls.

Like any proper experiment, a performance or application test requires a control group and controlled data for all groups. If it was a pharmaceutical test you might have a group with a placebo. In our field we need to create a “BESTline” first. A “Bestline” is not a baseline.

Here is an example.

You have a Client in Singapore and a Server in New York City. The client is Singapore takes 40 milliseconds to execute a transaction and European clients only need 30 milliseconds. Singapore, although farther away, has a faster connection and is expected to get it done in the same time as Europe. What now? Take a BESTline. Use a client in New York City running the same transaction in the same way on similar equipment on the same server as the other two tests. You may discover that it still takes 25 milliseconds! This may due to various issues in the Data Center, Server or PC itself, 25 milliseconds is the fastest it goes!

This means that the first 25 milliseconds have nothing to do with the transport distance or speed. It DOESN’T mean that you have to accept those 25 milliseconds. There is a great deal that can be done about it. However, it is not the network and you now know you have to focus on the Server, PC, Data Center and other components.

Such controls are easy to do–yet seldom done. That common error results in many false leads and false errors as well as lost time and money.