Security of TCP/IP Protocols

WeChat Public Account: Computer and Network Security

ID: Computer-network

TCP/IP is the protocol currently used on the Internet. The reason it has achieved its brilliant status today is due to the many advantages it embodies in its design principles, such as simplicity, ease of expansion, and best-effort delivery. These principles provide users of the TCP/IP protocol with a very convenient interconnection environment, leading to a rapid increase in Internet users. However, behind these advantages, the TCP/IP protocol also has a series of security flaws. These flaws are common to all implementations of TCP/IP, and this article will briefly introduce these security risks.

1. Overview of TCP/IP

1.1 Basic Structure of TCP/IP

TCP/IP is a set of Internet protocols, which includes not only the two key protocols TCP and IP but also other protocols such as UDP, ARP, ICMP, Telnet, and FTP. The design goal of TCP/IP is to connect different networks, i.e., to realize the Internet. To achieve this goal, TCP/IP is designed as a four-layer structure, from top to bottom: Application Layer, Transport Layer, Network Layer, and Physical Link Layer, as shown in Figure 1.

Figure 1 Basic Logical Structure of TCP/IP

Figure 1 shows the logical structure of the TCP/IP protocol layers. Any computer wishing to communicate with other computers on the Internet must have such a logical structure. Each layer can have one or more modules, with each module implementing certain data processing functions. Applications such as Telnet and FTP run at the application layer. The transport layer provides end-to-end data transmission for the application layer, with two protocols: TCP and UDP. The network layer implements packet forwarding, which is a key technology for interconnecting networks, and the protocol for the network layer is the IP protocol. The physical link layer includes the physical network lines, network drivers, and some protocols such as ARP. The most common physical network today is Ethernet, and the ENET module is the Ethernet network driver. The small circle under the IP module represents the IP address, while the small circle under the ENET module represents the MAC address. The IPv4 address is 32 bits, and IPv6 is being introduced, which has a length of 128 bits.

There are two important principles in the TCP/IP layered structure: (1) At the same endpoint, each layer only interacts with adjacent layers; for example, applications do not care how the network layer forwards packets or through which networks the data is transmitted; (2) The same layer has a peer relationship between different endpoints. Peer layers can communicate with each other, such as communication between applications, communication between TCP modules, etc.

1.2 TCP/IP Communication Model

The communication model is one of the most fundamental models of TCP/IP, describing how data is transmitted between endpoints. In Figure 1, the connections between layer modules indicate the route of data flow. At the sending end, data flows from the upper layer to the lower layer. For programs using the TCP protocol, data flows from the application through the TCP module. For programs using the UDP protocol, data flows from the application through the UDP module. Each time a data unit passes through a module, a header is added to identify where the unit came from. The data unit between the TCP and IP modules is called a TCP packet. The data unit between the UDP and IP modules is called a UDP packet. The data unit between the IP and ENET modules is called an IP packet. Once outside the ENET module, the data unit transmitted over the cable is an Ethernet frame.

At the receiving end, data flows from the lower layer to the upper layer. Each time a data unit passes through a module, it is sent to the corresponding module based on the content of the corresponding header, and the corresponding header information is removed. In the ENET module, based on the protocol item in the Ethernet frame, it is determined whether the data is sent to the IP module or the ARP module. In the IP module, based on the protocol item in the IP header, it is determined whether the data is sent to the TCP or UDP module. In the TCP and UDP modules, based on the port items in the TCP and UDP headers, it is determined which application the data is sent to.

TCP/IP provides two main transport protocols: TCP and UDP. The TCP protocol is a connection-oriented protocol. It guarantees error-free data transmission through a sending and acknowledgment mechanism. The UDP protocol is connectionless; it only sends and receives all packets without guaranteeing whether the data arrives. Whether to use the TCP or UDP protocol is determined by the application program. For example, FTP uses TCP, while SNMP uses UDP.

The ARP protocol is the Address Resolution Protocol, which converts the other party’s IP address into a MAC address for the network driver. Since Ethernet frames reach their destination based on the MAC address, there are two possibilities: if the destination IP address is in the same network, the data is sent directly to the destination, i.e., the destination’s MAC address is that of the destination. On the other hand, if the destination IP address is not in the same network, the data is sent to the gateway, and the destination’s MAC address is that of the gateway.

1.3 TCP/IP Network Interconnection Model

Another main function of TCP/IP is the interconnection between different networks. The network interconnection function is implemented at the network layer, i.e., an IP module can connect to two different physical link layers to achieve interconnection between the two networks, as shown in Figure 2.

Figure 2 An IP Module Connecting Two Networks

Figure 2 shows the structure of a network layer and physical link layer with two network cards connected to two networks. This structure can implement packet forwarding, i.e., it can forward packets coming from one network to another, a function shared by gateways and routers. Each network has its own network driver and ARP module, as well as two MAC addresses corresponding to two IP addresses. In the IP module, based on the destination IP address marked on the data unit, it is determined which network the data is sent to. In the case of the two networks shown, data from Ethernet 1 can be sent to Ethernet 2, and vice versa. This achieves a simple gateway function. If an IP module connects to three networks, data from one network can choose to be sent to one of the remaining networks, which is the routing selection function. Through the data forwarding of gateways and routing selection functions, interconnection between different networks is achieved.

2. Denial of Service Attacks

Denial of Service (DoS) attacks consume the resources of the target host or network, thereby disrupting or paralyzing the services provided to legitimate users. Currently, DoS attacks can be divided into three categories: bandwidth exhaustion, resource exhaustion, and processing flaw types. Bandwidth exhaustion attacks mainly congest the target network’s outlet, leading to bandwidth consumption that cannot provide normal Internet services. Common examples include Smurf attacks, UDP Flood attacks, and MStream Flood attacks. The general countermeasure for such attacks is QoS, which limits the flow of such data streams on routers or firewalls to ensure normal bandwidth usage. Pure bandwidth exhaustion attacks are relatively easy to identify and can be discarded. Resource exhaustion attacks involve attackers severely consuming critical processing resources of the target server, such as CPU and memory, causing the target server to be unable to provide normal services. Common examples include SynFlood attacks and Naptha attacks. Both types of attacks exploit issues in the system’s handling of normal network protocols; even if the server or network does not have inherent problems, it may still be attacked. For processing flaw type DoS attacks, they are usually due to unnecessary flaws (bugs) introduced during system implementation, which cause the system to be unable to continue providing services when attackers use certain abnormal traffic.

In recent years, with the development of large-scale attack techniques, some Distributed Denial of Service (DDoS) methods have emerged, utilizing multiple computers to launch DDoS attacks simultaneously against one or multiple targets. DDoS attacks enhance attack power by employing various new attack techniques, such as data forgery, eliminating attack packet characteristics, comprehensively utilizing protocol flaws and system processing flaws, using mixed attack packets, and employing pre-generated attack packets to improve the effectiveness of attacks. Such attacks are usually more challenging to prevent and control.

Below, we will briefly introduce several common security risks caused by issues in the TCP/IP protocol.

2.1 SYN Flood Attacks

The most classic attack is the SYN flood attack, which exploits vulnerabilities in the TCP/IP protocol to carry out the attack. Typically, establishing a TCP connection involves three steps: the client sends a SYN packet to the server, the server allocates certain resources for this connection and returns a SYN/ACK packet, waiting for the final ACK packet to establish the connection, and finally, the client sends an ACK message, thus establishing the connection between the two parties and allowing data to be transmitted through the connection. The attack process involves sending SYN packets frantically without returning ACK packets, causing the server to consume too many resources, leading to excessive system resource usage and an inability to respond to other operations or normal network requests.

This attack is a classic example of using few resources to occupy a large amount of the opponent’s resources. A P4 Linux system can send approximately 30–40 Mbit/s of 64-byte SYN flood packets, while a typical server will have no response with only 20 Mbit/s of traffic (including mouse and keyboard). Moreover, SYN flood can be conducted remotely and can also spoof source IP addresses, making it very challenging to trace; to investigate, one must check the routers of all backbone network operators step by step.

Common solutions to SYN flood attacks include router rate limiting and SynCookie. Router rate limiting restricts the arrival rate of SYN packets; the SynCookie method requires the client to respond with a digital receipt when establishing a TCP connection to prove its authenticity, thus solving the problem of limited resources in the target computer system’s half-open connection queue.

2.2 Naptha

Because establishing each TCP connection consumes relatively large resources, if a large number of TCP connections are established with the same server, the server may become unable to respond to other users due to resource exhaustion. The problem with this idea is that if using the usual APIs, the attacker would crash before the server could respond. Therefore, Naptha does not use traditional network APIs to establish TCP connections; unlike a real TCP/IP stack, it does not maintain any connection state records, responding only based on certain flags in the packets sent to it. By this method, it can establish thousands of connections with the target host while using very few resources compared to the target host. Using this method, it poses a real threat to a specific service or the TCP/IP stack itself on the target host. Naptha attacks can be implemented in a distributed manner, making them even more effective.

The first step of the attack is to send a series of SYN packets from all possible ports of a forged IP address to the target host. Then, a program needs to run in the local area network where the forged IP is located to ensure that the router’s ARP table contains this “virtual host” (the forged IP address). Next, it listens for packets sent from the target host to the virtual host. This program will respond to those packets using appropriate flags and sequence numbers to establish connections. The use of a virtual host is mainly to make tracking the source of the attack more difficult.

In summary, the Naptha attack illustrates the severity of resource exhaustion attacks. There is currently no obvious solution to this problem.

2.3 Traffic Amplifiers

Traffic amplifiers are often used to implement distributed denial of service attacks. A traffic amplifier refers to a system that processes input traffic and amplifies it several times; thus, if an attacker sends a large amount of traffic with the source address modified to that of the target system to these amplifiers, a large amount of traffic will flood the target system, leading to a denial of service attack.

Smurf attacks are named after the program that initially launched this attack, Smurf. This attack method combines IP spoofing and ICMP reply methods to flood the target system with large amounts of network packets, causing the target system to deny service to normal systems. The attacker sends a deceptive Ping packet (echo request) to the broadcast address of a network with many hosts and Internet connections; this target network is referred to as a reflection site, and the source address of the deceptive Ping packet is that of the system being attacked. If the router receives this packet sent to the IP broadcast address (e.g., 202.112.0.255), it will map it to the Ethernet broadcast address FF:FF:FF:FF:FF:FF, broadcasting to all hosts in the local network segment. All ECHO packets will then be forwarded to the attacked system, and when the attacker uses a large number of reflection networks, the attacked system will lose service capability due to a lack of available network bandwidth.

Another common method is to utilize DNS servers for DNS queries. Attackers send a large number of query requests to multiple DNS servers, with the source IP address of these requests being that of the attacked host. The DNS servers will send a large number of query results back to the attacked host, congesting the network where the attacked host resides or preventing it from providing services.

For these attacks, router-based ACLs and rate limiting are relatively effective preventive measures. Additionally, for Smurf attacks, routers can be configured not to forward packets targeting broadcast addresses from external networks.

2.4 Attacks on OSPF

OSPF (Open Shortest Path First) is another routing protocol used within autonomous systems. The routing algorithm used by OSPF is the link-state algorithm. In this algorithm, each router announces to neighboring routers the complete routing state, including reachable routers, connection types, and other relevant information. Compared to RIP, the OSPF protocol has implemented an authentication process. However, the protocol still has some security issues.

LSA (Link State Advertisement) is the information that routers must exchange in the OSPF protocol. An LSA header format is shown in Figure 3.

Figure 3 LSA Header Format

The LSA sequence number is 32 bits long and indicates the update degree of the LSA. The LSA sequence number is a signed integer, ranging between 0x80000001 (negative) and 0x7fffffff. A larger LSA sequence number indicates that the LSA has been updated. It is worth noting that any router can change the header information of this LSA. An attacker receiving an LSA can increment the LSA sequence number by 1 (Seq++ attack), recalculating the LSA checksum to ensure that the LSA is valid, and then retransmitting this LSA to other routers. Other routers receiving this LSA will find that the LSA sequence number has been incremented, indicating that the LSA has been updated, and they will update their routing state and continue to disseminate this LSA until the creator of the LSA receives it and finds that the content is incorrect. If the attacker continuously modifies the LSA sequence number received, it will lead to network instability.

In addition to incrementing the sequence number, the attacker can also set the sequence number to the maximum value, i.e., 0x7fffffff (MaxSeq attack). Of course, each time the LSA is modified, the attacker must recalculate the checksum to ensure the LSA is valid. When the LSA reaches its creator, it is reset and retransmitted. If the attacker continuously modifies the LSA sequence number received, it will also cause network instability.

The third method of attack on OSPF is the MaxAge attack. When the attacker receives an LSA, they set the age item of the LSA to the maximum value (generally 3600) and then send it to other routers. Other routers receiving this LSA will clear the information of this LSA from their routing state. When the creator of this LSA receives it, the LSA is reset and retransmitted. Like the previous attacks, this will also cause network instability.

2.5 BGP Vulnerabilities

BGP (Border Gateway Protocol) is the routing information exchange protocol between core routers of autonomous systems (AS). Like the TCP/IP protocol, BGP also contains various security vulnerabilities, such as IP spoofing, eavesdropping, SYN attacks, etc. Any entity can add information to a BGP connection or interrupt that connection. Coupled with IP spoofing attack techniques, an entity can remotely reset any BGP router in the world.

The reason BGP has so many security issues is that it lacks a mechanism to protect the integrity, validity, and authentication of BGP connection messages. Additionally, there is no validation of the NLRI (Network Layer Reachability Information) and AS_PATH items.

BGP has four message types: OPEN, KEEPALIVE, NOTIFICATION, and UPDATE. Any entity can forge OPEN, KEEPALIVE, and NOTIFICATION messages to disrupt a BGP connection. It can also forge UPDATE messages with ATOMIC_AGGREGATE, AS_PATH, or NLRI items to disrupt routing functionality. The consequences of problems occurring in routers running the BGP protocol can be catastrophic, potentially causing the entire ISP network to be inaccessible, making such security attacks even more severe. Fortunately, most core routers already implement strict access control, making it unlikely for intruders to directly attack core routers.

Currently, there are some security extensions for BGP, such as adding integrity check options to BGP messages to mitigate this risk, but most ISPs still prefer access control to address this issue, as the impact is much smaller.

3. Sniffing, Spoofing, and Hijacking

IP packets are generally transmitted in plaintext and do not have source verification. These two issues are among the most serious security vulnerabilities in TCP/IP networks. Lack of content encryption allows data to be easily eavesdropped on in broadcast-type local area networks. For example, on Ethernet, simply setting the network card to promiscuous mode allows one to listen to all data packets. By analyzing these packets, attackers may obtain necessary authentication information or sensitive content, such as passwords for application protocols like Telnet, FTP, POP3, etc., which are transmitted in plaintext. If these passwords are intercepted while being transmitted over the Internet, it can lead to significant security risks. Additionally, if the data contains personal sensitive information or business secrets, eavesdropping could result in major losses. Even if the eavesdropper cannot see the specific content of the data, they can analyze which hosts have which services running and which hosts communicated with each other, thus revealing the trust relationships between hosts. This information poses security risks.

Lack of source authentication is another significant issue. Attackers can impersonate other users to gain unauthorized privileges. For example, attackers can use forged IP addresses to hijack traffic. Furthermore, if attackers use other IP addresses for malicious attacks, they can effectively conceal their source while causing damage to the reputation and performance of the impersonated party. Spoofing ARP is a common method of IP address impersonation, where ARP packets are sent with the IP address of the impersonated host and the Ethernet address of the attacker’s machine as the source address, thus causing IP address impersonation. Using the source routing option in the IP packet header is another method for IP address impersonation; by specifying the source routing option, an IP packet can reach the destination host along a pre-specified route. In general, when one end uses the source routing option, it often indicates that there are sufficient reasons (such as congestion avoidance, fault routing, and efficiency considerations) to believe that the source route performs better, making it likely that the destination host will use the reverse route of the source route for communication, thus achieving source IP impersonation.

Attackers can even hijack a connection, becoming an intermediary between the two session parties. This means that the attacker acts as an intermediary between two parties in a conversation, forwarding messages between them. The attacker can add or delete some session content without either party being aware. In this case, the communication between the two parties is completely insecure. Generally, as long as an attacker can successfully impersonate one of the parties, they can hijack the session.

By comprehensively utilizing security issues in other protocols, the risks of sniffing, spoofing, and hijacking still exist even in non-broadcast local area networks or wide area networks.

3.1 TCP Sequence Number Prediction

The TCP sequence number prediction was first proposed by Morris and is one of the most famous flaws in the field of network security. The essence of this attack is to establish a connection by predicting the sequence number when the destination host does not respond with an acknowledgment packet. Thus, the intruder can impersonate a trusted host and communicate with the destination host.

The normal process of establishing a TCP connection is a three-way handshake, where the client takes an initial sequence number ISNC and sends the first SYN packet, the server acknowledges this packet and sets its own initial sequence number to ISNS, and the client acknowledges this, establishing the connection. The connection establishment process can be described as follows:

TCP Connection Establishment Process

Client → Server: SYN (ISNC)

Server → Client: ACK (ISNC), SYN (ISNS)

Client → Server: ACK (ISNS)

Client → Server: Data

and/or

Server → Client: Data

As can be seen, during the connection establishment process, the client must receive the initial sequence number ISNS from the server. Until the ISNS is received, it is a random number for the client.

Assuming the attacker somehow obtains the server’s initial sequence number ISNS, they can impersonate another trusted host and send information to the destination host. This process is as follows:

Attacker → Server: SYN (ISNX), SRC = Impersonated Host

Server → Impersonated Host: ACK (ISNX), SYN (ISNS)

Attacker → Server: ACK (ISNS), SRC = Impersonated Host

Attacker → Server: ACK (ISNS), SRC = Impersonated Host, Data

(where ISNX is the initial sequence number from the attacker)

Thus, the attacker can send arbitrary data to the server. If this connection allows remote command execution (e.g., rsh), the attacker can execute any operation on the server.

In this intrusion method, the predictability of ISNS is a core issue, so this flaw relies on the predictability of TCP sequence numbers. ISNS is generated by the TCP/IP module implemented by the operating system. For different operating systems, the implementation of the TCP/IP module varies, so the mechanism for generating ISNS also differs. In older Berkeley systems, the initial sequence number variable is increased by a fixed value every second, and after a connection is initialized, this fixed value is halved. Therefore, if an attacker establishes a normal connection with the server and observes the initial sequence number ISNS from the server, they can accurately predict the value of the initial sequence number variable at any given moment on the server, meaning they can predict ISNS. Another variant of the TCP sequence number attack is to utilize the netstat service. If the target host runs the netstat service, it will provide information about the TCP sequence numbers on other ports of that host. In this case, the attacker does not need to predict but can directly obtain ISNS. Some newer operating systems do not generate ISN in a completely random manner; for instance, some operating systems generate values that are incremented, and others may produce values that, while appearing random, may not have a uniform distribution upon closer analysis, potentially exhibiting behaviors similar to strange attractors.

In fact, during the transmission process mentioned above, packets sent from the server to the impersonated host could be received by the impersonated host, which would find this to be a nonexistent connection and send a RST packet to block the connection from being established. To overcome this issue, the attacker can send a large number of SYN packets to the impersonated host (SYN-Flood attack), exploiting the fact that TCP discards more than five consecutive SYN packets, thereby conducting a denial of service type attack on the impersonated host to prevent it from blocking the establishment of the attack connection. Another option for the attacker is to wait until the impersonated host closes or restarts to carry out the attack.

3.2 RIP Attacks

RIP (Routing Information Protocol) is an internal routing protocol (IGP) used within autonomous systems (AS). RIP is used to exchange routing information between routers within an autonomous system. The routing algorithm used by RIP is the distance-vector algorithm. The main idea of this algorithm is that each router announces to neighboring routers which routers can be reached through it and their distances. It is noteworthy that the RIPv1 does not specify an authentication mechanism, while RIPv2 adds authentication mechanism settings. If the receiver does not authenticate the source and blindly accepts and processes this information, an intruder may send forged routing information to the destination host and along the way to various gateways. Thus, if the intruder announces a route to the destination host through themselves, all packets destined for the host will be sent to the intruder. This allows the intruder to impersonate the destination host, eavesdrop on all packets intended for the destination host, and even insert arbitrary packets into the data stream.

3.3 Use of Source Routing Options

The source routing option in the IP packet header is used to specify the routing situation of the IP packet, allowing an IP packet to reach the destination host along a pre-selected route. Now, assuming the destination host uses the reverse route of the source route to communicate with the source host, this handling is quite reasonable, as in general, one end using the source routing option often indicates that there are sufficient reasons (such as congestion avoidance, fault routing, and efficiency considerations) to believe that the source route performs better.

However, this also creates opportunities for intruders; when an intruder knows in advance that a certain host has a trusted host, they can utilize the source routing option to impersonate the trusted host, thus attacking the system, which essentially allows the host to be attacked by all other hosts.

Solution: This type of attack is difficult to prevent. A simple preventive measure is to prohibit packets using source routing from passing through the gateway, but this method is powerless against attacks from machines within the same subnet. Moreover, this method completely prohibits the source routing option, which is unreasonable. In theory, every host could determine the routing status to intelligently judge the legality of the source routing option, but this is practically impossible. Perhaps the best preventive measure is to completely avoid IP address-based authentication methods, such as R protocols, X protocols, etc. For Cisco routers, the command: no ip source-route can be used to avoid this attack.

3.4 ICMP Redirection

ICMP redirection messages are used by gateways to suggest an alternative route to hosts. Therefore, this message can be subjected to attacks similar to RIP. However, compared to RIP, ICMP redirection messages have more restrictions. For example, ICMP can only be passively sent after the destination host sends a packet; it cannot be used to change the destination host’s routing table at any time. ICMP redirection information can generally only be sent by the first hop (gateway). Subsequent gateways cannot change the source machine’s route or the previous gateway’s routing table.

Now, assuming an intruder has entered the backup gateway in the destination host’s network, first, the intruder impersonates another host T and sends a connection request to the destination host. When the destination host confirms the connection, the intruder sends a fake ICMP packet, impersonating the main gateway, indicating that host T must be relayed by the intruder. In this way, the intruder can listen to or arbitrarily modify the data stream of this connection. If the destination host modifies the global routing table upon receiving the ICMP redirection message, it can affect the entire network of the destination host.

Solution: Since ICMP redirection messages are only used in situations where there are multiple gateways in a local area network, and can only be sent by the local area network gateway, in most cases, simply ignoring this message will not cause significant problems. In cases where it is necessary, careful authentication is a powerful tool to ensure the security of ICMP redirection messages. Modifying only the routing for that connection upon receiving ICMP redirection information is a prudent approach that can be widely adopted. For Cisco routers, the command no ip redirect can be used to avoid this attack.

3.5 DNS Security Issues

The DNS service provides various services, including domain name resolution. It has multiple security vulnerabilities.

First, an intruder can conduct domain spoofing attacks. For R-class services (Rlogin, Rexec), when an intruder initiates a connection, the destination host first checks the list of trusted hostnames or addresses. If any of these are domain names, the destination host may utilize the DNS server to resolve the domain name. Assuming the intruder impersonates the DNS server and provides a response, the destination host may mistakenly believe the intruder is a trusted host. For this type of attack, the UDP source port number and DNS sequence number should be sought; the DNS sequence number generally starts at 0, while the UDP source port number can be obtained through netstat services or some UDP port scanning tools. If the intruder can impersonate the DNS server’s response, they can eavesdrop on all connections.

Domain name cheating is also a common security issue. There are various methods for domain name cheating, and DNS poisoning is one of them. It exploits vulnerabilities in DNS caching servers to lead users who intend to visit a certain website to unknowingly be redirected to other websites controlled by the attacker. This can be achieved by exploiting vulnerabilities in the user’s ISP’s DNS caching server or controlling it, thereby altering the response results for domain accesses within that ISP. Alternatively, attackers can exploit vulnerabilities in authoritative domain servers to implement cache poisoning, inserting incorrect domain records into the cache, causing all users utilizing that cache server to obtain erroneous DNS resolution results.

For these attacks, adopting DNSSEC is a feasible method.

4. Security Issues of TCP/UDP Application Layer Services

4.1 Information Exposure by Finger

Among all services with information exposure risks, Finger is one of the most dangerous. This is because:

(1) Finger has no authentication mechanism. Anyone can use Finger to obtain information about the target host.

(2) The information provided by Finger includes usernames, the origin of users, and other details, which can be used for password guessing attacks and impersonation attacks on trusted hosts, posing significant potential dangers.

(3) The lack of authentication in Finger means that it is impossible to determine whether a host is using Finger for “legitimate” purposes, making it difficult to ascertain the role of Finger even if the host is attacked.

Solution: Disable the Finger service. If there is sufficient reason to enable the Finger service, it is advisable to set Finger to: /bin/cat/etc/something.

4.2 Information Exposure by FTP

The FTP protocol itself has no security issues, but almost all implementations have the following problems:

(1) The FTP general user password is the same as the login password and is transmitted in plaintext, increasing the risk of a breach at any node. By simply eavesdropping on the local area network or router, a large number of passwords can be obtained. Thus, a node can be easily attacked.

(2) Some nodes’ anonymous FTP services provide another attack vector. Especially uploadable FTP services are more dangerous as they often allow intruders to place and spread Trojan horses. An attacker can upload a modified software containing malicious code. When a user on another host downloads and installs the software, a backdoor can be established. Anonymous FTP also poses a risk of exposing account and password information. Since anonymous FTP cannot log actions, attacks based on FTP are more covert.

Solution: Some nodes have begun to attempt using one-time passwords, making attacks based on (1) more challenging. Of course, employing encryption technology is also a good approach.

For servers, preventing attacks based on (2) is difficult. It could be required that every uploaded software must provide the uploader’s authentication information (e.g., email address) and verification, but this method is clearly inconvenient. Additionally, software producers should include data signatures in their produced software as a measure. Lastly, users installing software must be sufficiently cautious and aware of the software they install to prevent such attacks.

4.3 Security Issues of Telnet

Telnet itself does not have security issues. Its security vulnerabilities are similar to those of FTP (1), but somewhat more severe. Since Telnet transmits data in plaintext, not only the user password but also all user operations and responses are transparent. Thus, if Telnet is eavesdropped, the impact is larger and more severe. Another issue with Telnet is that it may allow intruders to inject any possible data packets.

Solution: Adding address authentication to servers where Telnet must be enabled can mitigate some issues. A better approach is to use encryption technology. It is also good practice to ensure that user work is conducted locally.

4.4 Security Issues of POP3

Since the POP3 password is the same as the account password, it has similar issues to FTP (1), and the solutions are also similar.

4.5 Security Issues of TFTP/BOOTP

TFTP allows reading files set to be readable by all without authentication. This can expose critical information such as accounts and working directories. Some TFTP services allow uploading files to directories writable by all, making this service even more dangerous.

BOOTP protocol allows diskless workstations to boot from the network. If an intruder impersonates a BOOTP server, the diskless workstation will run a modified kernel, leading to unpredictable consequences. If BOOTP uses RARP to obtain an IP address, this service becomes even more vulnerable, as Ethernet provides no security guarantees. Cross-segment BOOTP is even more dangerous.

Solution: Since TFTP is rarely used under normal circumstances, simply prohibiting it is the safest option. Otherwise, it is best to run the TFTP service process in a restricted environment. For BOOTP services, authentication should be a straightforward solution. Additionally, caution should be exercised regarding the booting of diskless machines.

4.6 Security Issues of DHCP Protocol

DHCP services assign IP addresses, masks, and DNS servers to clients. Without any verification, an attacker can specify the client’s DNS server as one they control, thus implementing all DNS spoofing attacks.

Generally speaking, using a self-specified DNS server is much safer.

4.7 Security Issues of RPC, Ruserd, Rstatd

RPC, or Remote Procedure Call, is a distributed computing protocol proposed by Sun and widely used. Almost all implementations of this protocol default to having Ruserd and Rstatd services. Ruserd lists all active users on the system, while Rstatd reports the current running status of the system. Since both services require no authentication, they may expose some security information about the system.

Solution: The Ruserd service is similar to the Finger service, so generally, it is unnecessary to have this service. Rstatd is also generally unnecessary to enable.

4.8 Security Issues of Rlogin, Rexec, and Other Services

The security vulnerabilities of Rlogin and Rexec have been discussed earlier. Their main issues are:

(1) Information exposure, similar to the security issues of Telnet.

(2) Trusted hosts being impersonated, including both IP address and hostname impersonation. Rlogin and Rexec do not add new content compared to Telnet, though they are slightly more convenient, they pose serious security vulnerabilities and make systems difficult to manage and control. Therefore, it is recommended to cancel these two services.

4.9 Security Issues of the X Protocol

The X protocol is a TCP-based protocol for graphical interface description and display, enabling remote display of graphical interfaces, greatly facilitating the use of UNIX.

The security issues of the X protocol primarily stem from its reliance on trusted host mechanisms; in nearly all implementations, the eligibility to receive X events generally depends on the IP address, allowing all IP spoofing to be used to attack X services.

Receiving X events poses significant threats to system security:

(1) It allows the capture of all keyboard inputs on the X server host.

(2) It allows the viewing of all graphical interface situations on the X server host.

(3) It allows control over all programs running on the X server host with graphical interfaces.

Thus, the X protocol poses a significant threat to system security.

Solution: Implementing user-based X protocol permission restrictions can reduce such attacks, but cannot fundamentally eliminate them. A better approach would be to employ encryption technology.

WeChat Public Account: Computer and Network Security

ID: Computer-network