Network Monitor is software designed and developed in order to monitor all clients in the Local Area Network (LAN). Network monitor is an application used to obtain a capture or sampling of network traffic. Analyzing this traffic will often help in resolving network connectivity issues. Before developing any computerized system, it is important to examine the problems in the existing system and the additional information that should be fulfilled in the proposed system. Proper analysis of the existing system is the backbone of the design and development of every real world projects. The system at present runs manually and involves minimum security. There are no proper resources available in the existing system, for monitoring the systems in a Local Area Network (LAN) area. In the existing system file management was a tedious task, It was very difficult to handle files across the LAN.
Network Monitor: Possible Drawbacks of Existing Systems
- The system resources where scattered and the user has to choose various programs at different places for each of their needs.
- Chatting was not possible.
- File transferring process was difficult.
- Mapping of the resources was not possible.
- System was not User Friendly
- Time Consuming
Network Monitor: Packet Sniffing
Packet sniffing or packet capture software is extensively used as tools for protocol analysis and security. In protocol design research, such a tool comes handy in analyzing, debugging and testing of a new protocol implementation. In Security, as is true for any tools, it may be used both as a positive way to detect intrusions or attacks on a system as well as in the malicious way to hack for private and personal data of others. Even though use of upper layer encryption techniques make it difficult to gather data directly, yet these tools are important in learning about existing sessions, collecting encrypted data to launch offline attacks to generate the encryption key and any such attack limited only by ones imagination. Hence, packet sniffer software is one of the most essential tools required to get started to be able to perform any of the above mentioned activities. The goal of our project is to write a packet sniffer “Net Vigilant”, capable of sniffing across wired and wireless interfaces and provide additional packet aggregation, filtering and analysis capabilities. The goal of the project is not to provide a novel approach towards sniffing on the network but rather to provide a basic understanding to the challenges involved in writing such a software and also to build up from the knowledge and experience gained to design more advanced security tools.
Packet sniffing is an essential activity for network engineers as well as security experts. If, used in a positive way, it is the most essential tool for network analysis, protocol analysis, network troubleshooting, intrusion detection and hundreds of such other applications. The key challenge in writing such software is to collect raw packets directly from the interface cards and parsing them to reveal useful information. In normal network programming through sockets, a software module listens on a particular socket for packets intended for its use, hence for a module wanting to sniff for all packets, it shall have to listen on all the TCP ports so that TCP does not throw away packets on finding no module attached to the intended port number in the packet. Also, each protocol layer performs filtering of the traffic, for example, any TCP control packet will not be passes above the TCP layer, any IP control packet is consumed by the IP layer and so on. Moreover, the hardware network interface does an initial filtering of packets not intended for it. Hence, it is almost certain that the normal programming methods will not allow for the capabilities that we seek to capture in a packet sniffing software. The way out of this situation is to have some type of a software hook which can gather packets before it is passed through the protocol layer processing. Also, to be able to capture packets not intended for the current network interface, the software should set the interface to the “promiscuous mode” provided such a mode is supported by the hardware and the device driver of the network card.
The “software hook”, that we mentioned above, exists, in UNIX as the PF_PACKET socket (libpcap library) and in Windows as the Winpcap library. In our work we make use of the Winpcap library to be able to capture raw packets from the interface. The story does not end at being able to capture raw packet. In fact, it is the most basic step. There are certain hurdles in being able to analyze correctly the raw packets which are nothing but a set of hexadecimal gibberish to the uninformed. There are challenges in being able to serialize the data coming in, in network byte order, for storage in the file systems. Also, a major task is to be able to provide an easy to use and elegant user interface for running the software as well as present the packet data in a more human readable form.
With all this in mind, we designed “Net Vigilant”, a packet sniffer and analyzer tool for wired and wireless interfaces. “Net vigilant” has a state-of-the-art graphical user interface, designed on the .NET platform. All the code has been written in C# over the .NET platform to ensure interoperability across windows systems.
It may be argued, that such tools already exist in plenty and that a new endeavor may not be justified. However, “Net Vigilant” has been designed to be the stepping stone for further design of more complicated tools and also a learning experience for novice programmers to design and implement their own network software. It is basically the foundation bed for more advanced innovations in the future.
Network Monitor: Application Basic Features
- Chatting module monitors the remote clients on the LAN in basis of the service request and providing message transfer between different clients over the LAN. It evokes providing access and denying access according to each Client according to their request.
- File Transfer module shows how to perform file operations on the files of a remote site. These operations include changing current directory, creating new directory, renaming a directory, deleting a file, copying contents of file from a remote file to the local file and vice versa, etc.
- Enumerating Network Resources gives us the information about how to connect and disconnect the remote drive programmatically. The main functionality in enumeration is listing of remote drives such as connecting as well as disconnecting the particular map drive. This enumerated network being used for mapping any remote system, hard disk to a particular drive, which is in n/w drive. Where this is being used for browsing the hard disk directly. Various properties is being present in the n/w neighborhood and map drive is one of the services in it.
- File properties gives the particulars of the file selected from any location of the system.
- System Information displays information on the accessible processes running on the system. It also gives the system architecture such as the I/O and O/p devices and the system hardware information.
- Memory Information displays the Memory capacity of the system, information of free space and initial boot up and memory accessed by the various process or application.
- Help menu provides necessary information about the project to the users while running this project.
TCP Flags:
A, ACK- Acknowledge- The receiver will send an ACK which equals the senders Sequence # plus the “Len”, or amount of data at the TCP layer. SYN, and FIN flags also count as 1 byte. The ACK can also be
though of as the sequence number of the next octet the receiver expects to receive.
S, SYN- Synchronize is used during session setup to agree on initial sequence numbers. Sequence # are random.
F, FIN- Finish is used during a graceful session close to show that the sender has no more data to send.
R, RST- Reset is an instantaneous abort in both directions, (abnormal session disconnection)
P, PSH- Push forces data delivery with out waiting for buffers to fill. Used for interactive traffic. The data will
also be delivered to the application on the receiving end with out buffering.
U, URG- Urgent- Data is sent out of band.
3 Way Hand Shake:
Time Dst IP Src IP Protocol Description
20.862 157.57.24.193 157.57.11.169 TCP ….S., len: 4, seq: 346564214, ack: 0, win: 8192,
20.866 157.57.11.169 157.57.24.193 TCP .A..S., len: 4, seq: 339000739, ack: 346564215, win: 8760,
20.866 157.57.24.193 157.57.11.169 TCP .A…., len: 0, seq: 346564215, ack: 339000740, win: 8760,
Graceful Close (Modified 3 Way Hand Shake):
Time Dst IP Src IP Protocol Description
39.295 157.57.11.169 157.57.24.193 TCP .A…F, len: 0, seq: 339000917, ack: 346564257, win: 8718,
39.295 157.57.24.193 157.57.11.169 TCP .A…., len: 0, seq: 346564257, ack: 339000918, win: 8583,
39.298 157.57.24.193 157.57.11.169 TCP .A…F, len: 0, seq: 346564257, ack: 339000918, win: 8583,
39.300 157.57.11.169 157.57.24.193 TCP .A…., len: 0, seq: 339000918, ack: 346564258, win: 8718,
In the above two traces, TCP is the highest layer protocol so the relevant session information can be read from the summary line of the trace. If there is a higher layer protocol(NBT, SMB, Telnet, FTP, etc.) , then you will have to look into the packet for the TCP flags, ack’s and seq numbers.
Re-transmission Behavior (this section “borrowed” from “TCP/IP Implementation Details”)
TCP starts a re-transmission timer when each outbound segment is handed down to IP. If no acknowledgment has been received for the data in a given segment before the timer expires, then the segment is retransmitted, up to the TcpMaxDataRetransmissions times. The default value for this parameter is 5.
The re-transmission timer is initialized to 3 seconds when a TCP connection is established; however it is adjusted “on the fly” to match the characteristics of the connection using Smoothed Round Trip Time (SRTT) calculations as described in RFC793. The timer for a given segment is doubled after each re-transmission of that segment. Using this algorithm, TCP tunes itself to the “normal” delay of a connection. TCP connections over high-delay links will take much longer to time out than those over low-delay links[1].
The following trace clip shows the re-transmission algorithm for two hosts connected over Ethernet on the same subnet. An FTP file transfer was in progress, when the receiving host was disconnected from the network. Since the SRTT for this connection was very small, the first re-transmission was sent after about one-half second. The timer was then doubled for each of the re-transmissions that followed. After the fifth re-transmission, the timer is once again doubled, and if no acknowledgment is received before it expires, then the transfer is aborted.
delta source ip dest ip pro flags description
0.000 10.57.10.32 10.57.9.138 TCP .A…., len: 1460, seq: 8043781, ack: 8153124, win: 8760
0.521 10.57.10.32 10.57.9.138 TCP .A…., len: 1460, seq: 8043781, ack: 8153124, win: 8760
1.001 10.57.10.32 10.57.9.138 TCP .A…., len: 1460, seq: 8043781, ack: 8153124, win: 8760
2.003 10.57.10.32 10.57.9.138 TCP .A…., len: 1460, seq: 8043781, ack: 8153124, win: 8760
4.007 10.57.10.32 10.57.9.138 TCP .A…., len: 1460, seq: 8043781, ack: 8153124, win: 8760
8.130 10.57.10.32 10.57.9.138 TCP .A…., len: 1460, seq: 8043781, ack: 8153124, win: 8760
After machine “X’s” retries are exhausted you may not see a “Reset” right away. If machine “Y” finally responds, machine “X” may then reset the connection.
Sliding Windows:
During the hand shake, the send window size is set to the other hosts receive window. The window size is a buffer and is the amount of data the sender can send and the receiver can receive without an ACK. The “window’ can slide forward after that packet is acknowledged.
With a receive window of 8760, the sender may send 8760 bytes before receiving an ack. The receiver could ack every packet, every other packet or the entire 8760 depending on the IP stack and timing. (See Delayed Ack Timer, and Retransmit timer) NT 3.51 will wait and ack the entire Window size of data. If the PUSH bit set, data will be delivered up to the application right away, but the ack may still be delayed.
The sequence number in frame 51 is 349349990. The Ack in frame 57 is 349358750. This is the sequence number from frame 51 plus the amount of data received in frames 51 through 56 (6 frames x 1460 =8760) . Also, the ACK 349358750 is the sequence number of the next packet that the host expects to receive.
Frame Time Src Other Addr Dst Other Addr Protocol Description
50 3.923 157.57.11.169 157.57.24.193 TCP .A…., len: 0, seq: 356870796, ack: 349349990, win: 8760,
51 3.924 157.57.24.193 157.57.11.169 FTP Data Transfer To Client, Port = 1636, size 1460
+ TCP: .A…., len: 1460, seq: 349349990, ack: 356870796, win: 8760, src: 20 dst: 1636
52 3.940 157.57.24.193 157.57.11.169 FTP Data Transfer To Client, Port = 1636, size 1460
53 3.941 157.57.24.193 157.57.11.169 FTP Data Transfer To Client, Port = 1636, size 1460
54 3.943 157.57.24.193 157.57.11.169 FTP Data Transfer To Client, Port = 1636, size 1460
55 3.944 157.57.24.193 157.57.11.169 FTP Data Transfer To Client, Port = 1636, size 1460
56 3.946 157.57.24.193 157.57.11.169 FTP Data Transfer To Client, Port = 1636, size 1460
57 3.947 157.57.11.169 157.57.24.193 TCP .A…., len: 0, seq: 356870796, ack: 349358750, win: 4096,
The Window size is also used for flow control. If a host will advertising a smaller Window size when it is buffers are filling or a Window size of 0 if it can not receive data at all. In frame 50 above, the host is advertising a Window size of 8760 and in frame 57 it has been dropped to 4096.
Ports, Connections, and Endpoints:
Port numbers define the ultimate destination within a machine.
Connections are identified by a pair of endpoints.
An Endpoint is the (host, port). Ex. (199.199.40, 21)
Well Known Ports are between 1-1023 and are managed by the Internet Assigned Numbers Authority (IANA)
Well known ports are defined in RFC 1340. These ports are used by specific servers services. For example, FTP port 21, Telnet port 23 are well known ports. Most clients use ports 1024-5000 and don’t really care what port is used on their end of the connection. Ports above 5000 are often used for other server services that are not well known.
Trace reading suggestions:
Follow a session using source and destination IP address and Port numbers. If you find a Reset, focus on the sequence numbers and ACK’s that proceed it. Get the calculator out to see what ACK is corresponding to what data sent. Is the sender doing retries? Note the number of retries and the time elapsed. The default number of retries is 5. Is the receiver asking for a missed frame by Acking a previous sequence number? Did the sender back up and resend the previous packet? A Reset can be caused by time-outs at the TCP layer or by time outs of higher layer protocols. Resets originating at the TCP layer should be easy to read from the trace. Resets originating form higher layer protocols my be more difficult to determine the cause. For example an SMB read may time out in 45 seconds and cause a Reset of the session even though communications are slow but working at the TCP layer. The trace may only narrow down what component is at fault. From there you may need to use other troubleshooting methods to determine the cause.
To see TCP sequencing when higher-level protocols are present, go to display->options, and select “auto”(based on protocols in display filter). Then go to filter,double click on “protocol=any”, click “disable all”, select TCP, and click “enable”. Then click ok. Now your view will show TCP sequence numbers on the summary lines.
[1] Adding [1] to the registry parameter TcpMaxDataRetransmissions approximately doubles the total re-transmission time-out period for all connections.