Reverse proxy configuration method based on WSS

Abstract

The invention provides a reverse proxy configuration method based on a WSS, and the method comprises the steps: basic network parameter configuration: fixing an intranet IP of a rear-end application server as a preset intranet address, and setting a service monitoring port of the server as a preset WS port matched with a forwarding rule of a reverse proxy server, the back-end service is ensured to receive the proxy forwarding request only through the intranet; firewall refinement rule configuration: adopting an iptables tool to construct a hierarchical access control rule, including executing a rule emptying operation, deleting all existing rules in the iptables, and avoiding old rule conflicts; setting a chain default strategy, configuring the default strategy of the INPUT chain and the default strategy of the FORWARD chain as'discard ', and only reserving the default strategy of the OUTPUT chain as'accept'; executing unauthorized traffic interception: rejecting and discarding all inbound requests, including SYN connection requests directly initiated by a client, which are not allowed by the rules, so as to realize physical isolation between a back-end service and a public network; the technical problem that a back-end service port is exposed due to proxy configuration errors in a WSS reverse proxy scene is solved.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of network proxy, and particularly relates to a reverse proxy configuration method based on WSS. BACKGROUND

[0002] The present application aims at overcoming the deficiencies of the prior art (see Figure 4 ), and provides a method for preventing WSS proxy errors from exposing backend service ports; by implementing a double isolation strategy in the network architecture, the present application ensures that even if the Nginx proxy layer is configured incorrectly, the client cannot directly establish a connection with the backend service, thereby fundamentally eliminating the risk of route penetration. SUMMARY

[0003] The present embodiment aims to provide a reverse proxy configuration method based on WSS, which is used to solve the technical problem of exposing backend service ports due to proxy configuration errors in the WSS reverse proxy scenario.

[0004] A reverse proxy configuration method based on WSS is used to solve the technical problem of exposing backend service ports due to proxy configuration errors in the WSS reverse proxy scenario, which includes the following steps:

[0005] S1: Basic network parameter configuration: fix the internal IP of the backend application server as a preset internal address, and set the business listening port of the server as a preset WS port matching the forwarding rule of the reverse proxy server, to ensure that the backend service only receives proxy forwarding requests through the internal network;

[0006] S2: Firewall fine-grained rule configuration: use the iptables tool to build hierarchical access control rules, which specifically include:

[0007] S2.1. Perform rule emptying operation to delete all existing rules in iptables to avoid conflicts with old rules;

[0008] S2.2. Set the chain default policy, configure the INPUT chain and the FORWARD chain default policy as "drop", and only keep the OUTPUT chain default policy as "accept" to build a minimum permission access foundation;

[0009] S2.3. Configure necessary traffic release rules: allow inbound traffic related to established connections including ESTABLISHED, RELATED states and local loopback interface lo traffic, and only allow the internal IP of the preset reverse proxy server to access the preset WS port through the TCP protocol;

[0010] S2.4. Perform unauthorized traffic interception: perform rejection and discard on all inbound requests including client directly initiated SYN connection request which are not allowed by the above rules, realize physical isolation of backend service and public network.

[0011] Further, the rule empty operation is specifically: execute the iptables-F command to completely clear the existing rules of the INPUT, OUTPUT, FORWARD chain in iptables.

[0012] Further, the specific operation of setting the chain default policy includes: executing the iptables-P INPUT DROP command to configure the INPUT chain policy, executing the iptables-P FORWARD DROP command to configure the FORWARD chain policy, and executing the iptables-P OUTPUT ACCEPT command to configure the OUTPUT chain policy.

[0013] Further, the specific operation of allowing inbound traffic related to established connections is: executing the iptables-A INPUT-m state--state ESTABLISHED, RELATED-j ACCEPT command to ensure normal data interaction between the backend and the reverse proxy server.

[0014] Further, the specific operation of allowing local loopback interface traffic is: executing the iptables-A INPUT-i lo-j ACCEPT command to ensure the normal communication of internal server processes such as log processes and monitoring processes.

[0015] Further, the specific operation of allowing only the preset reverse proxy server to access the preset WS port is: executing the iptables-A INPUT-p tcp-s preset reverse proxy server IP--dport preset WS port-j ACCEPT command, wherein "preset reverse proxy server IP" is the intranet IP of the reverse proxy server, and "preset WS port" is the business listening port of the backend application server.

[0016] Further, the implementation logic of unauthorized traffic interception is: through the default "drop" policy of the INPUT chain, the inbound packets that do not match any pass rules (including client directly accessing the backend port SYN request) are silently discarded, and no identification information of any port is returned.

[0017] Further, the double isolation strategy specifically refers to: the first layer is guided to the proxy layer by the public network port forwarding restriction of the reverse proxy server; the second layer is only allowed to access the business port by the internal network IP of the proxy server through the iptables rule of the backend server, and the two layers of isolation form complementation, so that even if the proxy layer is configured incorrectly, the backend port cannot be directly accessed by the public network.

[0018] Further, the method further comprises a rule validity verification step: testing unauthorized port access from the public network environment (should be timed out or rejected), and testing backend port access after simulating proxy configuration error (should be no response) to verify the validity of the isolation strategy.

[0019] The WSS-based reverse proxy configuration method provided by the application solves the technical problem of exposing the backend service port caused by proxy configuration error in the WSS reverse proxy scenario.

[0020] In order to make the above-mentioned purposes, characteristics and advantages of the application more obvious and easy to understand, the following preferred embodiments are described in detail below, and the accompanying drawings are described as follows. DETAILED DESCRIPTION

[0021] Figure 1 : Method step diagram of the WSS-based reverse proxy configuration method of the application;

[0022] Figure 2 : Flowchart of blocking illegal connection when proxy error of the WSS-based reverse proxy configuration method of the application;

[0023] Figure 3 : Network architecture and firewall rule schematic diagram of the WSS-based reverse proxy configuration method of the application;

[0024] Figure 4 : Flowchart of routing penetration when proxy error of the WSS-based reverse proxy configuration method of the application. DETAILED DESCRIPTION

[0025] The technical solutions in the embodiments of the application will be described below with reference to the accompanying drawings in the embodiments of the application.

[0026] A WSS-based reverse proxy configuration method (see Figure 1 ), and the following are detailed implementation steps of the public network service end opening port of the application:

[0027] This step focuses on the open configuration of the reverse proxy server (taking Nginx as an example) as the public network service end, covering the whole process of IP and port planning, proxy service deployment, firewall fine rule configuration, rule verification and persistence, to ensure that the public network service is compliant and has security protection capability.

[0028] S1. Public network server basic environment planning and confirmation, configure public IP address allocation and binding;

[0029] S1.1 Obtain a legal and stable public IP address from an Internet Service Provider (ISP), in this embodiment set as `203.0.113.10`. The IP must have independent routing capability and not be listed in the public black list or have access restrictions.

[0030] S1.2 In the operating system of the reverse proxy server (such as CentOS, Ubuntu, etc.), bind the public IP address to the server's public network card (usually named `eth0` or `enp0s3`) through network configuration tools (such as `nmcli`, `ifconfig`, or graphical network manager). The specific operation is as follows:

[0031] S1.3 Edit the network card configuration file. For example, execute the `vim / etc / sysconfig / network-scripts / ifcfg-eth0` command to open the configuration file on the CentOS system.

[0032] S1.4 Set the static IP parameters in the configuration file, add or modify the following content:

[0033] BOOTPROTO=static # Static IP mode, avoid IP dynamic change leading to service unavailable

[0034] IPADDR=203.0.113.10 # Bound public IP address

[0035] NETMASK=255.255.255.0 # Subnet mask, fill in according to public IP network segment planning

[0036] GATEWAY=203.0.113.1 # Public gateway address, provided by ISP

[0037] DNS1=8.8.8.8 # Primary DNS server, ensure domain name resolution normal

[0038] DNS2=114.114.114.114 # Backup DNS server, improve resolution reliability

[0039] ONBOOT=yes # Server automatically enables the network card when booting

[0040] S1.5 Save the configuration file and restart the network service by executing the command `systemctl restart network` (CentOS 7) or `nmcli connection reload` (CentOS 8 and above) to make the public IP configuration take effect.

[0041] S1.6 Verify the public IP binding result by executing the command `curl ifconfig.me` or `wget-qO-ifconfig.me`. If the returned result is `203.0.113.10`, it confirms that the public IP has been successfully bound and can access the public network normally.

[0042] S1.7 Public Network Service Port Planning and Confirmation

[0043] S1.8 Based on business requirements and security specifications, determine the public network service ports that need to be opened. In this embodiment, the ports that need to be opened include:

[0044] -SSH management port: `22`, used for remote login to the server for operation and maintenance. Access sources need to be restricted to reduce risks.

[0045] - HTTPS port: `443`, used to handle encrypted communication based on HTTP. It needs to be open if the business includes access to web pages.

[0046] -WSS port: `10338`, used to carry real-time communication requests of the WebSocket Secure protocol, is the core business port.

[0047] S1.9 Check if the planned port is occupied by executing the command `netstat -tuln|grep port number` (e.g., `netstat -tuln|grep 10338`). If no results are returned, it means the port is not occupied. If the port is occupied, you need to stop the process occupying the port (execute `kill -9 process ID`) or re-plan an unoccupied port to avoid port conflicts that may cause service startup failure.

[0048] S2 and Nginx proxy service deployment and public network port listening configuration

[0049] S2.1 Install Nginx dependency packages, ensuring no dependencies are missing during compilation or installation. Execute the following commands:

[0050] -CentOS system: `yum install-y gcc gcc-c++ pcre pcre-devel zlib zlib-devel openssl-devel`, where `openssl-devel` is used to support TLS encryption (WSS protocol dependency);

[0051] -Ubuntu system: `apt-get install-y gcc g++ libpcre3 libpcre3-dev zlib1g zlib1g-dev libssl-dev`.

[0052] S2.2 Install Nginx, you can choose to install through official source (recommended, easy for subsequent updates) or compile from source:

[0053] S2.3 Official source installation (take CentOS as an example):

[0054] - Install Nginx official source, execute `rpm-Uvh http: / / nginx.org / packages / centos / 7 / noarch / RPMS / nginx-release-centos-7-0.el7.ngx.noarch.rpm`;

[0055] - Install Nginx, execute `yum install-y nginx`;

[0056] - Start Nginx service and set up self-start at boot, execute `systemctl start nginx` and `systemctlenable nginx`;

[0057] - Verify Nginx installation results, execute `nginx-v`, if it returns Nginx version information (such as `nginx / 1.24.0`), it means the installation is successful.

[0058] S2.4 Compile from source (suitable for scenarios that require custom configuration):

[0059] - Download Nginx source package, execute `wget http: / / nginx.org / download / nginx-1.24.0.tar.gz` (version can be selected according to requirements);

[0060] - Unzip the source package, execute `tar-zxvf nginx-1.24.0.tar.gz` and enter the decompressed directory `cd nginx-1.24.0`;

[0061] - Configure the compilation parameters, focus on enabling the TLS module, execute:

[0062] . / configure --prefix= / usr / local / nginx\

[0063] --with-http_ssl_module\# Enable SSL module, support HTTPS / WSS

[0064] --with-stream\# Enable stream processing module, facilitate subsequent port forwarding configuration

[0065] --with-http_stub_status_module# Enable status monitoring module, facilitate service operation and maintenance

[0066] - Compile and install, execute `make&&make install`;

[0067] - Create Nginx system service, execute `vim / usr / lib / systemd / system / nginx.service` and add the following content:

[0068] [Unit]

[0069] Description=Nginx Proxy Server

[0070] After=network.target

[0071] [Service]

[0072] Type=forking

[0073] ExecStart= / usr / local / nginx / sbin / nginx

[0074] ExecReload= / usr / local / nginx / sbin / nginx-s reload

[0075] ExecStop= / usr / local / nginx / sbin / nginx-s stop

[0076] PrivateTmp=true

[0077] [Install]

[0078] WantedBy=multi-user.target

[0079] - Start and set up the boot self-start, execute `systemctl daemon-reload`, `systemctl start nginx` and `systemctl enable nginx`.

[0080] S3, Nginx public port listening and WSS proxy configuration

[0081] S3.1 Edit the Nginx main configuration file or create a separate WSS proxy configuration file, for example, in a separate configuration file (for easy management):

[0082] S3.2 In the Nginx configuration directory (such as ` / etc / nginx / conf.d / ` for official source installation) or ` / usr / local / nginx / conf / conf.d / ` (for source code compilation installation), create a `wss-proxy.conf` configuration file, execute `vim / etc / nginx / conf.d / wss-proxy.conf`;

[0083] S3.3 Add public port listening and WSS proxy rules in the configuration file, as follows:

[0084]

[0085]

[0086]

[0087] S3.4 Verify the correctness of the Nginx configuration file syntax, execute `nginx-t`, if the return is `nginx:configuration file / etc / nginx / nginx.conf test is successful`, then confirm that the configuration has no syntax error; if there is an error, modify the configuration file according to the prompt until it is verified.

[0088] S3.5 Reload Nginx configuration to make public port listening and proxy rules effective, execute `systemctl reload nginx` (official source installation) or ` / usr / local / nginx / sbin / nginx-s reload` (source code compilation installation);

[0089] S3.6 Verify the Nginx public port listening state, execute `ss-tuln|grep-E'22|443|10338'`, if the return is similar to the following result, it means that the port has been successfully listened:

[0090]

[0091] S4. Fine-tuning public network server firewall rules

[0092] This step is based on the `iptables` firewall tool (default in Linux systems), which configures the inbound and outbound rules of the public network server based on the principle of "default deny + on-demand open", to achieve secure opening and access control of public network ports.

[0093] S4.1 Clear existing firewall rules to avoid conflicts with old rules, execute the following instructions:

[0094] iptables -F # Clear all chain rules

[0095] iptables -X # Delete all custom chains

[0096] iptables -Z # Reset all chain counters

[0097] S4.2 Configure firewall default policy, set the basic policy of "inbound default deny, forwarding default deny, outbound temporary allow", execute:

[0098] iptables -P INPUT DROP # Inbound traffic default deny, only open explicitly allowed ports and IPs

[0099] iptables -P FORWARD DROP # Forwarding traffic default deny, prevent server from being abused as a route

[0100] iptables -P OUTPUT ACCEPT # Outbound traffic temporarily allowed, then fine-tune restrictions later

[0101] S4.3 Allow established connections and associated inbound traffic to ensure the continuity of normal communication, execute:

[0102] iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

[0103] Note: `ESTABLISHED` indicates an established connection (such as client access to public network port, server returns data to client traffic), `RELATED` indicates related traffic to established connection (such as FTP passive mode connection), this rule is the basis for ensuring normal operation of services.

[0104] S4.4 Allow loopback interface traffic to avoid server internal process communication anomalies (such as Nginx and local log process communication), execute:

[0105] iptables -A INPUT -i lo -j ACCEPT

[0106] Note: `lo` is the loopback interface (IP `127.0.0.1`), only used for internal server communication, opening this interface has no security risk.

[0107] S4.5 Open SSH (port 22) and limit access source (key security measure, avoid brute force):

[0108] S4.6 If the operation and maintenance personnel have a fixed public IP (such as `192.168.0.100`, replace it with the actual operation and maintenance IP), only allow this IP to access port 22, execute:

[0109] iptables -A INPUT -p tcp -s 192.168.0.100 --dport 22 -j ACCEPT

[0110] S4.7 If the operation and maintenance personnel have no fixed IP, you need to allow any IP to access port 22, it is recommended to combine `fail2ban` and other tools to prevent brute force, only execute:

[0111] iptables -A INPUT -p tcp --dport 22 -j ACCEPT

[0112] S4.8 Open HTTPS (port 443), allow client access to HTTPS-based Web service, execute:

[0113] iptables -A INPUT -p tcp --dport 443 -j ACCEPT

[0114] S4.9 Open WSS (port 10338), allow client to initiate WSS connection request, execute:

[0115] iptables -A INPUT -p tcp --dport 10338 -j ACCEPT

[0116] S4.10 Outbound rule configuration: limit the outbound connection range of public service server

[0117] S4.11 Only allow public service server to initiate outbound connection to backend application server (internal IP `192.168.1.20`, port `12006`), ensure that proxy request is only forwarded to legal backend, execute:

[0118] iptables -A OUTPUT -p tcp -d 192.168.1.20 --dport 12006 -j ACCEPT

[0119] iptables -A OUTPUT -p udp --dport 53 -j ACCEPT # DNS UDP protocol (mainly)

[0120] iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT # DNS TCP protocol (for large size DNS response)

[0121] S4.13 Allow public service server to access necessary operation and maintenance resources (such as yum / apt source for software update; optional, configure according to actual needs), execute:

[0122] iptables -A OUTPUT -p tcp -d mirrors.aliyun.com --dport 80 -j ACCEPT iptables -A OUTPUT -p tcp -d mirrors.aliyun.com --dport 443 -j ACCEPT

[0123] S4.14 Configure the default rejection of the outbound rule to prohibit the public service server from initiating a connection to the address that is not explicitly allowed, execute:

[0124] iptables -A OUTPUT -j DROP

[0125] S5, backend application server configuration

[0126] This embodiment is used to configure the backend application server to achieve specific network access control.

[0127] S5.1: Set the internal IP of the backend application server to 192.168.1.20, and set its listening port to 12006 (WS); configure the firewall rules of the server, and use the iptables tool to execute the following operations:

[0128] S5.1.1: Input iptables -F command, clear all existing rules of iptables.

[0129] S5.1.2: Input iptables -P INPUT DROP command to set the default policy of the INPUT chain to drop.

[0130] S5.1.3: Input iptables -P FORWARD DROP command to set the default policy of the FORWARD chain to drop.

[0131] S5.1.4: Input iptables -P OUTPUT ACCEPT command to set the default policy of the OUTPUT chain to accept.

[0132] S5.1.5: Input iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT command to allow inbound traffic related to established connections.

[0133] S5.1.6: Input iptables -A INPUT -i lo -j ACCEPT command to allow inbound traffic from the local loopback interface.

[0134] S5.1.7: Input iptables -A INPUT -p tcp -s 192.168.1.10 --dport 12006 -j ACCEPT command (assuming the Nginx internal IP is 192.168.1.10) to allow only traffic from the reverse proxy server (IP 192.168.1.10) to access port 12006.

[0135] The implementation effect of the above configuration is shown in the flowchart of blocking illegal connections when the proxy server makes a mistake. Figure 2

[0136] S5, Public service server open validity and security verification

[0137] S5.1 Use `telnet` or `nc` tool to test port connectivity from public network environment (such as local computer through 4G / 5G network, avoid being in the same internal network with the server):

[0138] - Test port 22: `telnet 203.0.113.10 22` or `nc -zv 203.0.113.10 22`, if it returns `Connected to 203.0.113.10` (telnet) or `succeeded!` (nc), then confirm that port 22 is accessible;

[0139] - Test port 443: `nc -zv 203.0.113.10 443`, if it returns success information, it means that port 443 is accessible;​

[0140] - Test port 10338: `nc -zv 203.0.113.10 10338`, if it returns success information, it means that port 10338 is accessible.

[0141] S5.2 Test WSS service availability, use WebSocket client tools (such as `wscat`) to initiate WSS connection, execute `wscat -c wss: / / 203.0.113.10:10338`, if the connection is successful and can interact with the backend service normally, it means that the WSS service has been normally opened through the public network.

[0142] S5.3 Test access restriction of unopened ports, select an unopened port (such as `8080`), execute `nc -zv 203.0.113.10 8080`, if it returns `Connection refused` or times out without response, it means that the default deny rule of firewall is effective;

[0143] S5.4 Test outbound rule restriction, execute `ping 8.8.8.8` (test ICMP outbound, default not allowed) or `curl https: / / www.baidu.com` (test HTTPS outbound, not allowed in rules) on the public network service side, if both cannot access, it means that the outbound default deny rule is effective; execute `curl http: / / 192.168.1.20:12006`, if it can access the backend service, it means that the specific outbound rule is effective.

[0144] S5.5 Simulate Nginx proxy configuration error (such as changing `proxy_pass` to an incorrect address `http: / / 192.168.1.21:12006`), reload Nginx configuration (`systemctl reload nginx`).

[0145] S5.6 Initiate WSS connection from public network client, observe the client response, should receive `502 Bad Gateway` error, and the error information does not contain the real IP and port of the backend service;

[0146] S5.7 Try to initiate TCP connection (such as `nc -zv 192.168.1.20 12006`) from the public network client to the backend service port (`192.168.1.20:12006`), make sure that the client can access the internal network, which can be simulated by building a test environment), if the connection times out without response, it means that the backend firewall has blocked access from non-proxy sources, and the security of public network service side opening configuration is verified.

[0147] S6. Firewall rule persistence configuration

[0148] To avoid the loss of firewall rules after server restart, you need to persistently save the configured `iptables` rules:

[0149] For CentOS system:

[0150] S6.1 Install the `iptables-services` tool by executing `yum install -y iptables-services`;

[0151] S6.2 Save the current firewall rules by executing `service iptables save`, the rules will be saved to the ` / etc / sysconfig / iptables` file;

[0152] S6.3 Start the `iptables` service and set it to start automatically at boot by executing `systemctl start iptables` and `systemctl enable iptables`.

[0153] For Ubuntu system:

[0154] S6.4 Install the `iptables-persistent` tool by executing `apt-get install -y iptables-persistent`;

[0155] S6.5 Save the current firewall rules by executing `netfilter-persistent save`, the rules will be saved to the ` / etc / iptables / rules.v4` (IPv4) and ` / etc / iptables / rules.v6` (IPv6) files;

[0156] S6.6 Enable the `netfilter-persistent` service and set it to start automatically at boot by executing `systemctl start netfilter-persistent` and `systemctl enable netfilter-persistent`.

[0157] S6.7. Verify the rule persistence effect: execute `reboot` to restart the server, and after restarting, execute `iptables -L -n`, if the displayed rules are consistent with the previous configuration, it means that the rules have been successfully persisted.

[0158] The application provides a WSS-based reverse proxy configuration method, and solves the technical problem of exposure of a backend service port caused by proxy configuration errors in a WSS reverse proxy scenario.

[0159] The above merely illustrates the embodiments of the present application and is not used to limit the protection scope of the present application, and the present application can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A WSS-based reverse proxy configuration method, characterized in that, This document addresses the technical issue of backend service ports being exposed due to incorrect proxy configuration in WSS reverse proxy scenarios, and includes the following steps: S1: Basic network parameter configuration: Fix the internal IP of the backend application server to the preset internal address, and set the server's business listening port to the preset WS port that matches the forwarding rules of the reverse proxy server, so as to ensure that the backend service only receives proxy forwarding requests through the internal network. S2: Fine-grained firewall rule configuration: Using the iptables tool to build layered access control rules, specifically including: S2.

1. Perform a rule clearing operation, deleting all existing rules in iptables. Avoid conflicts with old rules; S2.

2. Set the default policy for the chains: configure the default policy of the INPUT chain and FORWARD chain to "discard", and keep only the default policy of the OUTPUT chain as "accept", thus building the foundation for least privilege access; S2.

3. Configure necessary traffic allowance rules: allow inbound traffic related to established connections, including ESTABLISHED, RELATED status and local loopback interface lo traffic, while only allowing the internal network IP of the preset reverse proxy server to access the preset WS port via TCP protocol; S2.

4. Execute unauthorized traffic interception: Reject and discard all inbound requests not permitted by the above rules, including SYN connection requests directly initiated by the client, to achieve physical isolation between the backend service and the public network.

2. The WSS-based reverse proxy configuration method according to claim 1, characterized in that, The rule clearing operation specifically involves executing the iptables -F command to completely clear the existing rules in the INPUT, OUTPUT, and FORWARD chains of iptables.

3. The WSS-based reverse proxy configuration method according to claim 1, characterized in that, The specific operations for setting the default chain policy include: executing the iptables-PINPUT DROP command to configure the INPUT chain policy, executing the iptables-PFORWARD DROP command to configure the FORWARD chain policy, and executing the iptables-P OUTPUT ACCEPT command to configure the OUTPUT chain policy.

4. The WSS-based reverse proxy configuration method according to claim 1, characterized in that, The specific operation to allow inbound traffic related to established connections is to execute the command iptables -A INPUT -m state --stateESTABLISHED,RELATED -jACCEPT to ensure normal data exchange between the backend and the reverse proxy server that have established connections.

5. The WSS-based reverse proxy configuration method according to claim 1, characterized in that, The specific operation to allow local loopback interface traffic is to execute the iptables-AINPUT-i lo-j ACCEPT command to ensure normal communication of internal server processes (such as logging processes and monitoring processes).

6. The WSS-based reverse proxy configuration method according to claim 1, characterized in that, The specific operation to allow only the preset reverse proxy server to access the preset WS port is as follows: execute the command iptables -A INPUT -p tcp -s preset reverse proxy server IP --dport preset WS port -j ACCEPT, where "preset reverse proxy server IP" is the internal network IP of the reverse proxy server and "preset WS port" is the business listening port of the backend application server.

7. The WSS-based reverse proxy configuration method according to claim 1, characterized in that, The implementation logic for unauthorized traffic interception is as follows: by using the default "drop" policy of the INPUT chain, inbound data packets (including SYN requests from clients directly accessing backend ports) that do not match any allow rules are silently dropped, and no port existence information is returned.

8. The WSS-based reverse proxy configuration method according to claim 1, characterized in that, The dual isolation strategy specifically refers to: the first layer restricts the forwarding of public network ports by the reverse proxy server, and centrally directs public network requests to the proxy layer; the second layer uses iptables rules on the backend server to only allow the internal network IP of the proxy server to access the business port. The two layers of isolation complement each other, so even if the proxy layer is misconfigured, the backend port cannot be directly accessed by the public network.

9. The WSS-based reverse proxy configuration method according to claim 1, characterized in that, The method also includes a rule validity verification step: testing unauthorized port access from a public network environment (which should time out or be rejected) and testing backend port access after simulating a proxy configuration error (which should not respond) to verify the effectiveness of the isolation policy.

Images