Firewall

Why can't I connect even when a port is opened on the firewall?

Please confirm the following 2 points: (1) The firewall rule has been applied to the host (2) The iptables inside the host has been closed. Whether the port is open can be checked with the nc command, for example, nc -nv 10.3.1.2 22. If the port is open but the service is not available, please check whether the service is running normally.

Another situation preventing access could be that the ISP actively blocks certain ports due to high-risk ports, for example, the 445 port. At present, the list of port blockages reported by the ISP is as follows:

TCP: 42,135,137,138,139,445,593,1025,1068,1434,3127,3130,3332,4444,5554,6669,9996,12345,31337,54321

UDP: 135,445,593,1026,1027,1068,1434,4444,5554,9996

Why can't the host be pinged?

Please confirm the following two points: (1) The firewall rule allows icmp and is applied to the host (2) The iptables inside the host has been closed

How to open a certain port for all IPs?

Source IP wrote: 0.0.0.0/0

How to restrict some malicious users from accessing my host?

If the malicious user's access IP can be obtained, a blocking (Drop) rule containing that source IP can be added to the host firewall

Does the intranet have ACL functionality?

Yes, network ACL can realize subnet-level security isolation.

How can my intranet host be isolated from other people's hosts?

SurferCloud's intranet utilizes Software Defined Network (SDN) techology for network isolation between different users' hosts

Will the new rules take effect immediately after modifying the firewall?

Users sometimes encounter issues where the rules don't take effect after modification when using the firewall. This is caused by lengthy TCP connections.

Normally, firewall rules are immediately effective. But in certain scenarios, the firewall rule does not take effect immediately.

Taking Nginx as an example, Nginx will send a FIN packet after triggering keepalive_timeout (default is 65 seconds), making nf_conntrack_tcp_timeout_established ineffective, and triggering nf_conntrack_tcp_timeout_time_wait rule, whose default rule is 120 seconds.

In this situation, it can take up to two minutes for the firewall to take effect.

For long-lasting connection scenarios similar to MySQL, since the system kernel and parameter setting of nf_conntrack_tcp_timeout_established defaults the expiry time to 5 days, once the connection is established, it is very difficult to immediately block the connection by modifying the firewall settings.

Remedial measures for firewall not taking immediate effect:

As mentioned in the MySQL scenario above, its port is 3306. Suppose we need to block connections from 1.2.3.4, we can process it in the cloud host using the "RAW" table of iptables.

iptables -t raw -I PREROUTING -s 1.2.3.4 -p tcp -m tcp --dport 3306 -j DROP

This method works because in the Linux system's Netfilter, a RAW table with a higher priority was inserted before the conntrack of PREROUTING and OUTPUT hooks. Through RAW table, traffic that does not need to be conntracked can be separated.

What will happen to previously established connections after modifying the firewall?

The firewall will not block established connections, so these connections are not affected by the firewall

Possible reasons for firewall rule alteration failure:

Please check if there are duplicate firewall rules, if the protocol, port, source address, and action are repeated, then it is considered as rule duplication. If there are duplicate rules, you need to simultaneously delete all duplicate rules and resend the request.