Безопасность через неясность недооценивается

Автор оригинала: Utku Şen
  • Перевод
В информационной безопасности мы выработали ряд аксиом, с которыми не принято спорить:

  • Никогда не внедряйте собственную криптографию.
  • Всегда используйте TLS.
  • Безопасность через неясность (security by obscurity) — это плохо.

И тому подобное. Большинство из них в целом верны. Однако мне начинает казаться, что люди слепо следуют этим аксиомам как культу карго. И многие на самом деле не думают об исключениях из правил. В этой статье я выскажу свои возражения против идеи «безопасность через неясность — это плохо».

Риск, эшелонированная оборона и швейцарский сыр


Одной из главных задач ИБ является снижение рисков. Согласно методологии OWASP, риск возникновения проблемы рассчитывается по формуле:

Риск = Вероятность * Воздействие

По этой формуле, проблема удалённого выполнения кода (RCE) представляет больший риск, чем проблема межсайтового скриптинга, поскольку RCE несёт большее воздействие. Здесь всё просто. Но что насчёт метрики вероятности? Согласно OWASP, вероятность определяется так:

На самом высоком уровне это приблизительная оценка шансов, что конкретная уязвимость будет раскрыта и использована злоумышленником

Таким образом, если мы уменьшаем вероятность, то уменьшаем общий риск. Это хорошо. На самом деле это очень похоже на известную концепцию «эшелонированной обороны». Её также называют «моделью швейцарского сыра».



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

Безопасность через неясность


Итак, поговорим о безопасности через неясность. Плохая идея использовать её в качестве единственного уровня защиты. Если злоумышленник пройдёт его, то вас больше ничто не защитит. Но на самом деле он неплох в качестве «дополнительного» уровня. Потому что у него низкая стоимость внедрения и обычно он хорошо работает.

Рассмотрим несколько сценариев:

  • На моём сервере SSH запускается на дефолтном порту 22, а учётные данные root:123456. Какова вероятность компрометации?

Вероятность почти 100%, так как хакеры по всему интернету брутят сервисы со стандартными учётными данными.

  • SSH работает на порту 22, а учётные данные utku:123456. Какова вероятность компрометации?

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

  • SSH работает в порту 64323, а учетные данные utku:123456. Какова вероятность компрометации?

Мы изменили номер порта по умолчанию. Поможет ли это? Во-первых, мы снова устранили опасность стандартного брутфорса, поскольку он сканирует только общие порты. А как насчёт остальных? Я провёл небольшой опрос в своём твиттере, чтобы выяснить поведение людей при сканировании портов.


Как видите, многие склонны сканировать только стандартные и самые популярные порты. Таким образом, если вы измените порт с 22 на 64323, то устраните некоторые из потенциальных атак. Вы уменьшите вероятность и риск.

То же самое относится и к уязвимостям программного обеспечения. Если уязвимость обнаружена в протоколе Microsoft Remote Desktop Protocol, весь интернет начнёт сканировать порт 3389. Вы можете уменьшить риски, просто изменив порт по умолчанию.

Другие области применения


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

  • Обфускация кода: конечно, это общеизвестно. Хакеры тоже люди. Если вы хорошенько обфусцируете код, им придётся уделить больше времени на поиск проблем. В конце концов они могут сдаться.
  • Случайные имена переменных для веб-приложения: Вместо понятных имён переменных можно использовать случайные символы. Это может помочь точно так же, как обфускация кода.
  • Симметричное шифрование в базе данных: при записи данных в БД используйте функцию вроде encryption_algorithm(data, key). Аналогично, при считывании данных — decryption_algorithm(data, key). Если злоумышленник получил доступ к внутреннему коду, то, очевидно, сможет расшифровать БД. Но если из-за какой-то уязвимости злоумышленник считывает данные из БД, но не видит внутренний код (например, через SQL-инъекцию), то полученные данные ничего ему не дадут.

Применение в реальной жизни


Безопасность через неясность широко используется в физической/реальной безопасности. Например, президент едет из пункта А в пункт Б с кортежем из 30-ти автомобилей. Но он не сидит в своей президентской машине, чтобы не стать лёгкой мишенью. Он может находиться в любой машине из кортежа, и это снижает риск нападения.



Животные также используют безопасность через неясность — это камуфляж. Скрытность снижает вероятность быть убитым. Поэтому в процессе эволюции они приобрели такую способность.



Вывод


Безопасности через неясность самой по себе недостаточно. Всегда следует применять лучшие практики. Но если вы можете снизить риск с нулевыми затратами, то должны это сделать. Неясность — это хороший слой в общей системе безопасности.
GlobalSign
Компания

Комментарии 93

    +14

    Чего-то маловато.
    Только начал читать, а уже "до новых встреч".
    Тема интересная, излагается ясно и хорошо. Читать бы дальше, да читать.

      +3

      Закон больших чисел говорит, что как бы вы ни уменьшали вероятность использования уязвимости, если эта вероятность ненулевая, то её всё-равно кто-нибудь да найдёт и тогда приехали. Так что всё упирается в то, что если на неуловимого джо зарится только мамкин хекер и то случайно, то БЧН работает, но как только вы становитесь лакомым кусочком, то никакие обфускации и смены портов вам ничем не помогут от знающего своё дело человека. А усложняя жизнь чёрным хакерам, вы усложняете её и белым.

        +4
        Но ведь вывод статьи говорит как раз об этом.
          +4
          Как говорил мне мой шеф «Если мы заинтересуем кого-то настолько, что нас начнут целенаправленно ломать (речь о лицензиях, систему которых я пилил), то это будет означать только то, что мы к этому моменту уже будем купаться в деньгах. А пока пили что-нибудь попроще.»
          +12

          Однажды в своем проекте я сделал функцию, которая называлась md5 но на самом деле брала sha и обрезала до длины md5.

            +26

            Зачем?

              +3
              Чтобы никто не догадался
              +3
              Я звоню в полицию…
              0

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

                0
                Это не он написал, а автор. Статья — перевод.
                0

                Сразу пришла в голову мысль

                +4
                Если уязвимость обнаружена в протоколе Microsoft Remote Desktop Protocol, весь интернет начнёт сканировать порт 3389. Вы можете уменьшить риски, просто изменив порт по умолчанию.

                от таких «полезных» советов хочется ругаться матом. да, вы можете немного снизить риски, но этого абсолютно недостаточно и потому смена порта бесполезна.


                Я провёл небольшой опрос в своём твиттере, чтобы выяснить поведение людей при сканировании портов.

                ну так и вопрос поставлен некорректно.
                «просто посмотреть» — да, сканируются стандартные порты. «поискать уязвимости» — сканируются все порты.
                плюс непонятно вообще насколько коррелируют ответы читателей того твиттера с поведением реальных хакеров.


                в целом, вроде бы, написано и правильно, но сама статья скорее вредная, кто-то прочитает, поменяет местами 22 и 3389 порты и успокоится.

                  +17
                  в целом, вроде бы, написано и правильно, но сама статья скорее вредная, кто-то прочитает, поменяет местами 22 и 3389 порты и успокоится.
                  Так-то в статье чуть ли не в каждом абзаце написано, что это лишь дополнительная мера. Кто этого не увидит, тому уже ничего не поможет:)

                  Только вот такая защита против реальных атак практически бесполезна. Да, вы защитились от мелких хакеров, но ничего не сделали для реальной защиты.
                  Sazonov
                  от таких «полезных» советов хочется ругаться матом. да, вы можете немного снизить риски, но этого абсолютно недостаточно и потому смена порта бесполезна.
                  А нам вот хочется ругаться матом от логики «этого недостаточно, значит и делать этого не надо»
                  Сразу складывается ощущение, что автор такого утверждения находится в какой-то странной уверенности, что есть «абсолютно достаточная» «реальная защита» в «реальном мире».

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

                  Кроме того, мы этого не заметили в статье, но возможно просто пропустили.
                  Защита через «неясность» помогает от банальных ошибок персонала, которые тоже случаются. Не спасает, заметьте, т.к. речь опять же о вероятностях, а помогает.

                  Оставили открытыми порты базы наружу и не сразу заметили? Если содержимое базы шифруется, то обидно, досадно, но не проблема — в статье есть этот пример.

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

                  В конце концов набивший оскомину уже всем совет не вызывающий вопросов — не хранить пароли в открытом виде — это же прямое следование принципу «безопасность через неясность». Пусть мол тянут базу с хэшами — один черт это ничем никому не поможет.
                  Хотя тут-то ведь тоже можно возразить. Мол если уже добрались до базы, значит вся система уязвима, поэтому надо не фигней мол маятся с шифрованием пароелй, а базу защищать, т.к. «в реальном мире этой защиты шифрованием паролей недостаточно, спасет только от мелких хакеров» и поэтому «шифрования абсолютно недостаточно и поэтому оно бесполезно» — так?
                    –4
                    В конце концов набивший оскомину уже всем совет не вызывающий вопросов — не хранить пароли в открытом виде — это же прямое следование принципу «безопасность через неясность»

                    ни в коем разе.
                    security by obscurity — это использование «доморощенных» алгоритмов вместо стандартных, когда сокрытие внутреннего устройства считается дополнительной защитой.
                    если смену порта ssh ещё как-то можно сюда притянуть, то стандартные хэши в /etc/shadow или шифрование записей БД с помощью aes — это никак не «безопасность через неясность».


                    А нам вот хочется ругаться матом от логики «этого недостаточно, значит и делать этого не надо»

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

                      +8
                      стандартные хэши в /etc/shadow или шифрование записей БД с помощью aes — это никак не «безопасность через неясность».
                      Оно и есть, просто по прямому определению. Сами пароли в безопасности потому что хэш не дает ясности об их содержании, куда уж прямее. В статье упомянуто кстати
                      шифрование (цитата из статьи)
                      Симметричное шифрование в базе данных: при записи данных в БД используйте функцию вроде encryption_algorithm(data, key). Аналогично, при считывании данных — decryption_algorithm(data, key). Если злоумышленник получил доступ к внутреннему коду, то, очевидно, сможет расшифровать БД. Но если из-за какой-то уязвимости злоумышленник считывает данные из БД, но не видит внутренний код (например, через SQL-инъекцию), то полученные данные ничего ему не дадут.

                      Так что этот термин куда шире чем может показаться.

                      то есть вы предпринимаете абсолютно все действия, которые могут так или иначе снизить вероятность взлома?
                      Мы выше писали — "Поэтому речь всегда идет лишь об а) уменьшении вероятности взлома б) увеличении сложности взлома. Ни о чем больше речь идти не может."
                      В списке мероприятий смена стандартного метода доступа (порта, страницы админки, способа авторизации, имена печенек и т.д.) на альтернативу обычно является одной из самых простых вещей, это как почистить зубы утром. Да, даже если Вы не предпринимаете абсолютно все действия по укреплению здоровья — почистить зубы утром это базовая вещь:)
                      К тому же это избавляет от избыточности. В статье упомянуто, что мол 50% сканируют только стандартные порты. Может и так. Но по нашему опыту смена стандартного метода доступа снижает количество запросов на авторизацию в десятки раз. А это ниже нагрузка на сервак, меньше размер логов, меньше работы анализатору атак, меньше баз куда тебя включают по сигнатурам и так далее. Полезно даже безотносительно безопасности.
                        0
                        Оно и есть, просто по прямому определению

                        в википедии написано так:


                        Security through obscurity (or security by obscurity) is the reliance in security engineering on design or implementation secrecy as the main method of providing security to a system or component.

                        AFAIK это и есть общепризнанное определение.


                        а вы пытаетесь любое шифрование объявить security by obscurity.

                          +2
                          «security by obscurity» вообще более корректнее превести как неизве́стность или безве́стность. Неясность можно применить к камуфляжу например как сделал автор статьи. Оbscurity всё же имеет другой смысл. Незвестный алгоритм шифрования это не одно и тоже что и алгоритм маскирущийся под другой алгоритм. Смысл англ. выражения «security by obscurity» в отношении шифрования — нейзвестный алгоритм может иметь уязвимости так как он мало изучен. Поэтому в шифровании (кроме военного) и выкладываются алгоритмы для всеобщего обозрения. Знание алгоритма всеравно не приведет к компроментации шифрования если этот алгоритм надежен. Если взять современную версию OpenBSD, то как раз её безопасность и страдает от «неизвестности». Несмотря на то что код компактный и его можно проверить любому заинтересованному лицу, основное внимание всё же достается Linux. Это и есть классический вариант безвесности когда то популярной операционки. По этому поводу можно прочитать на англ. -> (https://www.csoonline.com/article/3250653/is-the-bsd-os-dying-some-security-researchers-think-so.html)
                            +1
                            мне кажется в интернте должно быть описани военных методов шифрования. У разведки противника уж точно есть.
                          +2

                          Если притягивать – то и шифрование данных попадёт в "security by obscurity". А что? Данные-то есть, а ключ – это детали нашего алгоритма.


                          Так что надо где-то остановиться. Привычная граница – использование неизвестных алгоритмов вместо проверенных с неизвестными ключами.

                            0

                            Граница тут всегда количественная: какая вероятность угадать нужные данные или получить их с первого подсматривания со стороны.


                            Номер порта SSH аналогичен алгоритму шифрования с 16-битным ключом, который передаётся открытым текстом во взаимодействии. То есть без сниффера надо 65535 проб, с ним — одна.
                            Стойкий пароль надо подбирать миллиардами проб (как минимум). Ключ — ещё больше на порядки.

                              0
                              Граница применимости – да, количественная. Но я говорил просто про термины – что называть security by obscurity, а что нет.
                                0

                                Так термин уже стал от этого зависеть, как только он получил постоянную отрицательную коннотацию. К сокрытию порта его применяют, а к защите паролем — нет, хотя односимвольный пароль тут хуже сокрытия порта :)
                                Надо или устранять эту коннотацию, или смириться и вводить другой термин для "положительного" варианта.

                                  +4
                                  Тут тонкость: если выбор порта рассматривать, как вариацию пароля (все знают, что он может быть заменён, и так мы слегка затрудняем атаку) – это одно. А если «мы поменяли порт, и никто об этом не догадается» – это другое.

                                  Ну в смысле суть «security by obscurity» – держать в секрете принимаемые меры (тем самым, помимо прочего, отказываясь от их аудита – в общем-то, это и есть основная проблема) и надеяться, что это поможет.
                                    0
                                    Ну в смысле суть «security by obscurity» – держать в секрете принимаемые меры (тем самым, помимо прочего, отказываясь от их аудита – в общем-то, это и есть основная проблема) и надеяться, что это поможет.

                                    Аудит бывает разный. Дружественный и не очень, внутренний и внешний.
                                    Мне нравится ваша формулировка в основе, но тут надо подшлифовать. Хотя по сути оно всё равно сведётся в итоге к оценке лёгкости получения необходимой информации тем, кому не положено — но вариант с отказом от аудита тут должен быть важным частным случаем.

                                    +1

                                    К выбору порта можно этот термин притянуть «за уши»: порт это часть протокола, изменяя порт мы изменяем протокол. Можно сделать и другие косметические изменения, например, поменять заголовки пакетов в ssh, это сломает всех ботов и тоже будет security by obscurity.


                                    Но и в статье, и в комментариях к ней происходит явная подмена терминов. Объявляют, что security by obscurity — это что угодно, включая требования к паролю и шифрование записей в БД.


                                    Попробую пояснить через формулировку «anti-security-by-obscurity». Итак, это подход, в котором явно выделяется некоторый относительно компактный секрет (пароли, приватные ключи, таблицы Энигмы, ключ от замка). Всё остальное, включая протоколы, алгоритмы, устройство замка, не считается секретной информацией. Речь не обязательно про то, что мы преподносим эту информацию всем на блюдечке с голубой каёмочкой, а про то, что при оценке угроз мы исходим из того, что она известна атакующему.


                                    Если же это требование не выполняется, если мы считаем, что безопасность обеспечивается «размазыванием» секретности на всё подряд, то мы и получаем security by obscurity. Недостаток этого подхода в том, что защищённость системы очень сложно оценить, поэтому зачастую он приводит к ложному ощущению защищённости.

                          +2
                          Так-то в статье чуть ли не в каждом абзаце написано, что это лишь дополнительная мера. Кто этого не увидит, тому уже ничего не поможет:)

                          Написано, да. Только вот без уточнения, что это поможет только при отсутствии направленной атаки на данную систему — это, мягко говоря, некорректно.


                          А нам вот хочется ругаться матом от логики «этого недостаточно, значит и делать этого не надо»

                          Проблема в том, что есть побочный эффект. У кого-то, например, суперзлобный файрволл, который считает все SSH не на порт 22 преступлением первой степени. Причём больше всего такого в корпоративном мире. И там как раз смена порта — это вариант, который практически никогда не считается допустимым. Сервис должен сидеть на стандартном порту, и точка. Защищаться — да, тут тебе и пароли со сменой раз в месяц, и брелки со вторым фактором, и сертификаты VPN, и прочая и прочая. Но — сервис должен выглядеть стандартно, точно так же, как на здании должна быть гордая табличка с названием. Это спецслужбы могут себе позволить невзрачные двери без вывески, но не корпорации. (Да, понятно, что у корпораций есть свои спецслужбы. Речь не о них.)


                          Защита через «неясность» помогает от банальных ошибок персонала, которые тоже случаются. Не спасает, заметьте, т.к. речь опять же о вероятностях, а помогает.

                          Если речь про открытую всем ветрам монгу — да, согласен — хотя это снова только вопрос нескольких дней и недель — потому что всё равно есть те, кто сканирует все порты на все виды сервисом.


                          Но нестандартные конфигурации увеличивают количество ошибок и близких проблем, включая "я снёс этот сервис, потому что херня какая-то" и "как это "на другом порту", вы что, с ума сошли? делайте как положено или я скажу директору и вас сегодня же уволят". Так что тут палка о двух колючих концах.


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

                          Тут категорически да, при условии, что и ключ шифрования не утёк. Но для этого нужно иметь хоть какую-то дисциплину администрирования ;(


                          Хотя тут-то ведь тоже можно возразить.

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

                            +2
                            Написано, да. Только вот без уточнения, что это поможет только при отсутствии направленной атаки на данную систему — это, мягко говоря, некорректно.

                            А почему вы считаете, что поможет только при отсутствии направленной атаки? При направленной атаке у 100% хакеров понимание неясности займет 0% ресурсов?

                              +1
                              При направленной атаке у 100% хакеров понимание неясности займет 0% ресурсов?

                              Не ноль, но ничтожную долю от всех затрат.

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

                                  Верно, обычные люди. Но после выяснения собственно порта — что делает тупой автомат на nmapʼе — дальше начнётся всякая проба стандартных паролей и т.п., что таки больше в объёме и для человека, и для компьютера.

                                    +3
                                    что делает тупой автомат на nmapʼе
                                    Ага, особенно когда фаервол банит его после скана 10 портов. В итоге вместо того чтобы сразу начинать брутфорсить SSH, придётся покупать пул IP адресов для скана портов. Это уже точно не будет являтся «ничтожной долей от всех затрат».

                                    Вообще я не имел ввиду этот конкретный случай со сменой порта SSH. Но даже тут можно всё усложнить, например, запустив какой нибудь фейковый SSH сервер типа Cowrie. Хотя это, наверное правильней называть «Security through cheating».
                                      –1

                                      Ну, это уже мы лезем в тему различия массового скана (где может найдётся одна жертва на пару тысяч адресов за месяц) и направленного (который будет делаться как-то сильно менее заметно). Но частично вы правы, безусловно — такой первичный скан сильно дороже и будет заметен даже в затратах на APT.


                                      Security through cheating

                                      Ну можно, да, пару сотен honeypotʼов запустить и замаскировать в них один реальный… это уже мы далеко пойдём в обсуждении подобных мер :) Главное то, что если уж начали такое делать — там точно не будет на входе юзеров с паролем типа 12345. (Ну, статистически.)

                                        0
                                        Offensive Countermeasures, если термин подбирать.
                                          +1

                                          Вот тут у Вас серьезная ошибка и недооценка. Уже сейчас есть возможность получить аналог "пула IP адресов" (совсем не их, но их функциональный аналог) за совершенно смешные деньги. Десятка центов точно хватит, чтобы просканировать все порты на одной точке входа, причем это можно делать параллельно для разных точек.

                                0
                                А нам вот хочется ругаться матом от логики «этого недостаточно, значит и делать этого не надо»

                                Нет, логика звучит так: "эти телодвижения создают лишь видимость повышения безопасности, поэтому лучше потратить своё время и внимание на то, что действительно её повышает". Например...


                                Оставили открытыми порты базы наружу и не сразу заметили? Если содержимое базы шифруется, то обидно, досадно, но не проблема — в статье есть этот пример.

                                … например, такая настройка системы, чтобы порты не могли непреднамеренным образом оказаться открытыми. Самый простой способ — превентивное сканирование.


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

                                +7
                                «security by obscurity» это ведь просто дополнительная мера. Во многих случаях, при относительно небольших усилиях можно уменьшить вероятность взлома в разы.

                                Простой пример, проекты с закрытым исходном кодом намного трудней взломать.
                                  +1
                                  Простой пример, проекты с закрытым исходном кодом намного трудней взломать.


                                  Это вы с чего решили? Статистика какая-то есть? Или просто не подумамши ляпнули?
                                  0
                                  Надо вешать поддельные очень тормозные сервисы на стандартные порты. Тогда сканирование замедляется.
                                  +12
                                  Какая-то поверхностно обзорная статья уровня «Яндекс-дзен». Непонятно, почему не пошли глубже? Например, не просто поменять порт SSH, но и заменить приветственный баннер. А также провести реальное исследование: выставить в интернет несколько виртуалок:
                                  — Одну со стандартным портом и простыми учётками.
                                  — Одну со стандартным портом и чуть более сложными учётками.
                                  — Одну с нестандартным портом (и далее по списку).
                                  А потом анализировать — через сколько всё это счастье взломается.
                                  И, да, опрос в твиттере не является серьёзным исследованием…
                                    +2

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

                                      +6
                                      Смена портов отфильтрует разве что скрипты и боты.
                                      По мне так уже это достаточная причина сменить порт.
                                        0

                                        Так скрипты и боты могут нагонять достаточно большой трафик.

                                          0
                                          Ошибаетесь. Можно настроить фаервол так, что первая же попытка подключиться к несуществующему порту (например, 22 — который переехал на другое место) приведёт к автоматическому бану IP, скажем, на сутки. После этого всё дальнейшее сканирование портов отправится «псу под хвост». Связка iptables+ipset позволяет выполнить эту операцию буквально тремя командами.
                                            0
                                            Довольно опасное мероприятие. Конкурент может сделать рекламный баннер и в нем загружать картинку с этого порта. Много людей будет заблокировано
                                              +1
                                              Обалдеть можно — какие у вас продвинутые конкуренты. Мало того, что прекрасно осведомлены о ваших ловушках, так ещё и отлично знают — как их обойти. От таких конкурентов не спрячешься.
                                                0
                                                На самом деле dim2r отчасти прав.

                                                Бан IP не должен быть настолько легким и быстрым — «обращение к несуществующему порту и всё», должна быть проверка на случайность этого обращения, особенно когда это обращение может быть легко спровоцировано 3-ей стороной. Хотя бы подождать попытки авторизации что-ли.

                                                О такой ловушке «догадаться» несложно, достаточно просто начать щупать сайт конкурента и оппа — уже о ней знаешь, это же базовая проверка — чекнуть все порты на реакцию.
                                                Эмулировать обращение к такой ловушке тоже примитивно, можно не только картинкой, но и ссылками (напрямую или через редирект) — не только люди в бан улетят, но и гугл/яндекс, что обычно куда болезненнее.
                                                  0
                                                  это же базовая проверка — чекнуть все порты на реакцию
                                                  После проверки первого же порта, находящегося в чёрном списке, IP проверяющего будет мгновенно забанен и придётся его менять, чтобы проверить остальные порты, что для случайного взломщика слишком геморройно. Если же у человека есть сеть сканирующих роботов — то это всё-таки необычный взломщик и вероятность нарваться на такого спеца — не шибко высока.
                                                  Эмулировать обращение к такой ловушке тоже примитивно, можно не только картинкой, но и ссылками (напрямую или через редирект) — не только люди в бан улетят, но и гугл/яндекс, что обычно куда болезненнее.
                                                  Для решения этой проблемы достаточно создать белый список ipset, в который добавить подсети ценных IP-адресов, и сделать проверку IP по этому списку в первом правиле фаервола — до всех прочих проверок.
                                                    0

                                                    Сейчас любая домохозяйка умеет ходить в интернет через впн.

                                                    +3
                                                    А разве нельзя всегда разрешать доступ забанненым IP к некоторым «публичным» портам, например, 80 и 443?
                                                    +1
                                                    какие у вас продвинутые конкуренты.

                                                    Есть специальные группы, которые занимаются взломами. Они могут сами выйти на конкурентов и предложить услуги. Когда замешаны деньги, то сообразительность возрастает в разы.
                                                      0
                                                      Да, я малость поразмыслил и решил согласиться с вашими доводами. Блокировка слишком простая и заметная. Нужно несколько усложнить: сделать, чтобы банилось после сканирования нескольких портов с одного и того-же IP — скажем, SSH и Telnet.
                                                  0

                                                  Да, классно, наверное, когда все пользователи в интернете сидят на фиксированных IP.

                                                    0
                                                    Не ошибаюсь. Настройка фаерволла — уже дополнительная мера предосторожности, второй слой сыра, если хотите.
                                                  +2

                                                  (Сразу дисклеймер: я не занимаюсь ИБ профессионально, в смысле зарабатывания денег именно на нём; это сопутствующее, хоть и давно.)


                                                  Сначала немного общих слов. Основная проблема определения security by obscurity — это непонимание границ тем, кто его некритично применяет. Отсутствие физической связи с Internet (даже косвенной) это надёжная защита? Безусловно, да. Парольный доступ с надёжным паролем? Считается, да. С паролем 12345? Безусловно, нет. Где граница, если незнание хакером пароля это та же obscurity? Он может случайно угадать даже какой-нибудь kshfk sdfhdskhjfw wreoihx,ms wkfejhsdk wefuysdb wfohfdskjhds. Можно ли вычислить приватный ключ ECDSA по публичному? Безусловно, можно! Только вот потратиться надо. Тем не менее на защите паролями и ключами стоит весь Интернет, и ещё веками стоять будет, если не придумают ничего новее. (Кстати, с биометрией ещё хуже. Но не будем уже в это вдаваться.)


                                                  Тогда что такое действительно опасный вариант security by obscurity? Это такой вариант, при котором секрет, необходимый для доступа, очень простой или легко может утечь от факта его использования. Все эти "очень" и "легко" должны выражаться количественно в виде вероятности узнать секрет, и сравниваться с критичными цифрами. В общем случае сейчас можно считать, что вероятность выше 1e-9 следует считать подозрительной для современного Интернета при условии наличия направленного интереса хакеров к ресурсу, а выше 1e-6 — недопустимой. Спецы могут подправить эти цифры. Для всяких секретных агенств значения надо минимум возвести в квадрат :)


                                                  Теперь к данному случаю. Во-первых: портов всего 65535. Просканировать их — нет проблем. Это сильно меньше названного мной для надёжной защиты базового уровня (65535<<1e6). Во-вторых, метод смены порта ssh известен хакерам уже лет 20, не меньше. Да, по другим портам смотрят меньше — но только потому, что предполагают, что если админ сменил порт, то он вообще разбирается в секьюрити и есть смысл меньше надеяться на его взлом — при массовом скане и только! При направленной атаке это не поможет, наоборот, заинтересуются больше — "тут есть что скрывать". Поэтому автор статьи уменьшил вероятность его пролома при массовом скане, но не при направленной атаке.


                                                  Второе тут — что порт крайне сложно засекретить. Это может помочь разве что при дополнительных средствах типа IPSec. Но ssh в мир под IPSec не закрыть. Даже если бы пространство портов было 64- или 128-битным, хакеру достаточно было бы увидеть один такой коннект, чтобы узнать, что кто-то ходит на этот порт. А количество тех, кто пишет трафики каких-нибудь домосетей в поисках жертв, и потом продаёт эти данные, огромно и будет только расти. Поэтому порт вообще это секрет Полишинеля, который работает до первого обнаружения. Да, именно так та самая плохая security by obscurity и работает: первое же открытие "секрета" нивелирует защиту в ноль.
                                                  (Можно было бы сделать, что порт меняется каждые несколько минут по алгоритму типа ключевого 2FA. Но утечка хотя бы от одного владельца ключа с другой стороны — секрет раскрыт. Лучше не стало.)


                                                  Что же делать? А как обычно — сильные пароли, а ещё лучше ключи. 2FA, если доступна по сумме факторов. А для ssh ещё крайне желательно AllowGroups и/или AllowUsers в конфиге sshd, чтобы пускать только реальных пользователей и заведомо отсекать всяких демонов. Доступ только по ключам из мира — тоже неплохая защита. Но — и смена порта хороша тем, что уменьшится замусоривание логов. Только помнить, что она сама по себе ничто.

                                                    +1
                                                    Отсутствие физической связи с Internet (даже косвенной) это надёжная защита? Безусловно, да.
                                                    Увы, не безусловно.
                                                    Второе тут — что порт крайне сложно засекретить
                                                    Можно использовать port knocking, как вариант. Теоретически количество комбинаций там можно до даже больше упомянутого 1e6 довести.
                                                      0
                                                      Увы, не безусловно.

                                                      Все подобные варианты я подвёл под "даже косвенной".


                                                      Можно использовать port knocking, как вариант.

                                                      Если там time-based ключевые фразы — то пойдёт, но для индивидуального использования: если у вас 100 пользователей, если у каждого свой ключ, это будет сложно в управлении, а если у всех одинаковый, утечка у одного заставит поменять у остальных.
                                                      Если одна фиксированная фраза — те же проблемы с подслушиванием, что у просто порта (хотя надёжнее статистически, чем у просто открытого порта).

                                                    +1
                                                    Мне кажется, когда сформировалась рекомендация не использовать «Безопасность через неясность» — имелось ввиду другое… И, пожалуй, правда это понимают не все и в этом смысле статья по делу. Если мы говорим об инфраструктуре предприятия и/или домашней сети, например — то тут, наверное, все методы хороши и автор прав. Хотя бы потому, что неясность — она для внешних атак, а для админа внутри — все ясно и понятно.

                                                    Однако совсем иначе дела обстоят с продуктом/сервисом. В таком случае вы предоставляете свое решение во вне и любой пользователь может быть как жертвой атаки, так и собственно атакующим… В такой ситуации вы создаете неясность и тем и другим (т.к. по умолчанию не можете разделить пользователей на «хороших» и «плохих» — вы же не знаете, зачем они приобрели продукт: чтоб пользоваться, или чтоб уязвимости искать), но в итоге добропорядочным пользователям остается надеятся только на то, что ВЫ знаете что делаете. Провести собственный аудит им будет затруднительно. Т.е. пользователи вынуждены доверять свою безопасность разработчику, за что переодически и расплачиваются.

                                                    С другой стороны — если разработчик использует полностью открытые механизмы защиты, пользователь может в общих чертах оценить риски, плюс привлечь сторонний аудит. Так же повысит доверие к разработчику программа баг-баунти (или как там называется то же самое но на безопасность? пен-тест?).

                                                    Мне кажется не использовать Безопасность через неясность — это все-таки про сервисы. Когда неясность двусторонняя — когда я как пользователь, тоже не понимаю как моя безопасность в данном решении обеспечивается. И тот факт, что «и хакер не понимает» — меня мало успокаивает…
                                                      +1
                                                      Та же картина когда админ не один. Все админы должны знать что где и как, не только обладать паролями и ключами.
                                                      И рост инфраструктуры приводит к тому что security thru obscurity удорожает администрирование так же как и взлом.
                                                      0
                                                      Но если из-за какой-то уязвимости злоумышленник считывает данные из БД, но не видит внутренний код (например, через SQL-инъекцию), то полученные данные ничего ему не дадут.

                                                      Возможно я что-то пропустил, но как шифрование БД влияет на SQL-инъекцию? SQL-инъекции позволяют получать данные из других таблиц посредством расширения запроса, т.е. ваш штатный интерфейс из-за инъекции выведет несколько больше информации чем должен был и как тут может повлиять шифрование?
                                                        0

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

                                                          0

                                                          Но ведь данные после запроса расшифровываются как-то при нормальной работе приложения? Ведь код на клиенте не с зашифрованным мусором работает? А значит, если удалось расширить запрос и получить больше данных, то они также расшифруются.

                                                            0
                                                            А значит, если удалось расширить запрос и получить больше данных, то они также расшифруются.

                                                            Не значит. Клиент БД на сервере вполне может держать ключ шифрования где-то отдельно (не в БД) и использовать шифрование своими средствами. И вот одна колонка полностью зашифрована — и что вы с этим сделаете не зная ключа?

                                                              0
                                                              Даже если хакер получил доступ к данным одного пользователя, то нужно предотвратить доступ к другим данным. Это можно сделать например через двойную инициализацию сессии базы данных. Сначала вход по user\password, потом вход еще по каким-то обсукрным данным для установки переменных сессии.

                                                              0
                                                              Если система уязвима к SQL-инъекциям, то очевидно, что в общем случае злоумышленник получит уже расшифрованные данные, т.к. запрос с инъекцией полетит тем же стандартным для приложения путём, что и нормальный запрос, с расшифровкой данных на лету. Исключение будет разве что в том крайне редком случае, когда используется не шифрование БД, а конкретно каких-то там избранных данных, при этом расшифровка делается «вручную» на прикладном уровне, а не прозрачно на уровне доступа к данным. Но так ведь мало кто делает, т.к. это кастомный велосипед, который и время на разработку требует, и конечный результат сильно зависит от квалификации разработчика. Поэтому практически везде юзается прозрачное шифрование средствами СУБД, которое хорошо помогает от «утащить базу данных», «сниффить сетевой трафик» и т.д., но не помогает от SQL-инъекций.
                                                                0
                                                                разве что в том крайне редком случае, когда используется не шифрование БД, а конкретно каких-то там избранных данных,

                                                                Тут как раз этот вариант и имелся в виду, судя по описанию. Его редкость, думаю, немного преувеличена.


                                                                Поэтому практически везде юзается прозрачное шифрование средствами СУБД, которое хорошо помогает от «утащить базу данных», «сниффить сетевой трафик»

                                                                Странные вещи говорите. Для трафика есть HTTPS. Для утащить файлами — пароль зашифровки должен лежать рядом, чтобы сервер базы мог запускаться сам (вариант участия человека на каждый старт не рассматриваем… разве что автомат, который запрашивает пароль по сети при старте? такого я ещё не видел, хотя теоретически возможно).


                                                                Ну и SQL инъекции в плохом коде, по отчётам последних лет, сильно вероятнее взлома с доступом к полной FS или запуском шелла — поправьте, если что-то изменилось.

                                                                  0
                                                                  Странные вещи говорите. Для трафика есть HTTPS.

                                                                  Во многих СУБД там между драйвером на клиенте и сервером БД используется не HTTPS, а нативный протокол, порой разработанный ещё в те времена, когда этих ваших интернетов не было.
                                                                  Для утащить файлами — пароль зашифровки должен лежать рядом, чтобы сервер базы мог запускаться сам (вариант участия человека на каждый старт не рассматриваем… разве что автомат, который запрашивает пароль по сети при старте? такого я ещё не видел, хотя теоретически возможно).

                                                                  Вообще, как раз второй вариант и используется. Например, это уже много лет как штатная опция для MS SQL Server. Сервер по сети обращается к Windows Certificate Store или к Azure Key Vault под своей учёткой, и получает оттуда ключи. У него самого они нигде не хранятся. Так же умеет делать и Oracle. И, думаю, и многие другие популярные СУБД. Тут ничего не надо сочинять/программировать, просто настроить.
                                                                    0

                                                                    Я плотно видел только mysql и postgres (в базовом варианте), там такого не водилось. ok, спасибо за инфу.
                                                                    В таком варианте действительно прозрачное шифрование должно относительно легко строиться.
                                                                    Но вот явное шифрование видел сам и слышал пару раз, а для паролей так вообще норма. Было, что они по специфике лежат в открытом виде — ну вот именно что шифровали обратимым образом с ключом, который лежал в достаточно хитром месте. Да, SbO (будем уже сокращать тему всей статьи;)) в чистом виде, но вместе с мерами защиты доступа на сам сервер получалось, что предполагали максимальную опасность именно от инъекций, а при них добраться до того места было нереально, если ещё какая-нибудь дыра не нашлась бы.

                                                              0

                                                              Шифрование делает эти инъекции во многом бесполезными, даже в случае полного слива базы.

                                                                0
                                                                Еще надо спрятать таблицы и выставить только view. А во view использовать фильтрацию, чтобы не все данные показывались, а только те, которые относятся к текущему пользователю.
                                                              +2

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


                                                              К слову, это может сыграть и обратный эффект: скажем, все прозрачно и понятно, но не известен пароль — такое ломать скучно и только ради определенной выгоды. А если система неизвестная — может вызвать просто спортивный интерес.

                                                                +1
                                                                Как только утечет (а это случится рано или поздно)
                                                                А почему собственно она обязана утечь?
                                                                  0

                                                                  Тут либо эффект неуловимого Джо, либо если кто-то будет копать, то рано или поздно откапает.


                                                                  Вот взять систему свой-чужой в самолётах. Вроде как и работает, пока никто не знает как (или не знает пароль), но при этом то самолёт где-то упадет, то его банально украдут, в итоге приходилось часто менять и переделывать. https://www.google.com/amp/s/rg.ru/amp/2015/04/02/parol-site.html


                                                                  Да та же энигма — это ещё хуже (хотя там сама энигма утекла довольно быстро).


                                                                  Подходов много, кто-то может просто перебрать или удачно случайно натолкнуться на уязвимость, из которой соберёт всю остальную информацию.


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

                                                                    0

                                                                    По теории вероятности же. Если вероятность утечки за год N%, то чем больше лет работает, то тем больше вероятность, что хоть раз да утекёт за M лет. В каждому году те же N%, но суммарно растёт

                                                                    0
                                                                    через неясность в том, что это одноразово.

                                                                    Для серийных продуктов, типа MS-Word это не подойдет. А вот для одноразовых типа mySite.ru может сработать.
                                                                    +2
                                                                    Безопасность через неясность оценивается ровно так, как и должна.
                                                                    Хотите поменять порт SSH? Ничего не имею против, fail2ban`у работы меньше. Но это не имеет отношения к безопасности.
                                                                      +6
                                                                      Вспомнилась история где добрый человек создал у себя в корне веб-сайта «файл» db_backup.zip, и настроил чтобы его отдавало без возможности докачки, и с минимальной скоростью. А по факту это был скрипт который отдавал мусор из /dev/random. А потом тихими зимними вечерами наблюдал как «хацкеры» третьи сутки выкачивают 20 гиг мусора)
                                                                        0
                                                                        Я думаю все начинается с вашей модели угроз и понимания кому вы противостоите. А потом вы строите свою защиту. Я скорее на стороне, что если необходимо сервис защитить, то проще следовать проверенным рекомендациям и делать сразу как следует.
                                                                        Проблема основная в том, что если вы просто сменили порт, главное, чтобы вы не думали, что все безопасно. Это может уменьшить риск, но не исключить.
                                                                          0
                                                                          Я делал коварнее. Сначала смотрел, какие url прощупывают. Потом на самые частые вешал zip-bomb. admin.php, elrekt.php
                                                                          0
                                                                          С моей точки зрения, подобные упражнения оказывают гомеопатический эффект на безопасность, но усложняют администрирование инфраструктуры.
                                                                            +1

                                                                            используйте порт 65572. Он находится за пределами диапазона утилит сканирования, можете проверить. Хакер не сумеет найти его.


                                                                            зы для слишком прямолинейных: я знаю раскладку tcp заголовка.

                                                                              0
                                                                              а в чем прикол?
                                                                                0

                                                                                Номер порта двухбайтовый, то есть от 1 до 65535 (0 -зарезревирован)

                                                                                  0
                                                                                  непонятно, как выйти за диапазон, есть ли примеры?
                                                                                    0

                                                                                    Например, использовать более плотную укладку значений, давая больше 256 вариантов на один октет.
                                                                                    Поддерживается далеко не всеми раутерами и линиями связи, конечно.


                                                                                    Примеры — почитайте ECMA 99. Там не про связь, а про хранение данных, но массово используются варианты типа — вот это 0xA1, а вот это 0xA1*.


                                                                                    PS: полушутка, конечно :)

                                                                                0
                                                                                Ну а правда, в чём прикол? Порт 65572 — это порт 37, синхронизация времени. Хакер найдёт, правда не факт, что он его заинтересует.
                                                                                  0

                                                                                  Только не 37, а 36.

                                                                                    0

                                                                                    Хакер не найдёт 65572 ))) Он будет сокрыт

                                                                                      0
                                                                                      приведите пример конфигурации клиента и сервера
                                                                                  +1

                                                                                  В статье написана чушь. Security by obscurity это конкретная вещь, а именно "безопасность", полагающаяся на скрытие деталей реализации протокола. В стандартной модели угроз любой протокол считается a priori известным неограниченному кругу третьих лиц. В криптографических протоколах есть "секрет", который известен только взаимодействующим сторонам. Это — не деталь реализации, к алгоритму секрет не прибит гвоздями. В принципе, никто не запрещает считать порт частью секрета, если он нужен только одному клиенту, но это меньше 16 дополнительных бит энтропии, что, прямо скажем, по современным меркам совершенно несерьёзно, тем более что допускает отдельный перебор.


                                                                                  Почему детали реализации нельзя считать частью секрета — да потому что а) чтобы провести аудит надо их раскрыть третьим лицам, б) чтобы взаимодействовать с протоколом надо знать как он работает, в) их не так-то просто поменять и г) они заведомо известны тем, кто разрабатывал протокол, в отличие от секрета. Как следствие, ожидать что "хакер не узнает наш проприетарный протокол поэтому всё безопасно" это надеяться на "авось". Поэтому security though obscurity не работает. Нельзя гарантировать этот самый obscurity. Админам локалхоста конечно многое сойдёт с рук, но только потому что они как неуловимый Джо.


                                                                                  Автор видимо слышал звон, но представление про ИБ имеет мягко говоря поверхностное.


                                                                                  Disclaimer: я не настоящий сварщик, я про криптографию знаю только в рамках теории информации, непосредственно в ИБ не работаю. Но прописные истины настолько просты и их настолько просто узнать, что странно видеть их полное непонимание в "захабренном".

                                                                                    +1
                                                                                    Security by obscurity это конкретная вещь, а именно «безопасность», полагающаяся на скрытие деталей реализации протокола.
                                                                                    Протоколы и криптография это только частный случай «Security through obscurity ».

                                                                                      0

                                                                                      Ключ под ковриком — тоже частный случай :)

                                                                                        +1
                                                                                        Нет, потому что это типовое решение. Спрячьте ключ под коврик соседу, чтобы добавить неясности.

                                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                    Самое читаемое