Підвищення безпеки для FreeBSD за допомогою IPFW і SSHGuard

Сервери VPS часто стають мішенню зловмисників. Поширений тип атаки відображається в системних журналах у вигляді сотень несанкціонованих спроб входу через ssh. Налаштування брандмауера дуже корисно, але само по собі може не контролювати руйнівні спроби вторгнення.

У цьому підручнику показано, як створити розширений бар’єр вторгнення для FreeBSD за допомогою двох програм, ipfwбрандмауера та sshguard. SSHGuard — це невелика додаткова програма, яка відстежує системні журнали на наявність «зловживаючих» записів. Коли правопорушники намагаються отримати доступ, sshguardінструкція ipfwблокувати трафік, що надходить з IP-адреси порушника. Тоді правопорушника фактично закривають.

Коли ви зрозумієте, як працюють ці програми, керувати захистом сервера досить просто. Хоча цей посібник зосереджено на налаштуванні FreeBSD, його частини застосовуються до інших ОС і програмного забезпечення брандмауера.

Крок 1. Налаштування IPFW

FreeBSD надає 3 брандмауери в GENERICядрі за замовчуванням ( ) ipfw, pf, і ipfilter. Кожен з них має переваги та шанувальники, але ipfwє рідним програмним забезпеченням брандмауера FBSD і досить простим у використанні для наших цілей. Варто зазначити, що він ipfwвиконує багато речей, як показує його сторінка керівництва , однак такі можливості, як NAT, формування трафіку тощо, не потрібні для типової ситуації VPS. На щастя, основні функції брандмауера легко відповідають нашим вимогам.

Щоб запустити брандмауер під час завантаження, додайте наступне до /etc/rc.conf:

firewall_enable="YES"
firewall_script="/usr/local/etc/IPFW.rules"
firewall_logging="YES"

Доступна serviceкоманда для запуску/зупинки брандмауера вручну:

[user@vultr ~]$ sudo service ipfw start

Природно, ipfwне буде робити нічого, доки не додасть правила, часто з файлу, у цьому прикладі, розташованому за адресою /usr/local/etc/IPFW.rules. Фактично, файл правил може розташовуватися де завгодно або мати будь-яку назву, якщо він відповідає параметру «firewall_script». Файл правил детально описано нижче.

Крок 2. Встановіть та налаштуйте SSHGuard

sshguardпредставлений у кількох варіантах для використання з різними брандмауерами. Використовуйте pkgутиліту для отримання та встановлення sshguard-ipfw:

[user@vultr ~]$ sudo pkg install sshguard-ipfw

У більшості випадків це все, що потрібно зробити. Відповідна змінна автоматично вставляється /etc/rc.confдля запуску під час завантаження:

sshguard_enable="YES"

Значення за замовчуванням зазвичай працюють добре. Якщо потрібні інші значення, sshguardсторінка man надає детальну інформацію про параметри:

# sshguard--program defaults, so don't need to be in rc.conf unless assigning different value
# sshguard_pidfile="/var/run/sshguard.pid"
# sshguard_watch_logs="/var/log/auth.log:/var/log/mail"
# sshguard_blacklist="40:/var/db/sshguard/blacklist.db"
# sshguard_safety_thresh="40"
# sshguard_pardon_min_interval="420"
# sshguard_prescribe_interval="1200"

Ви можете почати sshguardзі звичайного serviceвиклику:

[user@vultr ~]$ sudo service sshguard start

Крок 3. Створіть сценарій правил

Найважче створити набір правил брандмауера. ipfwможе використовувати наданий /etc/rc.firewallсценарій, але його потрібно змінити, щоб пристосувати SSHGuard, а також різні сценарії роботи. Кілька веб-сторінок і посібник з FreeBSD містять корисну інформацію про це. Однак написати файл правил не так вже й складно, крім того, користувацький набір правил легше зрозуміти та змінити, коли це необхідно.

Важливою особливістю ipfwправил є те, що перший матч перемагає, а це означає, що порядок правил важливий. У ipfwкожне правило є командою, а файл правила є виконуваним сценарієм оболонки. Це дозволяє змінювати набір правил, змінюючи правила, а потім запускаючи файл правил як сценарій оболонки:

[user@vultr /usr/local/etc]$ sudo ./IPFW.rules

Як правило, файл правил визначає змінну для ipfwкоманди, потім очищає поточні правила, видає загальні правила, а потім переходить до встановлення правил «out», а потім «вхідних». Сторінка посібника ipfw та інші ресурси містять велику кількість інформації про структуру правил і параметрів, яких, м’яко кажучи, багато.

Оскільки версія FreeBSD sshguard була оновлена ​​до версії 1.6.2, метод вставки правил блокування для порушників змінився. Тепер адреси правопорушників зберігаються в таблиці ipfw (точніше таблиця 22), а не вставляються в правила вище 55000, як раніше.

На щастя, налаштувати файл правил для використання таблиці досить просто. Це просто питання розміщення правила таблиці в потрібному місці та використання правильного синтаксису під час написання правила.

Знайшовши sshguardправопорушника, він поміщає адресу порушника до свого чорного списку, а також вставляє адресу в ipfwтаблицю, щоб «запустити» заборону доступу. Це правило досягне таких цілей:

01000 deny ip from table\(22\) to any

У цьому випадку все одно необхідно встановити правила, що дозволяють вхідні послуги вище 01000. Наприклад, припустимо, що адреса 10.20.30.40є злочинцем у таблиці 22, і ми маємо таке правило ipfw:

56420 allow tcp from any to me dst-port 22 in via $vif

Оскільки ipfwзустріч правити 01000 перед тим правилом 56420 , 10.20.30.40буде заблоковано . Правило «дозволити 22 увійти» взагалі ніколи не побачить цього. Якби правило дозволу мало "звичайний" номер, наприклад 00420 , поганий трафік буде пропущений і ніколи не заблокований (оскільки 00420 менше 01000 і "перемагає перший матч").

Приємною особливістю оновленої версії є те, що тепер, коли sshguard запускається, всі адреси з чорного списку додаються до таблиці та доступні для блокування вхідних правопорушників без затримки. Чорний список накопичується і зберігається між сеансами.

На цьому етапі, ймовірно, доцільно показати повний ipfwнабір правил, змінений для sshguard. Коментарі мають полегшити дотримання логіки правила:

#!/bin/sh

# ipfw config/rules
# from FBSD Handbook, rc.firewall, et. al.

# Flush all rules before we begin.
ipfw -q -f flush

# Set rules command prefix
cmd="ipfw -q add "

vif="vtnet0"

# allow all for localhost
$cmd 00010 allow ip from any to any via lo0

# checks stateful rules.  If marked as "keep-state" the packet has
# already passed through filters and is "OK" without futher
# rule matching
$cmd 00101 check-state

# allow DNS out
$cmd 00110 allow tcp from me to any dst-port 53 out via $vif setup keep-state
$cmd 00111 allow udp from me to any dst-port 53 out via $vif keep-state

# allow dhclient connection out (port numbers are important)
$cmd 00120 allow udp from me 68 to any dst-port 67 out via $vif keep-state

# allow HTTP HTTPS replies
$cmd 00200 allow tcp from any to any dst-port 80 out via $vif setup keep-state
$cmd 00220 allow tcp from any to any dst-port 443 out via $vif setup keep-state

# allow outbound mail
$cmd 00230 allow tcp from any to any dst-port 25 out via $vif setup keep-state
$cmd 00231 allow tcp from any to any dst-port 465 out via $vif setup keep-state
$cmd 00232 allow tcp from any to any dst-port 587 out via $vif setup keep-state

# allow icmp re: ping, et. al. 
# comment this out to disable ping, et.al.
$cmd 00250 allow icmp from any to any out via $vif keep-state

# alllow timeserver out
$cmd 00260 allow tcp from any to any dst-port 37 out via $vif setup keep-state

# allow ntp out
$cmd 00270 allow udp from any to any dst-port 123 out via $vif keep-state

# allow outbound SSH traffic
$cmd 00280 allow tcp from any to any dst-port 22 out via $vif setup keep-state

# otherwise deny outbound packets
# outbound catchall.  
$cmd 00299 deny log ip from any to any out via $vif

# inbound rules
# deny inbound traffic to restricted addresses
$cmd 00300 deny ip from 192.168.0.0/16 to any in via $vif
$cmd 00301 deny ip from 172.16.0.0/12 to any in via $vif
$cmd 00302 deny ip from 10.0.0.0/8 to any in via $vif
$cmd 00303 deny ip from 127.0.0.0/8 to any in via $vif
$cmd 00304 deny ip from 0.0.0.0/8 to any in via $vif
$cmd 00305 deny ip from 169.254.0.0/16 to any in via $vif
$cmd 00306 deny ip from 192.0.2.0/24 to any in via $vif
$cmd 00307 deny ip from 204.152.64.0/23 to any in via $vif
$cmd 00308 deny ip from 224.0.0.0/3 to any in via $vif

# deny inbound packets on these ports
# auth 113, netbios (services) 137/138/139, hosts-nameserver 81 
$cmd 00315 deny tcp from any to any dst-port 113 in via $vif
$cmd 00320 deny tcp from any to any dst-port 137 in via $vif
$cmd 00321 deny tcp from any to any dst-port 138 in via $vif
$cmd 00322 deny tcp from any to any dst-port 139 in via $vif
$cmd 00323 deny tcp from any to any dst-port 81 in via $vif

# deny partial packets
$cmd 00330 deny ip from any to any frag in via $vif
$cmd 00332 deny tcp from any to any established in via $vif

# allowing icmp re: ping, etc.
$cmd 00310 allow icmp from any to any in via $vif

# allowing inbound mail, dhcp, http, https
$cmd 00350 allow udp from any 53 to me in via $vif
$cmd 00360 allow tcp from any 53 to me in via $vif
$cmd 00370 allow udp from any 67 to me dst-port 68 in via $vif keep-state

$cmd 00400 allow tcp from any to me dst-port 80 in via $vif setup limit src-addr 2
$cmd 00410 allow tcp from any to me dst-port 443 in via $vif setup limit src-addr 2

# SSHguard puts offender addresses in table 22. Set up the table rule
# Please note the '\(22\)' syntax, necessary since it's run as shell command
$cmd 01000 deny ip from table\(22\) to any

# allow inbound ssh, mail. PROTECTED SERVICES: numbered ABOVE sshguard blacklist range 
$cmd 56420 allow tcp from any to me dst-port 22 in via $vif setup limit src-addr 2
$cmd 56530 allow tcp from any to any dst-port 25 in via $vif setup keep-state
$cmd 56531 allow tcp from any to any dst-port 465 in via $vif setup keep-state
$cmd 56532 allow tcp from any to any dst-port 587 in via $vif setup keep-state

# deny everything else, and log it
# inbound catchall
$cmd 56599 deny log ip from any to any in via $vif

# ipfw built-in default, don't uncomment
# $cmd 65535 deny ip from any to any

Крок 4. Запуск і тестування

Потреби системи відрізняються, і різні варіанти портів для блокування або розблокування відображаються в наборі правил. Після завершення набору правил збережіть файл у /usr/local/etc/IPFW.rulesта запустіть служби FBSD:

 # service ipfw start
 # service sshguard start

Тепер розширений брандмауер має працювати! Перевірити sshguard:

 [user@vultr ~]$ sudo pgrep -lfa ssh

Якщо sshguardзапущено, відображаються його pid і повний командний рядок:

720 /usr/local/sbin/sshguard -b 40:/var/db/sshguard/blacklist.db -l /var/log/auth.log -l /var/log/maillog -a 40 -p 420 -s 1200 -w /usr/local/etc/sshguard.whitelist -i /var/run/sshguard.pid

Це показує набір правил брандмауера зі статистикою та останній раз, коли пакет відповідав правилу:

 [user@vultr ~]$ sudo ipfw -cat list

Через години чи дні адреси правопорушників додаються до чорного списку, а також до таблиці 22. Щоб переглянути всі адреси в таблиці, скористайтеся цією командою:

ipfw table 22 list

Результат друкується як:

10.10.10.118/32 0
10.10.10.72/32 0
...

Як описано вище, підключення з цих адрес заборонено. Звичайно, під час першого запуску sshguardв списку не буде жодної адреси, але з часом він може стати досить довгим. Одним з варіантів є створення окремих правил блокування для адрес із кількома записами в таблиці, а потім видалення їх із чорного списку.

Крок 5. Будьте пильними...

Бажано час від часу перевіряти журнали, щоб переконатися, що вторгнення контролюються. Загалом /var/log/auth.logі /var/log/securityінформативні. Можуть стати очевидними прогалини або помилки в охопленні мережевих послуг. Змінення набору правил брандмауера за потреби є звичайною частиною адміністрування сервера.

У попередніх версіях sshguard, коли /var/db/sshguard/blacklist.dbфайл збільшувався, він міг запобігти sshguardзапуску під час завантаження системи. Видалення або перейменування файлу чорного списку дозволено sshguardпочати. Здається, цю проблему вирішено в останній версії sshguard, тому цей обхідний шлях, ймовірно, більше не потрібен.

Обов’язково внесіть в білий список IP-адресу, з якої ви підключені до сеансу SSH. Якщо ви випадково заблокуєте себе, ви завжди можете підключитися до консолі noVNC на https://my.vultr.com і додати свою IP-адресу в білий список.

Підводячи підсумок, використання комбінації ipfwта sshguardдопомагає підтримувати вашу систему FreeBSD в безпеці та виконувати свою роботу. Зведення до мінімуму нав’язливої ​​мережевої активності має додаткову перевагу: менше «шуму» полегшує відстеження та налаштування роботи системи, сприяючи безпечнішому та краще працюючому серверу.

Ефективний захист системи/сервера FreeBSD не є особливо складним. Хоча для його запуску потрібні скромні зусилля, це окупається значно більшою безпекою VPS та проектом.