Network services are sometimes called daemons, servers, or just services. These services listen on network ports for incoming connections. Network services are often the focal point of attacks on a system. These services or processes are constantly running in the background. Since they are not connected to a terminal, the output they produce, if any, can be viewed in log files. Some services take advantage of the system logger while others create their own log files. This means if you're monitoring log files, you may need to check for logs that live outside of the var log directory. Consult the documentation and configuration for each specific service that you're interested in. These network services are designed to perform a single task. For example, the Secure Shell Daemon, SSHD, handles incoming SSH connections. A web server process like httpd listens for and response to incoming web requests. Use a dedicated user to run the network service. For example, don't run a database as the root user, instead, create a database user which runs the database servers and owns the associated data. That way, if the database service gets exploited, it will only have access to the things that that particular user has access to. If you were to run the databases root and it got exploited, then the attacker would have root privileges and have complete access to the system. Ports below 1,024 are known as privileged ports. This is because they require super user privileges to open. For network services that run on these low ports like a web server running on port 80, the root user can be used to open the port, but then it can drop its privileges to another user. For example, the Apache web server will start the master process as root to open port 80, and then spawn child processes running as the web server user. These processes that run as the web server user, are the processes that are actually responding to web requests and doing the work. If you're running a server on a low port, check the configuration of that service to see if you can specify a non root user to actually perform the work, even though root privileges are required to open the port. Since each service that is running on your system is a potential attack surface, be sure to stop and uninstall each service that you do not need. Better yet, never install them in the first place. Avoid using services that transmit and receive data un-encrypted and in the clear. You don't want sensitive data like usernames and passwords to be intercepted by an attacker. Many of the older legacy services that transmit data over the network un-encrypted, have newer secure alternatives. For example, you can replace telnet, rlogin, rsh and FTP with SSH. Stay on top of system and service updates. Exploits for services are routinely found in fixed, so be sure to keep your services updated with the latest security fixes. If you can, use a network service provided by your Linux distribution, so you can take advantage of easy updates. If you end up manually installing network services, then the responsibility of keeping up with security fixes is entirely in your hands. Network services listen for connections and many default to listening on every network interface and address on the system. Configure each service to bind to or listen on, only the interfaces and addresses that are needed for that service. For example, let's say you have a server that is running a web server process for your company's website, you wanna be able to log into the server over the network, so you configure SSHD. Let's say the server has two network connections. One on the public internet, so people can get to your website, and one on your private company network. If you allowed SSH to bind to all the addresses on your system, then SSH would be exposed to the outside world. Since only people from inside your company need SSH access, configure SSH to only listen on the private IP address of the server. You could let the web server listen on both the public and private networks so you can monitor the web service from inside your company, for example. The important point is that, by not exposing the SSH service to the public network, you reduce your attack surface and increase the security. Let's add a database service to the mix. Let's say that your web server needs to store some data in a database, and you decide to put that database on the same server. In this example, that database is a MySQL database and listens on port 3306. If you allow the database service to listen on all the network addresses on the server, then you expose yet another attack surface to the outside world. No one from the public internet needs direct access to the database. So don't expose the database on that network. They can make a web request and the web service will access the database as needed. If this database is only being used by the web server that runs on that system, then there's also no need to listen on the private network address either. And this situation I would bind the database to the loop back address of the server which is 127.0.0.1. This special IP address is not physically connected to any network, it's used for internal server communications only. Optionally, you could configure the database to listen on the private network address as well. This would allow for external monitoring of the database, for example. However, I would still configure the web server to connect to 127.0.0.1 on port 3306. This ensures that database traffic doesn't leave the server. If you're transferring un-encrypted data, this will at least keep that un-encrypted data off the network. Not only can you limit what network interface and address service listens on, you can also use the built-in Linux firewall to further control access to your system and that network service. To continuing with our example, let's say you want to restrict SSH access to only people who work in the IT department. The system administrators, programmers, network engineers and other it staff have their computers on the 10.20.30.0/24 network. You would configure the local Linux firewall to drop all network packets that were attempting to connect to SSH, unless those connections originated from the IT department's network. If an attacker were to gain access to a computer on another network inside your company, then they still wouldn't be able to SSH to that server. We'll get into the specifics of how to configure the firewall in another lesson, but for now know that using a local firewall is an option. If you want yet another layer of protection, you can use TCP Wrappers to define which hosts are or are not allowed to connect to Wrapped network Services. Wrapped network services are services that are TCP Wrapper aware. One of the most popular TCP Wrap services is inetd or its current incarnation xinetd. Xinetd is a super server which listens for incoming network requests and then dispatches those requests to the proper service. If a network connection makes it past the firewall, then it's examined by TCP Wrappers. If the connection is allowed by TCP Wrappers, then the request is handed off to the proper service. If the connection is bound to a service that directly supports TCP Wrappers, that connection is handed over directly to that service. If the request is bound to a service that xinetd manages, xinetd starts the sub-process or sub-service and hands over the request to it. We'll look at the details of configuring TCP Wrappers in another lesson.