С не брендовыми контроллерами недокументированное и странное поведение гораздо более возможно чем с контроллерами крупных вендоров.
Разный подход к качеству. Adaptec решил перестраховаться и написал такое. Скорее всего потому что поддержка в рамках контроллера достаточно скудная. Dell решил совместимость в той или иной степени гарантировать и тестировать у себя, потому что поддержка оказывается целиком для серверных систем в том числе и при миграциях.
The PERC H700 and H800 cards support migration of virtual disks from one controller to another without taking the target controller offline. The controller can import RAID virtual disks in optimal, degraded, or partially degraded states. You cannot import a virtual disk that is in an offline state. NOTE: The source controller must be offline prior to performing the disk migration. NOTE: Disks cannot be migrated back to previous PERC RAID controllers. NOTE: Importing secured virtual disks is supported as long as the appropriate key (LKM) is supplied/configured. When a controller detects a physical disk with an existing configuration, it flags the physical disk as foreign, and generates an alert indicating that a foreign disk was detected.
Версия прошивки не упоминается.
Можно мигирировать на более новые или такие же поколения контроллеров.
"купи точно такой же с точно такой же прошивкой" - это утверждение ложно.
Диски собранные в рейд хранят на себе некоторую информацию о конфигрурации рейда специально для того чтобы их можно было собрать обратно. Это DELL рейд контроллер и он это действительно делает так (проверено).
Эти диски можно вынуть из этого сервера и эту конфигурацию сможет импортировать любой другой рейд контролер DELL.
Возможно ли провести такую же атаку на какой-либо онлайн банк?
Если да, то почему мы не слышим такие истории каждый день?
Очевидно, беспечных владельцев реальных денег, которые хранятся на банковских счетах, со включенным онлайн банком и 2FA через SMS должно быть намного больше.
Поддерживаю тов. homm.
Мысль о том что это статья об отдельной реализации memory manager'а внутри браузера, который работает в ОС, в которой итак есть memory manager, возникает с самого начала и не развеивается до самого конца.
Вопрос который возникает после всего: почему реализовать собственный процесс управления памятью легче, чем помочь уже существующему memory manager'у ОС понять что некоторые области памяти можно отправлять в pagefile в первую очередь (например управляя активностью потоков, частотой использования памяти и при помощи приоритетов), и оставить эту работу ему?
Мы все видели Heartbleed в OpenSSL, который затронул большинство веб серверов, Meltdown/Spectre, который затронул почти все Intel процессоры, (ещё был shellshock, но не настолько страшный) поэтому уязвимости в широко распространенном ПО существующем десятилетия перешли из разряда «фантастически невероятных» в просто «маловероятные».
Речь о целенаправленных попытках подключения именно на этот адрес+порт. Десятки и сотни тысяч попыток подключения в течении дня. Чаще целыми подсетями, иногда разрозненные адреса.
То-есть вы исключаете вариант что до появления 0-day уязвимости у вас кто-то упорный найдёт ssh на нестандартном порту?
Конечно не исключаю.
Я просто увеличиваю время для его поиска, точно так же как увеличивается время подбора пароля при увеличение его длины. Плюс исключаю тех потенциальных атакующих, кто не ищет сервисы на нестандартных портах.
С учётом того что сменить порт абсолютно бесплатно и не вызывает особых проблем, то я не вижу причин этого не делать, и вижу в этом больше плюсов чем минусов.
Нестандартный порт — это такая security by obscurity.
никто не называет изменение порта методом обеспечения безопасности.
На веб-сервера тоже постоянно ломятся на всякие /phpMyAdmin и т.п., и что, теперь и вместо 80 порта другой использовать?
В случае с 80/443 портом для веб сервера выбора особого действительно нет, но давайте сравним две простые гипотетические ситуации на примере веб серверов:
1. Веб сервер использует стандартный порт 80.
Чтобы просканить все 80 порты в ipv4 интернете нужно ~25 минут при канале в 1ГБит.
2. Веб сервер использует нестандартный порт (например 62831).
Чтобы просканить вообще все 65к портов в ipv4 интернете нужно ~19 суток при канале в 1ГБит.
В веб сервере обнаруживается DOS уязвимость. Злодеи публикуют POC код. Любой может его использовать.
25 минут меньше чем 19 суток и затраты на поиск уязвимого сервера на нестандартных портах явно выше (примерно в 65000 раз). Т.е. риск эксплуатации уязвимости во втором случае ниже (от 2 раз до 65 000).
В случае с веб сервером — да, от стандартных портов никуда не деться.
В случае с SSH — нет особых проблем в использовании нестандартных портов.
Сканируются все 65 тысяч портов. Попробуйте повесить открытую http прокси на какой-нибудь совсем странный порт вроде 63241 и проверьте через сколько дней через нее повалит китайский спам.
Не спорю, что сканируются периодически все 65к портов, но судя по логам, полный портскан происходит заметно реже чем скан самых распространенных портов, на глаз — примерно в 100-1000 раз реже.
Тут дело не в каких-то листах. Просто все ipv4 адреса в мире постоянно сканируются.
Речь не о сканах, а о том, что после того как адрес+порт были отключены, именно в этот адрес+порт продолжаются попытки подключения в течении года и больше. Независимо от сканов портов.
Логи фаерволла собираю в graylog, там это очень наглядно.
На гигабитном канале TCP-SYN скан всего интернета по одному порту занимает ~20 минут (zmap, masscan).
Я может как-то неправильно считаю, но если размер TCP-SYN пакета ~48 байт, в интернете 4294967296 адресов, то это 192 ГБайт.
При канале в 1 ГБит/сек, 192Гбайта будут переданы за ~25 минут.
Т.е. скан всего интернета по одному порту со скоростью 1Гбит занимает ~25 минут.
По 65к портам — это ~19 суток.
Чем перевешивать SSH на нестандартные порты, и думать будто это вас от чего-то защищает
Не передёргивайте, никто не говорит что это мера защиты. Это всего лишь способ уменьшения риска с учётом вышесказанного.
Я не могу себе позволить выставлять SSH на стандартном 22 порту в интернет в виду следующих опасений:
1. Всем известно что 22 порт постоянно сканируется, ботнеты и пр. Любой владелец фаерволла который собирает его логи знает что постоянно происходят сканы по стандартным портам (~1000шт)
2. Даже после того как на этом адресе 22 порт недоступен с год — боты продолжают в него намеренно долбить, что как бы намекает, что адрес попал в список
…
3. Допустим в SSH протоколе обнаруживается 0-day уязвимость.
За последние пару лет мы видели что такое случается с проектами с открытым кодом, тот же OpenSSL.
Хорошо если эта уязвимость была обнаружена правильными товарищами, тогда есть шанс на то, что кто-то успеет обновиться.
Плохо, если об этой уязвимости все узнают после её открытой эксплуатации.
В такой ситуации, заполучив POC код, нет никаких проблем воспользоваться shodan.io (или тем же списком от ботов) и зодолбить всех кто найдётся на 22 порту.
0-day уязвимости вполне может быть не важна длина ключа.
Я параноик и это гипотетически невозможная ситуация?
Все примеры какие-то бытовые. Один спал, другой воровал, третий пилил/получал откаты. DLP система для проверки даты на справках — вообще смешно.
Можете привести пример, когда DLP система действительно помогла предотвратить или выявить утечку ценных данных, которые компания пыталась охранять, именно когда сотрудник пытался это сделать намеренно?
Ну т.е. то, почему DLP системы вообще так называются в первую очередь.
Возможно, вам стоит обратить внимание на стандартный набор правил для ipv6 firewall в свежих версиях RouterOs. Они не появляются сами по себе при активации ipv6. /system default-configuration print
Они вполне себе вменяемы и откомментированны.
Проблема будет решена, если не передавать чувствительные данные через систему мониторинга и не хранить их в ней?
Например, не хранить в ней логины/пароли.
С не брендовыми контроллерами недокументированное и странное поведение гораздо более возможно чем с контроллерами крупных вендоров.
Разный подход к качеству. Adaptec решил перестраховаться и написал такое. Скорее всего потому что поддержка в рамках контроллера достаточно скудная. Dell решил совместимость в той или иной степени гарантировать и тестировать у себя, потому что поддержка оказывается целиком для серверных систем в том числе и при миграциях.
Например, для PERC H700 (что похоже на то что должно стоять в 11G сервере автора)
https://www.dell.com/support/home/en-us/product-support/product/poweredge-rc-h700/docs
User’s Guide -> Disk Migration
The PERC H700 and H800 cards support migration of virtual disks from
one controller to another without taking the target controller offline.
The controller can import RAID virtual disks in optimal, degraded,
or partially degraded states. You cannot import a virtual disk that is in
an offline state.
NOTE: The source controller must be offline prior to performing the disk migration.
NOTE: Disks cannot be migrated back to previous PERC RAID controllers.
NOTE: Importing secured virtual disks is supported as long as the appropriate key
(LKM) is supplied/configured.
When a controller detects a physical disk with an existing configuration,
it flags the physical disk as foreign, and generates an alert indicating that
a foreign disk was detected.
Версия прошивки не упоминается.
Можно мигирировать на более новые или такие же поколения контроллеров.
"купи точно такой же с точно такой же прошивкой" - это утверждение ложно.
Диски собранные в рейд хранят на себе некоторую информацию о конфигрурации рейда специально для того чтобы их можно было собрать обратно. Это DELL рейд контроллер и он это действительно делает так (проверено).
Эти диски можно вынуть из этого сервера и эту конфигурацию сможет импортировать любой другой рейд контролер DELL.
Версия прошивки на это не влияет.
Если LZ4 может хорошо сжимать ваши бекапы MSSQL - значит сами бекапы выполняются без сжатия и достаточно рыхлые сами по себе.
Попробуйте включить сжатие прямо при выполнении бекапов в SQL и получите гораздо лучший результат (BACKUP DATABASE ... WITH COMPRESSION).
Это не создаёт никакой измеримой дополнительной нагрузки на современных процессорах в 2022 году.
Если да, то почему мы не слышим такие истории каждый день?
Очевидно, беспечных владельцев реальных денег, которые хранятся на банковских счетах, со включенным онлайн банком и 2FA через SMS должно быть намного больше.
Мысль о том что это статья об отдельной реализации memory manager'а внутри браузера, который работает в ОС, в которой итак есть memory manager, возникает с самого начала и не развеивается до самого конца.
Вопрос который возникает после всего: почему реализовать собственный процесс управления памятью легче, чем помочь уже существующему memory manager'у ОС понять что некоторые области памяти можно отправлять в pagefile в первую очередь (например управляя активностью потоков, частотой использования памяти и при помощи приоритетов), и оставить эту работу ему?
Тут интересно написано про жизнь pagefile.
Если вы пытаетесь донести какую-то информацию или высказать свою точку зрения, то можете делать это сразу без вступлений.
Конечно не исключаю.
Я просто увеличиваю время для его поиска, точно так же как увеличивается время подбора пароля при увеличение его длины. Плюс исключаю тех потенциальных атакующих, кто не ищет сервисы на нестандартных портах.
С учётом того что сменить порт абсолютно бесплатно и не вызывает особых проблем, то я не вижу причин этого не делать, и вижу в этом больше плюсов чем минусов.
Действительно, я ошибся примерно на 14% в большую сторону.
Но качественно это не изменило оценку.
В случае с 80/443 портом для веб сервера выбора особого действительно нет, но давайте сравним две простые гипотетические ситуации на примере веб серверов:
1. Веб сервер использует стандартный порт 80.
Чтобы просканить все 80 порты в ipv4 интернете нужно ~25 минут при канале в 1ГБит.
2. Веб сервер использует нестандартный порт (например 62831).
Чтобы просканить вообще все 65к портов в ipv4 интернете нужно ~19 суток при канале в 1ГБит.
В веб сервере обнаруживается DOS уязвимость. Злодеи публикуют POC код. Любой может его использовать.
25 минут меньше чем 19 суток и затраты на поиск уязвимого сервера на нестандартных портах явно выше (примерно в 65000 раз). Т.е. риск эксплуатации уязвимости во втором случае ниже (от 2 раз до 65 000).
В случае с веб сервером — да, от стандартных портов никуда не деться.
В случае с SSH — нет особых проблем в использовании нестандартных портов.
Не спорю, что сканируются периодически все 65к портов, но судя по логам, полный портскан происходит заметно реже чем скан самых распространенных портов, на глаз — примерно в 100-1000 раз реже.
Речь не о сканах, а о том, что после того как адрес+порт были отключены, именно в этот адрес+порт продолжаются попытки подключения в течении года и больше. Независимо от сканов портов.
Логи фаерволла собираю в graylog, там это очень наглядно.
Я может как-то неправильно считаю, но если размер TCP-SYN пакета ~48 байт, в интернете 4294967296 адресов, то это 192 ГБайт.
При канале в 1 ГБит/сек, 192Гбайта будут переданы за ~25 минут.
Т.е. скан всего интернета по одному порту со скоростью 1Гбит занимает ~25 минут.
По 65к портам — это ~19 суток.
Не передёргивайте, никто не говорит что это мера защиты. Это всего лишь способ уменьшения риска с учётом вышесказанного.
1. Всем известно что 22 порт постоянно сканируется, ботнеты и пр. Любой владелец фаерволла который собирает его логи знает что постоянно происходят сканы по стандартным портам (~1000шт)
2. Даже после того как на этом адресе 22 порт недоступен с год — боты продолжают в него намеренно долбить, что как бы намекает, что адрес попал в список
…
3. Допустим в SSH протоколе обнаруживается 0-day уязвимость.
За последние пару лет мы видели что такое случается с проектами с открытым кодом, тот же OpenSSL.
Хорошо если эта уязвимость была обнаружена правильными товарищами, тогда есть шанс на то, что кто-то успеет обновиться.
Плохо, если об этой уязвимости все узнают после её открытой эксплуатации.
В такой ситуации, заполучив POC код, нет никаких проблем воспользоваться shodan.io (или тем же списком от ботов) и зодолбить всех кто найдётся на 22 порту.
0-day уязвимости вполне может быть не важна длина ключа.
Я параноик и это гипотетически невозможная ситуация?
Можете привести пример, когда DLP система действительно помогла предотвратить или выявить утечку ценных данных, которые компания пыталась охранять, именно когда сотрудник пытался это сделать намеренно?
Ну т.е. то, почему DLP системы вообще так называются в первую очередь.
blogs.technet.microsoft.com/askpfeplat/2018/05/07/credssp-rdp-and-raven
blogs.technet.microsoft.com/yongrhee/2018/05/09/after-may-2018-security-update-rdp-an-authentication-error-occurred-this-could-be-due-to-credssp-encryption-oracle-remediation
/system default-configuration printОни вполне себе вменяемы и откомментированны.
Например, не хранить в ней логины/пароли.