Хакер - это не только некая личность в Интернете. Это может быть и уволившейся админ, доступ которому заблокировали не сразу. Не исключено, что подобный товарищь мог оставить себе лазейку, чтоб вернуться обратно, особенно если на сервере есть что-то ценное.
Поэтому основной смысл статьи в том, чтобы расскзать куда нужно смотреть, чтобы "точно" закрыть все форточки, а не ограничиваться банальной блокировкой учеток и выявлением активности reverse shell.
Вообще-то в случае оговоренного в статье линукса, самая популярная библиотека - libpcap - выхватывает пакеты до оговоренного же в статье nftables. Так что видно будет абсолютно всё, неважно что вы там в nftables делаете.
В моих тестах дефолтных debian tcpdump не фидел фильтрованный трафик. Да и к тому же это только в статье рассматривается локальный netfilter. Эти же способы могут использоваться и для обхода шлюзовых FW. Разве что какой-нибудь особо умный NGFW сможет что-то сделать.
У всех способов есть плюсы и минусы. Специально не стал рассказывать как бороться с проблемами, чтоб не делать готовый RAT. Те кому надо сами разберутся, а новички не будут играть в чудо-хакеров.
Можно и в рамках одного виджета. Но разделение на технические и эмоциональные реакции быть должно. Иначе будет как в статье "Умер всеми любимый <такой-то человек>"
Главная проблема реакций была в том их было слишком мало, в результате чего было непонятно что ставить, так как ничего из предложенного не нравилось и нужных ассоциаций не вызывало.
Возможно нужно было взять стандартные иконки реакций, что были в соц. сетях, так было бы понятней. А вообще оценка контента действительно должна быть двух уровневой. Поясню.
Возьмем пример, статья "Умер всеми любимый <такой-то человек>". Когда вы плюсуете статью - вы выражаете радость от смерти или то что статья хорошо написана? Чтобы избежать это неоднозначности эмоциональный отклик на статью и должен быть двух уровневым:
Первый уровень - качество статьи, всеми привычный рейтинг. Здесь мы благодарим автора за то что он написал статью и сделал это качественно. Тогда плюс под "Умер всеми любимый <такой-то человек>" будет означать не то, что мы радумеся смерти, а то что автор молодец и мы хотим, чтобы как можно больше людей узнало об этом.
Второй уровень - это эмоции, которые вызвал контент статьи. Например, печаль, боль, радость, удивление, воодушевление, "хм.. прикольно", "хабр торт" и т.д. Этот уровень ни на что не влияет и просто позволяет поделиться, дать эмоциональную оценку событию описанному в статье.
И еще когда вводятся какие-либо оценки нужно учить пользователей ими пользоваться. В противном случае будет как у некоторых профессоров ВУЗов. У одних "5 - это значит вы усвоили программу", а у других "4 - это значит что вы усвоили программу, а 5 - это Wow, вы должны знать больше чем я".
Двух уровневая оценка сделает нормальной ситуацию, когда статья "Умер всеми любимый <такой-то человек>" наберет рейтинг +1000 и будет содержать 1000 эмоциональных реакци боли и утраты.
Пример ущербности одноуровневой оценки успешно показан в сериале "Загрузка". Здесь главная героиня всеми силами пытается развлечь бессмертного оцифрованного старика и старательно изображает утку для охоты.
Однако старику не смотря на все старания работницы не нравится забава и он оценивает ее на 3 бала, что снижает ее эффективный рейтинг как работника и влечет финансовые последствия.
Для инсталляции сервера (любого) делаю install.sh, который все ставит и настраивает. Скрипт рассчитан на работу в ОС с minimal install составе. Если его запустить 2 раза, то ничего не сломается и все будет тем же что и требуется, но дело не в этом.
Ansible хорош при управлении большим числом узлов, если массовости не требуется, то он избыточен и проще (быстрее) сделать скриптами.
Основная фишка данного подхода - возможность работы отовсюду, даже из BIOS. Для некоторых сценариев беспроводной доступ может быть запрещен на уровне политики безопасности.
SSH нужен только для удобства. Если есть альтернативы для копирования скриптов, то пожалуйста. Кроме того, в консоли на андройде не очень удобно работать, с компа привычнее.
Произвести атаку AES несколько сложнее в условиях реального времени, поскольку многие шифрования выполняются параллельно на графическом процессоре.
На GPU не шифрует. Это не дает профита, поскольку расходы на копирование блоков памяти съедают преимущества от скорости GPU. Об этом на Хабре статьи есть от производителей криптосредств. Возможно что-то не так перевели, или авторы клик-бейтят.
Он такой же, как и в статье за исключением того, что не отключаю автодополнение (Tab в командной строке) и не отключаю NTP. В REG-файле нужные строки помечены восклицательными знаками (; !!!!!!!!!)
Хакер - это не только некая личность в Интернете. Это может быть и уволившейся админ, доступ которому заблокировали не сразу. Не исключено, что подобный товарищь мог оставить себе лазейку, чтоб вернуться обратно, особенно если на сервере есть что-то ценное.
Поэтому основной смысл статьи в том, чтобы расскзать куда нужно смотреть, чтобы "точно" закрыть все форточки, а не ограничиваться банальной блокировкой учеток и выявлением активности reverse shell.
В моих тестах дефолтных debian tcpdump не фидел фильтрованный трафик. Да и к тому же это только в статье рассматривается локальный netfilter. Эти же способы могут использоваться и для обхода шлюзовых FW. Разве что какой-нибудь особо умный NGFW сможет что-то сделать.
У всех способов есть плюсы и минусы. Специально не стал рассказывать как бороться с проблемами, чтоб не делать готовый RAT. Те кому надо сами разберутся, а новички не будут играть в чудо-хакеров.
Можно и в рамках одного виджета. Но разделение на технические и эмоциональные реакции быть должно. Иначе будет как в статье "Умер всеми любимый <такой-то человек>"
Нажать вместо одной кнопки 2?
Не сложно, а не привычно. Поэтому и нужно обучение.
Главная проблема реакций была в том их было слишком мало, в результате чего было непонятно что ставить, так как ничего из предложенного не нравилось и нужных ассоциаций не вызывало.
Возможно нужно было взять стандартные иконки реакций, что были в соц. сетях, так было бы понятней. А вообще оценка контента действительно должна быть двух уровневой. Поясню.
Возьмем пример, статья "Умер всеми любимый <такой-то человек>". Когда вы плюсуете статью - вы выражаете радость от смерти или то что статья хорошо написана? Чтобы избежать это неоднозначности эмоциональный отклик на статью и должен быть двух уровневым:
Первый уровень - качество статьи, всеми привычный рейтинг. Здесь мы благодарим автора за то что он написал статью и сделал это качественно. Тогда плюс под "Умер всеми любимый <такой-то человек>" будет означать не то, что мы радумеся смерти, а то что автор молодец и мы хотим, чтобы как можно больше людей узнало об этом.
Второй уровень - это эмоции, которые вызвал контент статьи. Например, печаль, боль, радость, удивление, воодушевление, "хм.. прикольно", "хабр торт" и т.д. Этот уровень ни на что не влияет и просто позволяет поделиться, дать эмоциональную оценку событию описанному в статье.
И еще когда вводятся какие-либо оценки нужно учить пользователей ими пользоваться. В противном случае будет как у некоторых профессоров ВУЗов. У одних "5 - это значит вы усвоили программу", а у других "4 - это значит что вы усвоили программу, а 5 - это Wow, вы должны знать больше чем я".
Двух уровневая оценка сделает нормальной ситуацию, когда статья "Умер всеми любимый <такой-то человек>" наберет рейтинг +1000 и будет содержать 1000 эмоциональных реакци боли и утраты.
Пример ущербности одноуровневой оценки успешно показан в сериале "Загрузка". Здесь главная героиня всеми силами пытается развлечь бессмертного оцифрованного старика и старательно изображает утку для охоты.
Однако старику не смотря на все старания работницы не нравится забава и он оценивает ее на 3 бала, что снижает ее эффективный рейтинг как работника и влечет финансовые последствия.
Для инсталляции сервера (любого) делаю install.sh, который все ставит и настраивает. Скрипт рассчитан на работу в ОС с minimal install составе. Если его запустить 2 раза, то ничего не сломается и все будет тем же что и требуется, но дело не в этом.
Ansible хорош при управлении большим числом узлов, если массовости не требуется, то он избыточен и проще (быстрее) сделать скриптами.
Каждый инструмент хорош для своей задачи.
Редактирование текстовых конфигов скриптами кажется простым только тем, кто с этим никогда не сталкивался в проде ;-)
Ansible хорош, но не панацея. Довольно часто, то что он делает значительно проще сделать Shell скриптами.
ФСТЭК, ФСБ ... мало органов?
Именно так. Забыл написать про KVM в статье, а хотел )
Основная фишка данного подхода - возможность работы отовсюду, даже из BIOS. Для некоторых сценариев беспроводной доступ может быть запрещен на уровне политики безопасности.
SSH нужен только для удобства. Если есть альтернативы для копирования скриптов, то пожалуйста. Кроме того, в консоли на андройде не очень удобно работать, с компа привычнее.
Пауза возникает на стороне ОС. Соответственно воздействуя на её длительность паузы можно изменить.
Спасибо, поправил.
Этот способ позволяет не использовать клиента, в некоторых случаях это принципиальный момент.
На GPU не шифрует. Это не дает профита, поскольку расходы на копирование блоков памяти съедают преимущества от скорости GPU. Об этом на Хабре статьи есть от производителей криптосредств. Возможно что-то не так перевели, или авторы клик-бейтят.
Редактор остался в светлой теме
Он такой же, как и в статье за исключением того, что не отключаю автодополнение (Tab в командной строке) и не отключаю NTP. В REG-файле нужные строки помечены восклицательными знаками (; !!!!!!!!!)
Вся приведенная в статье информация актуальна на момент написания статьи.