В-четвертых, CentOS переключается на брандмауэр iptables
Переключение на iptables должно сначала отключить firewalld по умолчанию, а затем установить службу iptables.
1. Закройте брандмауэр:
service firewalld stop systemctl отключить firewalld.service #Отключить запуск брандмауэра
2. Установите брандмауэр iptables
yum installiptables-services
3. Изменить конфигурацию брандмауэра iptables
vi / etc / sysconfig / iptables # Редактировать файлы конфигурации брандмауэра
Вот полный файл конфигурации:
: wq! # Сохранить и выйти
запуск сервиса iptables systemctl включите iptables.service # Установите брандмауэр для запуска
<End>
Политики UFW по умолчанию
По умолчанию межсетевой экран UFW блокирует весь входящий и пересылаемый трафик и разрешает весь исходящий трафик. Это означает, что любой, кто пытается получить доступ к вашему серверу, не сможет подключиться, если вы специально не откроете порт. Приложения и службы, работающие на вашем сервере, смогут получить доступ к внешнему миру.
Политики по умолчанию определены в и могут быть изменены либо путем изменения файла вручную, либо с помощью команды .
Политики брандмауэра — это основа для создания более сложных и определяемых пользователем правил. Как правило, исходные политики по умолчанию UFW являются хорошей отправной точкой.
Настройка хранения истории в bash_history
Полезным будет внести некоторые изменения в стандартный механизм сохранения истории команд. Он часто выручает, когда надо вспомнить одну из ранее введенных команд. Стандартные настройки имеют некоторые ограничения, которые неудобны. Вот их список:
- По-умолчанию, сохраняются только последние 1000 команд. Если их будет больше, то более старые будут удаляться и заменяться новыми.
- Не указаны даты выполнения команд, только их список в порядке выполнения.
- Файл со списком команд обновляется после завершения сессии. При параллельных сессиях часть команд может быть утеряна.
- Сохраняются абсолютно все команды, хотя в хранении некоторых нет никакого смысла.
Список последних выполненных команд хранится в домашней директории пользователя в файле .bash_history (в начале точка). Его можно открыть любым редактором и посмотреть. Для более удобного вывода списка, можно в консоли ввести команду:
# history
и увидеть пронумерованный список. Быстро найти конкретную команду, можно с помощью фильтрации только нужных строк, например вот так:
# history | grep yum
Так мы увидим все варианты запуска команды yum, которые хранятся в истории. Исправим перечисленные недостатки стандартных настроек хранения истории команд в CentOS 7. Для этого нужно отредактировать файл .bashrc, который находится в том же каталоге, что и файл с историей. Добавляем в него следующие строки:
export HISTSIZE=10000 export HISTTIMEFORMAT="%h %d %H:%M:%S " PROMPT_COMMAND='history -a' export HISTIGNORE="ls:ll:history:w:htop"
Первый параметр увеличивает размер файла до 10000 строк. Можно сделать и больше, хотя обычно хватает такого размера. Второй параметр указывает, что необходимо сохранять дату и время выполнения команды. Третья строка вынуждает сразу же после выполнения команды сохранять ее в историю. В последней строке мы создаем список исключений для тех команд, запись которых в историю не требуется. Я привел пример самого простого списка. Можете дополнить его на свое усмотрение.
Для применения изменений необходимо разлогиниться и подключиться заново или выполнить команду:
# source ~/.bashrc
Порты, протоколы, и службы
В файле /etc/services несколько строк, связанных с Samba:
На самом деле количество портов можно сократить к следующему виду:
…потому что это порты, которые слушают службы сервера Samba. Первые три строки представляют порты, используемые сетью windows, так как сеть TCP/IP стала стандартной в операционной системе Windows 95. Оставшийся порт стал использоваться, когда Microsoft представила свою службу каталогов с Windows 2000. Для устранения неполадок или настройки полезно отметить, что протоколы UDP (порты 137 и 138) обслуживаются демоном nmbd, а протоколы TCP (порты 139 и 445) обслуживаются smbd.
Вы можете сами проверить, какие порты используются Samba, с помощью этих команд (от root):
И Вы увидите, что порты, перечисленные выше, появляются в выходных данных вместе с протоколом (TCP или UDP), которые используются для связи.
Сетевые настройки на сервере CentOS 7
Первый раз с сетевыми настройками сервера CentOS мы сталкиваемся, когда производим установку. На экране первоначальной настройки есть отдельный пункт, касающийся настройки сетевых интерфейсов:
Зайдя в него мы видим список подключенных сетевых карт. Каждую из них можно включить соответствующим ползунком (пункт 1 на картинке). При активировании интерфейса он автоматически получает настройки по dhcp. Результат работы dhcp можно посмотреть тут же. Если вас не устраивают эти настройки, их можно отредактировать, нажав configure(пункт 3 на картинке). Здесь же можно задать hostname(пункт 2 на картинке):
Открыв окно дополнительный настроек Ehernet, вы сможете изменить имя сетевого интерфейса, указать настройки IP (пункт 1 на картинке), выбрать ручные настройки (пункт 2 на картинке), назначить ip адрес (пункт 3 на картинке), установить dns сервер (пункт 4 на картинке) и сохранить сетевые настройки (пункт 5 на картинке):
После выполнения остальных настроек начнется установка. После установки у вас будет сервер с указанными вами сетевыми настройками.
Теперь рассмотрим другую ситуацию. Сервер, а соответственно и конфигурацию сети, производили не вы, а теперь вам надо ее посмотреть либо изменить. В вашем распоряжении консоль сервера, в ней и будем работать. Если у вас установка производилась с дистрибутива minimal, то при попытке посмотреть сетевые настройки с помощью команды ifconfig в консоли вы увидите следующее:
Bash: ifconfig: command not found
или в русской версии:
Bash: ifconfig команда не найдена
Для работы с ifconfig и прочими сетевыми утилитами необходимо установить пакет net-tools. Сделаем это:
# yum -y install net-tools.x86_64
Теперь можно увидеть настройки сети:
# ifconfig
eno16777728: flags=4163 mtu 1500
inet 192.168.159.129
RX packets 319 bytes 36709 (35.8 KiB)
TX packets 256 bytes 148817 (145.3 KiB)
lo: flags=73 mtu 65536
inet6::1 prefixlen 128 scopeid 0x10
RX packets 6 bytes 624 (624.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6 bytes 624 (624.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Если у вас нет желания устанавливать дополнительный пакет, то можно воспользоваться более простой командой ip с параметрами:
# ip addr
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
inet 127.0.0.1/8 scope host lo
inet6::1/128 scope host
valid_lft forever preferred_lft forever
2: eno16777728: mtu 1500 qdisc pfifo_fast state UP qlen 1000
inet 192.168.159.129/24 brd 192.168.159.255 scope global dynamic eno16777728
valid_lft 1709sec preferred_lft 1709sec
inet6 fe80::20c:29ff:fe7d:593f/64 scope link
valid_lft forever preferred_lft forever
По настройкам из этого файла мы получаем ip адрес по dhcp. Чтобы вручную прописать статический ip, приводим файл к следующему содержанию:
Мы изменили параметры:
BOOTPROTOс dhcp на noneDNS1 указали dns сервер IPADDR, настроили статический ip адрес PREFIX, указали маску подсети GATEWAY. настроили шлюз по-умолчанию
Чтобы изменения вступили в силу, необходимо перечитать сетевые настройки:
Restarting network (via systemctl):
Проверяем, применилась ли новая конфигурация сети:
# ifconfig:
eno16777728: flags=4163 mtu 1500
inet 192.168.159.129 netmask 255.255.255.0 broadcast 192.168.159.255
inet6 fe80::20c:29ff:fe7d:593f prefixlen 64 scopeid 0x20
ether 00:0c:29:7d:59:3f txqueuelen 1000 (Ethernet)
RX packets 672 bytes 71841 (70.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 572 bytes 290861 (284.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Все в порядке, новые настройки сетевого интерфейса установлены.
Как получить сетевые настройки по DHCP
Теперь рассмотрим обратную ситуацию. Допустим, у вас сетевая карта имеет какие-то настройки, установленные вручную. Но вы хотите, чтобы ваш компьютер получал настройки сети по dhcp в качестве клиента. Для этого вам нужно произвести операцию, обратную той, что мы делали раньше. То есть открываем файл /etc/sysconfig/network-scripts/ifcfg-eth0 и удаляем там строки с параметрами DNS, IPADDR, PREFIX, GATEWAY а в параметре BOOTPROTO указываем значение «dhcp». Сохраняем файл и перезапускаем сеть:
# /etc/init.d/network restart
Затем проверяем, получил ли наш client по dhcp настройки.
RHEL7/CentOS7 and Fedora firewalld
A nice introduction is RHEL7: How to get started with Firewalld.
The default firewall service is now firewalld, which is a front-end service on top of the iptables service.
The dynamic firewall daemon firewalld provides a dynamically managed firewall with support for network “zones” to assign a level of trust to a network and its associated connections and interfaces.
See Introduction to firewalld.
A graphical configuration tool:
firewall-config
is used to configure firewalld, which in turn uses iptables tool to communicate with netfilter in the kernel which implements packet filtering.
A command line (CLI) configuration tool:
firewall-cmd
may also used to configure firewalld.
To make any new rule permanent, run the command with the flag.
See the manual firewall-cmd for further information.
The firewalld configuration files are in the directory where XML files contain the firewall rules.
See firewalld log messages in:
varlogfirewalld
What are Chains?
A chain is a set of rules, checked one by one until it is matched. There are 3 chains: INPUT, FORWARD and OUTPUT (they are processed in that order).
Notice in the example above that the default policy for each chain is set to ACCEPT. In other words it will expect you to create your rules on which traffic to deny, leaving everything else to get through. It’s far more secure to do the opposite, so we’ll set the default policies to DROP.
Wait! If we do this now then we’ll lose connectivity to our Linux host, assuming of course you are connected via SSH. We’ll do that in a later step.
Order of Chains
- Flush all chains
- Add rules for connections you want to drop
- Add rules for connections you want to accept
- Add logging rules (optional)
- Set default policy to drop for each chain
- Save and restart
Настройка netfilter/iptables для подключения нескольких клиентов к одному соединению.
Давайте теперь рассмотрим наш Linux в качестве шлюза для локальной сети во внешнюю сеть Internet. Предположим, что интерфейс eth0 подключен к интернету и имеет IP 198.166.0.200, а интерфейс eth1 подключен к локальной сети и имеет IP 10.0.0.1. По умолчанию, в ядре Linux пересылка пакетов через цепочку FORWARD (пакетов, не предназначенных локальной системе) отключена. Чтобы включить данную функцию, необходимо задать значение 1 в файле /proc/sys/net/ipv4/ip_forward:
netfilter:~# echo 1 > /proc/sys/net/ipv4/ip_forward
Чтобы форвардинг пакетов сохранился после перезагрузки, необходимо в файле /etc/sysctl.conf раскомментировать (или просто добавить) строку net.ipv4.ip_forward=1.
Итак, у нас есть внешний адрес (198.166.0.200), в локальной сети имеется некоторое количество гипотетических клиентов, которые имеют адреса из диапазона локальной сети и посылают запросы во внешнюю сеть. Если эти клиенты будут отправлять во внешнюю сеть запросы через шлюз «как есть», без преобразования, то удаленный сервер не сможет на них ответить, т.к. обратным адресом будет получатель из «локальной сети». Для того, чтобы эта схема корректно работала, необходимо подменять адрес отправителя, на внешний адрес шлюза Linux. Это достигается за счет (маскарадинг) в , в .
netfilter:~# iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT netfilter:~# iptables -A FORWARD -m conntrack --ctstate NEW -i eth1 -s 10.0.0.1/24 -j ACCEPT netfilter:~# iptables -P FORWARD DROP netfilter:~# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Итак, по порядку сверху-вниз мы разрешаем уже установленные соединения в цепочке FORWARD, таблице filter, далее мы разрешаем устанавливать новые соединения в цепочке FORWARD, таблице filter, которые пришли с интерфейса eth1 и из сети 10.0.0.1/24. Все остальные пакеты, которые проходят через цепочку FORWARD — отбрасывать. Далее, выполняем маскирование (подмену адреса отправителя пакета в заголовках) всех пакетов, исходящих с интерфейса eth0.
Примечание. Есть некая общая рекомендация: использовать правило -j MASQUERADE для интерфейсов с динамически получаемым IP (например, по DHCP от провайдера). При статическом IP, -j MASQUERADE можно заменить на аналогичное -j SNAT —to-source IP_интерфейса_eth0. Кроме того, SNAT умеет «помнить» об установленных соединениях при кратковременной недоступности интерфейса. Сравнение MASQUERADE и SNAT в таблице:
Кроме указанных правил так же можно нужно добавить правила для фильтрации пакетов, предназначенных локальному хосту — как описано в . То есть добавить запрещающие и разрешающие правила для входящих и исходящих соединений:
netfilter:~# iptables -P INPUT DROP netfilter:~# iptables -P OUTPUT DROP netfilter:~# iptables -A INPUT -i lo -j ACCEPT netfilter:~# iptables -A OUTPUT -o lo -j ACCEPT netfilter:~# iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT netfilter:~# iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT netfilter:~# iptables -A OUTPUT -p icmp -j ACCEPT netfilter:~# cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000 netfilter:~# iptables -A OUTPUT -p TCP --sport 32768:61000 -j ACCEPT netfilter:~# iptables -A OUTPUT -p UDP --sport 32768:61000 -j ACCEPT netfilter:~# iptables -A INPUT -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT netfilter:~# iptables -A INPUT -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
В результате, если один из хостов локальной сети, например 10.0.0.2, попытается связаться с одним из интернет-хостов, например, 93.158.134.3 (ya.ru), при , их исходный адрес будет подменяться на внешний адрес шлюза в цепочке POSTROUTING таблице nat, то есть исходящий IP 10.0.0.2 будет заменен на 198.166.0.200. С точки зрения удаленного хоста (ya.ru), это будет выглядеть, как будто с ним связывается непосредственно сам шлюз. Когда же удаленный хост начнет ответную передачу данных, он будет адресовать их именно шлюзу, то есть 198.166.0.200. Однако, на шлюзе адрес назначения этих пакетов будет подменяться на 10.0.0.2, после чего пакеты будут передаваться настоящему получателю в локальной сети. Для такого обратного преобразования никаких дополнительных правил указывать не нужно — это будет делать все та же операция MASQUERADE, которая помнит какой хост из локальной сети отправил запрос и какому хосту необходимо вернуть пришедший ответ.
Примечание: желательно негласно принято, перед всеми командами iptables очищать цепочки, в которые будут добавляться правила:
netfilter:~# iptables -F ИМЯ_ЦЕПОЧКИ
Примеры настройки Iptables
Чтобы закрепить навыки настройки Iptables, рекомендуется протестировать утилиту в разных режимах. Например, отобразить список правил, очистить его, установить параметры по умолчанию или удалить их.
Список правил
Просмотр правил Iptables осуществляется командой:
$ iptables –L
Также есть возможность указать нужную цепочку, например:
$ iptables -L INPUT
Очистка правил
При любых ошибках в работе Iptables, чтобы исключить нарушение функционирования ядра перед другими действиями, требуется очистить правила, «обнулить» вводные данные. Выполняется эта процедура командой:
$ sudo iptables –F
Если речь идет об определенной цепочке, то она будет выглядеть иначе:
$ sudo iptables -F Input
Перечисленные действия выполняются для таблицы filter, которая подключена изначально.
Правила «по умолчанию»
Задаются правила «по умолчанию» вручную. Пример команд:
$ sudo iptables -p INPUT ACCEPT $ sudo iptables -p OUTPUT ACCEPT $ sudo iptables -p FORWARD DROP
Здесь мы разрешаем все цепочки INPUT и OUTPUT, запрещаем FORWARD.
Блокировка пакетов
Заблокировать пакеты можно действием DROP. Оно позволяет включать фильтрацию по разным признакам вроде IP-адреса, маске сети, порту и пр.
Пример:
$ sudo iptables -A INPUT -s 20.20.20.20 -j DROP
Блокируются входящие пакеты на IP 20.20.20.20.
$ sudo iptables -A OUTPUT -s 20.20.20.20 -j DROP
Теперь мы заблокировали пакеты, исходящие на IP 20.20.20.20.
Есть возможность указать маску сети, например, 20.20.20.0/255. Тогда правила будут применяться ко всем IP, входящим в указанный диапазон. Если же требуется заблокировать подключение строго по определенному протоколу, вводится команда:
$ sudo iptables -A INPUT -p tcp --dport ssh -s 10.10.10.10 -j DROP
Она блокирует все входящие соединения по SSH.
Удаление правил
При удалении правил в Iptables вводится команда с опцией -D. Но перед этим может понадобиться просмотреть перечень правил:
$ sudo iptables -L
Пример удаления правила:
$ sudo iptables -A OUTPUT -s 10.10.10.10 -j DROP
Если требуется полное удаление правил, применяется команда:
$ sudo iptables –F
Сохранение правила Iptables
Теперь остается опробовать режим сохранения правил
Важно учитывать, что он действует до перезагрузки компьютера. После этой процедуры необходимо задавать их заново. В Ubuntu процесс требует ввода команды:
В Ubuntu процесс требует ввода команды:
$ sudo /sbin/iptables-save
Для операционных систем на ядре Red Hat и CentOS она выглядит иначе:
$ sudo /sbin/service iptables save
Ничего сложного в настройке и управлении Iptables нет. Основные функции понятны даже новичкам, поэтому утилита и остается стандартом де-факто для всех систем на базе Linux.
Применение и восстановление правил iptables
Правило добавленное через консоль, применяется в фаерволе, но не сохраняется в дальнейшем, поэтому сохранять правила нужно вручную.
iptables-save > /path to file/filename
Если правило добавлено сразу в файл, то оно не применяется в фаерволе и его надо применить.
iptables-restore < /path to file/filename
Для восстановления правил после перезагрузки или включения системы необходимо применять iptables-restore. Чтобы не проделывать процедуру восстановления правил каждый раз, правила можно добавить в автозагрузку.
CentOS
В CentOS добавить правила в автозагрузку можно посредством правки файла rc.local.
# Редактируем файл: nano /etc/rc.d/rc.local # Добавляем в конец файла: /sbin/iptables-restore < /root/iptables_rules # Сохраняем и выходим. # Делаем файл исполняемым: chmod +x /etc/rc.d/rc.local
Теперь правила будут применяться в фаерволе при запуске системы. Для того чтобы запретить загрузку через rc.local, уберите добавленную строку или закомментируйте ее.
#/sbin/iptables-restore < /root/iptables_rules
Debian & Ubuntu
В Debian & Ubuntu все работает также, только rc.local расположен в каталоге /etc, загрузку можно прописать здесь. Можно сделать иначе, в Debian & Ubuntu запуск правил удобнее прописать в конф. файле сетевых интерфейсов /etc/network/interfaces.
# Редактируем файл: nano /etc/network/interfaces # Добавляем строку в конец раздела eth0: pre-up iptables-restore < /root/iptables_rules
Теперь правила будут стартовать совместно с сетевым интерфейсом. Можно делать перезапуск правил путем перезагрузки сетевого интерфейса, для применения внесенных правок.
ifdown eth0 && ifup eth0
Можно пойти дальше и прописать команду для сохранения текущего состояния правил при выключении/перезапуске компьютера или при перезапуске интерфейса.
# Редактируем файл: nano /etc/network/interfaces # Добавляем строку в конец раздела eth0: post-down iptables-save > /root/iptables_rules
Теперь, даже если вы забудете сохранить внесенные изменения в правила, система сделает это автоматически. Файл интерфейсов должен выглядеть примерно так:
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 192.168.1.7 netmask 255.255.255.0 gateway 192.168.1.1 network 192.168.1.0 broadcast 192.168.1.255 # Сохранение правил iptables post-down iptables-save > /root/iptables_rules # Старт правил iptables pre-up iptables-restore < /root/iptables_rules
Данные схемы рабочие, но неудобные, делать сохранение и восстановление правил можно по другому, при помощи специальных утилит. Теперь когда мы знаем механизм работы, можно переходить к изучению утилит помогающих управлять правилами iptables.
Putting It All Together
Now we’ve seen the basics, we can start combining these rules.
A popular UNIX/Linux service is the secure shell (SSH) service allowing remote logins. By default SSH uses port 22 and again uses the tcp protocol. So if we want to allow remote logins, we would need to allow tcp connections on port 22:
# Accept tcp packets on destination port 22 (SSH) iptables -A INPUT -p tcp --dport 22 -j ACCEPT
This will open up port 22 (SSH) to all incoming tcp connections which poses a potential security threat as hackers could try brute force cracking on accounts with weak passwords. However, if we know the IP addresses of trusted remote machines that will be used to log on using SSH, we can limit access to only these source IP addresses. For example, if we just wanted to open up SSH access on our private lan (192.168.0.x), we can limit access to just this source IP address range:
# Accept tcp packets on destination port 22 (SSH) from private LAN iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 22 -j ACCEPT
Using source IP filtering allows us to securely open up SSH access on port 22 to only trusted IP addresses. For example, we could use this method to allow remote logins between work and home machines. To all other IP addresses, the port (and service) would appear closed as if the service were disabled so hackers using port scanning methods are likely to pass us by.
Ports and Protocols
Above we have seen how we can add rules to our firewall to filter against packets matching a particular interface or a source IP address. This allows full access through our firewall to certain trusted sources (host PCs). Now we’ll look at how we can filter against protocols and ports to further refine what incoming packets we allow and what we block.
Before we can begin, we need to know what protocol and port number a given service uses. For a simple example, lets look at bittorrent. Bittorrent uses the tcp protocol on port 6881, so we would need to allow all tcp packets on destination port (the port on which they arrive at our machine) 6881:
# Accept tcp packets on destination port 6881 (bittorrent) iptables -A INPUT -p tcp --dport 6881 -j ACCEPT
Here we append (-A) a rule to the INPUT chain for packets matching the tcp protocol (-p tcp) and entering our machine on destination port 6881 (--dport 6881).
Note: In order to use matches such as destination or source ports (--dport or --sport), you must first specify the protocol (tcp, udp, icmp, all).
We can also extend the above to include a port range, for example, allowing all tcp packets on the range 6881 to 6890:
# Accept tcp packets on destination ports 6881-6890 iptables -A INPUT -p tcp --dport 6881:6890 -j ACCEPT
Конфигурация IPTABLES для веб-сервера
Конфигурация Iptables по умолчанию на CentOS не разрешает доступ к HTTP (TCP порт 80) и HTTPS (TCP ПОРТ 443 )которые использует веб-сервер (например Apache).
Шаг 1: Flush или удалите все IPTABLES правила
# iptables -F # iptables -X # iptables -t nat -F # iptables -t nat -X # iptables -t mangle -F # iptables -t mangle -X
Шаг 2: Установите правила по дефолту
# iptables -P INPUT DROP # iptables -P FORWARD ACCEPT # iptables -P OUTPUT ACCEPT
Шаг 3: Разрешить доступ к SSH и HTTP для 80 порта и HTTPS для 443 порта
# iptables -A INPUT -i lo -j ACCEPT (Данная команда говорит добавить (-А) правило в фильтр входящих соединений (INPUT), разрешающее (-j ACCEPT) любой трафик, поступающий на локальный интерфейс (-i lo). Локальный хост часто используется для размещения базы данных, к которой подключаются веб-сайт и почтовый сервер. Таким образом, VPS имеет доступ к базе данных, но взломать ее через интернет нельзя.) # iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT (еще одно правило, которое позволит устанавливать исходящие соединения) # iptables -A INPUT -p icmp -j ACCEPT (разрешить пинговать этот сервер) # iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT # iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT # iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
Настройка SSH в CentOS
Продолжаем настраивать centos. Внесем некоторые изменения в работу ssh для небольшого увеличения безопасности. Хотя речь стоит вести больше не о безопасности, а об удобстве и эффективности. По-умолчанию, сервис ssh работает на 22 порту и если все оставить как есть, то мы получим огромное количество попыток авторизоваться. Боты сканят непрерывно интернет и подбирают пароли к ssh. Это не доставляет в реальности каких-то серьезных хлопот и тем не менее, подобные запросы забивают лог secure и трятят некоторые ресурсы сервера как миниум на установку соединения и рукопожатия (handshake).
Чтобы немного закрыть себя от сканов простых ботов, изменим порт, на котором работает ssh. Можно выбрать любой пятизначный номер, это не принципиально. От автоматического сканирования это защитит. Повесим демон ssh на 25333 порт. Для этого редактируем файл /etc/ssh/sshd_config.
Раскомментируем строку Port 22 и заменим значение 22 на 25333.
Так же я обычно разрешаю подключаться по ssh пользователю root. Мне так удобнее. Проблем с этим у меня никогда не возникало. Если вы считаете, что это не безопасно, не трогайте эту настройку. Чтобы разрешить пользователю root подключаться по ssh, раскомментируйте строку
Сохраняем файл. Теперь обязательно изменяем настройки iptables, добавляем в разрешенные подключения вместо 22 порта 25333. Если этого не сделать, то после перезапуска sshd мы потеряем удаленный доступ к серверу. Итак, открываем /etc/iptables.sh и меняем в строке
22 на 25333 и исполняем файл. Наше текущее соединение не оборвется, так как оно уже установлено, но заново подключиться по ssh к 22 порту уже не получится.
Перезапускаем sshd:
Кстати, если вы не отключили SELinux, то просто так не сможете сменить порт ssh. Получите ошибку при перезапуске.
Наглядный пример того, как работает защита SELinux. Если у вас кто-то заберется на сервер через какую-то уязвимость и захочет открыть отдельный ssh серввер на каком-то нестандартном порту, у него ничего не получится.
Проверяем какой порт слушает sshd:
Если вывод такой же как у меня, то все в порядке, теперь к ssh можно подключаться по 25333 порту.
Добавим еще одну небольшую настройку. Иногда, когда возникают проблемы с dns сервером, логин по ssh подвисает на 30-60 секунд. Вы просто ждете после ввода логина, когда появится возможность ввести пароль. Чтобы избежать этого замедления, укажем ssh не использовать dns в своей работе. Для этого в конфиге раскомментируем строку с параметром UseDNS и отключим его. По-умолчанию он включен.
Для применения изменений нужно перезапустить ssh службу, как мы уже делали ранее. Настройку службы sshd в centos закончили, двигаемся дальше.
Редактирование файла с конфигурацией
С помощью iptables-save и iptables-restore можно сохранять и восстанавливать
конфигурации.
Выглядят файлы с конфигурацией следующим оригинальным образом
vi fwoff
# Generated by iptables-save v1.4.21 on Fri May 12 00:29:45 2023
*filter
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT
COMMIT
# Completed on Fri May 12 00:29:45 2023
В эти файлы можно вносить изменения. Перед этим желательно восстановить конфигурацию из
какого-то другого файла.
iptables-restore < fwoff
vi fwon
# Generated by iptables-save v1.4.21 on Fri May 12 00:29:45 2023
*filter
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack —ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp —dport 22 -j ACCEPT
-A INPUT -j DROP
COMMIT
# Completed on Fri May 12 00:29:45 2023
Последнее правило запрещает всё что не разрешено явно.
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all — anywhere anywhere
ACCEPT all — anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT tcp — anywhere anywhere tcp dpt:ssh
DROP all — anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Вывод
Это методы, которые могут помочь вам запускать, останавливать, отключать и включать службы управления пакетами в системах на базе Linux. По умолчанию разные дистрибутивы Linux могут иметь разные службы, например: Ubuntu может иметь iptables в качестве службы по умолчанию и предустановленной службы, в то время как CentOS может использовать firewalld в качестве службы по умолчанию для управления входящими и исходящими IP-пакетами.
Представлены наиболее распространенные приемы управления этими службами практически во всех дистрибутивах Linux, однако, если вы найдете что-то и хотите добавить к этой статье, ваши комментарии всегда приветствуются.