Комментарии 101
Чего-то маловато.
Только начал читать, а уже "до новых встреч".
Тема интересная, излагается ясно и хорошо. Читать бы дальше, да читать.
Закон больших чисел говорит, что как бы вы ни уменьшали вероятность использования уязвимости, если эта вероятность ненулевая, то её всё-равно кто-нибудь да найдёт и тогда приехали. Так что всё упирается в то, что если на неуловимого джо зарится только мамкин хекер и то случайно, то БЧН работает, но как только вы становитесь лакомым кусочком, то никакие обфускации и смены портов вам ничем не помогут от знающего своё дело человека. А усложняя жизнь чёрным хакерам, вы усложняете её и белым.
Так и есть. И это аргумент против этой ерунды с обфускацией или переносом портов (если перенос порта не решает другой проблемы)
Лучше не создавать илюзии безопасности и не говорить о ней а честно оценивать риски. Если шеф говорит пока нет риска и вы говорите "у нас нет никакой безопасности" это понятно и открыто. И ситуация может заставить вас занятся "нормальной" безопасностью. Ежели вы начинаете коммуникацию типа ну это не надежно но у нас уже есть "обфускация", то ваша организация особенно далекие от темы люди могут решить, что кое какие меры таки приняты и ваша задница кое-как да прикрыта (Но это не так!), тем самым откладывая настояще выделение ресурсов на решение проблемы… Я лично сталкивался с этом и думаю в этом основной АНТИПЭТТЕРН или покрайней мере не малый его аспект.
Так и есть. И это аргумент против этой ерунды с обфускацией или переносом портов (если перенос порта не решает другой проблемы)
Это аргумент против совсем другой «ерунды» — системы безопасности в собственном приложении. Переносы портов и тому подобные вещи преследуют иную цель, защититься от безмозглых роботов, которые автоматически щупают известные сервисы на предмет известных им уязвимостей. И это вполне себе работает.
Однажды в своем проекте я сделал функцию, которая называлась md5 но на самом деле брала sha и обрезала до длины md5.
Зачем?
Вполне может случиться так, что обрезав контрольную сумму вы понизили энтропию результата и ухудшили безопасность или повысили вероятность коллизий даже по сравнению с md5.
Я не стану утверждать что это истинно в данном конкретном случае, это общая рекомендация для всех кустарных манипуляций с шифрованием.
Вы очень много написали про уменьшение вероятности. Только вот такая защита против реальных атак практически бесполезна. Да, вы защитились от мелких хакеров, но ничего не сделали для реальной защиты.
Лично мне напрашивается аналогия с тем, что некоторые думают что марлевые маски защищают от коронавируса, потому что как минимум отсеивают крупные частицы. Так вот, в реальном мире это не так.
Сразу пришла в голову мысль
Если уязвимость обнаружена в протоколе Microsoft Remote Desktop Protocol, весь интернет начнёт сканировать порт 3389. Вы можете уменьшить риски, просто изменив порт по умолчанию.
от таких «полезных» советов хочется ругаться матом. да, вы можете немного снизить риски, но этого абсолютно недостаточно и потому смена порта бесполезна.
Я провёл небольшой опрос в своём твиттере, чтобы выяснить поведение людей при сканировании портов.
ну так и вопрос поставлен некорректно.
«просто посмотреть» — да, сканируются стандартные порты. «поискать уязвимости» — сканируются все порты.
плюс непонятно вообще насколько коррелируют ответы читателей того твиттера с поведением реальных хакеров.
в целом, вроде бы, написано и правильно, но сама статья скорее вредная, кто-то прочитает, поменяет местами 22 и 3389 порты и успокоится.
в целом, вроде бы, написано и правильно, но сама статья скорее вредная, кто-то прочитает, поменяет местами 22 и 3389 порты и успокоится.Так-то в статье чуть ли не в каждом абзаце написано, что это лишь дополнительная мера. Кто этого не увидит, тому уже ничего не поможет:)
Только вот такая защита против реальных атак практически бесполезна. Да, вы защитились от мелких хакеров, но ничего не сделали для реальной защиты.Sazonov
от таких «полезных» советов хочется ругаться матом. да, вы можете немного снизить риски, но этого абсолютно недостаточно и потому смена порта бесполезна.А нам вот хочется ругаться матом от логики «этого недостаточно, значит и делать этого не надо»
Сразу складывается ощущение, что автор такого утверждения находится в какой-то странной уверенности, что есть «абсолютно достаточная» «реальная защита» в «реальном мире».
Всё к чему есть доступ у кого-то можно взломать, так или иначе, в конце концов можно предложить админу выбор между пожизненным и отдачей паролей.
Поэтому речь всегда идет лишь об а) уменьшении вероятности взлома б) увеличении сложности взлома. Ни о чем больше речь идти не может.
Кроме того, мы этого не заметили в статье, но возможно просто пропустили.
Защита через «неясность» помогает от банальных ошибок персонала, которые тоже случаются. Не спасает, заметьте, т.к. речь опять же о вероятностях, а помогает.
Оставили открытыми порты базы наружу и не сразу заметили? Если содержимое базы шифруется, то обидно, досадно, но не проблема — в статье есть этот пример.
Случайно упал апач и статика с конфигами ушла в открытом виде по хттп (одна крупная фрилансерская биржа) и беда, а вот если бы файлы были зашифрованными, то это могло бы дать время поменять доступы прописанные в конфигах.
В конце концов набивший оскомину уже всем совет не вызывающий вопросов — не хранить пароли в открытом виде — это же прямое следование принципу «безопасность через неясность». Пусть мол тянут базу с хэшами — один черт это ничем никому не поможет.
Хотя тут-то ведь тоже можно возразить. Мол если уже добрались до базы, значит вся система уязвима, поэтому надо не фигней мол маятся с шифрованием пароелй, а базу защищать, т.к. «в реальном мире этой защиты шифрованием паролей недостаточно, спасет только от мелких хакеров» и поэтому «шифрования абсолютно недостаточно и поэтому оно бесполезно» — так?
В конце концов набивший оскомину уже всем совет не вызывающий вопросов — не хранить пароли в открытом виде — это же прямое следование принципу «безопасность через неясность»
ни в коем разе.
security by obscurity — это использование «доморощенных» алгоритмов вместо стандартных, когда сокрытие внутреннего устройства считается дополнительной защитой.
если смену порта ssh ещё как-то можно сюда притянуть, то стандартные хэши в /etc/shadow или шифрование записей БД с помощью aes — это никак не «безопасность через неясность».
А нам вот хочется ругаться матом от логики «этого недостаточно, значит и делать этого не надо»
то есть вы предпринимаете абсолютно все действия, которые могут так или иначе снизить вероятность взлома?
стандартные хэши в /etc/shadow или шифрование записей БД с помощью aes — это никак не «безопасность через неясность».Оно и есть, просто по прямому определению. Сами пароли в безопасности потому что хэш не дает ясности об их содержании, куда уж прямее. В статье упомянуто кстати
Так что этот термин куда шире чем может показаться.
то есть вы предпринимаете абсолютно все действия, которые могут так или иначе снизить вероятность взлома?Мы выше писали — "Поэтому речь всегда идет лишь об а) уменьшении вероятности взлома б) увеличении сложности взлома. Ни о чем больше речь идти не может."
В списке мероприятий смена стандартного метода доступа (порта, страницы админки, способа авторизации, имена печенек и т.д.) на альтернативу обычно является одной из самых простых вещей, это как почистить зубы утром. Да, даже если Вы не предпринимаете абсолютно все действия по укреплению здоровья — почистить зубы утром это базовая вещь:)
К тому же это избавляет от избыточности. В статье упомянуто, что мол 50% сканируют только стандартные порты. Может и так. Но по нашему опыту смена стандартного метода доступа снижает количество запросов на авторизацию в десятки раз. А это ниже нагрузка на сервак, меньше размер логов, меньше работы анализатору атак, меньше баз куда тебя включают по сигнатурам и так далее. Полезно даже безотносительно безопасности.
Оно и есть, просто по прямому определению
в википедии написано так:
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.
Если притягивать – то и шифрование данных попадёт в "security by obscurity". А что? Данные-то есть, а ключ – это детали нашего алгоритма.
Так что надо где-то остановиться. Привычная граница – использование неизвестных алгоритмов вместо проверенных с неизвестными ключами.
Граница тут всегда количественная: какая вероятность угадать нужные данные или получить их с первого подсматривания со стороны.
Номер порта SSH аналогичен алгоритму шифрования с 16-битным ключом, который передаётся открытым текстом во взаимодействии. То есть без сниффера надо 65535 проб, с ним — одна.
Стойкий пароль надо подбирать миллиардами проб (как минимум). Ключ — ещё больше на порядки.
Так термин уже стал от этого зависеть, как только он получил постоянную отрицательную коннотацию. К сокрытию порта его применяют, а к защите паролем — нет, хотя односимвольный пароль тут хуже сокрытия порта :)
Надо или устранять эту коннотацию, или смириться и вводить другой термин для "положительного" варианта.
Ну в смысле суть «security by obscurity» – держать в секрете принимаемые меры (тем самым, помимо прочего, отказываясь от их аудита – в общем-то, это и есть основная проблема) и надеяться, что это поможет.
Ну в смысле суть «security by obscurity» – держать в секрете принимаемые меры (тем самым, помимо прочего, отказываясь от их аудита – в общем-то, это и есть основная проблема) и надеяться, что это поможет.
Аудит бывает разный. Дружественный и не очень, внутренний и внешний.
Мне нравится ваша формулировка в основе, но тут надо подшлифовать. Хотя по сути оно всё равно сведётся в итоге к оценке лёгкости получения необходимой информации тем, кому не положено — но вариант с отказом от аудита тут должен быть важным частным случаем.
К выбору порта можно этот термин притянуть «за уши»: порт это часть протокола, изменяя порт мы изменяем протокол. Можно сделать и другие косметические изменения, например, поменять заголовки пакетов в ssh, это сломает всех ботов и тоже будет security by obscurity.
Но и в статье, и в комментариях к ней происходит явная подмена терминов. Объявляют, что security by obscurity — это что угодно, включая требования к паролю и шифрование записей в БД.
Попробую пояснить через формулировку «anti-security-by-obscurity». Итак, это подход, в котором явно выделяется некоторый относительно компактный секрет (пароли, приватные ключи, таблицы Энигмы, ключ от замка). Всё остальное, включая протоколы, алгоритмы, устройство замка, не считается секретной информацией. Речь не обязательно про то, что мы преподносим эту информацию всем на блюдечке с голубой каёмочкой, а про то, что при оценке угроз мы исходим из того, что она известна атакующему.
Если же это требование не выполняется, если мы считаем, что безопасность обеспечивается «размазыванием» секретности на всё подряд, то мы и получаем security by obscurity. Недостаток этого подхода в том, что защищённость системы очень сложно оценить, поэтому зачастую он приводит к ложному ощущению защищённости.
Так-то в статье чуть ли не в каждом абзаце написано, что это лишь дополнительная мера. Кто этого не увидит, тому уже ничего не поможет:)
Написано, да. Только вот без уточнения, что это поможет только при отсутствии направленной атаки на данную систему — это, мягко говоря, некорректно.
А нам вот хочется ругаться матом от логики «этого недостаточно, значит и делать этого не надо»
Проблема в том, что есть побочный эффект. У кого-то, например, суперзлобный файрволл, который считает все SSH не на порт 22 преступлением первой степени. Причём больше всего такого в корпоративном мире. И там как раз смена порта — это вариант, который практически никогда не считается допустимым. Сервис должен сидеть на стандартном порту, и точка. Защищаться — да, тут тебе и пароли со сменой раз в месяц, и брелки со вторым фактором, и сертификаты VPN, и прочая и прочая. Но — сервис должен выглядеть стандартно, точно так же, как на здании должна быть гордая табличка с названием. Это спецслужбы могут себе позволить невзрачные двери без вывески, но не корпорации. (Да, понятно, что у корпораций есть свои спецслужбы. Речь не о них.)
Защита через «неясность» помогает от банальных ошибок персонала, которые тоже случаются. Не спасает, заметьте, т.к. речь опять же о вероятностях, а помогает.
Если речь про открытую всем ветрам монгу — да, согласен — хотя это снова только вопрос нескольких дней и недель — потому что всё равно есть те, кто сканирует все порты на все виды сервисом.
Но нестандартные конфигурации увеличивают количество ошибок и близких проблем, включая "я снёс этот сервис, потому что херня какая-то" и "как это "на другом порту", вы что, с ума сошли? делайте как положено или я скажу директору и вас сегодня же уволят". Так что тут палка о двух колючих концах.
а вот если бы файлы были зашифрованными, то это могло бы дать время поменять доступы прописанные в конфигах.
Тут категорически да, при условии, что и ключ шифрования не утёк. Но для этого нужно иметь хоть какую-то дисциплину администрирования ;(
Хотя тут-то ведь тоже можно возразить.
Все подобные риски имеют ненулевую вероятность, и серьёзный разговор начинается только после их количественной оценки.
Написано, да. Только вот без уточнения, что это поможет только при отсутствии направленной атаки на данную систему — это, мягко говоря, некорректно.
А почему вы считаете, что поможет только при отсутствии направленной атаки? При направленной атаке у 100% хакеров понимание неясности займет 0% ресурсов?
При направленной атаке у 100% хакеров понимание неясности займет 0% ресурсов?
Не ноль, но ничтожную долю от всех затрат.
Верно, обычные люди. Но после выяснения собственно порта — что делает тупой автомат на nmapʼе — дальше начнётся всякая проба стандартных паролей и т.п., что таки больше в объёме и для человека, и для компьютера.
что делает тупой автомат на nmapʼеАга, особенно когда фаервол банит его после скана 10 портов. В итоге вместо того чтобы сразу начинать брутфорсить SSH, придётся покупать пул IP адресов для скана портов. Это уже точно не будет являтся «ничтожной долей от всех затрат».
Вообще я не имел ввиду этот конкретный случай со сменой порта SSH. Но даже тут можно всё усложнить, например, запустив какой нибудь фейковый SSH сервер типа Cowrie. Хотя это, наверное правильней называть «Security through cheating».
Ну, это уже мы лезем в тему различия массового скана (где может найдётся одна жертва на пару тысяч адресов за месяц) и направленного (который будет делаться как-то сильно менее заметно). Но частично вы правы, безусловно — такой первичный скан сильно дороже и будет заметен даже в затратах на APT.
Security through cheating
Ну можно, да, пару сотен honeypotʼов запустить и замаскировать в них один реальный… это уже мы далеко пойдём в обсуждении подобных мер :) Главное то, что если уж начали такое делать — там точно не будет на входе юзеров с паролем типа 12345. (Ну, статистически.)
Вот тут у Вас серьезная ошибка и недооценка. Уже сейчас есть возможность получить аналог "пула IP адресов" (совсем не их, но их функциональный аналог) за совершенно смешные деньги. Десятка центов точно хватит, чтобы просканировать все порты на одной точке входа, причем это можно делать параллельно для разных точек.
А нам вот хочется ругаться матом от логики «этого недостаточно, значит и делать этого не надо»
Нет, логика звучит так: "эти телодвижения создают лишь видимость повышения безопасности, поэтому лучше потратить своё время и внимание на то, что действительно её повышает". Например...
Оставили открытыми порты базы наружу и не сразу заметили? Если содержимое базы шифруется, то обидно, досадно, но не проблема — в статье есть этот пример.
… например, такая настройка системы, чтобы порты не могли непреднамеренным образом оказаться открытыми. Самый простой способ — превентивное сканирование.
И, кстати шифрация БД — это не БЧН, а как раз наоборот — БД может быть открыта без снижения безопасности. Можно пойти ещё дальше и хранить приватный ключ лишь на пользовательском устройстве, тогда компроментация любого сервера не создаст угрозу безопасности. Но это не везде применимо, конечно.
Простой пример, проекты с закрытым исходном кодом намного трудней взломать.
— Одну со стандартным портом и простыми учётками.
— Одну со стандартным портом и чуть более сложными учётками.
— Одну с нестандартным портом (и далее по списку).
А потом анализировать — через сколько всё это счастье взломается.
И, да, опрос в твиттере не является серьёзным исследованием…
Смена портов отфильтрует разве что скрипты и боты. Проверить все порты хоста на наличие открытых и определить что за сервис на нем крутится не составляет большого труда. Если это и есть первый слой швейцарского сыра, то дырки в нем просто огромные
Смена портов отфильтрует разве что скрипты и боты.По мне так уже это достаточная причина сменить порт.
Так скрипты и боты могут нагонять достаточно большой трафик.
Бан IP не должен быть настолько легким и быстрым — «обращение к несуществующему порту и всё», должна быть проверка на случайность этого обращения, особенно когда это обращение может быть легко спровоцировано 3-ей стороной. Хотя бы подождать попытки авторизации что-ли.
О такой ловушке «догадаться» несложно, достаточно просто начать щупать сайт конкурента и оппа — уже о ней знаешь, это же базовая проверка — чекнуть все порты на реакцию.
Эмулировать обращение к такой ловушке тоже примитивно, можно не только картинкой, но и ссылками (напрямую или через редирект) — не только люди в бан улетят, но и гугл/яндекс, что обычно куда болезненнее.
это же базовая проверка — чекнуть все порты на реакциюПосле проверки первого же порта, находящегося в чёрном списке, IP проверяющего будет мгновенно забанен и придётся его менять, чтобы проверить остальные порты, что для случайного взломщика слишком геморройно. Если же у человека есть сеть сканирующих роботов — то это всё-таки необычный взломщик и вероятность нарваться на такого спеца — не шибко высока.
Эмулировать обращение к такой ловушке тоже примитивно, можно не только картинкой, но и ссылками (напрямую или через редирект) — не только люди в бан улетят, но и гугл/яндекс, что обычно куда болезненнее.Для решения этой проблемы достаточно создать белый список ipset, в который добавить подсети ценных IP-адресов, и сделать проверку IP по этому списку в первом правиле фаервола — до всех прочих проверок.
какие у вас продвинутые конкуренты.
Есть специальные группы, которые занимаются взломами. Они могут сами выйти на конкурентов и предложить услуги. Когда замешаны деньги, то сообразительность возрастает в разы.
Да, классно, наверное, когда все пользователи в интернете сидят на фиксированных IP.
(Сразу дисклеймер: я не занимаюсь ИБ профессионально, в смысле зарабатывания денег именно на нём; это сопутствующее, хоть и давно.)
Сначала немного общих слов. Основная проблема определения 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, чтобы пускать только реальных пользователей и заведомо отсекать всяких демонов. Доступ только по ключам из мира — тоже неплохая защита. Но — и смена порта хороша тем, что уменьшится замусоривание логов. Только помнить, что она сама по себе ничто.
Увы, не безусловно.
Все подобные варианты я подвёл под "даже косвенной".
Можно использовать port knocking, как вариант.
Если там time-based ключевые фразы — то пойдёт, но для индивидуального использования: если у вас 100 пользователей, если у каждого свой ключ, это будет сложно в управлении, а если у всех одинаковый, утечка у одного заставит поменять у остальных.
Если одна фиксированная фраза — те же проблемы с подслушиванием, что у просто порта (хотя надёжнее статистически, чем у просто открытого порта).
Однако совсем иначе дела обстоят с продуктом/сервисом. В таком случае вы предоставляете свое решение во вне и любой пользователь может быть как жертвой атаки, так и собственно атакующим… В такой ситуации вы создаете неясность и тем и другим (т.к. по умолчанию не можете разделить пользователей на «хороших» и «плохих» — вы же не знаете, зачем они приобрели продукт: чтоб пользоваться, или чтоб уязвимости искать), но в итоге добропорядочным пользователям остается надеятся только на то, что ВЫ знаете что делаете. Провести собственный аудит им будет затруднительно. Т.е. пользователи вынуждены доверять свою безопасность разработчику, за что переодически и расплачиваются.
С другой стороны — если разработчик использует полностью открытые механизмы защиты, пользователь может в общих чертах оценить риски, плюс привлечь сторонний аудит. Так же повысит доверие к разработчику программа баг-баунти (или как там называется то же самое но на безопасность? пен-тест?).
Мне кажется не использовать Безопасность через неясность — это все-таки про сервисы. Когда неясность двусторонняя — когда я как пользователь, тоже не понимаю как моя безопасность в данном решении обеспечивается. И тот факт, что «и хакер не понимает» — меня мало успокаивает…
Но если из-за какой-то уязвимости злоумышленник считывает данные из БД, но не видит внутренний код (например, через SQL-инъекцию), то полученные данные ничего ему не дадут.
Возможно я что-то пропустил, но как шифрование БД влияет на SQL-инъекцию? SQL-инъекции позволяют получать данные из других таблиц посредством расширения запроса, т.е. ваш штатный интерфейс из-за инъекции выведет несколько больше информации чем должен был и как тут может повлиять шифрование?
Злоумышленник получил зашифрованные данные, ключа не знает — для него это пока просто набор бессмысленных байтов.
Но ведь данные после запроса расшифровываются как-то при нормальной работе приложения? Ведь код на клиенте не с зашифрованным мусором работает? А значит, если удалось расширить запрос и получить больше данных, то они также расшифруются.
А значит, если удалось расширить запрос и получить больше данных, то они также расшифруются.
Не значит. Клиент БД на сервере вполне может держать ключ шифрования где-то отдельно (не в БД) и использовать шифрование своими средствами. И вот одна колонка полностью зашифрована — и что вы с этим сделаете не зная ключа?
разве что в том крайне редком случае, когда используется не шифрование БД, а конкретно каких-то там избранных данных,
Тут как раз этот вариант и имелся в виду, судя по описанию. Его редкость, думаю, немного преувеличена.
Поэтому практически везде юзается прозрачное шифрование средствами СУБД, которое хорошо помогает от «утащить базу данных», «сниффить сетевой трафик»
Странные вещи говорите. Для трафика есть HTTPS. Для утащить файлами — пароль зашифровки должен лежать рядом, чтобы сервер базы мог запускаться сам (вариант участия человека на каждый старт не рассматриваем… разве что автомат, который запрашивает пароль по сети при старте? такого я ещё не видел, хотя теоретически возможно).
Ну и SQL инъекции в плохом коде, по отчётам последних лет, сильно вероятнее взлома с доступом к полной FS или запуском шелла — поправьте, если что-то изменилось.
Странные вещи говорите. Для трафика есть HTTPS.
Во многих СУБД там между драйвером на клиенте и сервером БД используется не HTTPS, а нативный протокол, порой разработанный ещё в те времена, когда этих ваших интернетов не было.
Для утащить файлами — пароль зашифровки должен лежать рядом, чтобы сервер базы мог запускаться сам (вариант участия человека на каждый старт не рассматриваем… разве что автомат, который запрашивает пароль по сети при старте? такого я ещё не видел, хотя теоретически возможно).
Вообще, как раз второй вариант и используется. Например, это уже много лет как штатная опция для MS SQL Server. Сервер по сети обращается к Windows Certificate Store или к Azure Key Vault под своей учёткой, и получает оттуда ключи. У него самого они нигде не хранятся. Так же умеет делать и Oracle. И, думаю, и многие другие популярные СУБД. Тут ничего не надо сочинять/программировать, просто настроить.
Я плотно видел только mysql и postgres (в базовом варианте), там такого не водилось. ok, спасибо за инфу.
В таком варианте действительно прозрачное шифрование должно относительно легко строиться.
Но вот явное шифрование видел сам и слышал пару раз, а для паролей так вообще норма. Было, что они по специфике лежат в открытом виде — ну вот именно что шифровали обратимым образом с ключом, который лежал в достаточно хитром месте. Да, SbO (будем уже сокращать тему всей статьи;)) в чистом виде, но вместе с мерами защиты доступа на сам сервер получалось, что предполагали максимальную опасность именно от инъекций, а при них добраться до того места было нереально, если ещё какая-нибудь дыра не нашлась бы.
Шифрование делает эти инъекции во многом бесполезными, даже в случае полного слива базы.
Насколько я понимаю, основная проблема в защите через неясность в том, что это одноразово. Вот у вас есть самописная система безопасности и пока никто не знает как она работает — она может справляться эффективно. Как только утечет (а это случится рано или поздно) как она работает — у вас больше нет этого уровня безопасности от слова совсем. Как второстепенный уровень чтобы просто убрать интерес — может быть, но как основной — точно нет.
К слову, это может сыграть и обратный эффект: скажем, все прозрачно и понятно, но не известен пароль — такое ломать скучно и только ради определенной выгоды. А если система неизвестная — может вызвать просто спортивный интерес.
Как только утечет (а это случится рано или поздно)А почему собственно она обязана утечь?
Тут либо эффект неуловимого Джо, либо если кто-то будет копать, то рано или поздно откапает.
Вот взять систему свой-чужой в самолётах. Вроде как и работает, пока никто не знает как (или не знает пароль), но при этом то самолёт где-то упадет, то его банально украдут, в итоге приходилось часто менять и переделывать. https://www.google.com/amp/s/rg.ru/amp/2015/04/02/parol-site.html
Да та же энигма — это ещё хуже (хотя там сама энигма утекла довольно быстро).
Подходов много, кто-то может просто перебрать или удачно случайно натолкнуться на уязвимость, из которой соберёт всю остальную информацию.
Иными словами, если у вас обычный домашний компьютер и никому не нужно — может и сработать, а если банк — будут копать и рано или поздно то ли социальная инженерия сработает, то ли удача, то ли уязвимость в какой-то известной системе, после чего вы мгновенно теряете все преимущество скрытия.
По теории вероятности же. Если вероятность утечки за год N%, то чем больше лет работает, то тем больше вероятность, что хоть раз да утекёт за M лет. В каждому году те же N%, но суммарно растёт
через неясность в том, что это одноразово.
Для серийных продуктов, типа MS-Word это не подойдет. А вот для одноразовых типа mySite.ru может сработать.
Хотите поменять порт SSH? Ничего не имею против, fail2ban`у работы меньше. Но это не имеет отношения к безопасности.
Проблема основная в том, что если вы просто сменили порт, главное, чтобы вы не думали, что все безопасно. Это может уменьшить риск, но не исключить.
используйте порт 65572. Он находится за пределами диапазона утилит сканирования, можете проверить. Хакер не сумеет найти его.
зы для слишком прямолинейных: я знаю раскладку tcp заголовка.
Номер порта двухбайтовый, то есть от 1 до 65535 (0 -зарезревирован)
Например, использовать более плотную укладку значений, давая больше 256 вариантов на один октет.
Поддерживается далеко не всеми раутерами и линиями связи, конечно.
Примеры — почитайте ECMA 99. Там не про связь, а про хранение данных, но массово используются варианты типа — вот это 0xA1, а вот это 0xA1*.
PS: полушутка, конечно :)
В статье написана чушь. Security by obscurity это конкретная вещь, а именно "безопасность", полагающаяся на скрытие деталей реализации протокола. В стандартной модели угроз любой протокол считается a priori известным неограниченному кругу третьих лиц. В криптографических протоколах есть "секрет", который известен только взаимодействующим сторонам. Это — не деталь реализации, к алгоритму секрет не прибит гвоздями. В принципе, никто не запрещает считать порт частью секрета, если он нужен только одному клиенту, но это меньше 16 дополнительных бит энтропии, что, прямо скажем, по современным меркам совершенно несерьёзно, тем более что допускает отдельный перебор.
Почему детали реализации нельзя считать частью секрета — да потому что а) чтобы провести аудит надо их раскрыть третьим лицам, б) чтобы взаимодействовать с протоколом надо знать как он работает, в) их не так-то просто поменять и г) они заведомо известны тем, кто разрабатывал протокол, в отличие от секрета. Как следствие, ожидать что "хакер не узнает наш проприетарный протокол поэтому всё безопасно" это надеяться на "авось". Поэтому security though obscurity не работает. Нельзя гарантировать этот самый obscurity. Админам локалхоста конечно многое сойдёт с рук, но только потому что они как неуловимый Джо.
Автор видимо слышал звон, но представление про ИБ имеет мягко говоря поверхностное.
Disclaimer: я не настоящий сварщик, я про криптографию знаю только в рамках теории информации, непосредственно в ИБ не работаю. Но прописные истины настолько просты и их настолько просто узнать, что странно видеть их полное непонимание в "захабренном".
Security by obscurity это конкретная вещь, а именно «безопасность», полагающаяся на скрытие деталей реализации протокола.Протоколы и криптография это только частный случай «Security through obscurity ».
В этих двух примерах показана не безопасность через неясность, а стеганография.
Безопасность через неясность недооценивается