Packet Analysis and Wireshark Online Training – May 27th

April 22nd, 2009 csanders 4 comments

I’ve just announced my second online training event. This event will be happening on Wednesday, May 27th at 2 PM EST.

 

Course Description:

This is an introductory level packet analysis course with a focus on practical usage. The goal of this course will be to give you exactly what you need to jump deep into your network with Wireshark and begin getting value out of these skills immediatley. This course will use completely new files and scenarios and will not repeat any real-world scenarios taught in my book or in my previous trainings.

 

Prerequisites:

In order to understand what is going on in this course you will need to have a decent level of experience troubleshooting networks and client/server communications. You won’t be expected to know how individual protocols look on the wire (I’ll teach you that) but you will be expected to know what DHCP/DNS/SMTP/ETC are used for. 

The course will be administered using Citrix Go2Meeting which will transmit live audio and video from my computer. Because of this, some form of broadband Internet connection is recommended. I’ve used this format before and it seemed to work really well as all users were able to connect and listen/watch successfully.

 

Who Should Attend:

If you troubleshoot or maintain a network on a daily basis then this course will provide immediate value to you. Packet Analysis is one of the hottest growing skill sets amongst IT staff in the world and is an absolute requirement to troubleshoot certain problems that may be faced. If you want to save yourself time, save your organization money, or make yourself more marketable by increasing your skill set, then this is the course for you.

 

Cost:

The early registration cost for this course is $100 USD. This pricing is valid until May 5th. After May 5th, the cost goes up to $150 USD. If you work for a non-profit or in education, please e-mail me for a discounted rate. The course is limited to a set number of participants so that I can get to all questions that may be asked, so your best bet is to get in early.

 

Curriculum:

Hour 1 – Intro, Theory, and Getting Your Feet Wet

  • How Packet Analysis Can Help You
  • “War Stories”
  • How a Packet Sniffer Works
  • Getting and Installing Wireshark
  • Sniffer Placement on Your Network
  • Walkthrough of Wiresharks Features Using Real Trace Files

Hour 2 – Protocols and Performance with Real World Case Scenarios

  • Analyzing Common Protocols When They Work and When They Don’t
  • Troubleshooting Network Performance Problems
  • Steps for Creating a Network Baseline
  • The 7 Deadly Sins of the Network

Hour 3 – Security, Wireless, and More Real World Scenarios

  • Analyzing Common Network Attacks
  • Wireless Packet Analysis
  • Additional Tools and Resources
  • Q&A

 

Registration:

In order to sign up for this course, please fill out the registration form below. At some point after registering, you should receive an e-mail from me with payment details.

 

 

As always, if you  have any questions regarding this training please e-mail me.

Share This Post:
  • Print
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati

Keeping Capture Files Manageable

April 20th, 2009 csanders No comments

When you are capturing a lot of traffic the size of your capture files can grow really quickly. When this happens you are really going to have a hard time getting anything done when trying to sort through the file. There are a couple of things you can to do prevent this from happening.

Use an Effective Capture Filter

Capture filters are great when you know what you are looking for. If you ONLY want SMTP traffic, you can capture only that traffic. If you ONLY want to see HTTP POSTs, then you can capture only that traffic. If you aren’t sure what you are looking for then its bests to stick to capturing everything and using display filters, but when you have an eye on your target then capture filters are a great way to cut through the weeds. You will find this especially beneficial when capturing packets from a busy server or network segment.

Some of the things you can filter based upon include:

  • Specific Protocols
  • A Particular IP/MAC Address
  • Incoming/Outgoing Traffic Only

Split the Capture File as It’s Being Captured

Wireshark has some really great flexibility in allowing you to split a capture file as its being created. You can access this by selecting Capture from the main drop-down menu and selection Options, or by pressing Ctrl+K.

captureoptions

You have a couple of options here and they all become available to you when you place a check mark next to the Use Multiple Files box. There are two primary sections which I’ve creatively labeled the Multiple File and Stop Capture sections.

The multiple file section lets you specify a point at which a new file is created, either by reaching a certain size limit or at a certain time interval. I find that I typically use the size option for typical uses, but specifying a time interval for the packet capture can become very useful when you are trying to pinpoint when a certain event is happening. In this scenario you could start the capture at 12:00 and place and set the multiple file option to create the next file every 1 hour which should create a nice clean display of capture files by the hour.

It’s important to note that you can specify both of these criteria and in this case, a new file will be created when EITHER condition is met. In this top section you can also specify a maximum number of files to be created (don’t underestimate the value of this, I’ve accidentally filled up a hard drive on many occasions) and specify a ring buffer. A ring buffer uses a set number of files, and after the last file has been written it will begin overwriting the first file and cycling back through.

The stop capture section of this area is very straightforward and allows you to stop a capture after it reaches a certain point, either at a certain number of packets captured, a certain size limit, or a particular time interval. This comes in handy when you want to start a capture and run off to lunch or take a call.

Ensure You Are Capturing in the Best Location

One of the most overlooked parts of the packet analysis process is ensuring you are properly tapped into the network and getting the packets you need. Although the typical concern is whether or not you are getting enough packets, there are some cases in which you may be capturing TOO MUCH information. If you are having trouble weeding through a large capture file then you need to ask yourself if you really need to be where you are at. If it is a client/server issue, do you really need to capture from the server or would capturing from the client yield the traffic you need? If you are analyzing a slow network link, do you really need to be inside the router or would you be best suited to tap the outside interface of the router and get away from the internal networks broadcast domain?

Working with larger capture files is a real quick way to bog down your system and further complicate what may already be a long drawn out process. Using these techniques you should be able to keep tabs on your capture file size and make your analysis process quite a bit more efficient.

Share This Post:
  • Print
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
Categories: Packet Analysis Tags: ,

Using a Tap for Packet Analysis

April 8th, 2009 csanders 1 comment

I’ve already written quite a bit about getting on the wire as it pertains to packet analysis. Half the battle when you are capturing packets is placing the sniffer computer so that it captures the packets you need. The advent of switched networks makes this a bit harder on us as traffic is now directed and not free-flowing across every port on a network. In a post a few months ago I outlined three methods for getting on the wire. Those three methods were ARP Cache Poisoning, Hubbing Out, and Port Mirroring. One other technique which I had not previously used, but have now grown to love is using a network tap.

 

tap-diagram2A tap is basically a hardware device that you can place on the wire to intercept the right packets.

 

The tap has at least three ports. These are inbound and outbound ports and a monitor port.

 

Say you wanted to intercept all network traffic entering your router. Typically, you would have a single cable going from a switch to your router. In order to insert the tap into the mix, you would unplug the current cable from the router and plug it into the inbound port on the tap. You would add an additional cable from the outbound port of the tap into the port on your router. Lastly, you would place a cable into the monitor port that leads to your analysis machine. The analysis machine will then capture all traffic flowing between the switch port and the router.

 

The great thing about doing this as opposed to hubbing out is that you aren’t using an old school hub that could cause dropped packets and limits you to half-duplex communication. This is also advantageous over ARP cache poisoning because it doesn’t generate any extra traffic on the wire, which is something you typically want to avoid doing…especially in security scenarios.  If your layer three switches typically have a very high processor utilization, you could also consider this over port mirroring. The tap adds no extra traffic or latency to the traffic on the wire and is completely undetectable.

 

barr_tapThat all being said I recommend the Barracuda network tap. They run about $130 and have an added benefit of having TWO monitor ports. One port monitors all inbound traffic and the other monitors all outbound traffic rather than having a single port for both, which can add some flexibility in your analysis. The Barracuda tap also allows for the use of a nine volt battery in situations where a power outlet isn’t handy or you just want to capture some packets quickly.

 

 

 

You can get the Barracuda network tap from http://www.barracudanetworks.com/tap/.

Share This Post:
  • Print
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
Categories: Packet Analysis Tags: ,

Chappell University

February 23rd, 2009 csanders No comments

Laura Chappell, one of the packet analysis world’s best, has just announced Chappell University. Here is her official statement from her newsletter:

“Chappell University (www.chappellU.com) is open for registration today. Subscription-level service will be open soon – I’ll let you know. Chappell University is an affordable, on-demand, online training system to maintain and enhance IT skills in the area of analysis, troubleshooting and security. Last night I uploaded two lab workbooks with over 100 lab exercises using Wireshark to spot network problems, security breaches, and analyze normal and abnormal TCP/IP communications. I’ve recoreded video answers to all the lab exercises. In addition, I’ve uploaded my trace file respository and you’ll see me uploading additional WLAN, VoIP, bot-infections, application, etc., trace files each quarter. Check out the new YouTube Channel for Chappell University at www.youtube.com/chappellU and the video “Ethical Hacking with NetScanTools Pro: Tutorial on ARP Scanning to Discover All Local Hosts” (even those hidden behind firewall applications). “

If you haven’t had the pleasure of experiencing Laura’s training on-site, or via Wireshark University, I would highly reccommend both. As I said, she is one of the best in the field.

Share This Post:
  • Print
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati

Pcapr Packet Repository

February 16th, 2009 csanders 5 comments

In the past when folks had asked me if I was aware of any type of packet capture file repository in the Internet, I had pointed them towards OpenPacket.org. The site never really seemed to take off, and I just saw this post on Bejtlich’s TaoSecurity blog. That being the case, I will now be recommending Pcapr from Mu Dynamics. I’ve just now been made aware of it, but it already seems to have quite a bit of good content. I hope to contribute some files from my lab to it as well.

Share This Post:
  • Print
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
Categories: Packet Analysis Tags:

Practical Packet Analysis Training Online – December 11th

November 9th, 2008 csanders 2 comments

The date has been set for my first ever online Wireshark training. This will be held live on Thursday, December 11th at 2 PM Central Standard Time. The training will be taught via Go2Meeting and the slides and capture files used will be made available after the presentation. The cost for attending is $150. The only prerequisite is a basic knowledge of computer networking and an interest in the subject. Here is a breakdown of the curriculum:

Hour 1

Benefits of Packet Analysis
How a Packet Sniffer Works
Installing Wireshark
The OSI Model
Types of Traffic on the Wire
Analyzer Placement on the Cabling System
Basic Wireshark Features
Advanced Wireshark Features
Wireshark Statistics

Hour 2

Display/Capture Filters
Common Protocols (TCP, HTTP, DNS, DHCP, ARP, TELNET, FTP, POP, SMTP, etc)
Troubleshooting Performance Problems
Network Baselines
Wireless Packet Analysis

Hour 3

Additional Wireshark Tools and Resources
Useful Websites and Other Learning Resources
Q&A

 

I already have quite a few people signed up and will be limiting the number of attendees so that I can answer as many questions during the Q&A as I can without leaving anybody out. If you are interested, e-mail me at chris@chrissanders.org and reference the class. Payment is accepted via check (must have it very soon so it can clear in time for the training) or PayPal (info will be provided when you e-mail me).

Share This Post:
  • Print
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati

Wireshark Quick Tip – Viewing HTTP Requests

October 12th, 2008 csanders No comments

Wireshark is a great way to monitor Internet traffic when the need arises. In situations where some type of proxy server isn’t in place to monitor Internet traffic, Wireshark is a great substitute. Whether you capture the target computers traffic via port mirroring or ARP cache poisoning, Wireshark has a simple interface you can use to view the HTTP traffic going across the wire. In order to do this, capture the appropriate traffic and select Statistics from the drop down menu, select HTTP, and choose the Requests option. You will be presented with the option to filter the traffic. Once you create a filter if you choose to, click the Create Stat button and you will see a window like the one below that will give you a breakdown of the HTTP requests captures on the wire.

HTTPRequests

One important note…make sure that when you are capturing this traffic you filter out any HTTP requests that may be occurring on your analysis computer. Although you may not be browsing to the Internet interactively, that’s not to say your computer is generating HTTP requests due to Antivirus updates, Windows updates, etc.

Share This Post:
  • Print
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
Categories: Packet Analysis Tags: ,

Wireshark Quick Tip – Creating Firewall ACL Rules

August 24th, 2008 csanders No comments

One of the coolest newer features of Wireshark is the ability to automatically generate firewall ACL rules based upon a packet you may be viewing. As an example of this, take a look at the following packet:

If you look at the data portion of this packet you can see that this is packet generated by the infamous blaster worm. Notice the destination port is 4444 which is the standard port used by blaster. In the case, let’s say we want to create a firewall ACL rule that blocks anything with a destination port of 4444 on an iptables firewall. If we select this packet, go to Analyze > Firewall ACL Rules on the standard toolbar, we will get a dialog that will let us build custom firewall rules based upon the contents of this packet. In our scenario here, we would select Netfilter (IPTABLES) from the vendor drop down box, and select TCP Port 4444 in the filter box. This will output the exact command you need to enter in your iptables configuration to enact this firewall rule. If you play around with this feature you will see that there is quite a bit you can do with it.

This feature is very new and doesn’t support a lot of different vendors, but this should develop over time.

Share This Post:
  • Print
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
Categories: Packet Analysis Tags: ,

Wireshark Quick Tip – Capture Summary Window

June 15th, 2008 csanders 2 comments

One of the first windows you may often want to view when analyzing a capture file is the capture summary window. You can access this by opening a capture file and going to Statistics in the drop-down menu and selecting Summary. The wireshark summary window gives us a few really useful things. First of all, it gives us a time reference as to when the capture was taken as detailed in the first packet and last packet fields. Second of all, and one of the things I find most useful is the throughput fields displayed in this window. Here you can see the things such as the average packet size, total bytes captures, and the average Mbytes per second. I often will use the Mbit/sec to determine congestion on the wire. You can compare this number with the line speed on the network (100 Mbit/sec, 1 GB/sec, etc) to determine if you are seeing congestion that might cause packet loss.

Share This Post:
  • Print
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
Categories: Packet Analysis Tags: ,

Top 10 Security Settings to Change After Installing AD

May 20th, 2008 csanders No comments

Derek Melber wrote a great little article about the top ten security settings to make directly after installing Active Directory. I’d recommend all of these. Our server guys here actually have a very similar procedure they follow when creating a new network.

Read the full article here.

Share This Post:
  • Print
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati

WSUS Clients Not Connecting

May 18th, 2008 csanders 8 comments

 I write a lot about WSUS because I think it is a necessity for any network with Windows servers or clients. It is typically pretty easy to setup but occasionally you will run into some issues. Out of all of the WSUS issues I hear about and directly experience (and trust me, I manage a LOT of WSUS servers) the most common problem I hear is when the computers in a network simply don’t connect to the WSUS server.

Here are a few items which are the most typical causes to this problem:

Lack of Patience

This is the number one overall issue I see. WSUS is built upon a technology that is by no means instant. It takes some time for updates to download, it takes some time for Group Policy Objects to apply, and it takes some time for computer to report in to WSUS in general. That being the case, if you have just installed WSUS and are looking at this article two hours later because computers aren’t reporting in, then you most likely haven’t waited long enough. I generally tell people to wait as long as two days after installing WSUS to start looking into why individual clients aren’t reporting.

Group Policy Issues

One of the simpler problems is that either the Group Policy Object for configuring the automatic update service is not being applied or it is misconfigured. At a minimum, your GPO should be configured so that it points the automatic update service to download from the WSUS server. Make sure you don’t have any typos in this path.

You can make sure that your GPO is being applied to the computer in question by typing GPRESULT into a command prompt on one of the machines in question. Remember, the Group Policy setting for configuring automatic updates is to be applied to computer objects, not users.

Client Requirements

WSUS clients must be Windows 2000 SP3, Windows XP, or Windows Server 2003 in order to take advantage of WSUS. I’ve seen lots of cases where someone would tell me a bunch of their workstations weren’t reporting in and updating only to find out they were Windows 2000 SP2 or something like that.

Imaged/Cloned Computers

In some network most if not all of the workstations were deployed with system images via Acronis, Ghost, or some similar program. If that’s the case, there is a good chance that the WSUS ID, a unique identifier found in the registry of every computer on your network, was not regenerated. These WSUS IDs are generated based upon the SID of a computer. If you configured your image so that it would generate a new SID upon pasting then you likely won’t have this problem, but this step is commonly forgotten. The WSUS ID is stored in these three registry keys:

HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateAccountDomainSid
HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdatePingID
HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateSusClientId

In order to generate a new WSUS ID, you will need to delete these keys on the client machine in question. After doing this, restart the Automatic Update service and run the command “wuauclt.exe /resetauthorization /detectnow. You should see the computer in the WSUS console shortly after that.

This process may seem a bit too manual when you have to perform it on multiple computers, so there is a VB script that can automate this a bit. You can download this script here: http://www.vbshf.com/vbshf/forum/forums/thread-view.asp?tid=199&start=1. You can simply download this script and perform the aforementioned steps remotely by just entering the computer name.

This covers a few of the most common reasons clients don’t report in. Obviously, there is no way to cover every possibly avenue, but hopefully this will eliminate some of the more common possibilities. As always, I respond to direct WSUS questions via e-mail. Also, the WSUS forums over at http://www.wsus.info/ are a great community driven resource for figuring out issues like this.

Share This Post:
  • Print
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati

InSecure Magazine and WindowsNetworking.com Articles

May 7th, 2008 csanders No comments

I’ve been pretty busy the past few weeks. I’ve just had an article published in InSecure Magazine entitled “Using Packet Analysis for Network Troubleshooting”, which can be seen here. Also, the great folks over at TechGenix just published my article entitled “Deploying Microsoft Windows Server Update Services (WSUS)” on WindowsNetworking.com, which can be seen here.

More coming soon!

Share This Post:
  • Print
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati
Categories: Publications Tags:

Using ARP Cache Poisoning for Packet Analysis

April 13th, 2008 csanders 4 comments

Unfortunately, sniffing packets isn’t always as easy as plugging into an open port and firing up Wireshark. In fact, it is sometimes more difficult to place a packet sniffer on a network’s cabling system than it is to actually analyze the packets. In the grand ole days of packet analysis when everybody used hubs you could plug in and sniff all of the traffic on a network segment. As most of you know now however, the advent of switched networks prevents this. When you plug a sniffer in to a port on a switch, you can only see broadcast traffic and the traffic transmitted and received by your machine. Because of that we have had to come up with a few alternative techniques to getting the traffic we need.

The three most popular techniques for doing this are port mirroring, hubbing out, and ARP cache poisoning. The goal of this article is to give a brief overview of port mirroring and hubbing out, which are very commonly used, and then to give a detailed explanation of ARP cache poisoning, the least well known of the trio.

The Common Techniques

Port Mirroring is probably one of the easiest ways to capture the traffic you are looking for. Also called port spanning, this is a feature available on most managed network switches. This is configurable by accessing the command line or GUI management for the switch the target and sniffer systems are plugged in to and entering commands which mirror the traffic of one port to another. For instance, to capture the traffic of a device plugged in to port 3 on a switch, you could plug your sniffer into port 6 and enter a vendor specific mirroring command that mirrors port 3 to port 6.

Hubbing out is a technique in which you localize the target device and your analyzer system on the same network segment by plugging them directly in to a hub. In order to do this, all you need is an old hub and a few network cables. Simply go to the switch that the target computer resides on and unplug it from the network. Plug the targets network cable, along with the cable for your sniffer, into the hub, and then plug the hub into the network switch. This will put your sniffer and the target machine on the same broadcast domain and allow you to see all of the packets going to and from the target machine, as well as yours. Since this does involve a brief moment of connectivity loss, I do highly recommend letting the user of the target system know that you will be briefly disrupting their connectivity, especially if it is someone in management!

Poisoning the ARP Cache

The ARP protocol was designed out of necessity to facilitate to translation of addresses between the second and third layers of the OSI model.  The second layer, or data-link layer, uses MAC addresses so that hardware devices can communicate to each other directly on a small scale. The third layer, or network layer, uses IP addresses (most commonly) to create large scalable networks that can communicate across the globe. The data link layer deals directly with devices connected together where as the network layer deals with devices that are directly connected AND indirectly connected. Each layer has its own addressing scheme, and they must work together in order to make network communications happen. For this very reason, ARP was created with RFC 826, “An Ethernet Address Resolution Protocol”. I’m not going to go into detail on the whole ARP process here, but I highly recommend reading my Packet School 201 write up on it here in order to better understand this process.

ARP cache poisoning is a more advanced form of tapping into the wire on a switched network. It is commonly used by hackers to send falsely addressed packets to client systems in order to intercept certain traffic or cause denial of service (DoS) attacks on a target, but ARP cache poisoning can still serve as a legitimate way to capture the packets of a target machine on a switched network.

ARP cache poisoning, sometimes referred to as ARP spoofing, is the process of sending ARP messages to an Ethernet switch or router with fake MAC (Layer 2) addresses in order to intercept the traffic of another computer.

 

Using Cain & Abel 

When attempting to poison the ARP cache, the first step is to download the required tools and collect some necessary information. We’ll use the popular security tool Cain & Abel from Oxid.it (http://www.oxid.it). The installation is pretty straight forward so I won’t go through that here.

Once you have installed the Cain & Abel software, you need to collect some additional information including the IP addresses of your analyzer system, the remote system you wish to capture the traffic from, and the router that the remote system is downstream from.

When you first open Cain & Abel, you will notice a series of tabs near the top of the window. (ARP cache poisoning is only one of a variety of Cain & Abel’s features.) For our purposes, we’ll be working in the Sniffer tab. When you click this tab, you will see an empty table. In order to fill this table you will need to activate the program’s built-in sniffer and scan your network for hosts.

Click the second icon on the toolbar, which resembles a network card. The first time you do this you will be asked to select the interface you wish to sniff. This interface should be the one that is connected to the network you will be performing your ARP cache poisoning on. Once you’ve selected this interface, click OK to activate Cain & Abel’s built-in sniffer. To build a list of available hosts on your network, click the icon that resembles a plus (+) symbol, and click OK.

The once-empty grid should now be filled with a list of all the hosts on your attached network, along with their MAC addresses, IP addresses, and vendor identifying information. This is the list you will work from when setting up your ARP cache poisoning.

At the bottom of the program window, you will see a set of tabs that will take you to other windows under the Sniffer heading. Now that you have built your host list, you will be working from the APR tab. Switch to the APR window by clicking the tab.

Once in the APR window, you are presented with two empty tables: an upper and a lower one. Once you set them up, the upper table will show the devices involved in your ARP cache poisoning, and the lower table will show all communication between your poisoned machines.

Continue setting up your ARP poisoning by clicking the icon resembling the plus (+) symbol on the program’s standard toolbar. The window that appears has two selection columns side by side. On the left side, you will see a list of all available hosts on your network. Click the IP address of the target computer whose traffic you wish to sniff. This will result in the right window showing a list of all hosts in the network, omitting the target machine’s IP address. In the right window, click the IP address of the router that is directly upstream of the target machine, and click OK.

The IP addresses of both devices should now be listed in the upper table in the main application window. To complete the process, click the yellow-and-black radiation symbol on the standard toolbar. This will activate Cain & Abel’s ARP cache poisoning features and allow your analyzing system to be the middleman for all communications between the target system and its upstream router.

You can now fire up your packet sniffer and begin the analysis process. When you are finished capturing traffic, simply click the yellow-and-black radiation symbol again to stop ARP cache poisoning.

A Final Note

As a final note on ARP cache poisoning, you should be very aware of the roles of the systems you implement this process for. For instance, do not use this technique when the target device is something with very high network utilization, such as a fileserver with a 1Gbps link to the network (especially if your analyzer system only provides a 100Mbps link). When you perform this rerouting of traffic, all traffic transmitted and received by the target system must first go through your analyzer system, therefore making your analyzer the bottleneck in the communication process. This can create a DoS-type effect on the machine you are analyzing, which will result in degraded network performance and faulty analysis data.

That is all there really is to ARP cache poisoning. This technique has always proved significantly useful in packet analysis experience and I hope it does in yours as well.

Share This Post:
  • Print
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati

Guest Post on TheLazyAdmin.com – WSUS FAQ

April 10th, 2008 csanders No comments

Dan Nerenberg over at TheLazyAdmin.com has just published a guest post from me about WSUS. If you have never heard of this site, then I’d highly recommend adding it to your daily reads. Originally started by former MVP and current Microsoft employee Rodney Buike, it contains a great deal of informative content.

The post is a detailed WSUS FAQ. If you are considering deploying WSUS but have some questions, then chances are that this FAQ will answer at least a couple of them. Check it out here.

Share This Post:
  • Print
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati

Proactive Security: Using SPF Records to Prevent E-Mail Domain Spoofing

April 5th, 2008 csanders 3 comments

SPAM and Phishing are both really big problems for pretty much an organization right now, and it appears to only be getting worse. One of the most common tactics used by spammers is to forge legitimate domain names in the e-mails this send. The goal here is to trick a user in to opening of these messages, or at least to get them through a SPAM filtering service to a users inbox.

The best way to prevent your e-mail domain from being spoofed is through the use of Sender Policy Framework (SPF) Records. This is basically a DNS TXT record that mail servers and spam filtering services access to verify the source of e-mail messages as they arrive.

In order to create a SPF record, start by opening the DNS MMC snap-in. From here, browse to the forward lookup zone for this DNS server, right click in the blank area, choose Other New Records, and select Text (TXT). The typical value for this record (minus the quotes) should be “v=spf1 a mx -all”. What this says is that all mail that is received from an IP address listed that’s listed in the sending domains A or MX records is legitimate. This will suffice for most companies, but in the case that you want to get a little stricter with this, you can use an entry of “v=spf1 a mx ip4:192.168.1.2 -all”. This basically specifies 192.168.1.2 as the only IP address that valid mail can be sent from.

It is considered a good proactive security principle to configure an SPF record for your domain, regardless of whether you are having SPAM/Phishing problems or not.

Share This Post:
  • Print
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Technorati