How to use Tcpdump ?

In this video, You can know how to use Tcpdump to capture and packet analyzer.

TCPdump for Linux/Unix Administrator

1. What is TCPdump ?

TCPDUMP is a command-line packet capture tool that runs in a Unix and Linux environment. It can provide very detailed information about any network conversation that runs across the wire.

An advantage of TCPDUMP is that it can be run remotely through a SSH or TELNET session, and the machine running TCPDUMP does not have to be running x-windows. The application uses very little overhead, since it's a non-graphical interface.

You can getting lastest version here : http://www.tcpdump.org

2. TCPdump Command .

NAME
tcpdump - dump traffic on a network
SYNOPSIS
tcpdump [ -adeflnNOpqRStuvxX ] [ -c count ]

[ -C file_size ] [ -F file ]

[ -i interface ] [ -m module ] [ -r file ]

[ -s snaplen ] [ -T type ] [ -U user ] [ -w file ]

[ -E algo:secret ] [ expression ]
DESCRIPTION

Tcpdump prints out the headers of packets on a network interface that match the boolean expression. It can also be run with the -w flag, which causes it to save the packet data to a file for later analysis, and/or with the -r flag, which causes it to read from a saved packet file rather than to read packets from a network interface. In all cases, only packets that match expression will be processed by tcpdump.

Tcpdump will, if not run with the -c flag, continue capturing packets until it is interrupted by a SIGINT signal (generated, for example, by typing your interrupt character, typically control-C) or a SIGTERM signal (typically generated with the kill(1) command); if run with the -c flag, it will capture packets until it is interrupted by a SIGINT or SIGTERM signal or the specified number of packets have been processed.

When tcpdump finishes capturing packets, it will report counts of:

    packets ``received by filter'' (the meaning of this depends on the OS on which you're running tcpdump, and possibly on the way the OS was configured - if a filter was specified on the command line, on some OSes it counts packets regardless of whether they were matched by the filter expression, and on other OSes it counts only packets that were matched by the filter expression and were processed by tcpdump);
    packets ``dropped by kernel'' (this is the number of packets that were dropped, due to a lack of buffer space, by the packet capture mechanism in the OS on which tcpdump is running, if the OS reports that information to applications; if not, it will be reported as 0).

On platforms that support the SIGINFO signal, such as most BSDs, it will report those counts when it receives a SIGINFO signal (generated, for example, by typing your ``status'' character, typically control-T) and will continue capturing packets.

Reading packets from a network interface may require that you have special privileges:

Under SunOS 3.x or 4.x with NIT or BPF:
    You must have read access to /dev/nit or /dev/bpf*.
Under Solaris with DLPI:
    You must have read/write access to the network pseudo device, e.g. /dev/le. On at least some versions of Solaris, however, this is not sufficient to allow tcpdump to capture in promiscuous mode; on those versions of Solaris, you must be root, or tcpdump must be installed setuid to root, in order to capture in promiscuous mode. Note that, on many (perhaps all) interfaces, if you don't capture in promiscuous mode, you will not see any outgoing packets, so a capture not done in promiscuous mode may not be very useful.
Under HP-UX with DLPI:
    You must be root or tcpdump must be installed setuid to root.
Under IRIX with snoop:
    You must be root or tcpdump must be installed setuid to root.
Under Linux:
    You must be root or tcpdump must be installed setuid to root.
Under Ultrix and Digital UNIX/Tru64 UNIX:
    Any user may capture network traffic with tcpdump. However, no user (not even the super-user) can capture in promiscuous mode on an interface unless the super-user has enabled promiscuous-mode operation on that interface using pfconfig(8), and no user (not even the super-user) can capture unicast traffic received by or sent by the machine on an interface unless the super-user has enabled copy-all-mode operation on that interface using pfconfig, so useful packet capture on an interface probably requires that either promiscuous-mode or copy-all-mode operation, or both modes of operation, be enabled on that interface.
    Sponsored Links

    EtherNet/IPAdd EtherNet/IP protocol to your embedded controller fastwww.ProtoCessor.com

    Modbus InterfaceLargest driver library interfaces 80+ protocols to Modbus RTU/TCPwww.FieldServer.com

    PC + LAN Infrared ControlControl your PC with an IR Remote Control A/V via PC / LAN / WLANwww.irtrans.com
Under BSD:
    You must have read access to /dev/bpf*.

Reading a saved packet file doesn't require special privileges.
OPTIONS
-a
    Attempt to convert network and broadcast addresses to names.
-c
    Exit after receiving count packets.
-C
    Before writing a raw packet to a savefile, check whether the file is currently larger than file_size and, if so, close the current savefile and open a new one. Savefiles after the first savefile will have the name specified with the -w flag, with a number after it, starting at 2 and continuing upward. The units of file_size are millions of bytes (1,000,000 bytes, not 1,048,576 bytes).
-d
    Dump the compiled packet-matching code in a human readable form to standard output and stop.
-dd
    Dump packet-matching code as a C program fragment.
-ddd
    Dump packet-matching code as decimal numbers (preceded with a count).
-e
    Print the link-level header on each dump line.
-E
    Use algo:secret for decrypting IPsec ESP packets. Algorithms may be des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc, cast128-cbc, or none. The default is des-cbc. The ability to decrypt packets is only present if tcpdump was compiled with cryptography enabled. secret the ascii text for ESP secret key. We cannot take arbitrary binary value at this moment. The option assumes RFC2406 ESP, not RFC1827 ESP. The option is only for debugging purposes, and the use of this option with truly `secret' key is discouraged. By presenting IPsec secret key onto command line you make it visible to others, via ps(1) and other occasions.
-f
    Print `foreign' internet addresses numerically rather than symbolically (this option is intended to get around serious brain damage in Sun's yp server --- usually it hangs forever translating non-local internet numbers).
-F
    Use file as input for the filter expression. An additional expression given on the command line is ignored.
-i
    Listen on interface. If unspecified, tcpdump searches the system interface list for the lowest numbered, configured up interface (excluding loopback). Ties are broken by choosing the earliest match.
    On Linux systems with 2.2 or later kernels, an interface argument of ``any'' can be used to capture packets from all interfaces. Note that captures on the ``any'' device will not be done in promiscuous mode.
-l
    Make stdout line buffered. Useful if you want to see the data while capturing it. E.g.,
    ``tcpdump -l | tee dat'' or ``tcpdump -l > dat & tail -f dat''.
-m
    Load SMI MIB module definitions from file module. This option can be used several times to load several MIB modules into tcpdump.
-n
    Don't convert host addresses to names. This can be used to avoid DNS lookups.
-nn
    Don't convert protocol and port numbers etc. to names either.
-N
    Don't print domain name qualification of host names. E.g., if you give this flag then tcpdump will print ``nic'' instead of ``nic.ddn.mil''.
-O
    Do not run the packet-matching code optimizer. This is useful only if you suspect a bug in the optimizer.
-p
    Don't put the interface into promiscuous mode. Note that the interface might be in promiscuous mode for some other reason; hence, `-p' cannot be used as an abbreviation for `ether host {local-hw-addr} or ether broadcast'.
-q
    Quick (quiet?) output. Print less protocol information so output lines are shorter.
-R
    Assume ESP/AH packets to be based on old specification (RFC1825 to RFC1829). If specified, tcpdump will not print replay prevention field. Since there is no protocol version field in ESP/AH specification, tcpdump cannot deduce the version of ESP/AH protocol.
-r
    Read packets from file (which was created with the -w option). Standard input is used if file is ``-''.
-S
    Print absolute, rather than relative, TCP sequence numbers.
-s
    Snarf snaplen bytes of data from each packet rather than the default of 68 (with SunOS's NIT, the minimum is actually 96). 68 bytes is adequate for IP, ICMP, TCP and UDP but may truncate protocol information from name server and NFS packets (see below). Packets truncated because of a limited snapshot are indicated in the output with ``[|proto]'', where proto is the name of the protocol level at which the truncation has occurred. Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering. This may cause packets to be lost. You should limit snaplen to the smallest number that will capture the protocol information you're interested in. Setting snaplen to 0 means use the required length to catch whole packets.
-T
    Force packets selected by "expression" to be interpreted the specified type. Currently known types are cnfp (Cisco NetFlow protocol), rpc (Remote Procedure Call), rtp (Real-Time Applications protocol), rtcp (Real-Time Applications control protocol), snmp (Simple Network Management Protocol), vat (Visual Audio Tool), and wb (distributed White Board).
-t
    Don't print a timestamp on each dump line.
-tt
    Print an unformatted timestamp on each dump line.
-U
    Drops root privileges and changes user ID to user and group ID to the primary group of user.

    Note! Red Hat Linux automatically drops the privileges to user ``pcap'' if nothing else is specified.
-ttt
    Print a delta (in micro-seconds) between current and previous line on each dump line.
-tttt
    Print a timestamp in default format proceeded by date on each dump line.
-u
    Print undecoded NFS handles.
-v
    (Slightly more) verbose output. For example, the time to live, identification, total length and options in an IP packet are printed. Also enables additional packet integrity checks such as verifying the IP and ICMP header checksum.
-vv
    Even more verbose output. For example, additional fields are printed from NFS reply packets, and SMB packets are fully decoded.
-vvv
    Even more verbose output. For example, telnet SB ... SE options are printed in full. With -X telnet options are printed in hex as well.
-w
    Write the raw packets to file rather than parsing and printing them out. They can later be printed with the -r option. Standard output is used if file is ``-''.
-x
    Print each packet (minus its link level header) in hex. The smaller of the entire packet or snaplen bytes will be printed. Note that this is the entire link-layer packet, so for link layers that pad (e.g. Ethernet), the padding bytes will also be printed when the higher layer packet is shorter than the required padding.
-X
    When printing hex, print ascii too. Thus if -x is also set, the packet is printed in hex/ascii. This is very handy for analysing new protocols. Even if -x is not also set, some parts of some packets may be printed in hex/ascii.

Introduction About Squid Proxy

What is Squid?

Squid is a fully-featured HTTP/1.0 proxy which is almost (but not quite - we're getting there!) HTTP/1.1 compliant. Squid offers a rich access control, authorization and logging environment to develop web proxy and content serving applications.
Where did Squid come from?

Squid is based on the Harvest Cache Daemon developed in the early 1990's. It was one of two forks from the codebase after the Harvest project ran to completion. (The other fork being what became Netapp's Netcache.)

The Squid project was funded by an NSF grant (NCR-9796082) which covered research into caching technologies. The ircache funding ran out a few years later and the Squid project continued through volunteer donations and the occasional commercial investment.

Squid is currently being developed by a handful of individuals donating their time and effort to building current and next generation content caching and delivery technologies. An ever-growing number of companies use Squid to save on their internet web traffic, improve performance, deliver faster browsing to their end-clients and provide static, dynamic and streaming content to millions of internet users worldwide.
Who uses Squid today?

A good question! Many of you are using Squid without even knowing it! Some companies have embedded Squid in their home or office firewall devices, others use Squid in large-scale web proxy installations to speed up broadband and dialup internet access. Squid is being increasingly used in content delivery architectures to deliver static and streaming video/audio to internet users worldwide.

Getting Squid
Obtaining Squid is easy! You have a number of choices here : http://www.squid-cache.org/Download/

(http://www.squid-cache.org)

Firewall Basics Concept

Firewall

A firewall is a part of a computer system or network that is designed to block unauthorized access while permitting authorized communications. It is a device or set of devices that is configured to permit or deny network transmissions based upon a set of rules and other criteria.

Firewalls can be implemented in either hardware or software, or a combination of both. Most personal computers contain a firewall, usually part of the operating system, to protect against threats from the Internet, and they are also found in routers that forward data between networks. Firewalls are frequently used to prevent unauthorized Internet users from accessing private networks connected to the Internet, especially intranets. All messages entering or leaving the intranet pass through the firewall, which inspects each message and blocks those that do not meet the specified security criteria.

Firewalls use several techniques to perform their functions:

   1. Packet filter: Packet filtering inspects each packet passing through the network and accepts or rejects it based on user-defined rules. Although difficult to configure, it is fairly effective and mostly transparent to its users. It is susceptible to IP spoofing.
   2. Application gateway: Applies security mechanisms to specific applications, such as FTP and Telnet servers. This is very effective, but can impose a performance degradation.
   3. Circuit-level gateway: Applies security mechanisms when a TCP connection is established. Once the connection has been made, packets can flow between the hosts without further checking.
   4. Proxy server: Intercepts all messages entering and leaving the network. The proxy server effectively hides the true network addresses.
History
The term firewall/fireblock originally meant a wall to confine a fire or potential fire within a building; cf. firewall (construction). Later uses refer to similar structures, such as the metal sheet separating the engine compartment of a vehicle or aircraft from the passenger compartment.

- The Morris Worm spread itself through multiple vulnerabilities in the machines of the time. Although it was not malicious in intent, the Morris Worm was the first large scale attack on Internet security; the online community was neither expecting an attack nor prepared to deal with one.
First generation: packet filters
The first paper published on firewall technology was in 1988, when engineers from Digital Equipment Corporation (DEC) developed filter systems known as packet filter firewalls. This fairly basic system was the first generation of what became a highly evolved and technical internet security feature. At AT&T Bell Labs, Bill Cheswick and Steve Bellovin were continuing their research in packet filtering and developed a working model for their own company based on their original first generation architecture.

This type of packet filtering pays no attention to whether a packet is part of an existing stream of traffic (i.e. it stores no information on connection "state"). Instead, it filters each packet based only on information contained in the packet itself (most commonly using a combination of the packet's source and destination address, its protocol, and, for TCP and UDP traffic, the port number).

TCP and UDP protocols constitute most communication over the Internet, and because TCP and UDP traffic by convention uses well known ports for particular types of traffic, a "stateless" packet filter can distinguish between, and thus control, those types of traffic (such as web browsing, remote printing, email transmission, file transfer), unless the machines on each side of the packet filter are both using the same non-standard ports.

Packet filtering firewalls work mainly on the first three layers of the OSI reference model, which means most of the work is done between the network and physical layers, with a little bit of peeking into the transport layer to figure out source and destination port numbers.When a packet originates from the sender and filters through a firewall, the device checks for matches to any of the packet filtering rules that are configured in the firewall and drops or rejects the packet accordingly. When the packet passes through the firewall, it filters the packet on a protocol/port number basis (GSS). For example, if a rule in the firewall exists to block telnet access, then the firewall will block the IP protocol for port number 23.
Second generation: application layer
Main article: Application layer firewall

The key benefit of application layer filtering is that it can "understand" certain applications and protocols (such as File Transfer Protocol, DNS, or web browsing), and it can detect if an unwanted protocol is sneaking through on a non-standard port or if a protocol is being abused in any harmful way.

An application firewall is much more secure and reliable compared to packet filter firewalls because it works on all seven layers of the OSI model, from the application down to the physical Layer. This is similar to a packet filter firewall but here we can also filter information on the basis of content. Good examples of application firewalls are MS-ISA (Internet Security and Acceleration) server, McAfee Firewall Enterprise & Palo Alto PS Series firewalls. An application firewall can filter higher-layer protocols such as FTP, Telnet, DNS, DHCP, HTTP, TCP, UDP and TFTP (GSS). For example, if an organization wants to block all the information related to "foo" then content filtering can be enabled on the firewall to block that particular word. Software-based firewalls (MS-ISA) are much slower than hardware based stateful firewalls but dedicated appliances (McAfee & Palo Alto) provide much higher performance levels for Application Inspection.

In 2009/2010 the focus of the most comprehensive firewall security vendors turned to expanding the list of applications such firewalls are aware of now covering hundreds and in some cases thousands of applications which can be identified automatically. Many of these applications can not only be blocked or allowed but manipulated by the more advanced firewall products to allow only certain functionally enabling network security administrations to give users functionality without enabling unnecessary vulnerabilities. As a consequence these advanced version of the "Second Generation" firewalls are being referred to as "Next Generation" and surpass the "Third Generation" firewall. It is expected that due to the nature of malicious communications this trend will have to continue to enable organizations to be truly secure.
Third generation: "stateful" filters
Main article: Stateful firewall

From 1989-1990 three colleagues from AT&T Bell Laboratories, Dave Presetto, Janardan Sharma, and Kshitij Nigam, developed the third generation of firewalls, calling them circuit level firewalls.

Third-generation firewalls, in addition to what first- and second-generation look for, regard placement of each individual packet within the packet series. This technology is generally referred to as a stateful packet inspection as it maintains records of all connections passing through the firewall and is able to determine whether a packet is the start of a new connection, a part of an existing connection, or is an invalid packet. Though there is still a set of static rules in such a firewall, the state of a connection can itself be one of the criteria which trigger specific rules.

This type of firewall can actually be exploited by certain Denial-of-service attacks which can fill the connection tables with illegitimate connections.
Subsequent developments
In 1992, Bob Braden and Annette DeSchon at the University of Southern California (USC) were refining the concept of a firewall. The product known as "Visas" was the first system to have a visual integration interface with colors and icons, which could be easily implemented and accessed on a computer operating system such as Microsoft's Windows or Apple's MacOS. In 1994 an Israeli company called Check Point Software Technologies built this into readily available software known as FireWall-1.

The existing deep packet inspection functionality of modern firewalls can be shared by Intrusion-prevention systems (IPS).

Currently, the Middlebox Communication Working Group of the Internet Engineering Task Force (IETF) is working on standardizing protocols for managing firewalls and other middleboxes.

Another axis of development is about integrating identity of users into Firewall rules. Many firewalls provide such features by binding user identities to IP or MAC addresses, which is very approximate and can be easily turned around. The NuFW firewall provides real identity-based firewalling, by requesting the user's signature for each connection. authpf on BSD systems loads firewall rules dynamically per user, after authentication via SSH.
Types
There are several classifications of firewalls depending on where the communication is taking place, where the communication is intercepted and the state that is being traced.
Network layer and packet filters

Network layer firewalls, also called packet filters, operate at a relatively low level of the TCP/IP protocol stack, not allowing packets to pass through the firewall unless they match the established rule set. The firewall administrator may define the rules; or default rules may apply. The term "packet filter" originated in the context of BSD operating systems.

Network layer firewalls generally fall into two sub-categories, stateful and stateless. Stateful firewalls maintain context about active sessions, and use that "state information" to speed packet processing. Any existing network connection can be described by several properties, including source and destination IP address, UDP or TCP ports, and the current stage of the connection's lifetime (including session initiation, handshaking, data transfer, or completion connection). If a packet does not match an existing connection, it will be evaluated according to the ruleset for new connections. If a packet matches an existing connection based on comparison with the firewall's state table, it will be allowed to pass without further processing.

Stateless firewalls require less memory, and can be faster for simple filters that require less time to filter than to look up a session. They may also be necessary for filtering stateless network protocols that have no concept of a session. However, they cannot make more complex decisions based on what stage communications between hosts have reached.

Modern firewalls can filter traffic based on many packet attributes like source IP address, source port, destination IP address or port, destination service like WWW or FTP. They can filter based on protocols, TTL values, netblock of originator, of the source, and many other attributes.

Commonly used packet filters on various versions of Unix are ipf (various), ipfw (FreeBSD/Mac OS X), pf (OpenBSD, and all other BSDs), iptables/ipchains (Linux).
Application-layer
Main article: Application layer firewall

Application-layer firewalls work on the application level of the TCP/IP stack (i.e., all browser traffic, or all telnet or ftp traffic), and may intercept all packets traveling to or from an application. They block other packets (usually dropping them without acknowledgment to the sender). In principle, application firewalls can prevent all unwanted outside traffic from reaching protected machines.

On inspecting all packets for improper content, firewalls can restrict or prevent outright the spread of networked computer worms and trojans. The additional inspection criteria can add extra latency to the forwarding of packets to their destination.
Proxies
Main article: Proxy server

A proxy device (running either on dedicated hardware or as software on a general-purpose machine) may act as a firewall by responding to input packets (connection requests, for example) in the manner of an application, whilst blocking other packets.

Proxies make tampering with an internal system from the external network more difficult and misuse of one internal system would not necessarily cause a security breach exploitable from outside the firewall (as long as the application proxy remains intact and properly configured). Conversely, intruders may hijack a publicly-reachable system and use it as a proxy for their own purposes; the proxy then masquerades as that system to other internal machines. While use of internal address spaces enhances security, crackers may still employ methods such as IP spoofing to attempt to pass packets to a target network.
Network address translation
Main article: Network address translation

Firewalls often have network address translation (NAT) functionality, and the hosts protected behind a firewall commonly have addresses in the "private address range", as defined in RFC 1918. Firewalls often have such functionality to hide the true address of protected hosts. Originally, the NAT function was developed to address the limited number of IPv4 routable addresses that could be used or assigned to companies or individuals as well as reduce both the amount and therefore cost of obtaining enough public addresses for every computer in an organization. Hiding the addresses of protected devices has become an increasingly important defense against network reconnaissance.

(Wikipedia.org)