Free tcpdump software for linux

tcpdump is a handy little library which provides a packet filtering mechanism based on the BSD packet filter (BPF).

Most notably, tcpdump needs this to work, and there is also a perl module (still in beta) which can use this as well. In plain english, if you want to write your own network traffic analyzer, this is the place to start.

pdumpq provides a pcap Dump for Linux/Netfilter QUEUE.

pdumpq can be used to take queued packets from netfilter/iptables and dump them to a file that decoders like tcpdump, ethereal, and snort can read.

You can also just pipe it through to the packet decoder and see what is in those packets as they come in. This is also an easy way to populate your snort alert database with iptables data.

Its features include automatic dumpfile rotation, filter on firewall marks and issue per-mark verdicts, and optional emailing of decoded packet dumps.

etherdump project is a very small and efficient ethernet sniffer.
EtherDump is a fork by Peter Willis of ipdump2-pre1 (by Christophe Devine) with a few small improvements and feature add-ons with the end result being able to stream raw frames over a network and eventually convert them into pcap format and import into a pcap-reading prog of your choice (I personally love Ethereal).
Pretty simple use; just run the prog with no arguments and you will get the usage instructions. Log a session to a file using ASCII hex dump and when you are done run `text2pcap hex_dump pcap_file and read `pcap_file with Ethereal or another libpcap-aware program.
Since version 2.01 EtherDump supports some minimal packet filtering rules. Some of the rules you can use are "proto" or "protocol", "sport" or "sourceport", "dport" or "destinationport", "src" or "source", and "dst" or "destination". You can also give "!" or "not" to negate a particular rule.
If you execute EtherDump from a symlink named "tcpdump", the default print out method is tcpdump-like.
On uClibc the compiled size is ~8kB so this is very well suited for embedded systems where you want to debug a network interface but dont have room for a whole libpcap+application_layer program. Instead just combine netcat or a CGI script + httpd with EtherDump and read the traffic (converted to pcap) on another machine on the network.
Enhancements:
- Changes by Peter Willis since 2.0:
- Changed configuration option to reflect new name is "etherdump", not "packetdump". -p is now -e.
- Added basic [ipv4] filtering rules.
- Improved tcpdump output.
- If etherdump was run as a program named tcpdump, defaults to tcpdump-like output.
- Added -i to specify interface.
- If EtherDump is executed as "tcpdump", tcpdump-like output is the default output type.

tcpflow is a program that captures data transmitted as part of TCP connections, and stores the data in a way that is convenient for protocol analysis or debugging.

A program like tcpdump shows a summary of packets seen on the wire, but usually doesnt store the data thats actually being transmitted. In contrast, tcpflow reconstructs the actual data streams and stores each flow in a separate file for later analysis.

tcpflow understands sequence numbers and will correctly reconstruct data streams regardless of retransmissions or out-of-order delivery. However, it currently does not understand IP fragments; flows containing IP fragments will not be recorded properly.

tcpflow is based on the LBL Packet Capture Library (available from LBL) and therefore supports the same rich filtering expressions that programs like tcpdump support.

tcpflow stores all captured data in files that have names of the form

128.129.130.131.02345-010.011.012.013.45103

where the contents of the above file would be data transmitted from host 128.129.131.131 port 2345, to host 10.11.12.13 port 45103.

I originally wrote this program to capture the data being sent by various programs that use undocumented network protocols in an attempt to reverse engineer them. RealPlayer (and most other streaming media players), ICQ, and AOL IM are good examples of this type of application. It should be compiled under most popular versions of UNIX; see the INSTALL file for details.

In tinkering with it, I later also found tcpflow to be useful for checking to see what cookies my browser was sending to various sites, looking at the MIME headers of HTTP requests people are sending to my web server, and verifying that various connections to my machine that were supposed to be encrypted actually were encrypted.

Mupper is a Rescue-cd project for the pegasos computers. Mupper rescue CD is based on Gentoo/Linux.
Mupper contains various tools like parted, midnight-commander and support for various filesystems (not SFS), but support for FAT,VFAT, ReiserFS,XFS and EXT3. Some network tools is also included like snort and tcpdump.
Enhancements:
- Now a full gcc is included with X and fluxbox.
- Also firefox is added.
- QT and GTK2+ toolkits is added.
- This released is a totaly makeover for mupper.

TCFS project is a cryptographic network file system featuring group sharing of encrypted files. TCFS will encrypt your files before sending them to the file server and will decrypt them before they are read by the requesting application.

Because the encryption/decryption process takes place on the client host, no clean data will travel the network. This is particularly valid for the encryption key.

Recent advances in hardware and communication technologies have made possible and cost effective to share a file system among several machines over a local (but possibly also a wide) area network.

One of the most successful and widely used such applications is Suns Network File System (NFS).

NFS is very simple in structure but assumes a very strong trust model: the user trusts the remote file system server (which might be running on a machine in different country) and a network with his/her data. It is easy to see that neither assumption is a very realistic one.

The server (or anybody with superuser privileges) might very well read the data on its local filesytem and it is well known that the Internet or any local area network (e.g, Ethernet) is very easy to tap (see for example, Berkeleys tcpdump application program).
Impersonification of users is also another security drawback of NFS.

In fact, most of the permission checking over NFS are performed in the kernel of the client. In such a context a pirate can temporarely assign to his own workstation the Internet address of victim. Without secure RPC no further authentication procedure is requested. From here on, the pirate can issue NFS requests presenting himself with any (false) uid and therefore accessing for reading and writing any private data on the server, even protected data.

Given the above, a user seeking a certain level of security should take some measures. We propose a new cryptographic file system, which we call TCFS, as a suitable solution to the problem of privacy for distributed file system.

Dynamic Encryption Modules in TCFS:

The dynamic encryption module feature of TCFS allows a user to specify the encryption engine of his/her choiche to be used by TCFS. So you are not forced anymore to use what us (the developer) consider the best (i.e., more secure and efficient) encryption algorithm. The encryption engine must be given in the form of a Linux module and must conform to (the very simple) TCFS API for encryption module. Essentially, it must specify four functions:

1. An initialization function that is called by TCFS when the user pushes her key into TCFS.

Typically the initialization function takes as input the key and returns a pointer to a struct containing a the result of a preprocessing of the key to be used for the encryption and the decryption.

For the specific case of DES the initialization function computes the 16 48-bit subkeys, one for each round of DES.

2. An encryption function which takes a block of data, the length of the block in bytes and the result of the initialization function and encrypts the data.

3. A decryption function which takes a block of data, the length of the block in bytes and the result of the initialization function and decrypts the data.

The encryption and the decryption functions are called each time TCFS needs to read/write a block of data.

4. A cleanup function which performs whatever operation is needed before the key removed by TCFS.

Our work improves on Matt Blazes CFS by providing deeper integration between the encryption service and the file system which results in a complete transparency of use to the user applications.

Release 2.2 of TCFS includes the possibility of threshold sharing files among users. Threshold sharing consists in specifying a minimum number of members (the threshold) that need to be ``active for the files owned by the group to become available.

TCFS enforces the threshold sharing by generating an encryption key for each group and giving each member of the group a share using a Threshold Secret Sharing Scheme. The group encryption key can be reconstructed by any set of at least threshold keys.

A member of the group that intends to become active does so by pushing her/his share of the group key into the kernel. The TCFS module checks if the number of shares available is above the threshold and, if it is so, it attempts to reconstruct the group encryption key. By the properties of the Threshold Secret Sharing Scheme, it is guaranteed that, if enough shares are available, the group encryption key is correctly reconstructed.

Once the group encryption key has been reconstructed, the files owned by the group become accessible. Each time a member decides to become inactive, her share of the group encryption key is removed. The TCFS module checks if the number of shares available has gone under the threshold. In this case, the group encryption key is removed from the TCFS module and files owned by the group become unaccessible.

The current TCFS implementation of the group sharing facility requires each memeber to trust the kernel of the machine that reconstructs the key to actually remove the key once the number of active users goes below the threshold. Future implementations will remove this requirement by performing the reconstruction of the key in a distributed manner.

Scapy is a powerful interactive packet manipulation tool, packet generator, network scanner, network discovery tool, and packet sniffer.
Scapy project provides classes to interactively create packets or sets of packets, manipulate them, send them over the wire, sniff other packets from the wire, match answers and replies, and more.
Interaction is provided by the Python interpreter, so Python programming structures can be used (such as variables, loops, and functions).
Report modules are possible and easy to make. It is intended to do about the same things as ttlscan, nmap, hping, queso, p0f, xprobe, arping, arp-sk, arpspoof, firewalk, irpas, tethereal, tcpdump, etc.
Enhancements:
- This release adds the ability to transcribe ASN1-specified protocols easily, SNMP protocol support, MIB parsing, OID/DNS/OUI resolving, configurable field value resolution, a startup script, and srflood() and srpflood() to flood with packets while catching answers.