Ubuntu server

Озаботившись бэкапами на своем скромном сервере я столкнулся с очевидным дальнейшим шагом а где все это добро хранить?

Выбора особо нет да и у меня есть халявный Яндекс Диск на котором со всеми бонусами у меня аж 63 Гб, грех не воспользоваться.

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

Давайте потратим минут 10-15 и на год забудем о проблеме, поехали.

Вводные данные на чем у меня все работает:

Ubuntu 18.04Yandex.Disk консольный клиент для одноименного дистрибутива

1. Зайдем под тем логином из по которого работает ваш ЯД по адресу https://oauth.yandex.ru/ и нажмем кнопочку Зарегистрировать новое приложение

   
   
   

2. Заполняем поля как указано на скриншоте

   
   
   

3. В пункте Доступы выберите Яндекс Диск REST API и поставьте галочки как на скриншоте

   
   
   

4. Спускаемся в самый низ страницы и жмем кнопку Создать приложение

   
   
   

5. В полученной странице есть все необходимые нам данные, обязательно сохраните их (PS мои реальные данные я удалил но сохранил вам на скрине для наглядности, у вас они будут другие)

   
   
   

6. Получим токен, зайдем браузером по адресу https://oauth.yandex.ru/authorize?response_type=token&display=popup&client_id=ВАШid где в самом конце укажем ID полученный в шаге 5

   
   

7. На этой странице жмем Разрешить

   
   
   

8. На этой странице увидим выданный токен, обязательно сохраните его!

   
   
   

9. Зайдем в консоль вашего сервера под рутом и создадим скрипт

   
   

   nano /root/yadisk.sh
   

   
   

   В котором пропишем следующие команды

   
   

   #!/bin/sh/usr/bin/curl -s -H "Authorization: OAuth ваш_токен" -X "DELETE" https://cloud-api.yandex.net/v1/disk/trash/resources/?path=
   

   
   

   где на месте ваш_токен внесем данные из шага 8

   
   

10. Сохраним скрипт и сделаем его исполняемым

    
    

    chmod 700 /root/yadisk.sh
    

    
    

11. Дадим команду crontab -e
    в открывшемся окне напишем

    
    

    0 3 * * * /root/yadisk.sh > /dev/null 2>&1
    

    
    

    Сохраним файл, сервис крон автоматически примет эти данные и запустит в указанное время. В данном случае это будет происходить каждый день в 3 часа ночи каждый год.

    
    

Ну вот и все, я дольше писал статью и делал скриншоты чем вы все это сможете реализовать у себя :)
Маленький совет я решил очищать корзину ДО того как будет запускаться следующий мой скрипт, который бэкапит базы данных моих сайтов, таким образом я могу быть чуть более спокоен что места на диске хватит для моих данных.

Если хотите убедиться что вы все сделали правильно то можете просто запустить эту команду в консоли

/usr/bin/curl -s -H "Authorization: OAuth ваш_токен" -X "DELETE" https://cloud-api.yandex.net/v1/disk/trash/resources/?path=

(не забудьте в эту строку внести ваш_токен)
и убедиться что корзина вашего аккаунта пуста.

На этом разрешите откланяться.

В рамках данного туториала настроим реверс прокси для работы наших сайтов в прозрачном режиме за 10 минут. Поехали.

Мною была поставлена задача что бы на моем сервере под руководством Proxmox с пулом сайтов работала без проблем прозрачная маршрутизация между посетителем и конечным сайтом. Т.к. в инете полно мануалов по базовой настройке Haproxy я столкнулся с проблемой что 99% этих статей описывают работ прокси сервера в режиме терминации а дальше информация идет по не защищенному варианту (от прокси до конечной ВМ). Меня это не устроило и я начал искать по крупицам информацию в сети. К сожалению в нашем русскоязычном сегменте ее мало (читай нет) пришлось шерстить буржуйский сегмент. Конечный результат предлагаю вашему вниманию, думаю кому ни будь он точно сгодится.

globallog /dev/log    local0log /dev/log    local1 noticestats socket /haproxy-admin.sock mode 660 level adminstats timeout 30sdaemondefaultsmaxconn 2000mode http        log globaloption dontlognull # bind *:443 ssl crt .option http-server-closetimeout http-request 10stimeout connect         5000timeout client          50000timeout server         50000frontend statsbind *:5000stats enablestats uri /statsstats refresh 10sstats auth admin:mysupersecretpassword #поменяйте на свой пароль

Блок отвечающий за работу ssl на ssl

frontend env_ssl_frontendbind *:443mode tcpoption tcplogtcp-request inspect-delay 10stcp-request content accept if { req_ssl_hello_type 1 }use_backend bk_app1 if { req.ssl_sni -m end site1.ru }use_backend bk_app2 if { req.ssl_sni -m end counter.site1.ru }use_backend bk_app3 if { req.ssl_sni -m end site2.com }  use_backend bk_app4 if { req.ssl_sni -m end site3.msk.ru }use_backend bk_app5 if { req.ssl_sni -m end site4.ru }use_backend bk_app6 if { req.ssl_sni -m end site5.msk.ru }backend bk_app1mode tcpbalance leastconnoption tcp-check server main 192.168.1.26:443 send-proxy checkbackend bk_app2mode tcpbalance leastconnoption tcp-checkserver main 192.168.1.38:443 send-proxy checkbackend bk_app3mode tcpbalance leastconnoption tcp-checkserver main 192.168.1.37:443 send-proxy checkbackend bk_app4mode tcpbalance leastconnoption tcp-checkserver main 192.168.1.100:443 checkbackend bk_app5mode tcpbalance leastconnoption tcp-checkserver main 192.168.1.31:443 send-proxy checkbackend bk_app6balance leastconnmode tcpoption tcp-checkserver main 192.168.1.200:443 check

Блок отвечающий за работу сайтов на 80 порту

frontend public        bind *:80        # бок сайтов        acl host_subdomain1 hdr(host) -i site1.ru         acl host_subdomain2 hdr(host) -i counter.site1.ru        acl host_subdomain3 hdr(host) -i site2.com        acl host_subdomain4 hdr(host) -i site3.msk.ru        acl host_subdomain5 hdr(host) -i site4.ru        acl host_subdomain6 hdr(host) -i site5.msk.ru        ## блок acl         use_backend subdomain1 if host_subdomain1        use_backend subdomain2 if host_subdomain2        use_backend subdomain3 if host_subdomain3        use_backend subdomain4 if host_subdomain4        use_backend subdomain5 if host_subdomain5        use_backend subdomain6 if host_subdomain6backend subdomain1        option httpclose        option forwardfor        cookie JSESSIONID prefix        server subdomain-1 192.168.1.26:80 checkbackend subdomain2        option httpclose        option forwardfor        cookie JSESSIONID prefix        server subdomain-2 192.168.1.37:80 checkbackend subdomain3        option httpclose        option forwardfor        cookie JSESSIONID prefix        server subdomain-3 192.168.1.31:80 checkbackend subdomain4        option httpclose        option forwardfor        cookie JSESSIONID prefix        server subdomain-4 192.168.1.100:80 checkbackend subdomain5        option httpclose        option forwardfor        cookie JSESSIONID prefix        server subdomain-5 192.168.1.200:80 checkbackend subdomain6        option httpclose        option forwardfor        cookie JSESSIONID prefix        server subdomain-6 192.168.1.38:80 check    

Что мы получили в итоге:

1. Генерация ssl сертификатов происходит на каждом сайте отдельно. Терминации на прокси сервере нет, идет прозрачное перенаправление на конечную машину которая и отдает посетителю свой ssl сертификат.
2. Проблем с Яндексом и его роботом дятлом (который мониторит сайт на доступность) не имеем.
3. Имеем быстрый и корректный отклик конечной машины для посетителей и поисковиков.
4. В качестве небольшого бонуса, имеем страничку с статистикой работы прокси сервера и сайтов которые он обслуживает. Для этого перейдите на ip (например у меня 192.168.1.150:5000) на котором он работает с портом 5000 и наслаждайтесь. Логин admin а пароль который вы сами установили в верхней секции этого конфига.

Отдельно хочу сделать замечание касаемо этого файла конфигурации Haproxy.

Весьма вероятно, что когда вы добавите в свой пул сайтов на PROXMOKS-e еще N кол-во виртуальных машин и вам понадобится получить сертификат с Letsencrypt, у вас может не получится это, тк Haproxy не сможет корректно отработать запрос и от вашей машины и к вашей машине.
В таком случае (под диванного сервера) сделайте выход c роутера (или что там у вас) проброс портов на новую ВМ, хотя бы 80 порт и после получения сертификата верните обратно. По крайней мере я так вышел из этой ситуации. Подробнее о проблеме описано по ссылке

Как всегда, приветствуются конструктивные предложения и замечания.

Всем успехов!

PS Сам реверс прокси у меня поднят и прекрасно себя чувствует на Ubuntu 18.04 которая идет в шаблонах Proxmox-a. По началу я его запускал в режиме полноценной виртуалки но это решение себя не оправдало тк потребляло изрядную процессорную и прочие ресурсы хост машины. С переводом прокси сервера на LXC контейнер потребление по ресурсам упало почти до пары единиц процентов ресурсов хост машины и можно сказать что ничего не потребляет.

SSH довольно безопасен, особенно если вы примете разумные меры предосторожности, такие как требование аутентификации на основе пары ключей. Тем не менее, в дикой природе по-прежнему существует множество ботов, которые пытаются найти уязвимые хосты, пытаясь войти в систему с распространенными скомпрометированными именами пользователей и паролями, такими как root / root или admin / admin. Хотя маловероятно, что они добьются успеха, они все равно будут использовать вашу пропускную способность и генерировать огромное количество журналов.
Один из способов минимизировать количество попыток входа в систему методом перебора изменить порт по умолчанию, который прослушивает SSH. Однако это не считается хорошей практикой во-первых, нужно помнить, что каждый раз, когда они подключаются к серверу, следует устанавливать правильный порт, отличный от порта по умолчанию. Более того, это может создать еще одну уязвимость безопасности, если выбранный порт больше 1024. Обычно только root может связываться с номерами портов ниже 1024. Однако, если для SSH используется больший номер порта, при определенных обстоятельствах пользователи без корневого доступа может заменить демон SSH другой, возможно, вредоносной службой.
Лучший способ решить возникшую проблему использовать инструмент, который заблокирует злоумышленнику доступ к SSH-серверу. Одним из таких широко используемых инструментов является fail2ban ( www.fail2ban.org ). Анализируя журналы, fail2ban обнаруживает повторяющиеся неудачные попытки аутентификации и автоматически устанавливает правила брандмауэра для отбрасывания трафика, исходящего с IP-адреса злоумышленника.

Установка fail2ban на Ubuntu

Ручная установка
Установить fail2ban в Ubuntu (и других дистрибутивах на основе Debian) очень просто:

$ sudo apt install fail2ban

Проверяем как это работает

Вы можете проверить, запущена ли служба, с помощью следующей команды:

$ sudo systemctl status fail2ban

Вывод должен быть похож на следующий статус службы должен быть активным:

fail2ban.service Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2021-05-18 12:36:36 ***; ** min ago
Docs: man:fail2ban(1)
Process: 723*** ExecStartPre=/bin/mkdir -p /run/fail2ban (code=exited, status=0/SUCCESS)
Main PID: 723*** (f2b/server)
Tasks: 5 (limit: 38293)
Memory: 18.0M
CGroup: /system.slice/fail2ban.service
723488 /usr/bin/python3 /usr/bin/fail2ban-server -xf start

Посмотрим, как fail2ban изменил правила iptables:

$ sudo iptables -L -n -v

Вы также должны увидеть, что в конфигурации iptables есть новая цепочка f2b-sshd, на которую ссылается правило цепочки INPUT:

Chain INPUT (policy ACCEPT 73411 packets, 6622K bytes)
pkts bytes target prot opt in out source destination
1019 65297 f2b-sshd tcp * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22

Chain f2b-sshd (1 references)
pkts bytes target prot opt in out source destination
8 480 REJECT all * * 94.191.93.46 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all * * 77.50.75.162 0.0.0.0/0 reject-with icmp-port-unreachable
10 600 REJECT all * * 51.254.143.190 0.0.0.0/0 reject-with icmp-port-unreachable
10 600 REJECT all * * 46.101.97.5 0.0.0.0/0 reject-with icmp-port-unreachable
9 540 REJECT all * * 43.129.28.88 0.0.0.0/0 reject-with icmp-port-unreachable
9 540 REJECT all * * 41.221.168.167 0.0.0.0/0 reject-with icmp-port-unreachable
9 540 REJECT all * * 35.247.219.12 0.0.0.0/0 reject-with icmp-port-unreachable
12 720 REJECT all * * 220.180.119.192 0.0.0.0/0 reject-with icmp-port-unreachable
10 600 REJECT all * * 218.75.121.75 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all * * 213.87.101.176 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all * * 192.139.15.34 0.0.0.0/0 reject-with icmp-port-unreachable
21 1260 REJECT all * * 187.104.145.210 0.0.0.0/0 reject-with icmp-port-unreachable
8 480 REJECT all * * 177.191.189.13 0.0.0.0/0 reject-with icmp-port-unreachable
10 600 REJECT all * * 159.89.82.134 0.0.0.0/0 reject-with icmp-port-unreachable
10 600 REJECT all * * 159.75.140.97 0.0.0.0/0 reject-with icmp-port-unreachable
8 480 REJECT all * * 157.92.13.105 0.0.0.0/0 reject-with icmp-port-unreachable
11 660 REJECT all * * 117.80.225.245 0.0.0.0/0 reject-with icmp-port-unreachable
9 540 REJECT all * * 106.53.121.179 0.0.0.0/0 reject-with icmp-port-unreachable
865 56057 RETURN all * * 0.0.0.0/0 0.0.0.0/0


Пакет fail2ban содержит инструмент под названием fail2ban-client. Он позволяет вам проверять статус службы и взаимодействовать с ней (например, позволяет вручную блокировать и разблокировать IP-адреса, включать и отключать тюрьмы и т. Д.)

Посмотрим, какие jails активны:

$ sudo fail2ban-client status

Status
|- Number of jail: 1
`- Jail list: sshd


Есть только один jail sshd которsq отвечает за мониторинг журналов SSH-сервера на предмет неудачного входа в систему и настройку правил брандмауэра для блокировки дальнейших попыток.
Теперь мы можем проверить статистику по sshd jail:

$ sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
| |- Currently failed: 8
| |- Total failed: 26
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 22
|- Total banned: 25
`- Banned IP list: 106.53.121.179 117.80.225.245 157.92.13.105 159.75.140.97 159.89.82.134 177.191.189.13 187.104.145.210 213.87.101.176 218.75.121.75 220.180.119.192 35.247.219.12 41.221.168.167 43.129.28.88 46.101.97.5 51.254.143.190 77.50.75.162 94.191.93.46 1.55.165.141 120.53.245.68 104.131.178.145 106.56.102.83 152.32.146.21

Настройка fail2ban

В большинстве случаев конфигурации по умолчанию должно быть достаточно. Тем не менее, полезно понимать, что это за значения по умолчанию и как их можно изменить в соответствии с вашими потребностями.
В стандартной конфигурации fail2ban защитит SSH-сервер и заблокирует злоумышленника на 10 минут после 5 неудачных попыток входа в систему в течение 10 минут. Файл конфигурации по умолчанию можно найти в /etc/fail2ban/jail.conf. Файл хорошо документирован и в основном не требует пояснений. Имейте в виду, что вам не следует вносить какие-либо изменения в этот файл, так как он может быть перезаписан во время обновления fail2ban.

После изменения конфигурации не забудьте перезапустить службу:

$ sudo systemctl restart fail2ban

Должен заметить, что в данном случае я изменил параметры конфигурации, понимая стратегию атаки и получил суточный список атакующих хостов и заблокировал его.
Но об этом позже расскажу в отдельной заметке, если эта будет кому то полезна и интересна.