Configuring Network Services (HTTP and SSH)

When building or maintaining Linux systems, ensuring the stable operation of core services is paramount. Among these, web servers (typically based on HTTP) and remote management tools (SSH service) are two critical pieces of infrastructure. The HTTP service is responsible for delivering webpage content, API interfaces, and static resources externally, while SSH serves as the sole secure channel for system configuration, file transfer, and troubleshooting performed by operations personnel.

Before beginning specific configurations, you must adhere to the "Principle of Least Privilege" and a "Default Deny Policy". Modern Linux distributions (such as Ubuntu, CentOS) usually come pre-installed with these services' daemons upon installation. However, for security reasons, they often do not automatically start listening on ports or bind to all network interfaces by default. Therefore, administrators need to clearly know the service names, corresponding port numbers, and paths to system configuration files in order to perform precise starting/stopping and parameter adjustments.

Common Service Identification

In Linux systems, support for web server software varies slightly across different distributions:

Nginx: Currently the most popular reverse proxy and static web server, known for excellent performance and high concurrency support.
Apache (httpd): A classic open-source project with a rich plugin ecosystem, suitable for complex scenarios.
OpenSSH / OpenBSD SSH: Provides secure remote login functionality; the default port is 22.

Regardless of the software chosen, its configuration logic generally follows a dual mechanism where "configuration files define parameters" and "service management tools control status". For Nginx, the main configuration file is typically /etc/nginx/nginx.conf; for Apache, it resides at /etc/httpd/conf/httpd.conf (CentOS) or /etc/apache2/apache2.conf (Ubuntu). SSH port configurations are primarily modified in the master configuration file of SSHD.

Key Parameter Explanations

Listening Address and Port: This is the sole entry point exposed to external entities by the service. Default ports for HTTP/HTTPS are 80 and 443 respectively, while SSH defaults to 22. In production environments, it is strongly recommended to change non-standard service ports to unconventional values (such as 8080 or 2222) to evade automated scanning attacks.
Binding Interface: Configure whether the service listens only on 127.0.0.1 (local loopback) or 0.0.0.0 (all network interfaces). If internal network access is required, set it to a specific IP address rather than using wildcards (*) to limit unnecessary exposure.
User Permissions: The SSH service runs under the root or sshd account; modifying its configuration files typically requires sudo privileges. Web server configuration file permissions vary by distribution; some require root privileges, while others may only need ordinary user permissions (e.g., www-data).

Actual Configuration Steps and Examples

SSH Security Hardening Practices

The default SSH port 22 is highly susceptible to brute-force attacks. By modifying the Port parameter in the sshd_config file, you can migrate the service to a higher security level. Additionally, disabling password login while retaining key-based authentication is also one of the common best practices.

Edit Configuration File: Open the configuration source using a text editor.
```
sudo nano /etc/ssh/sshd_config
```
Modify Port Settings: Comment out Port 22 and add a new secure port (e.g., 2022).
Save and Reload Service: The Linux SSHD daemon typically supports configuration hot-reload. Execute the following command to apply the new configuration without restarting the system:
```
sudo systemctl reload sshd
```

Nginx Quick Deployment Example

Taking Ubuntu as an example, the Nginx configuration process is relatively intuitive and highly modularized. Suppose we need to host a website under the domain www.example.com and configure it to allow access only from internal networks (IP: 192.168.0.5).

Create Site Configuration File:

sudo nano /etc/nginx/sites-available/example.com

Write Core Directives: Define the listening address, domain name, and document root in the file. Note to use the listen directive to specify an IP rather than hardcoding a port number (unless multiple protocols are needed).
```
server {
    listen 192.168.0.5:80;
    server_name www.example.com;

    root /var/www/html/example;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}
```
Enable Configuration: Move the file from sites-available to sites-enabled.
```
sudo ln -s ../sites-available/example.com sites-enabled/example.com
```

Apache Virtual Host Configuration Logic

Apache uses a virtual host mechanism based on directories or names; its configuration files are typically located in /etc/apache2/sites-available/ (Ubuntu) directory. Unlike Nginx, Apache requires the service to be restarted for new site configurations to take effect. Within the VirtualHost block, you must explicitly specify <Directory> permissions to control file read scope and prevent issues such as websites becoming inaccessible or security risks due to incorrect directory permissions.

Verification and Maintenance Strategies

After completing configuration, strict testing is mandatory to ensure service availability. For SSH services, built-in debug mode can be used to view logs and confirm if port changes have taken effect; for web servers, connectivity tests should be performed by entering the corresponding IP:Port combination in a browser (e.g., http://192.168.0.5).

During daily maintenance, regularly checking system logs is key to identifying potential issues. Nginx and Apache typically record request errors in /var/log/nginx/error.log or /var/log/apache2/error_log; excessive failed authentication attempts for SSH will trigger the FailedPasswordAuthenticationThreshold mechanism and write entries into security audit logs. If configuration syntax errors occur or permissions are insufficient, services will fail to start (Start); at this point, check the corresponding systemd status output to locate the specific cause.

Through these standardized steps and parameter adjustments, administrators can establish a network infrastructure that is both efficient and secure, providing solid environmental support for upper-layer application deployment.