# Linux Basics Модуль Занятие 4
## Обеспечение безопасности Linux-серверов
### Практическая работа 4.1 Настройка файревола для защиты файлового сервера
В этой работе мы произведем настройку файлового сервера Samba, а также обеспечим доступ к нему с помощью сервиса iptables.
Задача:
- Получить доступ к папкам и файлам находящимся на файловом сервере Linux, клиентом Linux
- Получить доступ к папкам и файлам находящимся на файловом сервере Linux, клиентом Windows
- Добавить сервис Samba в автозагрузку OS Linux
- Настрить Samba ресурс с названием share и дать права на чтение группе пользователей users, но предоставить возможность записи для группы с именем admins, а также пользователю PT, для этого можете отредактировать файл `/etc/samba/smb.conf`.
- Настройка корзины для общего ресурса (для тех кому показалось легко)
- пояснить команду smbstatus (продемонстрировать, пояснить результат)
В серверной инфраструктуре Windows взаимодействие между компонентами происхоидт, в частности, на основе протокола SMB. Этот протокол позволяет передавать файлы между девайсами и создавать общие (shared) ресурсы (в их число входят общие папки, диски, принтеры и др.), которыми могут пользоваться участники инфраструктуры. Но иногда может потребоваться включение в инфраструктуру также и девайсов на UNIX-подобных ОС.
Для этой цели была придумана утилита Samba. Она позволяет работать с протоколом SMB, который используется в Windows для реализации файловой службы, службы печати, а также службы обмена сообщениями между процессами. Благодаря использованию Samba Linux может симулировать Windows-машины, и таким образом включаться в Active Directory.
Но в этой работе мы будем использовать Samba только для создания файлового сервера, с которым смогут достаточно легко общаться не только другие Linux-машины, но и Windows. Соответственно, в этой работе будут использоваться Linux-сервер, Linux-клиент и Windows-клиент.
#### Часть 1 Настройка Samba сервера
Сервер будет настроен на одной из Linux-машин, но т.к. по умолчанию Linux не работает с SMB, потребуется установка пакетов для работы с Samba для всех Linux
Команда: `sudo apt install samba samba-client`
Органзация Linux-сервера
Далее понадобится организовать папку, которая будет использоваться для файлого сервера, а также набор пользователей, которые будут работать в папке. Нам нужно создать нового пользователя **pt**, группы **users** и **admins**.
Добавление группы admins `sudo addgroup admins`
Добавление учетной записи kali в группу admins
Группа users по умолчанию создается в дистрибутивах Linux, и в нее добавляются все пользователи.
Добавим пользователя user1, который будет входить только в группу users
Команда: `sudo adduser user1`
Добавим пользователя pt, который не будет входить ни в группу users, ни в группу admins
Команды
```
sudo adduser pt
sudo usermod -rG users pt
```
Теперь перейдем к созданию папки, которая будет использоваться для работы файлового сервера.
Команда: `sudo mkdir -p <path>` (флаг -p используется для того, чтобы Linux создал все папки, которых не хватает для полного пути)
Также нам понадобится разрешить работу всех пользователей с этой папкой (т.к. добавление, удаление и вообще все действия с общей папкой выполняются с правами работающих в ней пользователей)
Команда: `sudo chmod -R 0777 <path>` (0777 указывает на свободные возможности работы с папкой и подпапками для всех пользователей)
Теперь нам понадобится внести настройки для сервера Samba. Нам нужно создать сетевую папку, у которой будут раграничены права доступа: admins и пользователь pt смогут свободно работать с папкой (выполнять операции на чтение и запись), группа users сможет только читать файлы из папки (создание новых папок и файлов будет невозможным). Откроем основной файл конфигурации Samba и добавим туда нужные конфигурации:
```
sudo nano /etc/samba/snb.conf
```
```
[global]
workgroup = WORKGROUP
security = user
map to guest = bad user
wins support = no
dns proxy = no
[share]
comment = share
path = /samba/share
guest ok = no
valid users = @users, @admins, pt
read only = yes
write list = @admins, pt
create mask = 0775
directory mask = 0775
force create mode = 0775
force directory mode = 0775
```
*Обяснянение конфигураций*
Все настройки делятся на две части: глобальная настрока и настройка общей папки (share). Блоки настройки выделяются именами блоков в квадратных скобках
Глобальная настройка:
+ workgroup - указание рабочей группы Windows, значение по умолчанию - WORKGROUP
+ security = user - установка режима безопасности для аутентификации по логину и паролю
+ map to guest = bad user - указание на отклонение входа при неправильном пароле для существующей учетной записи
+ wins support - поддержка WINS (службы разрешения имен серверов), здесь она ни к чему
+ dns proxy - возможность запрсоов по DNS
+ comment - установка комментария
+ path - путь до папки, которая используется для общего доступа
+ browseable = yes - разрешение на получение доступа к папке не только через прямой путь (папку можно будет увидеть, если обращаться к серверу по его IP адресу)
+ guest ok = no - запрет гостевых учетных записей
+ valid users - список пользователей, которым разрешен доступ до папки (указываются через запятую, перед группой ставится @)
+ read only - режим по умолчанию для пользователей (могут только просматривать папки и файлы, изменение невозможно) (благодаря этому пользователи группы users смогут просматривать каталоги)
+ write list - список пользователей, которые могут также изменять директорию (добавляются только пользователи, которым разрешено изменение - группа admins и пользователь pt)
+ create mask, directory mask, force create mode, force directory mode - тип доступа, который получают папки и файлы после создания.
После занесения настроек, проверим корректность файла конфигураций через команду `sudo testparm`, после чего перезапустим службу (название - **smbd**)
Теперь нам потребуется добавить уже созданные аккаунты из Linux в базу пользователей Samba. Делается это командой `sudo smbpasswd -a <user>` (флаг -а отвечает за добавление пользователя, для удаления использовать флаг -r)
Теперь можем перейти ко входу на файловый сервер.
Для входа через Windows понадобится набрать IP-адрес сервера и название папки общего доступа в таком формате:
```
\\<ip>\<name>
\\192.168.138.228\share
```
После появится окно, которое спросит логин и пароль
Для Linux-клиента понадобится использование утилиты smbclient
Вид команды:
```
smbclient //<ip>/<name> -U <username>
```
*где username указывает на учетную запись, от имени которой будет происходить взаимодейтсвие с папкой*
После появится диалог о ввдое пароля для ползователя. При успешной авторизации появится терминальный интерфейс, схожий с интерфейсом протокола FTP
Для начала зайдем на сервер с помощью УЗ user1 на Windows
Мы сможем посмотреть на то, что лежит в каталогах в сетевой папке. Но при попытке создания файла или удаления имеющихся папок
получим ошибку доступа
*Примечание*
После ввода данных Windows автоматически сохранит их для последующих сессий. Для того, чтобы посмотреть данные сохраненных сессий, используется команда `net use` в PowerShell
Для удаления данных нужно указать к команде путь до подключения и команду */dell*
Попробуем получить доступ к user1 через Linux-клиент
Мы можем посмотреть папки
Но создание новой папки будет невозожным из-за ошибки доступа.
Попробуем использовать учетные данные пользователя pt (он не принадлежит ни к одной группе, но имеет полные права взаимодействия с общим ресурсом)
Создание папки станет возможным.
Набор действий по созданию папки с УЗ pt, но уже на Linux
И те же действия от имени пользователя kali (принадлежит к группе admins)
В samba можно отслеживать состояние подключения пользователей. Для этого используется команда *smbstatus*
Она выводит ID процесса, который занимается редактированием\просмотром общего ресурса, пользователя, под которым произведен вход, IP-адрес, с которого произведен вход, а также инфорация о том, какой общий ресурс редактируется.
#### Часть 2 Использование iptables для ограничения доступа к серверу.
iptables используется в качестве файервола в Linux. Утилита может запрещать доступ по IP-адресу, порту и протоколу.
Вся работа утилиты состоит в том, чтобы прогонять все входящие и исходящие запросы через набор таблиц, которые содержат цепочки правил. Если заголовки пакета совпадают с данными в цепочке, утилита выполнит отмеченное в таблице действие (благодаря этому можно либо пропустить трафик дальше, либо отклонить его, либо выкинуть)
В этой части работы задача состоит в том, чтобы разрешить доступ к файловому серверу только из внутренней сети. Для того, чтобы более явно показать работу iptables, к сети будут причислены только сервер и один из клиентов, с которых ранее производился доступ до сервера (выбор будет производиться по значениям IP адресов).
Посмотрим IP адреса машин:
Windows (для получения доступа к информации об IP-адресе можно либо пройти в настройки адаптера сети, либо использовать команду Get-NetIPAddresss в Windows PowerShell)
Linux-клиент
Linux-сервер
На основе данных об IP адресе выберем диапазон сети 192.168.138.128\25 (он включит Linux-сервер и Linux-клиент, что позволит продемонстрировать работу iptables)
Теперь более детально определимся с доступом клиентов к серверу. Благодаря пакетам Samba SMB протокол использует TCP для взаимодейтсвия на портах 445 и 139, а также UDP для работы на портах 137 и 138.
На основе полученных данных рождается цепочка правил для iptables
```
iptables -A INPUT -p tcp -m tcp --dport 445 -s 192.168.138.128/25 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 139 -s 192.168.138.128/25 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 137 -s 192.168.138.128/25 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 138 -s 192.168.138.128/25 -j ACCEPT
iptables -A INPUT -s 0.0.0.0\0 -j REJECT
```
Теперь если мы попытаемся подключиться к серверу через Windows, то получим сообщение о недостижимости сервера
Но через Linux подключение все еще будет возможным
Теперь изменим правила так, чтобы все компьютеры во внутренней сети могли взаимодействовать с файловым сервером (для этого понадобится расширить сеть адреса отправки запроса до 192.168.138.228/24)
Эти настройки iptables будет хранить до первой перезагузки Linux. Нам понадобится сохранить настройки.
Для этого используется дополнительный модуль *iptables-persistent* Он сохраняет настройки iptables при завершении работы сервера и восстанавливает их при запуске.
Произведем установку
```
sudo apt install iptables-persistent
```
При первой установке программа может спросить о сохранении настроек
Далее добавим сервис утилиты в автозагрузку
```
sudo systemctl enalbe netfilter-persistent
```
После чего, если правила были изменены, используем утилиту *iptables-save* Эта утилита выводит все настройки в консоль при применении без аргументов.
По умолчанию, права для восстановления хранятся по пути */etc/iptables/* в файлах rules.v4 и rules.v6. Сохраним настройки в соответствующий файл путем направления вывода команды.
Теперь перезагрузка сервера не почем iptables
#### Часть 3 Настройка сетевой корзины.
Сейчас при удалении файлы удаляются с сервера безвозвратно. Дополнительное улучшение, которое можно принести на сервер - создать сетевую корзину, в которую будут попадать файлы прежде чем быть полностью удаленными.
Сетевая корзина представляет из себя дополнительную папку, в которую перемещаются файлы при вызове на девайсе клиента удаленного запроса на удаление файла или папки. С помощью Samba мы можем отловить запрос на удаление и перенаправить файл в специальную папку.
Настроим сетевую корзину.
Сначала создадим специальную папку, которая будет использоваться в качестве корзины (создаем папку с точкой в начале, чтобы она не была видна при просмотре). Также ей нужно будет выставить права на свободный доступ, как и общей папке для файлового сервера.
Далее нужно будет добавить дополнительные настройки в конфигурации Samba в месте настройки общей папки
```
recycle:version = yes
recycle:touch = yes
recycle:keeptree = yes
recycle:repository = <path>/%U
recycle:directory_mode = 0777
recycle:subdir_mode - 0777
vfs objects = recycle
```
*Объяснение настроек*
+ vfs objects - добавление в Samba возможности управления действиями при удалении файла
+ recycle:versions - установка версий удаляемого объекта (если имена одинаковые)
+ recycle:touch - изменение времени последнего взаимодействия с файлом
+ recycle:keeptree - перемещение файла в корзину вместе с поддеревом при удалении
+ recycle:repository - путь до папки, которая считается корзиной, *%U* в записи добавляет для каждого пользователя свою папку, благодаря чему пользователи не увидят удаленные файлы друг друга
+ directory_mode, subdir_mode - уровни прав доступа, которые ставятся переносимым файлам
Также добавим папку, которая будет использоваться для доступа к корзине (чтобы пользователи могли восстановить удаленные объекты)
```
[Recycle]
comment=Recycle
path = <path>/%U
available = yes
browseable = yes
read only = yes
guest ok = no
valid users = @users, @admins, pt
public = yes
writable = yes
write list = @admins, pt
```
*Объяснение настроек*
Для объявления такой папки достаточно указать путь на корзину и предоставить такие же права на чтение и запись, как и у основной сетевой папки
После внесения изменений перезагрузим процесс
И проверим работу удаления
При просмотре сруктуры каталога, мы видим, что файл сохраняется в корзине в папке с именем пользователя.
### Практическая работа 4.2 Организация Brute-Force атаки на SSH-сервер и защита его с помощью Fail2Ban
Более мощной утилитой для управления защитой сервера является Fail2Ban. Она позволяет блокировать отдельные IP адреса в зависимости от событий в других процессах (к примеру, излишне большое количество попыток входа в аккаунт, или слишком частое обращение к серверу).
Попробуем использовать его для блокировки слишком частого обращения к SSH серверу для ввода неправильного пароля.
1. Установим Fail2Ban
Команда: `sudo apt install fail2ban`
2. Настроим и запустим SSH сервер
Нам будет достаточно базовых настроек, кроме одного момента. Т.к. мы собираемся взламывать сервер с помощью brute-force атак, нам нужно выключить учет количества попыток, который ведет сам ssh.
Делается это с помощью пункта *MaxAuthTries* в конфиге sshd. Нам нужно сильно поднять изначально записанное значение.
Теперь сохраним настройки и перезапустим сервер SSH
3. Настройка fail2ban
Для начала посмотрим на все файлы, которые используются для настройки fail2ban
Сама по себе настройка состоит в том, чтобы определить "тюрьмы" или процессы учета каких-либо действий, сами учитываемые действия, а также то, что происходит после истечения счетчика (обычно как-либо блокируется доступ к сервису)
Основную роль играет файл jail.conf, его и откроем
Здесь нас встречает объявление, что этот файл лучше не модифицировать из-за того, что данные в этом файле могут быть изменены при обновлении, а использовать отдельный файл jail.local для хранения своих настроек.
Создадим этот файл в этой директории. и впишем в него настройки.
```
[sshd]
enable=true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 60
ignoreip = 127.0.0.1
```
*Объяснение настроек*
Настройку мы производим для sshd процесса (рассматриваем запросы, обращенные к нему)
+ port - отвечает за то, с какого порта к процессу сервера идут запросы - на этом сервере используется порт 22 (по умолчанию)
+ logpath - место, откуда fail2ban берет рассматриваемую информацию
+ filter - значение, по которому он фильтрует logpath
+ maxretry - количество ошибок, которые могут возникнуть до добавления источка событий в "тюрьму"
+ bantime - время нахождения в тюрьме
+ ignoreip - какой ip не подпадает под правило с тремя попытками входа
Теперь перезапустим fail2ban чтобы применить настройки
4. Демонстрация работы
Используем другой Linux клиент чтобы попробовать подключиться к SSH-серверу и намеренно допустим 3 ошибки при вводе пароля
В четвертый раз диалог о вводе пароля получен не будет
В файле /var/log/auth.log, в который выводится вся информация о попытках входа, в частности, через ssh, увидим, что было отловлено больше чем разрешено операций входа
В то же время, если мы посмотрим на состояние "тюрьмы" sshd, то увидим количество невыполненных аутентификаций (если их счетчик превысит 3, ip-адрес не сможет обратиться к SSH-серверу вообще)
Повторим действия по набору неправильного пароля еще несколько раз и посмотрим на состояние тюрьмы
IP-адрес внесен в бан-лист, а обращение к серверу не дает никакого ответа.
5. Использование brute-force атаки
Попробуем атаковать ssh-сервер с помощью brute-force атаки, которая заключается в переборе пароля для входа в систему.
Для этого используется утилита hydra.
Команда:
`sudo hydra -l ubu -P /usr/share/hydra/dpl4hydra_local.csv ssh://<ip> -I -v`
*Объяснение команды*
+ l - логин, который используется для входа
+ P - использование пароля из списка в файле (после идет путь до файла)
+ ssh://\<ip\> - указание ip адреса и сервиса для атаки
+ v - вывод информации о процессе подбора пароля
Через несколько секунд после запуска команды fail2ban заблокирует любые обращения с ip-адреса Linux клиента
Если мы отключим fail2ban
То при перезапуске атаки увидим, что поиск пароля происходит, и не заканчивается
### Практическая работа 4.3 Орагнизация DOS-атаки на nginx сервер и защита сервера.
Попробуем организовать атаку большим количеством запросов к серверу так, чтобы сервер перестал отвечать на запросы в течение некоторого времени.
Для начала потребуется установка nginx - сервиса обслуживания веб-сайтов, похожего на Apache.
1. Установка и настройка nginx
Установку будем производить путем выгрузки компонентов сервиса из репозитория разработчика, а не из репозитория ОС. Делается это для получения новейшей версии веб-сервера и выбора одной из нескольких версий nginx (есть разные версии, отличающиеся доступными возможностями и стабильностью работы)
1.1 Установим пакеты, необходимые для подключения репозитория
Команда: `sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring`
1.2 Скачаем официальный GPG ключ шифрования, который менеджер apt использует для проверки подлинности скачиваемых из репозитория пакетов
Команда: `curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
| sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg`
1.3 Теперь проверим, что ключ установлен правильно
Команда: `gpg --dry-run --quiet --no-keyring --import --import-options import-show /usr/share/keyrings/nginx-archive-keyring.gpg`
Должен появиться такой вывод (отпечаток ключа и время его действия).
1.4 Теперь нужно подключить репозиторий. Здесь также происходит выбор версии nginx (стабильная, или же включающая последние возможности). Подключим репозиторий со стабильной версией
Команда: ```echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
http://nginx.org/packages/debian `lsb_release -cs` nginx" \
| sudo tee /etc/apt/sources.list.d/nginx.list```
1.5 Теперь обновляем настройки менеджера пакетов и устанавливаем nginx (как при обычной установке пакетов)
Команды:
```
sudo apt update
sudo apt install nginx
```
1.6 Проверим, что сервис установился. Для этого нужно перейти в бразуере по IP-адресу нашего сервера (на самом сервере можно использовать IP 127.0.0.1)
Если до этого был установлен Apache, потребуется заменить начальную страницу, которая отображается при заходе на IP-адрес сервера.
1.7 Переместиться по пути `/var/www/html` (там хранятся страницы для отображения веб-серверами)
В папке мы увидим две страницы. Нас интересует страница *index.nginx-debian.html* Она не отображается. т.к. есть страница index.html. Мешающую страницу нужно переместить в папку, чтобы *index.nginx-debian.html* стала основной.
1.8 Теперь после проверки мы увидим начальную страницу nginx
1.9 Теперь перейдем к настройке. Нам нужно искусственно ограничить возможноти сервера по обработке запросов. Для этого мы изменим лимит количества обрабатываемых запросов в единицу времени. Для этого нужно перейти в файл настройки работы веб-страниц nginx: */etc/nginx/sites-enable/default*. Сам файл состоит из набора конфигураций, которым прописываются либо одиночные значения, либо наборы значений (в фигурных скобках) - контексты.
Нам нужно отыскать в контексте server опцию location и добавить в конец ее контекста следующие строки:
`limit_req zone=ltwo burst=5 nodelay`
Эта директива определяет зону, в которой сервер считает выполняемые запросы. Параметр *burst* определяет количество запросов, которые будут выполнены сверх скорости обработки запросов.
1.10 Перейдем к настройкам самого nginx. Нам нужно расписать скорость обратботки запросов на сервере Для этого перейдем по следующему пути в файл: */etc/nginx/nginx.conf*
В этом файле в контексте http нужно вставить следующую строку:
`limit_req_zone $binary_remote_addr zone=ltwo:10m rate=1r/s;`
Она определяет для нашей зоны скорость обработки запросов (3 в секунду).
Применим настройки и перезагрузим сервис
Теперь ngixn настроен и мы можем провести атаку. Эта атака заключается в отправке слишком большого количества запросов на сервер. Для этого нам достаточно открыть на машине-клиенте веб-страницу сервера и много раз нажать сочетание клавиш *Ctrl+R* (в большинстве бразуеров оно используется для перезагрузки страницы)
Через некоторое время мы получим ошибку 503 о недоступности сервера (если подождать несколько секунд и перезагрузить еще раз, сервер ответит нам страницей nginx)
Также информация о том, что сервер перестал отвечать на запросы, появится в логах ошибок nginx (путь до логов: /var/log/nginx/error.log)
Нам нежелательно получение ошибки 503 из-за того, что страницу умышленно перезагрузили слишком большое количество раз. Поэтому мы используем инструменты fail2ban для того, чтобы забанить пользователей, которые атакуют сервер.
Для этого сначала установим fail2ban, если он еще не установим, а также поставим дополнительный пакет *ipset*, который позволяет fail2ban эффективнее блокировать большое количетсво запросов
Теперь перейдем к настройке 'тюрьмы' fail2ban. Для этого сначала перейдем в файл /etc/fail2ban/jail.conf и найдем начально описание тюрьмы *nginx-limit-req*
В коментарии говорится, что нам нужно объявить зону просмотра запросов, чтобы использовать эту тюрьму. Мы ее уже объявили при настройке сервера nginx.
Сам по себе файл jail.conf не изменяется, т.к. настройки в нем могут быть стерты при обновлении пакетов. Но по умолчанию, этот файл импортирует настройки из другого файла - jail.local (он уже никак не затрагивается при обновлении). В нем и опишем настройки нашей тюрьмы
```
[nginx-limit-req]
port = http, https
enabled = true
filter = nginx-limit-req
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]
logpath = /var/log/nginx/*error.log
findtime = 600
bantime = 3600
maxretry = 4
```
*Объяснение настроек*
Тюрьма используется для запросов на порты http, https, при этом для отслеживания подозрительной активности используется файл /var/log/nginx/error.log. Весь файл фильтруется по фильтру nginx_limit_req. Для отфильтрованных событий выполняется действие по блокировке ip-адреса через утилиту iptables на 3600 секунд. Система пропустит первые 4 перезагрузки с одного IP адреса и не выдаст бан, следующие события уже будут заблокированы.
Если запросов с одного ip-адреса будет слишком много, будет правильным вообще не отвечать запросы такого клиента. Поэтому нужно внести изменения в настройки действий для заблокированных адресов (вместо действия REJECT, которое говорит серверу отправить сообщение о невозможности принятия, нужно выставить дейтсвие DROP, чтобы не тратить ресурсы системы).
Для этого нам нужно модифицировать настройки файла */etc/fail2ban/action.d/iptables-common.conf*
Этот файл тоже может быть изменен при обновлении, поэтому нам следует создать файл iptables-blocktype.local и внести свои настройки по изменению поведения iptables в него
Создадим этот файл в той же папке, в которой хранится iptables-common.conf и добавим следующие строки
```
[INIT]
blocktype = DROP
```
Эти стоки добавят новый тип дейтсвия. который fail2ban будет прописывать в iptables для блокировки нежелательных IP адресов
Теперь перезапустим fail2ban и проверим, что во внесенных конфигурациях нет ошибок
Проверим, что fail2ban создал нам тюрьму *nginx-limit-req*
И проверим, что в тюрьме пока нет никаких адресов
После чего убедимся, что правил в iptables нет (потому что никто еще не забанен)
А теперь проведем атаку по прошлому принципу с частой перезагрузкой веб-страницы сервера. Fail2ban отловит умышленные действия и перенесет ip-адрес машины-клиента в тюрьму
Теперь вместо ошибки 503 мы получим сообщение о невозможности подключения к серверу (все наши запросы отклоняются)
В тюрьме fail2ban наш адрес отображается как забаненный
А в iptables появилась новая таблица, в которой адрес машины клиента поставлен на DROP (все запросы клиента игнорируются)
Sign in with Wallet
Connect another wallet