​​Для Linux есть замечательный локальный веб сервер, который можно запустить с помощью python:

# cd /var/log
# python3 -m http.server 8181

Переходим браузером на 8181 порт сервера по IP адресу и видим содержимое директории /var/log. Когда скачали, завершаем работу. Это очень простой способ быстро передать файлы, когда не хочется ничего настраивать. Я регулярно им пользуюсь.

Для Windows есть похожий инструмент из далёкого прошлого, работающий и поддерживающийся до сих пор - HFS (HTTP File Server). Это одиночный исполняемый файл весом 2,1 Мб. Работает на любой системе вплоть до современной Windows 11. Скачиваете, запускаете и заходите через браузер на IP адрес машины, предварительно отключив или настроив firewall. Когда всё скачаете, сервер можно выключить, завершив работу приложения.

Сделано всё максимально просто. Никаких настроек не надо. Можете опубликовать какую-то директорию на компьютере или просто мышкой накидать список файлов. Это быстрее и удобнее, чем по SMB что-то передавать, так как надо настраивать аутентификацию. Плюс не всегда получается без проблем зайти с одной системы на другую. То версии SMB не совпадают, то учётка пользователя без пароля и SMB не работает, то просто гостевые подключения не разрешены. Из простого механизма, через который было удобно шарить папки, он превратился в какой-то геморрой. Мне проще через WSL по SCP передать данные, если есть SSH, что я и делаю, чем по SMB.

☝ Причём у этого веб сервера на самом деле очень много возможностей. Вот некоторые из них:

◽ Аутентификация пользователей
◽ Логирование
◽ Возможность настроить внешний вид с помощью HTML шаблонов
◽ Контроль полосы пропускания и отображение загрузки в режиме реального времени
◽ Может работать в фоновом режиме

В общем, это хорошая добротная программа для решения конкретной задачи. И ко всему прочему - open source. Обращаю внимание, что программа изначально написана на Delphi. На сайте скачивается именно она. А на гитхабе то же самое, только переписанное на JavaScript. Но есть и на Delphi репа.

⇨ Сайт / Исходники

#windows #fileserver

​​Сейчас в большинстве популярных дистрибутивов на базе Linux в качестве файрвола по умолчанию используется nftables. Конкретно в Debian начиная с Debian 10 Buster. Я обычно делаю вот так в нём:

# apt remove --auto-remove nftables
# apt purge nftables
# apt update
# apt install iptables

Но это не может продолжаться вечно. Для какого-нибудь одиночного сервера эти действия просто не нужны. Проще сразу настроить nftables. К тому же у него есть и явные преимущества, про которые я знаю:

◽️ единый конфиг для ipv4 и ipv6;
◽️ более короткий и наглядный синтаксис;
◽️ nftables умеет быстро работать с огромными списками, не нужен ipset;
◽️ экспорт правил в json, удобно для мониторинга.

Я точно помню, что когда-то писал набор стандартных правил для nftables, но благополучно его потерял. Пришлось заново составлять, поэтому и пишу сразу заметку, чтобы не потерять ещё раз. Правила будут для условного веб сервера, где разрешены на вход все соединения на 80 и 443 порты, на порт 10050 zabbix агента разрешены только с zabbix сервера, а на 22-й порт SSH только для списка IP адресов. Всё остальное закрыто на вход. Исходящие соединения сервера разрешены.

Начну с базы, нужной для управления правилами. Смотрим существующий список правил и таблиц:

# nft -a list ruleset
# nft list tables

Очистка правил:

# nft flush ruleset

Дальше сразу привожу готовый набор правил. Отдельно отмечу, что в nftables привычные таблицы и цепочки нужно создать отдельно. В iptables они были по умолчанию.

nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0\; }
nft add rule inet filter input ct state related,established counter accept
nft add rule inet filter input iifname "lo" counter accept
nft add rule inet filter input ip protocol icmp counter accept
nft add rule inet filter input tcp dport {80, 443} counter accept
nft add rule inet filter input ip saddr { 192.168.100.0/24, 172.20.0.0/24, 1.1.1.1/32 } tcp dport 22 counter accept
nft add rule inet filter input ip saddr 2.2.2.2/32 tcp dport 10050 counter accept
nft chain inet filter input { policy drop \; }

Вот и всё. Мы создали таблицу filter, добавили цепочку input, закинули туда нужные нам разрешающие правила и в конце изменили политику по умолчанию на drop. Так как никаких других правил нам сейчас не надо, остальные таблицы и цепочки можно не создавать. Осталось только сохранить эти правила и применить их после загрузки сервера.

У nftables есть служба, которая при запуске читает файл конфигурации /etc/nftables.conf. Запишем туда наш набор правил. Так как мы перезапишем существующую конфигурацию, где в начале стоит очистка всех правил, нам надо отдельно добавить её туда:

# echo "flush ruleset" > /etc/nftables.conf
# nft -s list ruleset >> /etc/nftables.conf
# systemctl enable nftables.service

Можно перезагружаться и проверять автозагрузку правил. Ещё полезная команда, которая пригодится в процессе настройки. Удаление правила по номеру:

# nft delete rule inet filter input handle 9

Добавление правила в конкретное место с номером в списке:

# nft add rule inet filter input position 8 tcp dport 22 counter accept

В целом, ничего сложного. Подобным образом настраиваются остальные цепочки output или forward, если нужно. Синтаксис удобнее, чем у iptables. Как-то более наглядно и логично, особенно со списками ip адресов и портов, если они небольшие.

Единственное, что не нашёл пока как делать - как подгружать очень большие списки с ip адресами. Вываливать их в список правил - плохая идея. Надо как-то подключать извне. По идее это описано в sets, но я пока не разбирался.

⇨ Документация

#nftables

Я уже давно использую заметки с канала как свои шпаргалки. Всё полезное из личных заметок перенёс сюда, плюс оформил всё это аккуратно и дополнил. Когда ищу какую-то информацию, в первую очередь иду сюда, ищу по тегам или содержимому.

Обнаружил, что тут нет заметки про tcpdump, хотя личная шпаргалка по этой программе у меня есть. Переношу сюда. По tcpdump можно много всего написать, материала море. Я напишу кратко, только те команды, что использую сам. Их немного. Tcpdump использую редко, если есть острая необходимость.

Я ко всем командам добавляю ключ -nn, чтобы не резолвить IP адреса в домены и не заменять номера портов именем протокола. Мне это мешает.

📌 Список сетевых интерфейсов, с которых tcpdump может смотреть пакеты:

# tcpdump -D

Если запустить программу без ключей, то трафик будет захвачен с первого активного интерфейса из списка выше.

📌 Слушаем все интерфейсы:

# tcpdump -nn -i any

Или только конкретный:

# tcpdump -nn -i ens3

📌 Исключаем SSH протокол. Если в трафике, на который мы смотрим, будет SSH соединение, то оно забивает весь вывод своей активностью. Глазами уже не разобрать. Исключаю его по номеру порта:

# tcpdump -nn -i any port not 22

По аналогии исключается любой другой трафик по портам. Если убираем слово not, то слушаем трафик только указанного порта.

📌 Пакеты к определённому адресату или адресатам:

# tcpdump -nn dst 8.8.8.8
# tcpdump -nn dst 8.8.8.8 or dst 8.8.4.4

Комбинация порта и адресата:

# tcpdump -nn dst 8.8.8.8 and port 53

Подобным образом можно комбинировать любые параметры: src, dst, port и т.д. с помощью операторов and, or, not,

📌 Смотрим конкретный протокол или исключаем его и не только:

# tcpdump arp -nn -i any
# tcpdump not arp -nn -i any
# tcpdump not arp and not icmp -nn -i any

На этом всё. Лично мне этих команд в повседневной деятельности достаточно. Не припоминаю, чтобы хоть раз использовал что-то ещё. Если надо проанализировать большой список, то просто направляю вывод в файл:

# tcpdump -nn -i any > ~/tcpdump.txt

На основе приведённых выше примеров можно посмотреть, к примеру, на SIP трафик по VPN туннелю от конкретного пользователя к VOIP серверу:

# tcpdump -nn -i tun4 src 10.1.4.23 and dst 10.1.3.205 and port 5060

Если не знакомы с tcpdump, рекомендую обязательно познакомиться и научиться пользоваться. Это не трудно, хоть на первый взгляд вывод выглядит жутковато и запутанно. Сильно в нём разбираться чаще всего не нужно, а важно увидеть какие пакеты и куда направляются. Это очень помогает в отладке. Чаще всего достаточно вот этого в выводе:

IP 10.8.2.2.13083 > 10.8.2.3.8118

Протокол IP, адрес источника и порт > адрес получателя и его порт.

#network

Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

В недавнем цикле статей по LVM в комментариях всплывали вопросы так называемого Bit Rot или битового гниения. Это когда на носитель записан бит 1 или 0, а со временем по разным причинам он поменял своё значение. В конечном счёте эти изменения ведут к тому, что нужный файл хоть и нормально прочитается, но окажется "битым". Причём подвержены этим ошибкам все типы устройств хранения - от лент и CD до современных SSD. Я проверял свои старые записанные CD диски. Многие из них хоть и прочитались, но часть данных была безвозвратно утеряна или повреждена.

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

Проще всего следить за целостностью файлов с помощью подсчёта контрольных сумм по тем или иным алгоритмам (CRC, MD5, SHA1 и т.д.) Есть много бесплатного софта, который автоматически может это выполнять и сравнивать по расписанию. В Linux такой софт обычно используется для контроля за системными файлами, чтобы определять несанкционированное изменение. Пример - Afick, Tripwire. Если у вас лежат файлы, с ними никто не работает, но изменилась контрольная сумма, значит возникли проблемы. Необходимо то же самое проверить на другом хранилище этих же файлов и если там контрольная сумма не менялась, значит тот файл оригинальный и стоит его восстановить из этой копии.

Некоторые файловые системы выполняют такие проверки в автоматическом режиме. Это заложено в их архитектуру. Пример - ZFS, Btrfs, ReiserFS, Ceph. Все эти файловые системы могут не только контролировать изменения, но и выполнять автоматическое восстановление повреждённых файлов, если хранилища на их основе собраны с избыточностью данных. То есть каждый файл хранится как минимум в двух или более копиях, для каждой из которых посчитана и сохранена контрольная сумма.

Важно понимать, что подобный контроль - не бесплатная операция. Она занимает системные ресурсы, как процессора, так и диска. И чем больше нагрузка на диск, тем больше ресурсов нужно. Перечисленные выше ФС обладают не только функциональностью контроля хэшей, но и многими другими, которые не обязательно будут нужны, но ресурсы они потребляют. Плюс, в них могут быть свои ошибки с вероятностью возникновения выше, чем Bit Rot. И стоит не забывать, что даже если вы возьмёте хранилище с ZFS или Ceph с контролем целостности файлов, это не освобождает вас от хранения этих же файлов где-то ещё.

Есть и другой механизм защиты файлов в Linux на основе контроля целостности - DM-integrity. С его помощью можно блочное устройство превратить в устройство с контролем целостности. А дальше с ним можно работать как с обычным диском - создавать разделы, тома Mdadm или Lvm. В случае нарушения целостности файла такое устройство будет возвращать Input/output error. Mdadm или LVM будут пытаться автоматически восстановить файл из копии, если хранилище обладает избыточностью данных, то есть собран рейд соответствующего уровня.

Таким образом мне не понятны претензии к Mdadm, Lvm или обычным файловым системам типа Ext4 или Xfs. Следить за целостностью файлов - не их задача. Где-то это будет слишком накладно, а где-то вообще не нужно. Если вам это необходимо, возьмите отдельный инструмент. В основном это актуально для долговременных хранилищ с холодными архивами.

☝️ Самая надёжная защита от Bit Rot - множественные копии. И тут очень важно соблюдать один принцип. Делать копию надо не от копии, а от оригинала данных. У вас есть исходное хранилище с данными, где они регулярно меняются. С него вы снимаете первый бэкап. Второй бэкап для другого хранилища надо снимать не с первого бэкапа, а тоже с исходного сервера. Иначе вы на все зависимые сервера принесёте битые файлы с первого бэкапа.

❓Для меня остался открытым другой вопрос. А как вообще понять, что у нас в хранилище файлы исправны, откроются и прочитаются? Как проверить изначальный источник правды для всех остальных копий?

#backup