Вчера, 28 марта вышел очередной релиз SystemRescue 13 – специализированный дистрибутив на базе Arch Linux для восстановления компьютеров. В новой версии новое ядро 6.18.20, добавлена поддержка bcachefs и серьезно обновлен софт.
В целом нельзя назвать SystemRescue 13 чем-то новым или оригинальным, все те же операции можно сделать и при помощи любого загрузочного диска с любым Linux, но есть один момент.
На данном диске уже собрано все, что вам может понадобиться, поддержка mdadm, LVM, ZFS и различных файловых систем, включая NTFS, а также собраны все необходимые утилиты и добавлена подробная оффлайн справка.
В общем бери и работай, при необходимости можно поискать информацию через интернет, браузер также есть в комплекте.
А загрузившись с обычного инсталляционного диска вам сначала придется все необходимые библиотеки и утилиты сначала установить, а только потом начать работать. И это если есть доступ в сеть, а ее может и не быть.
Система сделана хорошо, добротно и удобна в работе. Кроме Linux администраторов она может быть полезна и их Windows коллегам, на скриншотах как раз разделы Windows системы, которую мы подключили автоматическим скриптом mountall, который находит и монтирует все поддерживаемые разделы ПК.
А в документации даже есть отдельный раздел, как сохранить данные с Windows ПК если он не загружается.
Поэтому рекомендуем данный дистрибутив иметь в своем наборе инструментов.
В целом нельзя назвать SystemRescue 13 чем-то новым или оригинальным, все те же операции можно сделать и при помощи любого загрузочного диска с любым Linux, но есть один момент.
На данном диске уже собрано все, что вам может понадобиться, поддержка mdadm, LVM, ZFS и различных файловых систем, включая NTFS, а также собраны все необходимые утилиты и добавлена подробная оффлайн справка.
В общем бери и работай, при необходимости можно поискать информацию через интернет, браузер также есть в комплекте.
А загрузившись с обычного инсталляционного диска вам сначала придется все необходимые библиотеки и утилиты сначала установить, а только потом начать работать. И это если есть доступ в сеть, а ее может и не быть.
Система сделана хорошо, добротно и удобна в работе. Кроме Linux администраторов она может быть полезна и их Windows коллегам, на скриншотах как раз разделы Windows системы, которую мы подключили автоматическим скриптом mountall, который находит и монтирует все поддерживаемые разделы ПК.
А в документации даже есть отдельный раздел, как сохранить данные с Windows ПК если он не загружается.
Поэтому рекомендуем данный дистрибутив иметь в своем наборе инструментов.
👍39❤3⚡1🤮1
И снова про мощность точки доступа
Мнение, что чем выше мощность точки доступа – тем лучше бытует не только среди обывателей, но и среди коллег, которые считают ее залогом качественной и стабильной беспроводной связи. Однако это совсем не так.
Начнем, как всегда, плясать от печки, т.е. теории. Для передачи данных в беспроводной среде используется аналоговый сигнал – электромагнитная волна, имеющая в идеале форму синусоиды (точнее двух синусоид, но это не так важно).
Чтобы передать какую-либо информацию мы определенным образом искажаем форму волны – этот процесс называется модуляцией. Причем искажаем мы форму не абы как, а строго на определенную физическую величину.
Чем сильнее мы искажаем форму волны – тем больше информации мы можем передать за единицу времени, но тем меньше физическая разница между уровнями искажения, а значит тем ниже помехоустойчивость.
Почему? Потому что электромагнитная волна при распространении взаимодействует с другими электромагнитными волнами, что также приводит к взаимным искажениям формы, этот процесс называется интерференцией (вспоминаем школу и круги на воде).
Чем меньше физическая разница между уровнями модуляции, тем легче их исказить так, что передаваемое значение окажется искажено. Кроме того, по мере распространения волны уровень сигнала падает, а следовательно он еще сильнее подвергается искажениям.
В результате при отдалении на некоторое расстояние мы уже не сможем без ошибок демодулировать волну (т.е. расшифровать переданную информацию) и тут нам нужно или усиливать сигнал, или использовать более простую, а следовательно, более медленную модуляцию.
Ну вот же, видите! Сами написали про повышение уровня сигнала. Но на самом деле не все так просто. Мощность сигнала ограничивается регламентированными значениями и если путем некоторых манипуляций мы можем повысить сигнал точки доступа, то уровень мощности оконечных устройств мы повысить не можем. Более того, все официально продаваемые в стране устройства будут соответствовать нормативам на мощность излучения передатчика.
А теперь вспоминаем еще одну аксиому – все решения в беспроводной сети принимает клиент. Клиент – довольно умное устройство и более-менее знает свои способности. И в голове у него есть некая «табличка», где указаны уровни сигнала точки доступа и доступные уровни модуляции.
Если клиент находится в зоне уверенного приема (синий круг на картинке), то он начинает использовать быструю модуляцию, мощности его передатчика также хватает на уверенную связь с точкой и точка его прекрасно слышит. В этом случае все хорошо. Связь быстрая и стабильная.
Но чем дальше мы отходим от точки, тем слабее становится уровень сигнала и клиент начинает переходить на более простые уровни модуляции, в результате чего скорость падает.
Что будет если мы повысим мощность передатчика? Клиент увидит, что уровень сигнала точки высокий и снова выберет сложную модуляцию. Но точка находится вне зоны уверенного покрытия передатчика клиента и слышит его плохо, ну или вообще не слышит.
В первом случае у нас начнутся потери пакетов, звук начнет заикаться, картинка рассыпаться. Во втором все еще хуже, сигнал есть – связи нет.
Как видим, от увеличения мощности стало только хуже. Но и при номинальной мощности может оказаться так, что эфир достаточно зашумлен и устройства начинают использовать медленную модуляцию.
В этом случае имеет смысл уменьшить мощность точки доступа и увеличить их количество. Таким образом мы сократим зону уверенного приема до того уровня, где можно использовать быстрые уровни модуляции и клиенты вместо того, чтобы переходить на медленные уровни будут переключаться на соседнюю точку.
Почему это важно? Потому что полоса передачи в беспроводной сети делится на всех и делится по количеству переданных пакетов. И даже один медленный клиент будет влиять на работу более быстрых занимая большее эфирное время. Подробнее мы об этом писали здесь: https://t.me/interface31/4023
Если коротко – уменьшайте мощность, увеличивайте количество точек, других вариантов нет.
Мнение, что чем выше мощность точки доступа – тем лучше бытует не только среди обывателей, но и среди коллег, которые считают ее залогом качественной и стабильной беспроводной связи. Однако это совсем не так.
Начнем, как всегда, плясать от печки, т.е. теории. Для передачи данных в беспроводной среде используется аналоговый сигнал – электромагнитная волна, имеющая в идеале форму синусоиды (точнее двух синусоид, но это не так важно).
Чтобы передать какую-либо информацию мы определенным образом искажаем форму волны – этот процесс называется модуляцией. Причем искажаем мы форму не абы как, а строго на определенную физическую величину.
Чем сильнее мы искажаем форму волны – тем больше информации мы можем передать за единицу времени, но тем меньше физическая разница между уровнями искажения, а значит тем ниже помехоустойчивость.
Почему? Потому что электромагнитная волна при распространении взаимодействует с другими электромагнитными волнами, что также приводит к взаимным искажениям формы, этот процесс называется интерференцией (вспоминаем школу и круги на воде).
Чем меньше физическая разница между уровнями модуляции, тем легче их исказить так, что передаваемое значение окажется искажено. Кроме того, по мере распространения волны уровень сигнала падает, а следовательно он еще сильнее подвергается искажениям.
В результате при отдалении на некоторое расстояние мы уже не сможем без ошибок демодулировать волну (т.е. расшифровать переданную информацию) и тут нам нужно или усиливать сигнал, или использовать более простую, а следовательно, более медленную модуляцию.
Ну вот же, видите! Сами написали про повышение уровня сигнала. Но на самом деле не все так просто. Мощность сигнала ограничивается регламентированными значениями и если путем некоторых манипуляций мы можем повысить сигнал точки доступа, то уровень мощности оконечных устройств мы повысить не можем. Более того, все официально продаваемые в стране устройства будут соответствовать нормативам на мощность излучения передатчика.
А теперь вспоминаем еще одну аксиому – все решения в беспроводной сети принимает клиент. Клиент – довольно умное устройство и более-менее знает свои способности. И в голове у него есть некая «табличка», где указаны уровни сигнала точки доступа и доступные уровни модуляции.
Если клиент находится в зоне уверенного приема (синий круг на картинке), то он начинает использовать быструю модуляцию, мощности его передатчика также хватает на уверенную связь с точкой и точка его прекрасно слышит. В этом случае все хорошо. Связь быстрая и стабильная.
Но чем дальше мы отходим от точки, тем слабее становится уровень сигнала и клиент начинает переходить на более простые уровни модуляции, в результате чего скорость падает.
Что будет если мы повысим мощность передатчика? Клиент увидит, что уровень сигнала точки высокий и снова выберет сложную модуляцию. Но точка находится вне зоны уверенного покрытия передатчика клиента и слышит его плохо, ну или вообще не слышит.
В первом случае у нас начнутся потери пакетов, звук начнет заикаться, картинка рассыпаться. Во втором все еще хуже, сигнал есть – связи нет.
Как видим, от увеличения мощности стало только хуже. Но и при номинальной мощности может оказаться так, что эфир достаточно зашумлен и устройства начинают использовать медленную модуляцию.
В этом случае имеет смысл уменьшить мощность точки доступа и увеличить их количество. Таким образом мы сократим зону уверенного приема до того уровня, где можно использовать быстрые уровни модуляции и клиенты вместо того, чтобы переходить на медленные уровни будут переключаться на соседнюю точку.
Почему это важно? Потому что полоса передачи в беспроводной сети делится на всех и делится по количеству переданных пакетов. И даже один медленный клиент будет влиять на работу более быстрых занимая большее эфирное время. Подробнее мы об этом писали здесь: https://t.me/interface31/4023
Если коротко – уменьшайте мощность, увеличивайте количество точек, других вариантов нет.
💯22👍12❤3
Про танки. Начало
Есть такая игра – Мир танков, в нее играют многие наши коллеги, в том числе и я. В игре я давно, с декабря 2011 года и уже давно бродили некоторые мысли, которые хочется высказать.
Начнем с того, что любая игра, особенно онлайн, должна чем-то удерживать игроков, заставлять их возвращаться, максимально вовлекать их в игровой процесс для получения максимальной прибыли с микротранзакций.
Так работают не только танки, так работает любая онлайн игра. Но именно танки сумели сделать игровой процесс максимально токсичным и заставить игроков ходить на него как на работу.
И вместо того, чтобы отвлекать, развлекать и дарить положительные эмоции игра все чаще и чаще доставляет негатив и заставляет ее закрывать в раздраженном состоянии. И они хотят, чтобы за это мы еще платили деньги?
Как вообще должен функционировать данный проект? Основная цель геймплея – прокачка веток, от слабых танков к сильным и крутым. Но прокачка тесно связана с экономикой проекта. Потому что нельзя просто так брать и качать.
Ваш ключ к прокачке – опыт, чем активнее и эффективнее вы действуете в бою, тем больше опыта получаете, тем быстрее вы сможете прокачаться. Но опыт — это еще не все, после прокачки новые модули и новую технику нужно купить, на это требуются кредиты, которые тоже можно заработать в бою.
Чем выше уровень, тем больше опыта и кредитов вы вывозите за бой, но и тем выше ваши накладные расходы. В былые времена уже начиная с 8-го уровня играть в плюс было проблематично даже при победе, а десятки стабильно уходили в минус.
Это нормально, потому что в экономической модели игры предусмотрен премиум-аккаунт, немного живых денег в месяц и вот вы уже играете в плюс на восьмерках и в ноль на десятках.
А хотите немного пофармить или прокачать пересаженный экипаж – вот вам премиум техника, тоже за реальные деньги, она немного хуже прокачиваемой, но дает повышенные кредиты и опыт. Первые премы именно такими и были.
И все шло как бы себе неплохо, пока где-то там наверху не решили, что нужно больше золота. И приняли крайне сомнительные решения.
Старожилы должны помнить «песок» - уровни от первого по четвертый, где были быстрые тачанки, скоротечные бои и всякая веселая дичь. Но так или иначе, в песке было весело и там же начинающие осваивали основы игры практически в аркадном режиме.
Теперь же начинающий, после официального «цикла подготовки» появляется сразу на пятом, а опыт у него – только пострелять по ботам.
Теперь там новый «песок», с пятого по седьмой. Многим нравится, многие там играют. Но настоящий песок увы потерян, хотя там были и есть интересные машинки, но сегодня там делать нечего.
Если мы сунемся выше, то тоже увидим, что начиная с восьмого уровня бал правят премы, их много, их раздавали за всякие активности, марафоны, ящики, и они, внезапно, лучше прокачиваемых машин.
Я сам играю на премах, потому что они есть, потому что они неплохи, потому что они экономически выгодны.
А прокачка? А зачем? Старые ветки откровенно устарели, они не могут составить конкуренцию ни новым веткам, ни премам. Качать их – сродни садомазохизму.
Новые ветки качнуть можно, но что значит «качнуть»? Открыть за чертежи, серебро и свободку, чего у каждого обычно с запасом. Но при это помнить, что все это ненадолго и скоро новые «имбы» просто понерфят.
Именно так произошло с огнеметами, которые после их появления были просто фановыми и разрывали рандом, а теперь пойди найди огнемет в команде.
И таких историй великое множество. Или ты успел в числе первых или опоздал на праздник жизни.
А если я просто хочу пройтись по исторической ветке? Попробовать танки, которые реально ездили и воевали? Забудь, это просто корм для новых машин. Беспомощные и ни на что не способные: не попал в броню, не пробил, рикошет…
Вот не собирался дальше играть, а подкинули еще 6 дней према, ну будем заходить…
Есть такая игра – Мир танков, в нее играют многие наши коллеги, в том числе и я. В игре я давно, с декабря 2011 года и уже давно бродили некоторые мысли, которые хочется высказать.
Начнем с того, что любая игра, особенно онлайн, должна чем-то удерживать игроков, заставлять их возвращаться, максимально вовлекать их в игровой процесс для получения максимальной прибыли с микротранзакций.
Так работают не только танки, так работает любая онлайн игра. Но именно танки сумели сделать игровой процесс максимально токсичным и заставить игроков ходить на него как на работу.
И вместо того, чтобы отвлекать, развлекать и дарить положительные эмоции игра все чаще и чаще доставляет негатив и заставляет ее закрывать в раздраженном состоянии. И они хотят, чтобы за это мы еще платили деньги?
Как вообще должен функционировать данный проект? Основная цель геймплея – прокачка веток, от слабых танков к сильным и крутым. Но прокачка тесно связана с экономикой проекта. Потому что нельзя просто так брать и качать.
Ваш ключ к прокачке – опыт, чем активнее и эффективнее вы действуете в бою, тем больше опыта получаете, тем быстрее вы сможете прокачаться. Но опыт — это еще не все, после прокачки новые модули и новую технику нужно купить, на это требуются кредиты, которые тоже можно заработать в бою.
Чем выше уровень, тем больше опыта и кредитов вы вывозите за бой, но и тем выше ваши накладные расходы. В былые времена уже начиная с 8-го уровня играть в плюс было проблематично даже при победе, а десятки стабильно уходили в минус.
Это нормально, потому что в экономической модели игры предусмотрен премиум-аккаунт, немного живых денег в месяц и вот вы уже играете в плюс на восьмерках и в ноль на десятках.
А хотите немного пофармить или прокачать пересаженный экипаж – вот вам премиум техника, тоже за реальные деньги, она немного хуже прокачиваемой, но дает повышенные кредиты и опыт. Первые премы именно такими и были.
И все шло как бы себе неплохо, пока где-то там наверху не решили, что нужно больше золота. И приняли крайне сомнительные решения.
Старожилы должны помнить «песок» - уровни от первого по четвертый, где были быстрые тачанки, скоротечные бои и всякая веселая дичь. Но так или иначе, в песке было весело и там же начинающие осваивали основы игры практически в аркадном режиме.
Теперь же начинающий, после официального «цикла подготовки» появляется сразу на пятом, а опыт у него – только пострелять по ботам.
Теперь там новый «песок», с пятого по седьмой. Многим нравится, многие там играют. Но настоящий песок увы потерян, хотя там были и есть интересные машинки, но сегодня там делать нечего.
Если мы сунемся выше, то тоже увидим, что начиная с восьмого уровня бал правят премы, их много, их раздавали за всякие активности, марафоны, ящики, и они, внезапно, лучше прокачиваемых машин.
Я сам играю на премах, потому что они есть, потому что они неплохи, потому что они экономически выгодны.
А прокачка? А зачем? Старые ветки откровенно устарели, они не могут составить конкуренцию ни новым веткам, ни премам. Качать их – сродни садомазохизму.
Новые ветки качнуть можно, но что значит «качнуть»? Открыть за чертежи, серебро и свободку, чего у каждого обычно с запасом. Но при это помнить, что все это ненадолго и скоро новые «имбы» просто понерфят.
Именно так произошло с огнеметами, которые после их появления были просто фановыми и разрывали рандом, а теперь пойди найди огнемет в команде.
И таких историй великое множество. Или ты успел в числе первых или опоздал на праздник жизни.
А если я просто хочу пройтись по исторической ветке? Попробовать танки, которые реально ездили и воевали? Забудь, это просто корм для новых машин. Беспомощные и ни на что не способные: не попал в броню, не пробил, рикошет…
Вот не собирался дальше играть, а подкинули еще 6 дней према, ну будем заходить…
🤣29💯7❤6🤮3👍1
Полезная команда tee в Linux
Любой Linux-администратор, активно работающий в консоли, должен знать и умело использовать эту команду.
Как и все классические утилиты
Например:
Это удобно для фиксации промежуточного результата, особенно в целях логирования или отладки.
По умолчанию tee перезаписывает указанный файл, если же мы хотим его дописать, то следует использовать ключ
Для чего это нужно? Допустим вы запустили какую-то длительную команду, результат которой вам нужно записать в файл, а потом решили ее прервать по
Любой Linux-администратор, активно работающий в консоли, должен знать и умело использовать эту команду.
Как и все классические утилиты
tee выполняет одну задачу, но делает ее хорошо. Ее смысл можно представить в виде буквы Т - команда принимает на вход стандартны поток ввода и выдает его же в стандартный поток вывода, одновременно записывая его содержимое в один или несколько файлов.Например:
command | tee file1.log
file1.log. Это удобно для фиксации промежуточного результата, особенно в целях логирования или отладки.
command1 | tee file1.log | command2
По умолчанию tee перезаписывает указанный файл, если же мы хотим его дописать, то следует использовать ключ
-a:command1 | tee -a file1.log
-i, который предписывает игнорировать команды завершения, такие как Ctrl + C. Для чего это нужно? Допустим вы запустили какую-то длительную команду, результат которой вам нужно записать в файл, а потом решили ее прервать по
Ctrl + C, при наличии данного ключа tee продолжит работу и корректно завершит запись в файл.
ping ya.ru | tee -i ping_ya.txt
tee - это повышение прав для записи в системные файлы. Например:
sudo echo "строка_текста" > /etc/myconf.conf
echo "строка_текста" | sudo tee /etc/myconf.conf
tee - простая, но весьма удобная и функциональная команда.👍21👌11🔥8❤4⚡3
Как быстро вычислить отвечающие на Ping узлы подсети в терминале Linux
Такая задача встречается довольно часто, когда вам нужно получить список «живых» узлов подсети, неважно с какими целями и сделать это нужно быстро и просто.
Вам поможет утилита fping, для ее установки воспользуйтесь командой:
Затем запустите ее с ключами:
Разберем части команды подробнее:
▫️Ключ -a – предписывает вывести узлы, которые отвечают на ping
▫️Ключ -g – генерировать узлы назначения из указанного диапазона, можно указать начальный и конечный адреса через пробел или CIDR, как в нашем случае
▫️ 2>/dev/null – подавляет вывод потока ошибок, чтобы не выводить сообщения о недоступных узлах
Как видим, поставленная нами задача решена просто и быстро.
Но это еще не все, рекомендуем ознакомиться со всеми возможностями fping выполнив:
Кстати, советуем регулярно обращаться к справке даже тех утилит, которые вы знаете, это поможет узнать что-то новое (новые ключи) или вспомнить некоторые забытые возможности.
Такая задача встречается довольно часто, когда вам нужно получить список «живых» узлов подсети, неважно с какими целями и сделать это нужно быстро и просто.
Вам поможет утилита fping, для ее установки воспользуйтесь командой:
apt install fping
Затем запустите ее с ключами:
fping -a -g 192.168.172.0/24 2>/dev/null
Разберем части команды подробнее:
▫️Ключ -a – предписывает вывести узлы, которые отвечают на ping
▫️Ключ -g – генерировать узлы назначения из указанного диапазона, можно указать начальный и конечный адреса через пробел или CIDR, как в нашем случае
▫️ 2>/dev/null – подавляет вывод потока ошибок, чтобы не выводить сообщения о недоступных узлах
Как видим, поставленная нами задача решена просто и быстро.
Но это еще не все, рекомендуем ознакомиться со всеми возможностями fping выполнив:
fping -h
Кстати, советуем регулярно обращаться к справке даже тех утилит, которые вы знаете, это поможет узнать что-то новое (новые ключи) или вспомнить некоторые забытые возможности.
1👍45🤝3❤2
Логическая бомба
Казалось бы, на эту тему все говорено-переговорено, но с завидным постоянством наблюдаю как даже опытные коллеги регулярно создают логические бомбы.
Логическая бомба – это код, который при наступлении некоторых условий, которые можно заранее просчитать и предвидеть, производит некоторые деструктивные действия. И здесь трудно сослаться на случайность или недосмотр.
Почему же так происходит? На наш взгляд – это классическое «и так сойдет» и тот же самый русский авось. Т.е. надежда на то, что обстоятельства, приводящие к срабатыванию логической бомбы, не произойдут или находятся под контролем.
Рассмотрим классический пример, очистка устаревших данных, например, бекапов:
Что делает эта команда? Тупо ищет файлы старше 90 дней и удаляет их. И логических бомб тут сразу несколько.
1️⃣ Самая очевидная. Если у нас по какой-либо причине перестанут создаваться резервные копии, то через 90 дней у нас не останется ни одной. И тут ошибочно полагаться на мониторинг или иные средства контроля, так как сбой может произойти в любой части схемы.
Сначала сломался мониторинг, потом перестали создаваться копии – вот и все, привет горячий.
2️⃣ Далее. Команда работает без привязки к конкретному расположению. Если кто-то случайно переместит скрипт, то он подметет вообще случайные данные. Поэтому никаких относительных путей в подобных конструкциях быть не должно. Только абсолютные.
3️⃣ Теперь – самое неочевидное –
Поэтому постараемся сразу учесть эти моменты. Удалять всегда нужно привязываясь не ко времени или еще каким-то внешним параметрам, а по количеству остающихся копий, в этом случае даже если у вас перестанут создаваться копии, то последние всегда останутся. Во многих случаях это гораздо лучше ситуации, когда копии нет вообще.
Т.е. оставляем не копии за последние 90 дней, а 90 последних копий (или более, если в день создается более одной копии).
Жестко привязываемся к путям и учитываем возможность появления пробелов в имени файла:
Конструкция стала сложнее, мы, как и прежде ищем файлы, но сразу указываем директорию поиска, а список выводим построчно, в каждой строке размещая временную метку файла и его имя, взятое в кавычки.
Сортируем от самых старых к самым новым и отбрасываем последние 90 записей. Затем для каждой строки получаем второй аргумент (имя файла в кавычках) и передаем его на удаление.
Однозначно стало лучше, но не совсем. Что будет, если в эту папку попадут другие файлы? Они также будут удалены, при этом мы снова легко можем остаться без бекапов. Что будет если кто-то случайно закинет туда 100 новых файлов?
Правильно – из них останется только 90 самых последних и ни одного бекапа, ну или самый последний. Это видно на берегу? Видно. Значит это очередная логическая бомба и надо от нее избавляться.
Допустим, наши бекапы имеют имя
Или даже
Чем более строгое совпадение в шаблоне – тем безопаснее, но во всем нужно видеть меру и вовремя остановиться, потому что если увлечься, то можно погрязнуть в проверках для совсем уже маловероятных условий или событий.
Да, и не забывайте логировать все что делают подобные скрипты, чтобы в случае какой-либо нештатной ситуации вы хотя бы могли выполнить работу над ошибками.
Казалось бы, на эту тему все говорено-переговорено, но с завидным постоянством наблюдаю как даже опытные коллеги регулярно создают логические бомбы.
Логическая бомба – это код, который при наступлении некоторых условий, которые можно заранее просчитать и предвидеть, производит некоторые деструктивные действия. И здесь трудно сослаться на случайность или недосмотр.
Почему же так происходит? На наш взгляд – это классическое «и так сойдет» и тот же самый русский авось. Т.е. надежда на то, что обстоятельства, приводящие к срабатыванию логической бомбы, не произойдут или находятся под контролем.
Рассмотрим классический пример, очистка устаревших данных, например, бекапов:
find -type f -mtime +90 -exec rm -rf {} \;Что делает эта команда? Тупо ищет файлы старше 90 дней и удаляет их. И логических бомб тут сразу несколько.
1️⃣ Самая очевидная. Если у нас по какой-либо причине перестанут создаваться резервные копии, то через 90 дней у нас не останется ни одной. И тут ошибочно полагаться на мониторинг или иные средства контроля, так как сбой может произойти в любой части схемы.
Сначала сломался мониторинг, потом перестали создаваться копии – вот и все, привет горячий.
2️⃣ Далее. Команда работает без привязки к конкретному расположению. Если кто-то случайно переместит скрипт, то он подметет вообще случайные данные. Поэтому никаких относительных путей в подобных конструкциях быть не должно. Только абсолютные.
3️⃣ Теперь – самое неочевидное –
find, который не рекомендуется использовать в скриптах в силу ряда особенностей. В частности, если нам попадется файл с пробелами в имени, то строка будет разбита на две, что приведет к неожиданным последствиям. Чаще всего удаление не произойдет, но может случиться разное.Поэтому постараемся сразу учесть эти моменты. Удалять всегда нужно привязываясь не ко времени или еще каким-то внешним параметрам, а по количеству остающихся копий, в этом случае даже если у вас перестанут создаваться копии, то последние всегда останутся. Во многих случаях это гораздо лучше ситуации, когда копии нет вообще.
Т.е. оставляем не копии за последние 90 дней, а 90 последних копий (или более, если в день создается более одной копии).
Жестко привязываемся к путям и учитываем возможность появления пробелов в имени файла:
find /mnt/backup/ -type f -printf '%T@ "%p"\n' | \
sort -n | \
head -n -90 | \
awk '{print $2}' | \
xargs -I {} rm {}
Конструкция стала сложнее, мы, как и прежде ищем файлы, но сразу указываем директорию поиска, а список выводим построчно, в каждой строке размещая временную метку файла и его имя, взятое в кавычки.
Сортируем от самых старых к самым новым и отбрасываем последние 90 записей. Затем для каждой строки получаем второй аргумент (имя файла в кавычках) и передаем его на удаление.
Однозначно стало лучше, но не совсем. Что будет, если в эту папку попадут другие файлы? Они также будут удалены, при этом мы снова легко можем остаться без бекапов. Что будет если кто-то случайно закинет туда 100 новых файлов?
Правильно – из них останется только 90 самых последних и ни одного бекапа, ну или самый последний. Это видно на берегу? Видно. Значит это очередная логическая бомба и надо от нее избавляться.
Допустим, наши бекапы имеют имя
base1-YYYY-MM-DD.dump, поэтому добавляем в строку поиска новое условие: find /mnt/backup/increment/ -type f -name "base1*.dump" -printf '%T@ "%p"\n'
Или даже
find... -name "base1-*-*-*.dump"...
Чем более строгое совпадение в шаблоне – тем безопаснее, но во всем нужно видеть меру и вовремя остановиться, потому что если увлечься, то можно погрязнуть в проверках для совсем уже маловероятных условий или событий.
Да, и не забывайте логировать все что делают подобные скрипты, чтобы в случае какой-либо нештатной ситуации вы хотя бы могли выполнить работу над ошибками.
👍27❤12👀2
This media is not supported in your browser
VIEW IN TELEGRAM
Шутки в IT бывают разные: бывают достаточно безобидные, а бывают очень злые и деструктивные.
Поэтому мы за первые. Старая добрая шутка на 1 апреля.
🤯🤯🤯
А какие IT-шутки знаете вы?
Поэтому мы за первые. Старая добрая шутка на 1 апреля.
🤯🤯🤯
А какие IT-шутки знаете вы?
😁28🤷♂3🤔1👌1🌭1
А в розетку включить не пробовали?
В продолжение первоапрельской темы расскажу реальный случай. Было это в начале нулевых и работал я в компьютерной фирме. Был у нас один достаточно крупный дилер из области и неплохой мужик сам по себе, назовем его Юра.
Так вот, Юра купил навороченный компьютер и что-то там его не совсем устраивало, поэтому он заранее с нами договорился, мол привезу свой комп, посмотрите, магарыч с меня.
В общем привез, подключили мы его с моим начальником Колей и стали смотреть, а там совсем беда, не стартует… И так и эдак, ну никак.
Зовем Юру, мол попал ты пацан, мать мертвая, мать в гарантию, а это недели две, а то и месяц, мать то не простая, понтовая.
Юра в шоке, ведь утром еще все включалось, зовем посмотреть самого – убеждается, то матери карачун. Далее стадия принятия и все такое.
И тут подходит к нам другой сотрудник техотдела Женя, внимательно на нас смотрит, а потом задает единственный, но меткий вопрос:
- А в розетку включить не пробовали?
Оказалось, что лежащий на столе удлинитель типа «пилот» оказался никуда не подключен, ну как-то так исторически сложилось.
В итоге оказалось, что проблемы Юры совсем не проблемы, мы быстро все решили и он поехал домой довольный. А Женя получил на домашний адрес большую пиццу.
В продолжение первоапрельской темы расскажу реальный случай. Было это в начале нулевых и работал я в компьютерной фирме. Был у нас один достаточно крупный дилер из области и неплохой мужик сам по себе, назовем его Юра.
Так вот, Юра купил навороченный компьютер и что-то там его не совсем устраивало, поэтому он заранее с нами договорился, мол привезу свой комп, посмотрите, магарыч с меня.
В общем привез, подключили мы его с моим начальником Колей и стали смотреть, а там совсем беда, не стартует… И так и эдак, ну никак.
Зовем Юру, мол попал ты пацан, мать мертвая, мать в гарантию, а это недели две, а то и месяц, мать то не простая, понтовая.
Юра в шоке, ведь утром еще все включалось, зовем посмотреть самого – убеждается, то матери карачун. Далее стадия принятия и все такое.
И тут подходит к нам другой сотрудник техотдела Женя, внимательно на нас смотрит, а потом задает единственный, но меткий вопрос:
- А в розетку включить не пробовали?
Оказалось, что лежащий на столе удлинитель типа «пилот» оказался никуда не подключен, ну как-то так исторически сложилось.
В итоге оказалось, что проблемы Юры совсем не проблемы, мы быстро все решили и он поехал домой довольный. А Женя получил на домашний адрес большую пиццу.
🤣26👍17🥱4😁1
Free или Available memory в Linux
В очередной раз сталкиваюсь с тем, что администраторы не понимают разницу между этими двумя показателями оперативной памяти в Linux.
Например, команда
Почему так? Для этого нужно углубиться в принципы организации памяти в Linux. Кроме занятой процессами памяти –
Можем ли мы сбросить буферы и очистить кеш? Да, можем, но когда после этого приложению потребуется какие-то данные или вызов библиотеки – то все это снова будет подгружено с жесткого диска и вполне может оказаться, что сделали мы только хуже, так как производительность системы на некоторое время упрется в производительность дисков, пока снова не будет заполнен кеш.
Поэтому в данной ситуации рассчитывать на 22,5 ГБ доступной памяти будет крайне неосмотрительно. В лучшем случае система может посчитать, что ей выгоднее сбросить страницы приложений в своп, вместо очистки кеша.
А в худшем в вовсе может решить, что сохранить кеш важнее, нежели сохранить процесс и застрелит его при помощи OOM Killer.
Кстати, системы мониторинга, тот же Zabbix будут смотреть именно на свободную память и выдавать вам алерты при ее исчерпании, хотя доступной памяти может быть еще много.
Также рекомендуем прочесть следующие статьи:
🔹 Linux - начинающим. Что такое пространства подкачки и как они работают
🔹 Linux - начинающим. Что такое OOM Killer и как он работает
В очередной раз сталкиваюсь с тем, что администраторы не понимают разницу между этими двумя показателями оперативной памяти в Linux.
Например, команда
free -m может дать нам такой вывод:
total used free shared buff/cache available
Mem: 60169 27996 9001 8472 23171 22576
Почему так? Для этого нужно углубиться в принципы организации памяти в Linux. Кроме занятой процессами памяти –
used в системе присутствует еще буферы и кеш - buff/cache, которые содержат разделяемые библиотеки, буферы ввода-вывода и т.д. и т.п., что позволяет системе меньше обращаться к диску. Можем ли мы сбросить буферы и очистить кеш? Да, можем, но когда после этого приложению потребуется какие-то данные или вызов библиотеки – то все это снова будет подгружено с жесткого диска и вполне может оказаться, что сделали мы только хуже, так как производительность системы на некоторое время упрется в производительность дисков, пока снова не будет заполнен кеш.
Поэтому в данной ситуации рассчитывать на 22,5 ГБ доступной памяти будет крайне неосмотрительно. В лучшем случае система может посчитать, что ей выгоднее сбросить страницы приложений в своп, вместо очистки кеша.
А в худшем в вовсе может решить, что сохранить кеш важнее, нежели сохранить процесс и застрелит его при помощи OOM Killer.
Кстати, системы мониторинга, тот же Zabbix будут смотреть именно на свободную память и выдавать вам алерты при ее исчерпании, хотя доступной памяти может быть еще много.
Также рекомендуем прочесть следующие статьи:
🔹 Linux - начинающим. Что такое пространства подкачки и как они работают
🔹 Linux - начинающим. Что такое OOM Killer и как он работает
👍20❤3🤮2👌1
tcpdump – сеть как на ладони
При диагностике сетей очень важно убедиться в том, что нужные пакеты приходят на нужный узел и не просто приходят, а соответствуют критериям, которые вы указали в правилах фильтрации.
Иначе можно долго гадать, что происходит и почему не работает то, что «по идее» должно работать. Поэтому не будем гадать, а просто посмотрим трафик своими глазами, в этом нам поможет утилита
Для ее установки выполните:
После чего запустите ее с ключом -D, чтобы посмотреть какие интерфейсы в системе она видит и откуда может слушать трафик.
Далее мы можем просто запустить:
И сразу утонем в количестве информации, разобраться в которой будет решительно невозможно, поэтому, чтобы получить выжимку мы будем использовать фильтры, самые популярные из них:
▫️port
▫️host
▫️src
▫️dst
▫️tcp
▫️udp
▫️icmp
Например, мы хотим посмотреть все пакеты с портом назначения
Указанную нами конструкцию следует читать как: протокол UDP - порт назначения 34567.
Теперь утилита нам покажет все пакеты, которые соответствую данному критерию: у которых транспортный протокол UDP и в поле порт назначения стоит 34567.
А если мы хотим посмотреть пакеты только от определенного узла, чтобы понять доходит к нам на сервер он него что-нибудь или нет. Усложним фильтр и добавим в него две группы условий. Для их соединения можно использовать логические выражения:
▫️AND
▫️OR
Отдельно для отрицания условия можно использовать
▫️NOT
Например:
Здесь мы фильтруем по двум условиям: хост источник и протокол - порт назначения пакета.
Вот здесь может возникнуть вопрос, а почему нельзя написать так:
Вроде бы как пол логике вещей условия все равно соединяются как-бы по логическому И, однако это неверно. tcpdump требует явного указания условии соединения различных примитивов.
В нашем условии два примитива: хост и порт. Общий синтаксис примитива можно описать выражением:
В нашем случае примитивы взяты в фигурные скобки, каждый примитив должен явно соединяться через логический оператор. Например, наоборот, все пакеты, кроме определенного узла:
Если мы хотим захватить определенное количество пакетов, то используйте ключ
Данная команда захватит строго 50 пакетов, соответствующих условию.
Чтобы увеличить количество выводимой информации добавьте ключ
При работе tcpdump пытается разрешать адреса в DNS-имена, а порты в имена служб, чтобы предотвратить такое поведение используйте ключ
Но все это диагностика в реальном времени, а как быть, если мы хотим изучить полученный дамп подробно, в спокойной обстановке? Все просто, нужно записать его в файл, для этого предназначена опция
Теперь 50 пакетов, попадающих под фильтр, будут записаны в файл mydump.pcap, если вы не указали количество, то в файл запишется все, что tcpdump успел захватить, пока вы не прервали его работу через Ctrl+C.
Записанный файл можно открыть любым подходящим ПО, наиболее популярным является открытый анализатор пакетов Wireshark.
При диагностике сетей очень важно убедиться в том, что нужные пакеты приходят на нужный узел и не просто приходят, а соответствуют критериям, которые вы указали в правилах фильтрации.
Иначе можно долго гадать, что происходит и почему не работает то, что «по идее» должно работать. Поэтому не будем гадать, а просто посмотрим трафик своими глазами, в этом нам поможет утилита
tcpdump. Для ее установки выполните:
apt install tcpdump
После чего запустите ее с ключом -D, чтобы посмотреть какие интерфейсы в системе она видит и откуда может слушать трафик.
tcpdump -D
Далее мы можем просто запустить:
tcpdump -i enp3s0
И сразу утонем в количестве информации, разобраться в которой будет решительно невозможно, поэтому, чтобы получить выжимку мы будем использовать фильтры, самые популярные из них:
▫️port
▫️host
▫️src
▫️dst
▫️tcp
▫️udp
▫️icmp
Например, мы хотим посмотреть все пакеты с портом назначения
UDP 34567:tcpdump -i enp3s0 udp dst port 34567
Указанную нами конструкцию следует читать как: протокол UDP - порт назначения 34567.
Теперь утилита нам покажет все пакеты, которые соответствую данному критерию: у которых транспортный протокол UDP и в поле порт назначения стоит 34567.
А если мы хотим посмотреть пакеты только от определенного узла, чтобы понять доходит к нам на сервер он него что-нибудь или нет. Усложним фильтр и добавим в него две группы условий. Для их соединения можно использовать логические выражения:
▫️AND
▫️OR
Отдельно для отрицания условия можно использовать
▫️NOT
Например:
tcpdump -i enp3s0 src host 203.0.113.11 and udp dst port 34567
Здесь мы фильтруем по двум условиям: хост источник и протокол - порт назначения пакета.
Вот здесь может возникнуть вопрос, а почему нельзя написать так:
tcpdump -i enp3s0 src host 203.0.113.11 udp dst port 34567
Вроде бы как пол логике вещей условия все равно соединяются как-бы по логическому И, однако это неверно. tcpdump требует явного указания условии соединения различных примитивов.
В нашем условии два примитива: хост и порт. Общий синтаксис примитива можно описать выражением:
[протокол] [направление] {host|net|port|portrange} значениеВ нашем случае примитивы взяты в фигурные скобки, каждый примитив должен явно соединяться через логический оператор. Например, наоборот, все пакеты, кроме определенного узла:
tcpdump -i enp3s0 udp dst port 34567 and not src host 203.0.113.11
Если мы хотим захватить определенное количество пакетов, то используйте ключ
-с:tcpdump -i enp3s0 -с 50 src host 203.0.113.11 and udp dst port 34567
Данная команда захватит строго 50 пакетов, соответствующих условию.
Чтобы увеличить количество выводимой информации добавьте ключ
-v[v], чем больше v вы указали, тем на более глубокий уровень будет разбираться информация пакета, но не обольщайтесь, если пакет не содержит дополнительных подробностей, но ничего нового вы не увидите.При работе tcpdump пытается разрешать адреса в DNS-имена, а порты в имена служб, чтобы предотвратить такое поведение используйте ключ
-n:tcpdump -i enp3s0 -n src host 203.0.113.11 and tcp dst port 22
Но все это диагностика в реальном времени, а как быть, если мы хотим изучить полученный дамп подробно, в спокойной обстановке? Все просто, нужно записать его в файл, для этого предназначена опция
-w:tcpdump -i enp3s0 -c 50 src host 203.0.113.11 and tcp dst port 22 -w mydump.pcap
Теперь 50 пакетов, попадающих под фильтр, будут записаны в файл mydump.pcap, если вы не указали количество, то в файл запишется все, что tcpdump успел захватить, пока вы не прервали его работу через Ctrl+C.
Записанный файл можно открыть любым подходящим ПО, наиболее популярным является открытый анализатор пакетов Wireshark.
👍44
Гистерезис как средство стабилизации триггеров в Zabbix
Кто постоянно работает с Zabbix знает такое явление как дребезг триггеров (или флаппинг), когда контролируемое значение колеблется около значения срабатывания триггера и приводит к постоянному его срабатыванию и восстановлению.
Это неприятно, так как приводит к резкому росту количества уведомлений и именно с этим явлением предлагают бороться, но на самом деле проблема лежит глубже, это проблема иллюзии восстановления.
О чем это мы? Давайте возьмем для примера триггер High memory utilization, который имеет следующее выражение срабатывания:
Оно означает, что если все значения за последние 5 минут были выше порога, то триггер сработает. Это обусловлено использованием
Поэтому набор значений:
а набор:
При этом фактически ситуация по памяти у нас не меняется и триггер или будет постоянно флапать или замолчит, и мы будем уверены, что ситуация выправилась, хотя на самом деле это не так и она продолжает оставаться критичной.
Как этого избежать? Ввести гистерезис, т.е. переводить триггер в состояние восстановления не сразу после того, как выражение срабатывания перестало работать, а с задержкой, когда мы будем уверены, что ситуация действительно нормализировалась.
Примем для этого значения порог срабатывания – 5%, при этом условием восстановления будет то, что за 5 минут ни одно значение не превысит этот порог. Теперь, после срабатывания триггера по памяти (штатное значение 90%) он не перейдет в состояние восстановления до тех пор, пока утилизация памяти стабильно не снизится менее 85%.
Для этого в настройках триггера добавим выражение восстановления и запишем туда следующий текст:
Обратите внимание, что здесь мы используем не
Таким образом мы ввели четкий 5% коридор, который не только предотвращает флаппинг триггера, но и защищает нас от иллюзии ложного восстановления, когда триггер перешел в состояние ОК, но значения остались близки к критическим.
Рекомендуем настроить подобный гистерезис для всех триггеров, имеющих критическое значение для системы, где мы должны быть твердо уверенны, что проблема действительно ушла, а не затаилась на время.
Кто постоянно работает с Zabbix знает такое явление как дребезг триггеров (или флаппинг), когда контролируемое значение колеблется около значения срабатывания триггера и приводит к постоянному его срабатыванию и восстановлению.
Это неприятно, так как приводит к резкому росту количества уведомлений и именно с этим явлением предлагают бороться, но на самом деле проблема лежит глубже, это проблема иллюзии восстановления.
О чем это мы? Давайте возьмем для примера триггер High memory utilization, который имеет следующее выражение срабатывания:
min(/Linux by Zabbix agent/vm.memory.utilization,5m)>{$MEMORY.UTIL.MAX}Оно означает, что если все значения за последние 5 минут были выше порога, то триггер сработает. Это обусловлено использованием
min(), фактически мы берем наименьшее значение за 5 минут и сравниваем с порогом.Поэтому набор значений:
89 90 91 89 92 95 – не сработает, min = 89
а набор:
91 93 95 91 92 94 – сработает, min = 91
При этом фактически ситуация по памяти у нас не меняется и триггер или будет постоянно флапать или замолчит, и мы будем уверены, что ситуация выправилась, хотя на самом деле это не так и она продолжает оставаться критичной.
Как этого избежать? Ввести гистерезис, т.е. переводить триггер в состояние восстановления не сразу после того, как выражение срабатывания перестало работать, а с задержкой, когда мы будем уверены, что ситуация действительно нормализировалась.
Примем для этого значения порог срабатывания – 5%, при этом условием восстановления будет то, что за 5 минут ни одно значение не превысит этот порог. Теперь, после срабатывания триггера по памяти (штатное значение 90%) он не перейдет в состояние восстановления до тех пор, пока утилизация памяти стабильно не снизится менее 85%.
Для этого в настройках триггера добавим выражение восстановления и запишем туда следующий текст:
max(/Linux by Zabbix agent/vm.memory.utilization,5m) < ({$MEMORY.UTIL.MAX} - 5)Обратите внимание, что здесь мы используем не
min(), а max(), так как у нас ни одно значение метрики не должно в течении 5 минут превысить пороговое. Таким образом мы ввели четкий 5% коридор, который не только предотвращает флаппинг триггера, но и защищает нас от иллюзии ложного восстановления, когда триггер перешел в состояние ОК, но значения остались близки к критическим.
Рекомендуем настроить подобный гистерезис для всех триггеров, имеющих критическое значение для системы, где мы должны быть твердо уверенны, что проблема действительно ушла, а не затаилась на время.
👍25🤮2❤1🤔1👌1
CrowdSec – как система предотвращения вторжений (IPS)
CrowdSec – это популярное ПО с открытым кодом для предотвращения вторжений, многие считают его современным аналогом Fail2ban, однако это не совсем так.
Также сразу внесем ясность: ни Fail2ban, ни CrowdSec не являются средствами защиты от атак на отказ в обслуживании – DDoS, так как являются достаточно ресурсоемкими приложениями и способны в таком сценарии еще сильнее нагрузить сервер.
Но такая задача и не преследуется, данное ПО предназначено для защиты от вторжений: перебора паролей, взлома, проактивного анализа, эксплуатации уязвимостей.
Так чем не угодил Fail2ban, не считая, что CrowdSec стильный, модный, молодежный, весь из себя модульный, написан на Go и содержит встроенный дашборд и мониторинг.
Ключевое различие в подходе к обеспечению безопасности. Fail2ban прост, но в своей простоте он застыл на уровне 15-20 летней давности. Не учитывая современных подходов и сценариев.
Схему работы Fail2ban можно представить в упрощенном виде так:
Основной источник событий – это регулярные выражения, которые получают из лога нужные события, например, неудачная попытка ввода пароля. Затем идет простейший счетчик и, если событие повторилось 5 раз за 10 минут источник события улетает в бан.
Просто и незамысловато. Но это работало 15 лет назад, сейчас же интернет кишит умными ботами, которые один раз попав под бан вычисляют его временные параметры и продолжают свое дело так, чтобы не попадать в фильтры.
CrowdSec предлагает принципиально иную схему, хотя во многом она похожа на предшественника:
Здесь не просто по Regex выделяются нужные строки лога, а выделяются значимые события, которые потом не просто изменяют счетчик, а передаются на сценарный анализ.
Сценарий – это не только ответ на вопрос: что произошло, но и попытка определить, чтобы это могло значить. Сценарий содержит основные паттерны атак и если событие ложится в паттерн, то это одно, а если выбивается из него – то совсем другое, хотя это может быть одно и тоже событие.
Для примера: пользователь забыл пароль и неспеша подбирает его, скажем одна попытка через разные промежутки времени. Четыре неудачных и потом вспомнил, вошел. Потом запускает другой клиент и там автоматически подставился старый пароль.
Fail2ban однозначно отправит пользователя в бан. CrowdSec, при наличии грамотно написанного сценария, во-первых, учтет, что вход похож на подбор пароля человеком, не ботом, а по факту удачного входа сбросит прошлые неудачные попытки.
Если говорить грубо, то принципиальная разница в том, что Fail2ban просто считает ошибки, а CrowdSec пытается понять поведение.
Но за все надо платить. Бытует мнение, что так как Fail2ban написан на Python, а CrowdSec на Go – последний быстрее и менее ресурсоемкий. Однако это не так.
Fail2ban большую часть времени, пока парсер не выдал новое событие может находиться в состоянии покоя и ничего не делать, тогда как CrowdSec постоянно анализирует поведение на соответствие сценариям, т.е. работает фактически непрерывно.
Говорит ли это о том, что Fail2ban устарел? И, да и нет. Если вам нужно что-то простое и незамысловатое – выбор за старым добрым Fail2ban. Но это защита реактивная, которая сработает уже по факту.
Если же вы начинаете новый проект и нуждаетесь в проактивной защите, которая отсечет злоумышленника еще до, то обратите внимание на CrowdSec.
CrowdSec – это популярное ПО с открытым кодом для предотвращения вторжений, многие считают его современным аналогом Fail2ban, однако это не совсем так.
Также сразу внесем ясность: ни Fail2ban, ни CrowdSec не являются средствами защиты от атак на отказ в обслуживании – DDoS, так как являются достаточно ресурсоемкими приложениями и способны в таком сценарии еще сильнее нагрузить сервер.
Но такая задача и не преследуется, данное ПО предназначено для защиты от вторжений: перебора паролей, взлома, проактивного анализа, эксплуатации уязвимостей.
Так чем не угодил Fail2ban, не считая, что CrowdSec стильный, модный, молодежный, весь из себя модульный, написан на Go и содержит встроенный дашборд и мониторинг.
Ключевое различие в подходе к обеспечению безопасности. Fail2ban прост, но в своей простоте он застыл на уровне 15-20 летней давности. Не учитывая современных подходов и сценариев.
Схему работы Fail2ban можно представить в упрощенном виде так:
Лог → Парсинг/Regex → Решение → Действие
Основной источник событий – это регулярные выражения, которые получают из лога нужные события, например, неудачная попытка ввода пароля. Затем идет простейший счетчик и, если событие повторилось 5 раз за 10 минут источник события улетает в бан.
Просто и незамысловато. Но это работало 15 лет назад, сейчас же интернет кишит умными ботами, которые один раз попав под бан вычисляют его временные параметры и продолжают свое дело так, чтобы не попадать в фильтры.
CrowdSec предлагает принципиально иную схему, хотя во многом она похожа на предшественника:
Лог → Парсер → Событие → Сценарий → Решение → Действие
Здесь не просто по Regex выделяются нужные строки лога, а выделяются значимые события, которые потом не просто изменяют счетчик, а передаются на сценарный анализ.
Сценарий – это не только ответ на вопрос: что произошло, но и попытка определить, чтобы это могло значить. Сценарий содержит основные паттерны атак и если событие ложится в паттерн, то это одно, а если выбивается из него – то совсем другое, хотя это может быть одно и тоже событие.
Для примера: пользователь забыл пароль и неспеша подбирает его, скажем одна попытка через разные промежутки времени. Четыре неудачных и потом вспомнил, вошел. Потом запускает другой клиент и там автоматически подставился старый пароль.
Fail2ban однозначно отправит пользователя в бан. CrowdSec, при наличии грамотно написанного сценария, во-первых, учтет, что вход похож на подбор пароля человеком, не ботом, а по факту удачного входа сбросит прошлые неудачные попытки.
Если говорить грубо, то принципиальная разница в том, что Fail2ban просто считает ошибки, а CrowdSec пытается понять поведение.
Но за все надо платить. Бытует мнение, что так как Fail2ban написан на Python, а CrowdSec на Go – последний быстрее и менее ресурсоемкий. Однако это не так.
Fail2ban большую часть времени, пока парсер не выдал новое событие может находиться в состоянии покоя и ничего не делать, тогда как CrowdSec постоянно анализирует поведение на соответствие сценариям, т.е. работает фактически непрерывно.
Говорит ли это о том, что Fail2ban устарел? И, да и нет. Если вам нужно что-то простое и незамысловатое – выбор за старым добрым Fail2ban. Но это защита реактивная, которая сработает уже по факту.
Если же вы начинаете новый проект и нуждаетесь в проактивной защите, которая отсечет злоумышленника еще до, то обратите внимание на CrowdSec.
1👍28❤2🍌1
Завоздушило, так завоздушило…
Решили мы тут с сыном посмотреть новый интерфейс 1С:Предприятие 8.5, которые позиционируется как «воздушный». Для ознакомления взяли небольшую, полностью самописную конфигурацию, которую он в прошлом году написал в качестве школьного проекта.
Конфигурация для учета домашних финансов и проста как мычание: приход, расход, перемещение, учет по кошелькам и статьям расходов/доходов. Никаких сложных форм, все очень просто, что тут может пойти не так?
Для конвертации форм мы воспользовались встроенным инструментом в разделе Рефакторинг, который много чего исправил и оптимизировал. При этом мы надеялись, что официальный инструмент покажет нам как правильно, как это задумано самой 1С.
На первом скриншоте показано как было. Основная страница представляла собой журнал операций и список кошельков с балансом в каждом из них, между частями формы есть видимая граница, которую мы можем перемещать, например, сделав журнал по шире.
Табличная часть журнала при этом автоматом масштабируется, но даже в начальном виде никаких вопросов нет, вся информация прекрасно помещается по ширине, еще и места хватает.
А что мы видим в конвертированной конфигурации? При том же размере окна форма не поместилась по вертикали и у нас возникла вертикальная прокрутка, а откуда она возникла?
Смотрим на таблицу – это полное фиаско, таблица обрезана как по горизонтали, так и по вертикали, потому что не поместилась, а чтобы добраться до горизонтальной прокрутки таблицы нам нужно прокрутить вниз саму форму.
Вообще-то, всю жизнь было принято вписывать таблицу в видимую часть формы и добавлять в нее полосы прокрутки, доступные без скролла страницы. Зачем здесь сделано такое поведение – непонятно.
Ладно, если у нас не хватает места по горизонтали, давайте свернем левое меню и жизнь наладится. Свернули. И что??? И ничего, таблице как было плохо, так и осталось, зато справа появилось пустое место, которое мы никак использовать не можем.
Не лучше выглядят и документы. В старом интерфейсе Такси была другая беда – по умолчанию таблицу растягивало на всю форму, что в случае простых табличек, как у нас, смотрелось не очень. Но все равно таблица четко визуально выделялась, как и итог справа внизу.
Новая форма показала принципиально иной подход, таблица скукожилась по горизонтали, хотя ее шапка по-прежнему занимает почти всю ширину формы и там у нас всегда будет пустое место, если мы, конечно не растянем таблицу руками.
Визуального выделения таблицы у нас нет и итоги просто потерялись, так как невозможно сразу понять, что это за цифра внизу и зачем она там, особенно если таблица маленькая.
Откроем другой документ, точно с такой же структурой и что это??? Что??? Откуда в табличной части взялась горизонтальная прокрутка, если справа еще полно свободного места???
А документ перемещения вообще по высоте не поместился, предлагая нам его скроллить, хотя в исходной форме того же размера мы могли по вертикали поместить содержимое документа два раза.
И вообще, новый интерфейс показывает жуткий дефицит свободного места, особенно по вертикали, хотя в Такси его было с избытком. И если у нас не помещаются уже простые формы, то что говорить о сложных документах?
С таким подходом у нас даже шапка без вертикального скролла не поместится, не говоря уже о табличных частях, где содержится основная информация. А это, если кто забыл, учетная система, а не приложение для домохозяек с двумя большими кнопками.
Учитывая то, что основное разрешение рабочих мониторов – это FullHD, то работать с «воздушными» формами будет сущим мучением, вы же не думаете, что работодатели сразу побегут покупать 2K или 4K мониторы, на которых «воздушным» формам места уже хватает.
Пока все это выглядит как крайне сырой прототип и был бы это действительно прототип – вопросов бы не было, но на интерфейс 8.5 уже переводят рабочие конфигурации (пока только УНФ 3.0 и Розница 3.0), причем в безальтернативном варианте.
Решили мы тут с сыном посмотреть новый интерфейс 1С:Предприятие 8.5, которые позиционируется как «воздушный». Для ознакомления взяли небольшую, полностью самописную конфигурацию, которую он в прошлом году написал в качестве школьного проекта.
Конфигурация для учета домашних финансов и проста как мычание: приход, расход, перемещение, учет по кошелькам и статьям расходов/доходов. Никаких сложных форм, все очень просто, что тут может пойти не так?
Для конвертации форм мы воспользовались встроенным инструментом в разделе Рефакторинг, который много чего исправил и оптимизировал. При этом мы надеялись, что официальный инструмент покажет нам как правильно, как это задумано самой 1С.
На первом скриншоте показано как было. Основная страница представляла собой журнал операций и список кошельков с балансом в каждом из них, между частями формы есть видимая граница, которую мы можем перемещать, например, сделав журнал по шире.
Табличная часть журнала при этом автоматом масштабируется, но даже в начальном виде никаких вопросов нет, вся информация прекрасно помещается по ширине, еще и места хватает.
А что мы видим в конвертированной конфигурации? При том же размере окна форма не поместилась по вертикали и у нас возникла вертикальная прокрутка, а откуда она возникла?
Смотрим на таблицу – это полное фиаско, таблица обрезана как по горизонтали, так и по вертикали, потому что не поместилась, а чтобы добраться до горизонтальной прокрутки таблицы нам нужно прокрутить вниз саму форму.
Вообще-то, всю жизнь было принято вписывать таблицу в видимую часть формы и добавлять в нее полосы прокрутки, доступные без скролла страницы. Зачем здесь сделано такое поведение – непонятно.
Ладно, если у нас не хватает места по горизонтали, давайте свернем левое меню и жизнь наладится. Свернули. И что??? И ничего, таблице как было плохо, так и осталось, зато справа появилось пустое место, которое мы никак использовать не можем.
Не лучше выглядят и документы. В старом интерфейсе Такси была другая беда – по умолчанию таблицу растягивало на всю форму, что в случае простых табличек, как у нас, смотрелось не очень. Но все равно таблица четко визуально выделялась, как и итог справа внизу.
Новая форма показала принципиально иной подход, таблица скукожилась по горизонтали, хотя ее шапка по-прежнему занимает почти всю ширину формы и там у нас всегда будет пустое место, если мы, конечно не растянем таблицу руками.
Визуального выделения таблицы у нас нет и итоги просто потерялись, так как невозможно сразу понять, что это за цифра внизу и зачем она там, особенно если таблица маленькая.
Откроем другой документ, точно с такой же структурой и что это??? Что??? Откуда в табличной части взялась горизонтальная прокрутка, если справа еще полно свободного места???
А документ перемещения вообще по высоте не поместился, предлагая нам его скроллить, хотя в исходной форме того же размера мы могли по вертикали поместить содержимое документа два раза.
И вообще, новый интерфейс показывает жуткий дефицит свободного места, особенно по вертикали, хотя в Такси его было с избытком. И если у нас не помещаются уже простые формы, то что говорить о сложных документах?
С таким подходом у нас даже шапка без вертикального скролла не поместится, не говоря уже о табличных частях, где содержится основная информация. А это, если кто забыл, учетная система, а не приложение для домохозяек с двумя большими кнопками.
Учитывая то, что основное разрешение рабочих мониторов – это FullHD, то работать с «воздушными» формами будет сущим мучением, вы же не думаете, что работодатели сразу побегут покупать 2K или 4K мониторы, на которых «воздушным» формам места уже хватает.
Пока все это выглядит как крайне сырой прототип и был бы это действительно прототип – вопросов бы не было, но на интерфейс 8.5 уже переводят рабочие конфигурации (пока только УНФ 3.0 и Розница 3.0), причем в безальтернативном варианте.
🤣26🤮7🤔4❤2💯2