Centos 7 firewall cmd open port. Setting up interface zones


The Firewall installed in the operating system is used to prevent unauthorized traffic from passing between computer networks. Special rules for the firewall are created manually or automatically, which are responsible for access control. An OS developed on the Linux kernel, CentOS 7 has a built-in firewall, and it is managed using a firewall. FirewallD is enabled by default, and we would like to talk about setting it up today.

As mentioned above, the standard firewall in CentOS 7 is the FirewallD utility. That is why setting up a firewall will be discussed using this tool as an example. You can set filtering rules using the same iptables, but this is done in a slightly different way. We recommend that you familiarize yourself with the configuration of the mentioned utility by clicking on the following link, and we will begin analyzing FirewallD.

Firewall Basics

There are several zones - sets of rules for managing traffic based on trust in networks. All of them are given their own policies, the totality of which forms the firewall configuration. Each zone is assigned one or more network interfaces, which also allows you to adjust filtering. The applied rules directly depend on the interface used. For example, when connecting to public Wi-Fi, a firewall will increase the level of control, and on a home network it will provide additional access for participants in the chain. The firewall in question contains the following zones:

  • trusted — maximum level of trust in all network devices;
  • home - local network group. There is trust in the environment, but incoming connections are only available to certain machines;
  • work - work area. There is trust in most devices, and additional services are activated;
  • dmz is a zone for isolated computers. Such devices are disconnected from the rest of the network and allow only certain incoming traffic;
  • internal — zone of internal networks. Trust is applied to all machines, additional services are opened;
  • external — zone reverse to the previous one. In external networks, NAT masquerading is active, closing the internal network, but not blocking the ability to gain access;
  • public - a zone of public networks with distrust of all devices and individual reception of incoming traffic;
  • block - all incoming requests are reset with an error sent icmp-host-prohibited or icmp6-adm-prohibited;
  • drop - minimum trust level. Incoming connections are dropped without any notification.

The policies themselves can be temporary or permanent. When parameters appear or edit, the firewall action immediately changes without the need to reboot. If temporary rules were applied, they will be reset after FirewallD is restarted. The permanent rule is called that way - it will be saved permanently when the -permanent argument is applied.

Enabling FirewallD

First you need to start FirewallD or make sure that it is in an active state. Only a running daemon (a program that runs in the background) will apply firewall rules. Activation is done in just a few clicks:

  1. Launch classic "Terminal" any convenient method, for example, through the menu "Applications".
  2. Enter the command sudo systemctl start firewalld.service and press the key Enter.
  3. The utility is managed on behalf of the superuser, so you will have to confirm your authenticity by entering a password.
  4. To make sure the service is functioning, specify firewall-cmd --state .
  5. In the graphical window that opens, re-confirm your authenticity.
  6. A new line will be displayed. Meaning "running" indicates that the firewall is working.

If you ever need to temporarily or permanently disable the firewall, we recommend using the instructions presented in our other article at the following link.

View default rules and available zones

Even a firewall operating normally has its own specific rules and accessible zones. Before you start editing policies, we recommend that you familiarize yourself with the current configuration. This is done using simple commands:

  1. The firewall-cmd --get-default-zone command will help you determine the default zone.
  2. After activating it, you will see a new line where the required parameter will be displayed. For example, in the screenshot below, the zone is considered active "public".
  3. However, several zones can be active at once, and they are associated with a separate interface. Find out this information via firewall-cmd --get-active-zones .
  4. The firewall-cmd --list-all command will display the rules configured for the default zone. Take a look at the screenshot below. You see that the active zone "public" rule assigned "default"- default operation, interface "enp0s3" and two services were added.
  5. If you want to find out all the available firewall zones, enter firewall-cmd --get-zones .
  6. The parameters of a specific zone are determined via firewall-cmd --zone=name --list-all , where name— zone name.

After determining the necessary parameters, you can proceed to changing and adding them. Let's take a closer look at a few of the most popular configurations.

Setting up interface zones

As you know from the information above, each interface has its own default zone. It will remain there until the settings are changed by the user or programmatically. It is possible to manually transfer an interface to a zone for one session, and this is done by activating the command sudo firewall-cmd --zone=home --change-interface=eth0 . Result "success" indicates that the transfer was successful. Let us remind you that such settings are reset immediately after the firewall is rebooted.

When changing parameters like this, you should take into account that the services may be reset. Some of them do not support operation in certain zones, for example, although SSH is available in "home", but in custom or special ones the service will refuse to work. You can verify that the interface has been successfully linked to the new branch by entering firewall-cmd --get-active-zones .

If you want to reset your previously made settings, simply restart the firewall: sudo systemctl restart firewalld.service .

Sometimes it is not always convenient to change the interface zone for just one session. In this case, you will need to edit the configuration file so that all settings are entered on a permanent basis. To do this, we recommend using a text editor nano, which is installed from the official repository with sudo yum install nano . Next, all that remains is to do the following:

  1. Open the configuration file through an editor by typing sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0 , where eth0— the name of the required interface.
  2. Confirm your account authenticity to proceed further.
  3. Find the parameter "ZONE" and change its value to the desired one, for example, public or home .
  4. Hold down the keys Ctrl+O to save changes.
  5. Don't change the file name, just click on Enter.
  6. Exit the text editor via Ctrl+X.

Now the interface zone will be as you specified it until the next time you edit the configuration file. To make the updated settings take effect, run sudo systemctl restart network.service and sudo systemctl restart firewalld.service .

Setting the default zone

Above, we already demonstrated a command that allowed us to find out the default zone. It can also be changed by setting a parameter of your choice. To do this, just type sudo firewall-cmd --set-default-zone=name in the console, where name— name of the required zone.

The success of the command will be indicated by the inscription "success" on a separate line. After this, all current interfaces will be bound to the specified zone, unless otherwise specified in the configuration files.

Creating rules for programs and utilities

At the very beginning of the article, we talked about the action of each zone. Defining services, utilities and programs in such branches will allow you to apply individual parameters for each of them to suit the needs of each user. First, we recommend that you familiarize yourself with the full list of currently available services: firewall-cmd --get-services .

The result will be displayed directly in the console. Each server is separated by a space, and you can easily find the tool you are interested in in the list. If the required service is not available, it should be additionally installed. Read about installation rules in the official software documentation.

The above command shows only the service names. Detailed information for each of them is obtained through an individual file located along the path /usr/lib/firewalld/services. Such documents are in XML format, the path, for example, to SSH looks like this: /usr/lib/firewalld/services/ssh.xml, and the document has the following content:

SSH
Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.

Service support in a specific zone is activated manually. IN "Terminal" you should issue the command sudo firewall-cmd --zone=public --add-service=http , where --zone=public- zone for activation, and --add-service=http— name of the service. Please note that such a change will only apply to one session.

Permanent addition is done via sudo firewall-cmd --zone=public --permanent --add-service=http , and the result "success" indicates the successful completion of the operation.

You can view the full list of permanent rules for a specific zone by displaying the list in a separate console line: sudo firewall-cmd --zone=public --permanent --list-services .

Solving the problem of lack of access to the service

By default, the firewall rules indicate the most popular and secure services as allowed, but it blocks some standard or third-party applications. In this case, the user will need to manually change the settings to resolve the access problem. This can be done in two different ways.

Port forwarding

As you know, all network services use a specific port. It is easily detected by the firewall, and blocking can be carried out using it. To avoid such actions from the firewall, you need to open the required port with the command sudo firewall-cmd --zone=public --add-port=0000/tcp , where --zone=public- port area, --add-port=0000/tcp— port number and protocol. The firewall-cmd --list-ports option will display a list of open ports.

If you need to open ports included in the range, use the line sudo firewall-cmd --zone=public --add-port=0000-9999/udp , where --add-port=0000-9999/udp— range of ports and their protocol.

The above commands will only allow you to test the use of such parameters. If it was successful, you should add the same ports to the permanent settings, and this is done by entering sudo firewall-cmd --zone=public --permanent --add-port=0000/tcp or sudo firewall-cmd --zone=public --permanent --add-port=0000-9999/udp . The list of open permanent ports is viewed like this: sudo firewall-cmd --zone=public --permanent --list-ports .

Service Definition

As you can see, adding ports does not cause any difficulties, but the procedure becomes more complicated when a large number of applications are used. It becomes difficult to track all the ports in use, so a better option would be to define the service:


All you have to do is choose the most appropriate method for solving problems with access to the service and follow the instructions provided. As you can see, all actions are performed quite easily, and no difficulties should arise.

Creating custom zones

You already know that FirewallD initially created a large number of different zones with certain rules. However, there are situations when the system administrator needs to create a user zone, such as "publicweb" for an installed web server or "privateDNS"— for the DNS server. Using these two examples, we will look at adding branches:


In this article, you learned how to create custom zones and add services to them. We have already talked about setting them by default and assigning interfaces above; all you have to do is indicate the correct names. Remember to reboot your firewall after making any permanent changes.

As you can see, the FirewallD firewall is a fairly comprehensive tool that allows you to create the most flexible firewall configuration. All that remains is to make sure that the utility starts with the system and the specified rules immediately begin their work. Do this with the command sudo systemctl enable firewalld.

FirewallD is a firewall management tool available by default on CentOS 7 servers. It is basically a wrapper around IPTables and comes with a graphical configuration tool, firewall-config, and a command line tool, firewall-cmd. With the IPtables service, every change requires deleting old rules and creating new rules in the file ` /etc/sysconfig/iptables`, and with firewalld only the differences are applied.

FirewallD zones

FirewallD uses services and zones instead of rules and chains in Iptables. By default, the following zones are available:

  • drop– Drop all incoming network packets without response, only outgoing network connections are available.
  • block– Reject all incoming network packets with the message icmp-host-prohibited, only outgoing network connections are allowed.
  • public– only selected incoming connections are accepted, for use in public areas
  • external– For external networks with masquerading, only selected incoming connections are accepted.
  • dmz– demilitarized zone DMZ, publicly accessible with limited access to the internal network, only selected incoming connections are accepted.
  • work
  • home– For computers in the home zone, only selected incoming connections are accepted.
  • internal– For computers on your internal network, only selected incoming connections are accepted.
  • trusted– All network connections are accepted.

To get a list of all available zones:

# firewall-cmd --get-zones work drop internal external trusted home dmz public block

To view a list of default zones:

# firewall-cmd --get-default-zone public

To change the default zone:

Firewall Services

FirewallD services are XML configuration files containing service entry information for firewalld. To get a list of all available services:

# firewall-cmd --get-services amanda-client amanda-k5-client bacula bacula-client ceph ceph-mon dhcp dhcpv6 dhcpv6-client dns docker-registry dropbox-lansync freeipa-ldap freeipa-ldaps freeipa-replication ftp high-availability http https imap imaps ipp ipp-client ipsec iscsi-target kadmin kerberos kpasswd ldap ldaps libvirt libvirt-tls mdns mosh mountd ms-wbt mysql nfs ntp openvpn pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy proxy-dhcp ptp pulseaudio puppetmaster radius rpc-bind rsyncd samba samba-client sane smtp smtps snmp snmptrap squid ssh synergy syslog syslog-tls telnet tftp tftp-client tinc tor-socks transmission-client vdsm vnc-server wbem-https xmpp-bosh xmpp-client xmpp-local xmpp-server

XML configuration files are stored in directories /usr/lib/firewalld/services/ And /etc/firewalld/services/.

Setting up a firewall with FirewallD

As an example, here's how you can configure a firewall with FirewallD if you're running a web server, SSH on port 7022, and a mail server.

First we will set the default zone for DMZ.

# firewall-cmd --set-default-zone=dmz # firewall-cmd --get-default-zone dmz

To add persistent service rules for HTTP and HTTPS in the DMZ, run the following command:

# firewall-cmd --zone=dmz --add-service=http --permanent # firewall-cmd --zone=dmz --add-service=https --permanent

Open port 25 (SMTP) and port 465 (SMTPS):

Firewall-cmd --zone=dmz --add-service=smtp --permanent firewall-cmd --zone=dmz --add-service=smtps --permanent

Open, IMAP, IMAPS, POP3 and POP3S ports:

Firewall-cmd --zone=dmz --add-service=imap --permanent firewall-cmd --zone=dmz --add-service=imaps --permanent firewall-cmd --zone=dmz --add-service= pop3 --permanent firewall-cmd --zone=dmz --add-service=pop3s --permanent

Since the SSH port is changed to 7022, we will remove the SSH service (port 22) and open port 7022

Firewall-cmd --remove-service=ssh --permanent firewall-cmd --add-port=7022/tcp --permanent

To implement the changes we need to restart the firewall:

Firewall-cmd --reload

Finally, you can list the rules.

Centos 7, unlike CentOS 6, comes with a new firewall in the database - firewalld. It can be disabled and replaced with the good old iptables, but if there are no direct prerequisites for this, then it is better to get used to something new rather than rely on the old. This does not mean that Windows 10 is better than Windows 7, and Windows XP is better than Windows 7 ;) A good example on this topic is selinux. If at first almost everyone (including me) turned it off and even scolded it a little, now almost no one advises it, only if they are sure that it is necessary. On the contrary, many are already accustomed (or are getting used to) using semanage. We won’t immediately disable firewalld, but let’s try how it tastes.

Firewalld is not a fundamentally different firewall. This is another add-on to netfilter, so if you have experience with iptables, then after a little trouble you can easily start using the new tool.

Starting and stopping firewalld

Let's check if firewalld is running:

# systemctl status firewalld

There will be more information here. To briefly say yes (it works) or no, you can do this:

# firewall-cmd --state
running

Ok, it works.

Stopping firewalld:

# systemctl stop firewalld

Auto start prohibition:

# systemctl disable firewalld

Start firewalld:

# systemctl start firewalld

Enabling autostart:

# systemctl enable firewalld

Firewalld zones

Firewalld makes extensive use of the concept of a zone. List of all valid zones by default:

# firewall-cmd --get-zones
block dmz drop external home internal public trusted work

Purpose of zones (conditionally, of course):

  • drop - all incoming packets are discarded (drop) without response. Only outgoing connections are allowed.
  • block - incoming connections are rejected (rejected) with the response icmp-host-prohibited (or icmp6-adm-prohibited). Only system-initiated connections are allowed.
  • public - default zone. From the name it is clear that this zone is aimed at working in public networks. We don't trust this network and only allow certain incoming connections.
  • external - zone for the external interface of the router (so-called masquerading). Only incoming connections that we define are allowed.
  • dmz - DMZ zone, only certain incoming connections are allowed.
  • work - work network zone. We still don't trust anyone, but not as much as before :) Only certain incoming connections are allowed.
  • home - home zone. We trust the environment, but only certain incoming connections are allowed
  • internal - internal zone. We trust the environment, but only certain incoming connections are allowed
  • trusted - everything is allowed.

List of all active zones:

# firewall-cmd --get-active-zones
public
interfaces: enp1s0

Yep, the public zone, to which the enp1so network interface is attached. Next, we’ll add a new port to the public zone on which sshd will hang.

Knowing the name of the network interface (for example, enp1s0), you can find out which zone it belongs to:

# firewall-cmd --get-zone-of-interface=enp1s0
public

You can find out which interfaces belong to a specific zone:

# firewall-cmd --zone=public --list-interfaces
enp1s0

Example: allowing ssh on a non-standard port

Let's allow access to the server via ssh on port 2234/tcp, and not on 22/tcp, as is the default. Along the way, let's touch a little on selinux.

First, let's see what is generally allowed on our server:

# firewall-cmd --permanent --list-all
public (default)
interfaces:
sources:
services: ssh dhcpv6-client
masquerade: no
forward-ports:
icmp-blocks:
rich rules:

I don’t use ipv6 yet, so I’ll immediately remove the corresponding one. rule from firewalld:

# firewall-cmd --permanent --zone=public --remove-service=dhcpv6-client

Let's permanently allow (so that it doesn't get lost after a reboot) the connection to port 2234/tcp (we'll hang sshd on it):

# firewall-cmd --permanent --zone=public --add-port=2234/tcp

Let's reload the rules:

# firewall-cmd --reload

Let's check:

# firewall-cmd --zone=public --list-ports
2234/tcp

Ok, the port is open. Editing the sshd config:

# nano /etc/ssh/sshd_config
...
port 2234
...

# systemctl restart sshd.service

But SELinux, which you hopefully haven’t disabled, will not allow you to connect to ssh on a non-standard port (port 2234/tcp for sshd is non-standard). You can skip this step and check how SELinux protection works, or you can configure everything right away:

# yum provides semanage
# yum install policycoreutils-python
# semanage port -a -t ssh_port_t -p tcp 2234

Now everything is ok. We check the ssh connection on the new port. If everything is ok, close access to port 22:

# firewall-cmd --permanent --zone=public --remove-service=ssh
# firewall-cmd --reload

Let's see what happened:

# firewall-cmd --list-all
public (default, active)
interfaces:
sources:
services:
ports: 2234/tcp
masquerade: no
forward-ports:
icmp-blocks:
rich rules:

That's all.

Various useful commands:

Enable blocking mode for all outgoing and incoming packets:

# firewall-cmd --panic-on

Disable blocking mode for all outgoing and incoming packets:

# firewall-cmd --panic-off

Find out whether blocking mode for all outgoing and incoming packets is enabled:

# firewall-cmd --query-panic

Reload firewalld rules without losing current connections:

# firewall-cmd --reload

Reload firewalld rules and reset current connections (recommended only in case of problems):

# firewall-cmd --complete-reload

Add a network interface to the zone:

# firewall-cmd --zone=public --add-interface=em1

Add a network interface to the zone (will be saved after rebooting the firewall):

# firewall-cmd --zone=public --permanent --add-interface=em1

You can specify in the ifcfg-enp1s0 config which zone this interface belongs to. To do this, add ZONE=work to the file /etc/sysconfig/network-scripts/ifcfg-enp1s0. If the ZONE parameter is not specified, the default zone will be assigned (the DefaultZone parameter in the /etc/firewalld/firewalld.conf file.

Allow port range:

# firewall-cmd --zone=public --add-port=5059-5061/udp

Masquerade (masquerade, aka nat, aka...):

Check status:

# firewall-cmd --zone=external --query-masquerade

Turn on:

# firewall-cmd --zone=external --add-masquerade

It should be noted here that you can enable masquerade for the public zone, for example.

Redirect incoming messages on port 22 to another host:

# firewall-cmd --zone=external --add-forward-port=port=22:proto=tcp:toaddr=192.168.1.23

Redirect incoming messages on port 22 to another host by changing the destination port (from 22 to 192.168.1.23:2055):

# firewall-cmd --zone=external /
--add-forward-port=port=22:proto=tcp:toport=2055:toaddr=192.168.1.23

I'll end here, because... there can be an infinite number of examples. I’ll just add that I personally haven’t fully formed my opinion about the firewalld innovation, because... It takes a long time to get used to the syntax, and if there are different OS Linux in your zoo, then in the first place there may be problems with habit. But mastering firewalld will broaden your horizons—more often than not, it's worth the effort.

Benefits of firewalld

The main advantage is that you are a little abstracted from iptables chains. To enable port forwarding, you do not have to think about PREROUTING or POSTROUTING in addition to FORWARD. You are given "IPtables API from the manufacturer", something like that. If you have enabled nat, then it does not matter where exactly (under what serial number of the current rules) the rule is located. You simply indicate - enable nat on eth0. And no nonsense;) This can be convenient if you need to organize a web interface for managing your firewall.

It is possible to check the status (for example, whether nat is enabled or not!). And also use this in your scripts, in the logic of your application, for example. I don’t know how to create a status request (on/off) in iptables. You can, of course, do something like iptables -L -t nat | grep "...", but you must admit, this is a little different from running "firewall-cmd --zone=external --query-masquerade". There are, for example, hundreds of VMs with CentOS, in which the names of wan interfaces or something like that may be slightly different. And so you have a universal cmdlet that will give the expected result on different machines.

Disadvantages of firewalld

The main drawback, in my opinion, is that when you get used to it, you will start to get used to “pure” iptables, which is in Debian, and in Ubuntu, and in CentOS, and, in general, everywhere. Even, by the way, in Mikrotik the syntax and chains are similar in type to iptables. This is not for everyone, of course. And a professional doesn’t care what to work with; if there are specific conditions, he will work with what he has. But... I’m a retrograde person and desperately resist (in the absence of obvious advantages) the new products that each major player implements for themselves. RedHat would benefit from having more and more new specialists become firewalld aces.

And if you switched to firewalld, then the pure iptables syntax will only hinder you - there will be a mess or the firewall will simply break down if you start changing/adding rules not using the standard firewalld syntax.

I don't want firewalld! Give me back my old iptables!

If you still want to go back to the past and replace firewalld with iptables, then it’s not at all difficult to do:

This is no place for beginners:

# systemctl disable firewalld
# systemctl stop firewalld

Install good old iptables:

# yum install iptables-services

Launch the firewall:

# systemctl start iptables
# systemctl start ip6tables

Autostart when turned on:

# systemctl enable iptables
# systemctl enable ip6tables

To save iptables rules after reboot:

# /sbin/iptables-save > /etc/sysconfig/iptables
# /sbin/ip6tables-save > /etc/sysconfig/ip6tables

Or the old fashioned way:

# service iptables save

The current rules are in the files:
/etc/sysconfig/iptables
/etc/sysconfig/ip6tables

Restarting iptables (for example, after making any changes):

# systemctl restart iptables.service


Today I will introduce you to my vision of the initial configuration of a universal server on a popular OS. I will talk about how to do the basic setup of a centos server immediately after installation to use it in any capacity at your discretion. The given practical tips increase the security and convenience of working with the server. The article will be relevant for the two latest Centos releases - 7 and 8.

  1. List the initial centos settings that I perform on a freshly installed server.
  2. Show examples of configurations I use in a typical setup.
  3. Give advice on setting up centos based on your experience with the system.
  4. Provide a list of typical programs and utilities that help administer the server.

This article is part of a single series of articles about the server.

Introduction

After the new release of Centos 8, it became difficult to describe the initial setup of both servers in a single article, but I did not want to split the article, since there are many incoming links to it from different places. It’s more convenient to maintain general material on both releases, which is what I’ll do. At the same time, the differences between the two versions will be clearly visible; for a couple of years after the release of centos 8, both will be relevant and you will have to use both versions, depending on the situation.

Centos 7 uses a package manager yum, and in Centos 8 - dnf. At the same time, they left a symbolic link from yum to dnf, so you can write both the first name and the second. For consistency, I will use yum throughout, but I warn you, just so you understand why I do it this way. In fact, CentOS 8 uses dnf, this is a different, more modern package manager that allows you to work with different versions of the same software. For this purpose, separate repositories that appeared for centos 8 are used.

Initial setup of CentOS

Personally, I start any system setup, be it centos or another, after installation by completely updating the system. If the installation image was fresh, or the installation was carried out over the network, then most likely there will be no updates. Most often they exist, since installation images are not always updated regularly.

Updating the system

# yum update

For ease of administration, I always install Midnight Commander, or just mc:

# yum install mc

And immediately for it I turn on syntax highlighting for all files that are not explicitly marked in the file /usr/share/mc/syntax/Syntax syntax for sh and bash scripts. This universal syntax is fine for configuration files that you most often need to work with on the server. Overwriting the file unknown.syntax. This is the pattern that will be applied to .conf and .cf files, since there is no explicit syntax attached to them.

# cp /usr/share/mc/syntax/sh.syntax /usr/share/mc/syntax/unknown.syntax

Network utilities will come in handy next. Depending on the set of initial packages that you select when installing the system, you will have one or another set of network utilities. Here is a list of those that I personally am used to - ifconfig, netstat, nslookup and some others. If you need it, just like me, then I suggest installing them separately if they are not already installed. If you don't particularly need them and don't use them, you can skip installing them. Let's check what we have in the system at the moment

# ifconfig

If you see the answer:

Bash: ifconfig: command not found

This means the utility is not installed. Instead of ifconfig in CentOS there is now a utility ip. This applies not only to centos. This is the picture in almost all popular modern Linux distributions. I've been used to ifconfig for a long time, although I haven't used it much lately. I always liked that in different Linux distributions everything is approximately the same. Using ifconfig you can configure the network not only in Linux, but also in freebsd. It's comfortable. And when each distribution has its own tool, this is not convenient. Although now this is no longer very relevant, since I no longer work with Freebsd, and the ip utility is available in all Linux distributions. However, if you need ifconfig, you can install the package net-tools, which includes:

# yum install net-tools

In order for the nslookup or, for example, host commands to work, we need to install the package bind-utils. If this is not done, then use the command:

#nslookup

The output will be:

Bash: nslookup: command not found

So let's install bind-utils:

# yum install bind-utils

Disable SELinux

Disable SELinux. Its use and configuration is a separate matter. I won't do this now. So let's turn it off:

# mcedit /etc/sysconfig/selinux

change the value

SELINUX=disabled

You can reboot for the changes to take effect:

# reboot

And if you want to disable SELinux without rebooting, then run the command:

#setenforce 0

I constantly receive a lot of criticism about disabling SELinux. I know how it works, I know how to configure it. It's really not very complicated and not difficult to master. This is my conscious choice, although sometimes I tweak it. The way I work with the system is such that I most often do not need SELinux, so I don’t waste time on it and disable centos in the basic setup. System security is a complex job, especially in the modern world of web development, where microservices and containers rule the roost. SELinux is a niche tool that is not needed always and not everywhere. Therefore, it has no place in this article. Those who need it will separately enable SELinux and configure it.

Specifying network parameters

We continue with the basic setup of centos after installation. Now we will do it if for some reason we did not do this during installation, or if you need to change them. In general, the network in Centos is configured using NetworkManager and its console utility nmtui. It comes with the basic installation of the system. There is a simple and clear graphical interface, so there is nothing to tell. I'm more used to configuring the network through network-scripts configuration files. In centos version 7 they are present out of the box, in version 8 they were removed. To use them to configure the network, you must separately install the package network-scripts.

# yum install network-scripts

Now you can configure the network. To do this, open the file /etc/sysconfig/network-scripts/ifcfg-eth0

# mcedit /etc/sysconfig/network-scripts/ifcfg-eth0

If you receive network settings via dhcp, then the minimum set of settings in the configuration file will be like this.

TYPE="Ethernet" BOOTPROTO="dhcp" DEFROUTE="yes" IPV4_FAILURE_FATAL="no" NAME="eth0" DEVICE="eth0" ONBOOT="yes"

To configure a static IP address, the settings will be as follows.

TYPE="Ethernet" BOOTPROTO="none" DEFROUTE="yes" IPV4_FAILURE_FATAL="no" NAME="eth0" DEVICE="eth0" ONBOOT="yes" IPADDR=192.168.167.117 DNS1=192.168.167.113 PREFIX=28 GATEWAY= 192.168.167.113

In the IPADDR field we enter your address, in PREFIX the network mask, in GATEWAY the gateway, DNS address of the dns server. Save the file and restart the network to apply the settings:

# systemctl restart network

Setting up a firewall

Adding repositories

When setting up Centos, you often need software that is not included in the standard turnip. To install additional packages you need. The most popular is EPEL. There used to be rpmforge, but it has been closed for several years. Everyone forgot about him. We connect the EPEL repository. Everything is simple with it, it is added from the standard turnip:

# yum install epel-release

Also for CentOS 7, the REMI repository is extremely useful, which allows you to install more recent versions of php, unlike those in the standard repository. Let me remind you that this is version PHP 5.4, which is no longer any good and has been removed from support.

# rpm -Uhv http://rpms.remirepo.net/enterprise/remi-release-7.rpm

For Centos 8 remi is not yet relevant, but I think it is temporary. In principle, these two repositories in centos are usually enough for me in the general case. Others are connected for specific needs for installing various software.

Setting up history storage in bash_history

Let's move on to setting up the centos system on the server. It will be useful to make some changes to the standard mechanism for saving command history. It often helps out when you need to remember one of the previously entered commands. The standard settings have some limitations that are inconvenient. Here is their list:

  1. By default, only the last 1000 commands are saved. If there are more of them, the older ones will be deleted and replaced with new ones.
  2. There are no execution dates for the commands, just a list of them in order of execution.
  3. The command list file is updated after the session ends. During parallel sessions, some commands may be lost.
  4. Absolutely all commands are saved, although there is no point in storing some.

The list of recently executed commands is stored in the user's home directory in the file .bash_history(dot at the beginning). You can open it with any editor and view it. To display the list more conveniently, you can enter the command in the console:

#history

and see a numbered list. You can quickly find a specific command by filtering only the necessary lines, for example like this:

#history | grep yum

This way we will see all the options for running the yum command, which are stored in history. Let's correct the listed shortcomings of the standard settings for storing command history in CentOS. To do this you need to edit the file .bashrc, which is located in the same directory as the history file. Add the following lines to it:

Export HISTSIZE=10000 export HISTTIMEFORMAT="%h %d %H:%M:%S " PROMPT_COMMAND="history -a" export HISTIGNORE="ls:ll:history:w:htop"

The first option increases the file size to 10,000 lines. You can make more, although this size is usually enough. The second parameter specifies that the date and time the command was executed should be stored. The third line forces immediately after executing the command to save it to history. In the last line we create a list of exceptions for those commands that do not need to be recorded in history. I gave an example of the simplest list. You can add it at your discretion.

To apply the changes, you need to log out and connect again or run the command:

# source ~/.bashrc

That's all about setting up command history storage. There are a lot of interesting things you can configure in the .bashrc file. At one time I got carried away and experimented, but then I abandoned everything because it didn’t make sense. When working with customer servers, I most often see the default bash, so it’s better to get used to it and work in it. And individual settings and decorations are the lot of personal computers and servers. Not workers. So I don’t configure anything else according to the standard in the centos server in this regard.

Automatic system update

To maintain server security at the proper level, it is necessary to at least update it in a timely manner - both the kernel itself with system utilities, and other packages. You can do this manually, but for more efficient work it is better to configure automatic execution. It is not necessary to install updates automatically, but at least check for their availability. I usually follow this strategy.

Yum-cron

To automatically check for updates in Centos 7, the utility will help us yum-cron. It is installed traditionally via yum from the standard repository.

# yum install yum-cron

After installing yum-cron, an automatic task is created to run the utility in /etc/cron.daily And /etc/cron.hourly. By default, the utility downloads found updates, but does not apply them. Instead, an update notification is sent to the administrator's local root mailbox. Then you go in manual mode and decide whether to install updates or not at a time convenient for you. I find this mode of operation the most convenient, so I do not change these settings.

You can configure yum-cron through the configuration files, which are located at /etc/yum/yum-cron.conf And yum-cron-hourly.conf. They are well commented on, so they don’t need detailed explanations. I draw your attention to the section , where you can specify parameters for sending messages. By default, mail is sent via local host. You can change the settings here and send messages through a third-party mail server. But instead, I personally prefer to globally configure the entire server to forward local root mail to an external mailbox through authorization on another smtp server.

Dnf-automatic

As I said earlier, Centos 8 uses a different package manager - dnf. Configuring package updates there is done through the utility dnf-automatic. Let's install it and configure it.

# yum install dnf-automatic

It is no longer cron that manages scheduled launches, but systemd with its built-in scheduler. You can view automatic start timers with the command:

# systemctl list-timers *dnf-*

If there are no tasks there, then you can add a timer manually:

# systemctl enable --now dnf-automatic.timer

The default timer is set to start dnf-automatic an hour after the server boots and repeats daily. The timer config lives here - /etc/systemd/system/multi-user.target.wants/dnf-automatic.timer.

The config for dnf-automatic lives in /etc/dnf/automatic.conf. By default, it only downloads updates, but does not apply them. The config is well commented, so you can customize it as you wish. No special explanation is required. Configure updating system packages at your discretion. As I already said, I just download them automatically. I always keep the installation under control with manual control.

Disable message flooding in /var/log/messages

Continuing to configure centos, we will correct one small inconvenience. In the default installation of the 7th version of the system, your entire system log /var/log/messages After some time the server will be clogged with the following records.

Oct 16 14:01:01 xs-files systemd: Created slice user-0.slice. Oct 16 14:01:01 xs-files systemd: Starting user-0.slice. Oct 16 14:01:01 xs-files systemd: Started Session 14440 of user root. Oct 16 14:01:01 xs-files systemd: Starting Session 14440 of user root. Oct 16 14:01:01 xs-files systemd: Removed slice user-0.slice. Oct 16 14:01:01 xs-files systemd: Stopping user-0.slice. Oct 16 15:01:01 xs-files systemd: Created slice user-0.slice. Oct 16 15:01:01 xs-files systemd: Starting user-0.slice. Oct 16 15:01:01 xs-files systemd: Started Session 14441 of user root. Oct 16 15:01:01 xs-files systemd: Starting Session 14441 of user root. Oct 16 15:01:01 xs-files systemd: Started Session 14442 of user root. Oct 16 15:01:01 xs-files systemd: Starting Session 14442 of user root. Oct 16 15:01:01 xs-files systemd: Removed slice user-0.slice. Oct 16 15:01:01 xs-files systemd: Stopping user-0.slice. Oct 16 16:01:01 xs-files systemd: Created slice user-0.slice. Oct 16 16:01:01 xs-files systemd: Starting user-0.slice. Oct 16 16:01:01 xs-files systemd: Started Session 14443 of user root. Oct 16 16:01:01 xs-files systemd: Starting Session 14443 of user root. Oct 16 16:01:01 xs-files systemd: Removed slice user-0.slice.

I didn't notice them in Centos 8, so I don't need to do anything there. The messages do not provide any practical benefit, so we will turn them off. To do this, we will create a separate rule for rsyslog, where we will list all the message templates that we will cut. Let's place this rule in a separate file /etc/rsyslog.d/ignore-systemd-session-slice.conf.

# cd /etc/rsyslog.d && mcedit ignore-systemd-session-slice.conf if $programname == "systemd" and ($msg contains "Starting Session" or $msg contains "Started Session" or $msg contains "Created slice" or $msg contains "Starting user-" or $msg contains "Starting User Slice of" or $msg contains "Removed session" or $msg contains "Removed slice User Slice of" or $msg contains "Stopping User Slice of" ) then stop

Save the file and restart rsyslog to apply the settings.

# systemctl restart rsyslog

It is necessary to understand that in this case we disable flooding to the log file only on the local server. If you store logs on , then this rule will need to be configured on it.

Installing iftop, atop, htop, lsof on CentOS

And finally, to complete the setup, we’ll add a few useful utilities that may come in handy during the operation of the server.

iftop shows the loading of the network interface in real time, can be launched with various keys, I will not dwell on this in detail, there is information on this topic on the Internet. We put:

# yum install iftop

And two interesting task managers, I most often use htop, but sometimes atop comes in handy. Let's install both, see for yourself, figure out what you like best, what suits you:

# yum install htop # yum install atop

To display information about which files are used by which processes, I advise you to install the utility lsof. It will most likely come in handy sooner or later when you diagnose the server.

# yum install wget bzip2 traceroute gdisk

That's all for me. The basic setup of CentOS is complete, you can begin installing and configuring the main functionality.

Setting up system mail

To finish setting up the CentOS server, let's make sure that mail addressed to the local root is sent through an external mail server to the selected mailbox. If this is not done, then it will be locally compiled into a file /var/spool/mail/root. And there may be important and useful information. Let's configure it to be sent to the system administrator's mailbox.

I talked about this in detail in a separate article -. Here are just the commands and quick setup. Install the necessary packages:

# yum install mailx cyrus-sasl cyrus-sasl-lib cyrus-sasl-plain postfix

Let's draw something like this config for postfix.

Cat /etc/postfix/main.cf ## DEFAULT CONFIG BEGIN ###################### queue_directory = /var/spool/postfix command_directory = /usr/sbin daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix mail_owner = postfix inet_interfaces = localhost inet_protocols = all unknown_local_recipient_reject_code = 550 alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases debug_peer_level = 2 debugger_ command = PATH =/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 sendmail_path = /usr/sbin/sendmail.postfix newaliases_path = /usr/bin/ newaliases.postfix mailq_path = /usr/bin/mailq.postfix setgid_group = postdrop html_directory = no manpage_directory = /usr/share/man sample_directory = /usr/share/doc/postfix-2.10.1/samples readme_directory = /usr/share/ doc/postfix-2.10.1/README_FILES ## DEFAULT CONFIG END ###################### # Server name as output by the command hostname myhostname = centos-test. xs.local # Here, logically, you need to leave only the domain, but in this case it is better to leave the full name of the server so that the sender field # contains the full name of the server, this makes it more convenient to parse service messages mydomain = centos-test.xs.local mydestination = $myhostname myorigin = $mydomain # Server address through which we will send mail relayhost = mailsrv.mymail.ru:25 smtp_use_tls = yes smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = noanonymous smtp_t ls_security_level = may

We create a file with information about the username and password for authorization.

# mcedit /etc/postfix/sasl_passwd mailsrv.mymail.ru:25 [email protected]:password

Create a db file.

# postmap /etc/postfix/sasl_passwd

Now you can restart postfix and check if it works.

# systemctl restart postfix

To the standard alias for root in /etc/aliases, add an external address where mail addressed to root will be duplicated. To do this, edit the specified file, changing the last line.

#root: marc

Root: root, [email protected]

Updating the certificate database:

#newaliases

Let's send a letter via the console to the local root:

# df -h | mail -s "Disk usage" root

The letter should go to an external mailbox. If you use a mailbox from Yandex, you will most likely receive an error in the mail server log and the letter will not be sent.

Relay=smtp.yandex.ru:25, delay=0.25, delays=0/0/0.24/0.01, dsn=5.7.1, status=bounced (host smtp.yandex.ru said: 553 5.7.1 Sender address rejected: not owned by auth user. (in reply to MAIL FROM command))

This error means that your mail sender is not the same mailbox that you use for authorization. I tell you how to fix this in a separate article -. With other mail systems where there is no such check, everything should be fine as is.

This completes the local mail setup. Now all letters addressed to the local root, for example, reports from cron, will be duplicated to an external mailbox, and sent through a full-fledged mail server. So the letters will be delivered normally, without ending up in spam (although not necessarily, there are also heuristic filters).

Conclusion

We've gone through some initial steps to set up a CentOS server, which is what I usually do when preparing a server right after installation. I don’t pretend to be the absolute truth; I may be missing something or doing something that’s not entirely correct. I will be glad to have reasonable and meaningful comments and suggestions.

..
  • Understanding of the specifics of deploying, configuring and maintaining networks built on Linux.
  • The ability to quickly solve emerging problems and ensure stable and uninterrupted operation of the system.
  • Test yourself on the entrance test and see the program for more details.

    Starting with CentoOS 7, a new tool has appeared to configure traffic filtering rules firewalld. It is recommended to use it to manage iptables rules. In CentOS 8, instead of the standard iptables filtering package, the nftables framework is now used, and when you configure firewall rules through firewalld, you are actually configuring nftables. In this article, we will look at installing, basic concepts and configuring firewalld on a server running CentOS 8 (CentOS 7 is the same).


    FirewallD– a firewall to protect the server from unwanted traffic with support for dynamic rule management (without restarting) and the implementation of permanent firewall rules. Works as an interface for and nftables. FirewallD can be used on almost all Linux distributions.

    Basic firewalld concepts, zones and rules

    Before you begin installation and configuration firewalld, we'll introduce the concept of zones, which are used to define the level of trust for various connections. For different zones firewalld You can apply various filtering rules, specify active firewall options in the form of predefined services, protocols and ports, port forwarding and rich-rules.

    Firewalld filters incoming traffic by zone depending on the rules applied to the zone. If IP- the address of the request sender matches the rules of a certain zone, then the packet will be sent through this zone. If the address does not match any of the zones configured on the server, the packet will be processed by the default zone. When installing firewalld the default zone is called public.

    Firewalld has zones that are pre-configured with permissions for various services. You can use these settings or create your own zones. List of default zones that are created when installing firewalld (stored in the /usr/lib/firewalld/zones/ directory):

    drop minimum level of trust. All incoming connections are blocked without response, only outgoing connections are allowed;
    block the zone is similar to the previous one, but when incoming requests are rejected, the message icmp-host-prohibited for Ipv4 or icmp6-adm-prohibited for Ipv6 is sent;
    public represents public, untrusted networks. You can allow selected incoming connections on an individual basis;
    external external networks when using a firewall as a gateway. It's configured for NAT masquerading so your internal network remains private but accessible;
    internal antonym of external zone. The host has a sufficient level of trust, a number of additional services are available;
    dmz used for computers located in a DMZ (isolated computers without access to the rest of the network). Only certain incoming connections are allowed;
    work zone for work machines (most computers on the network are trusted);
    home home network zone. Most PCs can be trusted, but only certain incoming connections are supported;
    trusted trust all machines on the network. The most open of all available options, it requires conscious use.

    IN firewalld two sets of rules are used - permanent and temporary. Temporary rules work until the server is rebooted. By default, when adding rules to firewalld, the rules are considered temporary ( runtime). To add a rule on a permanent basis, you need to use the flag - permanent. Such rules will be applied after the server is rebooted.

    Installing and enabling firewalld on CentOS

    In CentOS 7/8, firewalld is installed by default with the OS. If you have removed it and want to install firewalld, you can use the standard /dnf manager:

    # yum install firewalld -y - for Centos 7
    # dnf install firewalld -y - for Centos 8

    To the demon firewalld started automatically when the server started, you need to add it to:

    # systemctl enable firewalld

    And run:

    # systemctl start firewalld

    Check service status:

    # systemctl status firewalld

    ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-10-14 14:54 :40 +06; 22s ago Docs: man:firewalld(1) Main PID: 13646 (firewalld) CGroup: /system.slice/firewalld.service └─13646 /usr/bin/python2 -Es /usr/sbin/firewalld --nofork --nopid Oct 14 14:54:40 server.vpn.ru systemd: Starting firewalld - dynamic firewall daemon... Oct 14 14:54:40 server.vpn.ru systemd: Started firewalld - dynamic firewall daemon.

    Or with the command:

    # firewall-cmd --state

    The firewall-cmd command is a firewalld frontend to nftables/iptables.

    # firewall-cmd --state

    Working with firewalld rules

    Default rules:

    Before setting up firewalld rules, you need to check which zone is used by default:

    # firewall-cmd --get-default-zone

    Since we just installed firewalld and haven’t configured it yet, we have a default zone public.

    Let's check the active zone. There is also one - public:

    # firewall-cmd --get-active-zones

    Public interfaces: eth0

    As you can see, the eth0 network interface is controlled by the zone public.

    To view the core rules, enter:

    # firewall-cmd --list-all

    Public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: dhcpv6-client ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:

    From the listing you can see that the usual operations related to the DHCP client and ssh have been added to this zone.

    Available zones

    To view a list of all zones, you need to run the command:

    # firewall-cmd --get-zones

    I got the following list:

    Block dmz drop external home internal public trusted work

    To check the rules of a specific zone, you need to add the flag - zone.

    # firewall-cmd --zone=home --list-all

    Home target: default icmp-block-inversion: no interfaces: sources: services: dhcpv6-client mdns samba-client ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:

    The rules of all zones can be viewed with the command:

    # firewall-cmd --list-all-zones

    The listing will be quite large, since there can be many zones.

    Change the default zone.

    By default, all network interfaces are located in the zone public, but they can be transferred to any of the zones with the command:

    # firewall-cmd --zone=home -change-interface=eth0

    After the parameter --zone= indicate the desired zone.

    To change the default zone, you need to use the command:

    # firewall-cmd --set-default-zone=home

    Adding application rules

    To open a port for an application, you can add a service to the exceptions. Display a list of available services:

    The output will contain a large number of services. Detailed information about the service is contained in its xml file. These files are located in the directory /usr/lib/firewalld/services.

    For example:

    # cd /usr/lib/firewalld/services

    Mail (SMTP) This option allows incoming SMTP mail delivery. If you need to allow remote hosts to connect directly to your machine to deliver mail, enable this option. You do not need to enable this if you collect your mail from your ISP"s server by POP3 or IMAP, or if you use a tool such as fetchmail. Note that an improperly configured SMTP server can allow remote machines to use your server to send spam.

    The XML file contains a description of the service, protocol and port number that will be opened in firewalld.

    When adding rules, you can use the parameter --add-service to open access to a specific service:

    # firewall-cmd --zone=public --add-service=http

    # firewall-cmd --zone=public --add-service=https

    After adding rules, you can check whether services have been added to the specified zone:

    # firewall-cmd --zone=public --list-services

    Dhcpv6-client http https ssh

    If you want to make these rules permanent, you need to add the parameter when adding —permanent.

    To remove a service from a zone:

    # firewall-cmd --permanent --zone=public --remove-service=http

    Dhcpv6-client https ssh test

    If you want to add your service to exceptions, you can create a file xml yourself and fill it out. You can copy data from any service, change the name, description and port number.

    Let's copy the file smtp.xml to the directory for working with user services:

    # cp /usr/lib/firewalld/services/smtp.xml /etc/firewalld/services

    Change the service description in the file.

    The xml file itself also needs to be renamed according to the name of your service. After that, you need to restart firewalld and check if our service is in the list:

    I called the service test and it appeared in the list:

    Syslog-tls telnet test tftp

    Now you can add the created service to any zone:

    # firewall-cmd --zone=public --add-service=test --permanent

    # firewall-cmd --zone=public --permanent --list-services

    Dhcpv6-client http https ssh test

    If you haven't found the service you need in the list, you can open the required port on firewalld with the command:

    # firewall-cmd --zone=public -add-port=77/tcp - open port 77 tcp
    # firewall-cmd --zone=public -add-port=77/udp - open port 77 udp
    # firewall-cmd --zone=public -add-port=77-88/udp - open port range 77-88 udp
    # firewall-cmd --zone=public -list-ports - check the list of allowed ports

    Block/allow ICMP replies:

    # firewall-cmd --zone=public --add-icmp-block=echo-reply
    # firewall-cmd --zone= public --remove-icmp-block=echo-reply

    Remove added port:

    # firewall-cmd --zone=public -remove-port=77/udp - remove temporary rule 77 udp

    # firewall-cmd --permanent --zone=public -remove-port=77/udp - remove permanent rule

    Adding your own zones

    You can create your own zone (I'll call it our):

    # firewall-cmd --permanent --new-zone=our

    After creating a new zone, as well as after creating a service, a reboot is required firewalld:

    # firewall-cmd --reload

    # firewall-cmd --get-zones

    Block dmz drop external home internal our public trusted work

    Zone our available. You can add services to it or open specific ports.

    Firewalld: blocking IP addresses, creating exceptions

    You can add trusted IP addresses to firewalld exceptions or block unwanted ones.

    To add a specific IP address (for example 8.8.8.8) to your server via firewalld, use the command:

    # firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" source address="8.8.8.8" accept"

    Check the area and make sure IP added to exceptions in rich rules:

    Public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: dhcpv6-client http https ssh test ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" source address="8.8.8.8" accept

    To block IP, need to replace accept on reject:

    # firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" source address="8.8.4.4" reject"

    # firewall-cmd --zone=public --list-all

    Public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: dhcpv6-client http https ssh test ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" source address="8.8.8.8" accept rule family="ipv4" source address="8.8.4.4" reject

    You can allow a specific service only for requests from a specific IP address:

    #firewall-cmd --permanent --add-rich-rule "rule family="ipv4" source address="10.10.1.0/24" service name="https" accept"

    If you urgently need to block all requests to the server, use the panic command:

    # firewall-cmd --panic-on

    You can disable panic mode either with the command:

    # firewall-cmd --panic-off

    Or by rebooting the server.

    You can lock the firewalld configuration to prevent local root services from changing the firewall rules you created:

    # firewall-cmd --lockdown-on

    Disable blocking mode:

    # firewall-cmd --lockdown-off

    Port forwarding in firewalld

    You can create a port forwarding rule in firewalld. To forward port 443 to 9090:

    # firewall-cmd --zone=public --add-forward-port=port=443:proto=tcp:toport=9090 --permanent

    To remove a port forwarding rule:

    # firewall-cmd --zone=public --remove-forward-port=port=443:proto=tcp:toport=9090





    

    2024 gtavrl.ru.