|
|
For purposes of the exam, DoS can be defined simply as malicious resource or service overuse, interruption, or annexation. In other words, the attack exhausts system resources so authorized users cannot log in or access resources on the target server, which directly affects availability. DoS attacks are constantly evolving and targeted as network-based or host-based assaults. We'll talk about several DoS attack types in this chapter as well as the many ways to mitigate DoS risks and countermeasure the inherent system vulnerabilities.
The most common forms of DoS attacks we should be concerned with include program buffer overflow; malformed packets such as overlapping IP fragments, Teardrop, Ping of Death, Smurf, Bonk, Boink, NewTear, WinNuke, Land, and LaTierra; as well as other general types of attacks such as SYN flooding. It is important that you understand that regardless of the particular type of DoS attack, all affect system availability.
When executable stacks with permissions set to read, write, and execute are allowed by default, programs may be inherently vulnerable to buffer overflow attacks. A buffer is commonly defined as a temporary storage space that allows a CPU time to store data before processing it. Generally, a buffer overflow occurs when a program process or task receives unwarranted and/or an abundance of data (sometimes referred to as "smashing the stack") that it is not properly programmed to deal with. As a result, the program typically operates in such an unexpected way that an intruder can abuse or misuse it, usually by inserting executable code into the stack with a payload that causes service denial or worse, giving the intruder access—many times with root privileges—to the system. More often than not, an intruder can gain root access to the system during a buffer overflow attack. Once inside, and after performing some damage or data theft, the intruder would typically delete traces of illegal access by removing activity logs when possible.
Here's a good example: An intruder sends a vulnerable program more data than it was programmed to handle. As a result, the program overruns the memory that was allotted for it and writes the extra data into system memory. At that point, the extra data, which usually contains a remote access Trojan (which we'll talk about in the next chapter), can be executed, thus allowing the intruder remote access to the system later on at the intruder's leisure. Technically speaking, these types of attacks contain instructions that patch the kernel to execute another program.
Sun recommends that you always monitor programs that are executed with privileges as well as the users who have rights to execute them. To do so, you can search your system for unauthorized use of the setuid (set user ID) and setgid (set group ID) permissions on programs to gain superuser privileges. Although we'll cover this in more detail in Chapters 9 and 10, the rest of this section provides a synopsis of how to find files with setuid permissions.
In a terminal session with superuser privileges, search for files with setuid permissions by using the find command:
find directory -user root -perm -4000 -exec ls -ldb {} \; >/tmp/filename
where
find directory checks all mounted paths starting at the specified directory, which can be root (/), sys, bin, or mail.
-user root displays files owned only by root.
-perm -4000 displays files only with permissions set to 4000.
-exec ls -ldb displays the output of the find command in ls -ldb format.
>/tmp/filename writes results to this file.
| Exam Watch |
On the exam, be prepared for questions regarding how intruders cover their tracks. After penetrating a target system, an attacker would erase traces of the incident by deleting activity logs and leaving backdoors in place to allow later clandestine access to the system. |
Following is sample output of what you can expect to see while finding files with setuid permissions:
-r-sr-xr-x 1 root bin 38836 Aug 10 16:16 /usr/bin/at-r-sr-xr-x 1 root bin 19812 Aug 10 16:16 /usr/bin/crontab ---s--x--x 1 root sys 46040 Aug 10 15:18 /usr/bin/ct -r-sr-xr-x 1 root sys 12092 Aug 11 01:29 /usr/lib/mv_dir -r-sr-sr-x 1 root bin 33208 Aug 10 15:55 /usr/lib/lpadmin -r-sr-sr-x 1 root bin 38696 Aug 10 15:55 /usr/lib/lpsched ---s--x--- 1 root rar 45376 Aug 18 15:11 /usr/rar/bin/sh -r-sr-xr-x 1 root bin 12524 Aug 11 01:27 /usr/bin/df -rwsr-xr-x 1 root sys 21780 Aug 11 01:27 /usr/bin/newgrp -r-sr-sr-x 1 root sys 23000 Aug 11 01:27 /usr/bin/passwd -r-sr-xr-x 1 root sys 23824 Aug 11 01:27 /usr/bin/su
 |
In this exercise, we'll use the find command to locate files with setuid permissions and then view the results with the more command.
Using the find Command to Locate Files with setuid Permissions
Log in with an account that has root privileges or use the switch user (su) command to become superuser. As superuser you'll have full privileges, which may be required to search all files. For example, to switch to root, simply open a terminal session and type su root, press ENTER, and then enter root's password at the prompt.
Search for files with setuid permissions with this command:
Viewing the Results
View the results in /tmp/findresults using the more command, like so:
more /tmp/findresults
where findresults is the filename to which you wrote your find results in the /tmp directory.
|
Malformed packet attacks come in several flavors and have been around for many years. To carry out this type of attack successfully, maliciously formatted Internet Protocol (IP) packets that include the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) are sent to a program that was not properly developed to handle unexpected packets. As a result, the target program would typically crash or at least function at a snail's pace, denying services of the software and/or system to authorized users. The most popular types of malformed packet attacks that you've likely heard about include overlapping IP fragments, Teardrop, Ping of Death, Smurf, Bonk, Boink, NewTear, WinNuke, Land, and LaTierra.
Since many of the attack types mentioned are common variations, we'll talk a little bit about the more conventional methods, including Teardrop, Ping of Death, and Smurf attacks. In Teardrop, the attacker modifies the length and fragmentation offset fields in IP packets, which causes the target to crash. Ping of Death, on the other hand, is an example of a malformed ICMP packet attack. The attacker sends an oversized ping packet (or ICMP datagrams) in an attempt to overflow the system's buffer to crash, freeze, or in some cases restart the system. In other words, an oversized packet would crash the server when the system tries to reconstruct it. In a Smurf attack, a normal-sized ping request is broadcast to every system on the target's trusted network. The sending address, however, is spoofed to be the same as the target victim system. As a result, the target would receive all of the replies from the broadcast, which would overload it and cause service denial.
The most common form of flooding we need to be aware of is in the form of a SYN attack. A SYN attack takes place during the TCP handshake. Before we talk more about how a SYN attack occurs, we should review the fundamentals of the TCP handshake process. But, first, let's define ports with regard to TCP and UDP. In network communications with TCP/IP and UDP, a port is an endpoint to a logical connection. In other words, the port number identifies a type of service and traffic. For example, port 80 is a well-known port typically used for HTTP traffic, and port 443 is used for HTTPS. A TCP handshake process is used to establish TCP connections between two IP nodes (for example, a web server and web browser). In other words, a server is listening on a particular port, waiting for a connection attempt to that port for a particular service. The process is simple: the client sends a connection request, the server acknowledges the request, the client then acknowledges the acknowledgement, and finally the connection is established. This is called a three-way handshake.
| Exam Watch |
You should fully understand the TCP handshake process, which will help you understand how a SYN attack works as well as to understand some of the more technical material in this book and on the exam. |
An excellent, detailed explanation of the TCP handshake was published by our friends at Microsoft in Knowledge Base article Q172983. As a technical review, we'll examine a summary of the article.
TCP implies a connection-oriented connection, which means that a reliable, ordered, guaranteed transfer of data must be obtained and acknowledged between a sender and receiver. At the TCP level, connection establishment, sending data, and connection termination maintain specific control parameters that govern the handshake process and ensure its completion. The control bits are listed here:
URG Urgent Pointer field significant
ACK Acknowledgement field significant
PSH Push function
RST Reset the connection
SYN Synchronize sequence numbers
FIN No more data from sender
A three-way handshake will take place in two scenarios: when establishing a connection (an active open) and when terminating a connection (an active close). To further explain the TCP handshake process, the next few sections review a sample capture.
The following sequence shows the process of a TCP connection being established. As you see in the first frame, the client, NTW3, sends a SYN packet (TCP .... S.). This is a request to the server to synchronize the sequence numbers. It specifies its initial sequence number (ISN), which is incremented by 1, (8221821 + 1 = 8221822), and that is sent to the server. For security purposes, it is important that ISNs be unpredictable by third parties. To initialize a connection, the client and server must synchronize each other's sequence numbers. The Acknowledgement field (ack: 0) is set to zero because this is the first part of the three-way handshake. Following is the extract from packet 1:
1 2.0785 NTW3 --> BDC3 TCP ....S., len: 4, seq: 8221822-8221825, ack: 0,
win: 8192, src: 1037 dst: 139 (NBT Session) NTW3 --> BDC3 IP
TCP: ....S., len: 4, seq: 8221822-8221825, ack: 0, win: 8192, src: 1037
dst: 139 (NBT Session)
TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 8221822 (0x7D747E)
TCP: Acknowledgement Number = 0 (0x0)
TCP: Data Offset = 24 (0x18)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x02 : ....S.
TCP: ..0..... = No urgent data
TCP: ...0.... = Acknowledgement field not significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......1. = Synchronize sequence numbers
TCP: ....... 0 = No Fin
TCP: Window = 8192 (0x2000)
TCP: Checksum = 0xF213
TCP: Urgent Pointer = 0 (0x0)
TCP: Options
TCP: Option Kind (Maximum Segment Size) = 2 (0x2)
TCP: Option Length = 4 (0x4)
TCP: Option Value = 1460 (0x5B4)
TCP: Frame Padding
00000: 02 60 8C 9E 18 8B 02 60 8C 3B 85 C1 08 00 45 00 .`.....`.;....E.
00010: 00 2C 0D 01 40 00 80 06 E1 4B 83 6B 02 D6 83 6B .,..@....K.k...k
00020: 02 D3 04 0D 00 8B 00 7D 74 7E 00 00 00 00 60 02 .......}t~....`.
00030: 20 00 F2 13 00 00 02 04 05 B4 20 20 .........
Request Acknowledgement In the second packet, the server, BDC3, sends an ACK and a SYN on this segment (TCP .A..S.). In this segment, the server is acknowledging the request of the client for synchronization. At the same time, the server is also sending its request to the client for synchronization of its sequence numbers. However, you'll see one noticeable difference in this segment— the server transmits an acknowledgement number (8221823) to the client. The acknowledgement is just proof to the client that the ACK is specific to the SYN that the client initiated. The process of acknowledging the client's request allows the server to increment the client's sequence number by 1 and uses it as its acknowledgement number. Following is the extract from packet 2:
2 2.0786 BDC3 --> NTW3 TCP .A..S., len: 4, seq: 1109645-1109648, ack:
8221823, win: 8760, src: 139 (NBT Session) dst: 1037 BDC3 --> NTW3 IP
TCP: .A..S., len: 4, seq: 1109645-1109648, ack: 8221823, win: 8760,
src: 139 (NBT Session) dst: 1037
TCP: Source Port = NETBIOS Session Service
TCP: Destination Port = 0x040D
TCP: Sequence Number = 1109645 (0x10EE8D)
TCP: Acknowledgement Number = 8221823 (0x7D747F)
TCP: Data Offset = 24 (0x18)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x12 : .A..S.
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......1. = Synchronize sequence numbers
TCP: ....... 0 = No Fin
TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x012D
TCP: Urgent Pointer = 0 (0x0)
TCP: Options
TCP: Option Kind (Maximum Segment Size) = 2 (0x2)
TCP: Option Length = 4 (0x4)
TCP: Option Value = 1460 (0x5B4)
TCP: Frame Padding
00000: 02 60 8C 3B 85 C1 02 60 8C 9E 18 8B 08 00 45 00 .`.;...`......E.
00010: 00 2C 5B 00 40 00 80 06 93 4C 83 6B 02 D3 83 6B .,[.@....L.k...k
00020: 02 D6 00 8B 04 0D 00 10 EE 8D 00 7D 74 7F 60 12 ...........}t `.
00030: 22 38 01 2D 00 00 02 04 05 B4 20 20 "8.-......
Acknowledging the Request In the third packet, the client sends an ACK on this segment (TCP .A....). In this segment, the client is acknowledging the request from the server for synchronization. The client uses the same algorithm the server implemented in providing an acknowledgement number. The client's acknowledgment of the server's request for synchronization completes the process of establishing a reliable connection, and as a result a three-way handshake takes place. Following is the extract from packet 3:
3 2.787 NTW3 --> BDC3 TCP .A...., len: 0, seq: 8221823-8221823, ack:
1109646, win: 8760, src: 1037 dst: 139 (NBT Session) NTW3 --> BDC3 IP
TCP: .A...., len: 0, seq: 8221823-8221823, ack: 1109646, win: 8760,
src: 1037 dst: 139 (NBT Session)
TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 8221823 (0x7D747F)
TCP: Acknowledgement Number = 1109646 (0x10EE8E)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x10 : .A ....
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: ....... 0 = No Fin
TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x18EA
TCP: Urgent Pointer = 0 (0x0)
TCP: Frame Padding
00000: 02 60 8C 9E 18 8B 02 60 8C 3B 85 C1 08 00 45 00 .`.....`.;....E.
00010: 00 28 0E 01 40 00 80 06 E0 4F 83 6B 02 D6 83 6B .(..@....O.k...k
00020: 02 D3 04 0D 00 8B 00 7D 74 7F 00 10 EE 8E 50 10 .......}t�....P.
00030: 22 38 18 EA 00 00 20 20 20 20 20 20 "8....
Although the three-way handshake requires only three packets to be transmitted over the network, the termination of this reliable connection will necessitate the transmission of four packets. Because a TCP connection is full duplex (that is, data can be flowing in each direction independent of the other), each direction must be terminated independently.
In the next session of packets, we see the client sending a FIN that is accompanied by an ACK (TCP .A...F). This segment has two basic functions: first, when the FIN parameter is set, it will inform the server that it has no more data to send. Second, the ACK is essential in identifying the specific connection they have established. Following is the extract from packet 4:
4 16.0279 NTW3 --> BDC3 TCP .A...F, len: 0, seq: 8221823-8221823,
ack:3462835714, win: 8760, src: 2337 dst: 139 (NBT Session) NTW3 --> BDC3
IP
TCP: .A...F, len: 0, seq: 8221823-8221823, ack: 1109646, win: 8760, src:
1037 dst: 139 (NBT Session)
TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 8221823 (0x7D747F)
TCP: Acknowledgement Number = 1109646 (0x10EE8E)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x11 : .A...F
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......1 = No more data from sender
TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x236C
TCP: Urgent Pointer = 0 (0x0)
00000: 00 20 AF 47 93 58 00 A0 C9 22 F5 39 08 00 45 00 . .G.X...".9..E.
00010: 00 28 9B F5 40 00 80 06 21 4A C0 5E DE 7B C0 5E .(..@...!J.^.{.^
00020: DE 57 09 21 05 48 0B 20 96 AC CE 66 AE 02 50 11 .W.!.H. ...f..P.
00030: 22 38 23 6C 00 00 "8#l..
Acknowledging the FIN In packet 5, you do not see anything special, except for the server acknowledging the FIN that was transmitted from the client. Following is the extract from packet 5:
5 16.0281 BDC3 --> NTW3 TCP .A...., len: 0, seq: 1109646-1109646,
ack: 8221824, win:28672, src: 139 dst: 2337 (NBT Session) BDC3 --> NTW3
IP
TCP: .A...., len: 0, seq: 1109646-1109646, ack: 8221824, win:28672, src:
139 dst: 2337 (NBT Session)
TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 1109646 (0x10EE8E)
TCP: Acknowledgement Number = 8221824 (0x7D7480)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x10 : .A ....
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = No Fin
TCP: Window = 28672 (0x7000)
TCP: Checksum = 0xD5A3
TCP: Urgent Pointer = 0 (0x0)
TCP: Frame Padding
00000: 00 A0 C9 22 F5 39 08 00 02 03 BA 84 08 00 45 00 ...".9........E.
00010: 00 28 D2 82 00 00 3F 06 6B BD C0 5E DE 57 C0 5E .(....?.k..^.W.^
00020: DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 10 .{.H.!.f... ..P.
00030: 70 00 D5 A3 00 00 90 00 01 00 86 00 p...........
After receiving the FIN from the client computer, the server will ACK, as shown in packet 6. Even though TCP has established connections between the two computers, the connections are still independent of one another. Therefore, the server must also transmit a FIN (TCP .A...F) to the client. Following is the extract from packet 6:
6 17.0085 BDC3 --> NTW3 TCP .A...F, len: 0, seq: 1109646-1109646, ack:
8221824, win:28672, src: 139 dst: 2337 (NBT Session) BDC3 --> NTW3 IP
TCP: .A...F, len: 0, seq: 1109646-1109646, ack: 8221824, win:28672, src:
139 dst: 2337 (NBT Session)
TCP: Source Port = 0x0548
TCP: Destination Port = 0x0921
TCP: Sequence Number = 1109646 (0x10EE8E)
TCP: Acknowledgement Number = 8221824 (0x7D7480)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x11 : .A...F
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......1 = No more data from sender
TCP: Window = 28672 (0x7000)
TCP: Checksum = 0xD5A2
TCP: Urgent Pointer = 0 (0x0)
TCP: Frame Padding
00000: 00 A0 C9 22 F5 39 08 00 02 03 BA 84 08 00 45 00 ...".9........E.
00010: 00 28 D2 94 00 00 3F 06 6B AB C0 5E DE 57 C0 5E .(....?.k..^.W.^
00020: DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 11 .{.H.!.f... ..P.
00030: 70 00 D5 A2 00 00 02 04 05 B4 86 00 p...........
Acknowledging the Close of a TCP Connection Finally, in packet 7, the client responds in the same format as the server by ACKing the server's FIN and incrementing the sequence number by 1. The client ACKing the FIN notification from the server identifies the close of a TCP connection. Following is the extract from packet 7:
7 17.0085 NTW3 --> BDC3 TCP .A...., len: 0, seq: 8221824-8221824, ack:
1109647, win: 8760, src: 2337 dst: 139 (NBT Session) NTW3 --> BDC3 IP
TCP: .A...., len: 0, seq: 8221824-8221824, ack: 1109647, win: 8760, src:
2337 dst: 139 (NBT Session)
TCP: Source Port = 0x0921
TCP: Destination Port = 0x0548
TCP: Sequence Number = 8221824 (0x7D7480)
TCP: Acknowledgement Number = 1109647 (0x10EE8F)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x10 : .A ....
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = No Fin
TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x236B
TCP: Urgent Pointer = 0 (0x0)
00000: 00 20 AF 47 93 58 00 A0 C9 22 F5 39 08 00 45 00 . .G.X...".9..E.
00010: 00 28 BA F5 40 00 80 06 02 4A C0 5E DE 7B C0 5E .(..@....J.^.{.^
00020: DE 57 09 21 05 48 0B 20 96 AD CE 66 AE 03 50 10 .W.!.H. ...f..P.
00030: 22 38 23 6B 00 00 "8#k..
Making a connection-oriented communication link between a client and a server is a delicate process. Now that you have a general understanding of the SYN-ACK procedure, let's discuss SYN attacks. During a SYN attack, by exploiting the TCP handshake process, the attacker sends a flood of connection requests but does not respond to any of the replies. This is referred to as a half-open connection, because during a normal connection between a client and a server, the connection is considered to be open after the handshake process. At that point, data can be exchanged between the client and the server. Therefore, when the server has not received an ACK from the client, the connection is perceptibly only half-open.
Half-open connections are typically achieved using IP spoofing. IP spoofing during a SYN attack happens when the attacker sends SYN messages to a target server that appear to originate from some other host. Unfortunately, the spoofed host address does not reply to SYN-ACK messages, thus keeping half-open connections with the target. The SYN messages will usually flood the server, and as a result the target system will basically fill up with requests until it is unable to accommodate new requests. In some cases, the system could consume available memory, crash, or be rendered inoperative. In other words, the target system will inevitably time-out each request after waiting for a response, thus causing the system to use up resources and potentially become unavailable. Because the source address is spoofed, it is difficult to determine the true origin of these packets.
To verify that this type of attack is occurring on Solaris systems, you can check the state of the server system's network traffic. To do so, you can manually use the netstat command in a terminal session. The netstat command displays network status and protocol statistics. You can display the status of TCP and UDP endpoints in table format and various types of network data, depending on the command-line option that is selected. The syntax options for this command are listed in Table 7-1.
|
Option |
Description |
|---|---|
|
-a |
Shows the state of all sockets, all routing table entries, or all interfaces, both physical and logical. |
|
-f address_family |
Limit all displays to those of the specified address_family. The value of address_family can be one of the following: inet For the AF_INET address family showing IPv4 information inet6 For the AF_INET6 address family showing IPv6 information unix For the AF_UNIX address family |
|
-f filter |
With -r only, limits the display of routes to those matching the specified filter. A filter rule consists of a keyword:value pair. The known keywords and the value syntax are as follows: af:{inet|inet6|unix|number.} Selects an address family. This is identical to -f address_family and both syntaxes are supported. {inif|outif}:{name|ifIndex|any|none} Selects an input or output interface. You can specify the interface by name (such as hme0) or by ifIndex number (for example, 2). If any is used, the filter matches all routes having a specified interface (anything other than null). If none is used, the filter matches all routes having a null interface. Note that you can view the index number (ifIndex) for an interface with the -a option of ifconfig(1M). {src|dst}:{ip-address[/mask]|any|none} Selects a source or destination IP address. If specified with a mask length, any routes with matching or longer (more specific) masks are selected. If any is used, all but addresses 0 are selected. If none is used, address 0 is selected. flags:[+ -]?[ABDGHLU]+ Selects routes tagged with the specified flags. By default, the flags as specified must be set in order to match. With a leading +, the flags specified must be set but others are ignored. With a leading -, the flags specified must not be set and others are permitted. |
|
-g |
Shows the multicast group memberships for all interfaces. |
|
-i |
Shows the state of the interfaces that are used for IP traffic. Normally this shows statistics for the physical interfaces. When combined with the -a option, this will also report information for the logical interfaces. |
|
-m |
Shows the STREAMS memory statistics. |
|
-n |
Shows network addresses as numbers. Netstat normally displays addresses as symbols. This option may be used with any of the display formats. |
|
-p |
Shows the net to media tables. |
|
-r |
Shows the routing tables. Normally, only interface, host, network, and default routes are shown, but when this option is combined with the -a option, all routes will be displayed, including cache. |
|
-s |
Shows per-protocol statistics. When used with the -M option, shows multicast routing statistics instead. When used with the -a option, per-interface statistics will be displayed, when available, in addition to statistics global to the system. |
|
-v |
Verbose. Shows additional information for the sockets, STREAMS memory statistics, and the routing table. |
|
-I interface |
Shows the state of a particular interface, which can be any valid interface such as hme0 or le0. When combined with the -a option, information for the logical interfaces is also reported. |
|
-M |
Shows the multicast routing tables. When used with the -s option, shows multicast routing statistics instead. |
|
-P protocol |
Limits display of statistics or state of all sockets to those applicable to protocol. The protocol can be either ip, ipv6, icmp, icmpv6, igmp, udp, tcp, or rawip. rawip can also be specified as raw. The command accepts protocol options only as all lowercase. |
|
-D |
Shows the status of DHCP configured interfaces. |
| On the Job |
The netstat command with -a and -f inet switches can be used to show the state of all sockets and all routing table entries for the AF_INET address family showing IPv4 information only. |
As an example we'll issue the netstat -a -f inet command. The following is an extract from the sample output during an attack:
172.16.43.11.22 172.16.43.100.21834 0 0 9112 0 SYN_RECEIVED 172.16.43.11.22 172.16.43.100.22090 0 0 9112 0 SYN_RECEIVED 172.16.43.11.22 172.16.43.100.22346 0 0 9112 0 SYN_RECEIVED 172.16.43.11.22 172.16.43.100.22602 0 0 9112 0 SYN_RECEIVED 172.16.43.11.22 172.16.43.100.22858 0 0 9112 0 SYN_RECEIVED 172.16.43.11.22 172.16.43.100.23114 0 0 9112 0 SYN_RECEIVED 172.16.43.11.22 172.16.43.100.24854 0 0 9112 0 SYN_RECEIVED 172.16.43.11.22 172.16.43.100.25080 0 0 9112 0 SYN_RECEIVED 172.16.43.11.22 172.16.43.100.26386 0 0 9112 0 SYN_RECEIVED 172.16.43.11.22 172.16.43.100.27609 0 0 9112 0 SYN_RECEIVED 172.16.43.11.22 172.16.43.100.28853 0 0 9112 0 SYN_RECEIVED 172.16.43.11.22 172.16.43.100.29134 0 0 9112 0 SYN_RECEIVED localhost.32801 localhost.32799 73620 0 73620 0 ESTABLISHED localhost.32799 localhost.32801 73620 0 73620 0 ESTABLISHED localhost.32803 localhost.32799 73620 0 73620 0 ESTABLISHED localhost.32799 localhost.32803 3620 0 73620 0 ESTABLISHED localhost.32805 localhost.32771 73620 0 73620 0 ESTABLISHED localhost.32771 localhost.32805 73620 0 73620 0 ESTABLISHED localhost.32810 localhost.32809 36810 0 73620 0 ESTABLISHED localhost.32809 localhost.32810 73620 0 73620 0 ESTABLISHED localhost.32813 localhost.32812 73620 0 73620 0 ESTABLISHED localhost.32812 localhost.32813 73620 0 73620 0 ESTABLISHED localhost.32816 localhost.32799 73620 0 73620 0 ESTABLISHED localhost.32799 localhost.32816 73620 0 73620 0 ESTABLISHED localhost.32819 localhost.32818 36810 0 73620 0 ESTABLISHED localhost.32818 localhost.32819 73620 0 73620 0 ESTABLISHED localhost.32822 localhost.32799 73620 0 73620 0 ESTABLISHED localhost.32799 localhost.32822 73620 0 73620 0 ESTABLISHED localhost.32825 localhost.32824 73620 0 73620 0 ESTABLISHED localhost.32824 localhost.32825 73620 0 73620 0 ESTABLISHED
The interesting part of this example accommodates only the first 12 lines. In them, we see SYN packets from a trusted but spoofed host using contact port 22 (which is Secure Shell, or SSH). Notice the change in source port numbers. In addition, too many connections in the SYN_RECEIVED state would typically indicate that the system is being attacked here.
|
|