Service Ports: The Door to the Programs on Your System


Network-based services are programs running on a machine that other computers on the network can access. The service ports identify the programs and individual sessions or connections taking place. Service ports are the numeric names for the different network-based services. They are also used as numeric identifiers for the endpoints of a particular connection between two programs. Service port numbers range from 0 to 65535.

Server programs (that is, daemons) listen for incoming connections on a service port assigned to them. By historical convention, major network services are assigned well-known, or famous, port numbers in the lower range from 1 to 1023. These port numbertoservice mappings are coordinated by the Internet Assigned Numbers Authority (IANA) as a set of universally agreed-on conventions or standards.

An advertised service is simply a service available over the Internet from its assigned port. If your machine isn't offering a particular service, and someone tries to connect to the port associated with that service, nothing will happen. Someone is knocking on the door, but no one lives there to answer. For example, HTTP is assigned to port 80 (though, again, there's no reason why you couldn't run it on port 8080, 20943, or any available port). If your machine isn't running an HTTP-based web server and someone tries to connect to port 80, the client program receives a connection shutdown message as an error message from your machine indicating that the service isn't offered.

The higher port numbers from 1024 to 65535 are called unprivileged ports. They serve a dual purpose. For the most part, these ports are dynamically assigned to the client end of a connection. The combination of client and server port number pairs, along with their respective IP host addresses, and the Transport protocol used, uniquely identifies the connection.

Additionally, ports in the 1024 through 49151 range are registered with the IANA. These ports can be used as part of the general unprivileged pool, but they are also associated with particular services such as SOCKS or X Window servers. Originally, the idea was that services offered on the higher ports were not running with root privilege. They were for use by user-level, nonprivileged programs. The convention may or may not hold in any individual case.

SERVICE NAMETOPORT NUMBER MAPPINGS

Linux distributions are supplied with a list of common service port numbers. The list is found in the /etc/services file.

Each entry consists of a symbolic name for a service, the port number assigned to it, the protocol (TCP or UDP) the service runs over, and any optional nicknames for the service. Table 1.5 lists some common service nametoport number mappings, taken from Red Hat Linux.

Table 1.5. Common Service NametoPort Number Mappings

PORT NAME

PORT NUMBER/PROTOCOL

ALIAS

ftp

21/tcp

- -

telnet

23/tcp

- -

smtp

25/tcp

mail

nicname

43/tcp

whois

domain

53/tcp

nameserver

domain

53/udp

nameserver

finger

79/tcp

- -

http

80/tcp

www www-http

pop3

110/tcp

pop-3

auth

113/tcp

authentication tap ident

nntp

119/tcp

readnews untp

ntp

123/udp

- -

https

443/tcp

- -


Note that the symbolic names associated with the port numbers vary by Linux distribution and release. Names and aliases differ; port numbers do not.

Also note that port numbers are associated with a protocol. The IANA has attempted to assign the same service port number to both the TCP and the UDP protocols, regardless of whether a particular service uses both transport modes. Most services use one protocol or the other. The domain name service uses both.


A Typical TCP Connection: Visiting a Remote Website

As an illustration, a common TCP connection is going to a website through your browser (connecting to a web server). This section illustrates the aspects of connection establishment and ongoing communication that will be relevant to IP packet filtering in later chapters.

What happens? As shown in Figure 1.6, a web server is running on a machine somewhere, waiting for a connection request on TCP service port 80. You click on the link for a URL in Netscape. Part of the URL is parsed into a hostname; the hostname is translated into the web server's IP address; and your browser is assigned an unprivileged port (for example, TCP port 14000) for the connection. An HTTP message for the web server is constructed. It's encapsulated in a TCP message, wrapped in an IP packet header, and sent out. For our purposes, the header contains the fields shown in Figure 1.6.

Figure 1.6. A TCP client connection request.


Additional information is included in the header that isn't visible at the packet-filtering level. Nevertheless, describing the sequence numbers associated with the SYN and ACK flags helps clarify what's happening during the three-way handshake. When the client program sends its first connection request message, the SYN flag is accompanied by a synchronization sequence number. The client is requesting a connection with the server and passes along a starting sequence number it will use as the starting point to number all the rest of the data bytes the client will send.

The packet is received at the server machine. It's sent to service port 80. The server is listening to port 80, so it's notified of an incoming connection request (the SYN connection synchronization request flag) from the source IP address and port socket pair (your IP address, 14000).

The server allocates a new socket on its end, (web server IP address, 80) and associates it with the client socket.

The web server responds with an acknowledgment (ACK) to the SYN message, along with its own synchronization request (SYN), as shown in Figure 1.7. The connection is now half open.

Figure 1.7. A TCP server connection request acknowledgment.


Two fields not visible to the packet-filtering level are included in the SYN-ACK header. Along with the ACK flag, the server includes the client's sequence number incremented by the number of contiguous data bytes received. The purpose of the acknowledgment is to acknowledge the data the client referred to by its sequence number. The server acknowledges this by incrementing the client's sequence number, effectively saying it received the data, and sequence number plus one is the next data byte the server expects to receive. The client is free to throw its copy of the original SYN message away now that the server has acknowledged receipt of it.

The server also sets the SYN flag in its first message. As with the client's first message, the SYN flag is accompanied by a synchronization sequence number. The server is passing along its own starting sequence number for its half of the connection.

This first message is the only message the server will send with the SYN flag set. This and all subsequent messages have the ACK flag set. The presence of the ACK flag in all server messages, as compared to the lack of an ACK flag in the client's first message, will be a critical difference when we get to the information available for constructing a firewall.

Your machine receives this message and replies with its own acknowledgment, after which the connection is established. Figure 1.8 shows a graphic representation of this. From here on, both the client and the server set the ACK flag. The SYN flag won't be set again by either program.

Figure 1.8. TCP connection establishment.


With each acknowledgment, the client and server programs increment their partner process's sequence number by the number of contiguous data received, plus one, indicating receipt of that many bytes of data, and indicating the next data byte in the stream the program expects to receive.

As your browser receives the web page, your machine receives data messages from the web server with packet headers, as shown in Figure 1.9.

Figure 1.9. An ongoing TCP server-to-client connection.





Linux Firewalls
Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort
ISBN: 1593271417
EAN: 2147483647
Year: 2005
Pages: 163
Authors: Michael Rash

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net