Часто можно встретить мнение, что linux безопасен. Пока — это действительно верно, никто особо тщательных усилий на создание атакующих программ не предпринимал, поэтому и создаётся иллюзия безопасности. Однако давайте попробуем сами заранее обратить внимание на те вещи в linux-системе, которые в будущем могут заинтересовать злоумышленников.
Данная статья не претендует на полноту обзора проблем, я хочу пока только обозначить контуры проблемы, которая уже существует, но пока никак особо не решается. Некоторые из описанных методов защиты можно заставить работать уже сейчас, некоторые — надо заставлять реализовывать авторов системного софта.
Update Почему-то для некоторых читателей общая идея статьи оказалась непонятной, поэтому пропишу явно: идея в том, чтобы показать некоторые конкретные примеры применения известных атак (если можно это назвать «атакой», конечно) в именно linux-окружении. Linux — ничуть не безопаснее в некоторых аспектах, чем другие системы.
О способах проникновения говорить смысла нет, вредный софт всё равно просочится на любую систему. И никакой антивирус не поможет. Также не будем особо углубляться в типы вредоносного ПО, пусть это будут «троянцы» и «вредители». Троянцы — это разнообразные кейлоггеры, похитители паролей и прочие шпионы. Вредители — это стиратели документов и разрушители системы. Далее всё это буду называть одним словом «вирус». Также опустим вопрос вредительства на системном уровне, то есть будем считать, что вирусу в /usr/bin не пробраться.
Итак, вирус в системе, например, через дырку в libflash запустился скачанный бинарник; для выживания ему нужно прописать себя в автозагрузку. В современной системе для этого есть множество разнообразных способов, часто крайне трудно вычислимых. В каждом Desktop Environment (DE) существует несколько способов запускать приложения при старте DE. Например, в KDE есть каталог ~/.kde/env, все файлы из которого выполняются при загрузке системы, аналогично работает каталог ~/.kde/Autostart (между этими двумя каталогами есть разница, но в рамках данной статьи она несущественна). Достаточно положить туда исполнимый файл-скрипт для запуска вируса и всё. Более хитрый вариант — просканировать этот каталог и встроить команду запуска уже в существующий скрипт.
О такой мелочи как маскировка имени вируса в списке процессов даже и не говорим. Вирус без проблем может выдавать себя за что угодно.
Помимо средств DE остаются разнообразные стартовые скрипты типа ~/.xsession или ~/.profile, или .zshrc. При большом желании, наверное, можно даже в ~/.fonts.conf какую-нибудь разрушительную дрянь засунуть.
Как бороться? Никак. Пока никаких средств надёжного контроля нет, с бардаком в скриптах никто (из авторов софта) особо не заморачивается. Параноидальное решение — считывать хешсуммы от критичных пользовательских файлов-конфигов и хранить их в месте, недоступном для изменения со стороны пользователя. Затем при запуске все хешсуммы проверять.
Помимо прописывания себя в файле автозапуска, вирус может добавить кучу полезной для него информации в конфигурационные файлы. Одной из самых привлекательных целей может стать переменная окружения PATH. Напомню, что в этой переменной хранится список путей, которые будут испробованы для поиска исполнимой программы. Обычно переменная PATH выглядит примерно так: /usr/bin:/bin, а вирус может её модифицировать как ~/bin:/usr/bin:/bin. Чревато это тем, что теперь программа, набранная без указания полного пути, будет сначала искаться в пользовательском каталоге, а уж потом в системных. А в пользовательском каталоге будет лежать заботливно подложенная вирусом программа с названием ssh или sudo; пользователь ничего не заметит, а введённые им критичные данные благополучно сольются.
Решение? Использовать только полные пути при запуске программ. Однако это не гарантированная защита. Более надёжным решением было бы ограничивать доступ к модификации критично важных переменных окружения.
Здесь всё совсем грустно. Как правило для нанесения максимального вреда достаточно одной команды — rm -rf ~/. После этого можно попрощаться со всеми данными.
Также ничего не мешает зашифровать все данные в домашнем каталоге, как это делают некоторые виндовые вирусы.
Также возможно и более мелкое вредительство, например, прописывание в конфиги браузеров всякой дряни (подмена домашней страницы, например). Централизованно бороться с таким невозможно, тут должны авторы приложений разбираться.
Несомненно, злоумышленникам значительно облегчит жизнь стандартность расположения профайлов приложений. Например, почти всегда профайл Оперы будет лежать в каталоге ~/.opera. Так что частично можно спастись, меняя стандартные пути профилей, многие приложения позволяют это делать.
Достойная защищённость требует изрядной доли паранойи. Значительно осложнить жизнь вирусу поможет система контроля запускаемых приложений (сравнение хешсумм исполнимых файлов и скриптов). Запретить «зацепиться» на диске можно запретом на запись на этот самый диск. При этом нужно всё-таки обеспечить какой-то способ модификации конфигурационных файлов.
Описанные способы и варианты — это лишь то, что приходит в голову при попытке задуматься о проблеме. Наверняка, найдутся ещё какие-нибудь особо изысканные методы (типа использования ~/.fonts.conf), но для начала хватит и этого. Вот только производители софта, в том числе и системного, над вопросами такой вот примитивно-бытовой безопасности не задумываются особо. А надо бы.
Данная статья не претендует на полноту обзора проблем, я хочу пока только обозначить контуры проблемы, которая уже существует, но пока никак особо не решается. Некоторые из описанных методов защиты можно заставить работать уже сейчас, некоторые — надо заставлять реализовывать авторов системного софта.
Update Почему-то для некоторых читателей общая идея статьи оказалась непонятной, поэтому пропишу явно: идея в том, чтобы показать некоторые конкретные примеры применения известных атак (если можно это назвать «атакой», конечно) в именно linux-окружении. Linux — ничуть не безопаснее в некоторых аспектах, чем другие системы.
О способах проникновения говорить смысла нет, вредный софт всё равно просочится на любую систему. И никакой антивирус не поможет. Также не будем особо углубляться в типы вредоносного ПО, пусть это будут «троянцы» и «вредители». Троянцы — это разнообразные кейлоггеры, похитители паролей и прочие шпионы. Вредители — это стиратели документов и разрушители системы. Далее всё это буду называть одним словом «вирус». Также опустим вопрос вредительства на системном уровне, то есть будем считать, что вирусу в /usr/bin не пробраться.
Автозапуск
Итак, вирус в системе, например, через дырку в libflash запустился скачанный бинарник; для выживания ему нужно прописать себя в автозагрузку. В современной системе для этого есть множество разнообразных способов, часто крайне трудно вычислимых. В каждом Desktop Environment (DE) существует несколько способов запускать приложения при старте DE. Например, в KDE есть каталог ~/.kde/env, все файлы из которого выполняются при загрузке системы, аналогично работает каталог ~/.kde/Autostart (между этими двумя каталогами есть разница, но в рамках данной статьи она несущественна). Достаточно положить туда исполнимый файл-скрипт для запуска вируса и всё. Более хитрый вариант — просканировать этот каталог и встроить команду запуска уже в существующий скрипт.
О такой мелочи как маскировка имени вируса в списке процессов даже и не говорим. Вирус без проблем может выдавать себя за что угодно.
Помимо средств DE остаются разнообразные стартовые скрипты типа ~/.xsession или ~/.profile, или .zshrc. При большом желании, наверное, можно даже в ~/.fonts.conf какую-нибудь разрушительную дрянь засунуть.
Как бороться? Никак. Пока никаких средств надёжного контроля нет, с бардаком в скриптах никто (из авторов софта) особо не заморачивается. Параноидальное решение — считывать хешсуммы от критичных пользовательских файлов-конфигов и хранить их в месте, недоступном для изменения со стороны пользователя. Затем при запуске все хешсуммы проверять.
Маскировка
Помимо прописывания себя в файле автозапуска, вирус может добавить кучу полезной для него информации в конфигурационные файлы. Одной из самых привлекательных целей может стать переменная окружения PATH. Напомню, что в этой переменной хранится список путей, которые будут испробованы для поиска исполнимой программы. Обычно переменная PATH выглядит примерно так: /usr/bin:/bin, а вирус может её модифицировать как ~/bin:/usr/bin:/bin. Чревато это тем, что теперь программа, набранная без указания полного пути, будет сначала искаться в пользовательском каталоге, а уж потом в системных. А в пользовательском каталоге будет лежать заботливно подложенная вирусом программа с названием ssh или sudo; пользователь ничего не заметит, а введённые им критичные данные благополучно сольются.
Решение? Использовать только полные пути при запуске программ. Однако это не гарантированная защита. Более надёжным решением было бы ограничивать доступ к модификации критично важных переменных окружения.
Вредительство
Здесь всё совсем грустно. Как правило для нанесения максимального вреда достаточно одной команды — rm -rf ~/. После этого можно попрощаться со всеми данными.
Также ничего не мешает зашифровать все данные в домашнем каталоге, как это делают некоторые виндовые вирусы.
Также возможно и более мелкое вредительство, например, прописывание в конфиги браузеров всякой дряни (подмена домашней страницы, например). Централизованно бороться с таким невозможно, тут должны авторы приложений разбираться.
Несомненно, злоумышленникам значительно облегчит жизнь стандартность расположения профайлов приложений. Например, почти всегда профайл Оперы будет лежать в каталоге ~/.opera. Так что частично можно спастись, меняя стандартные пути профилей, многие приложения позволяют это делать.
Выводы
Достойная защищённость требует изрядной доли паранойи. Значительно осложнить жизнь вирусу поможет система контроля запускаемых приложений (сравнение хешсумм исполнимых файлов и скриптов). Запретить «зацепиться» на диске можно запретом на запись на этот самый диск. При этом нужно всё-таки обеспечить какой-то способ модификации конфигурационных файлов.
Описанные способы и варианты — это лишь то, что приходит в голову при попытке задуматься о проблеме. Наверняка, найдутся ещё какие-нибудь особо изысканные методы (типа использования ~/.fonts.conf), но для начала хватит и этого. Вот только производители софта, в том числе и системного, над вопросами такой вот примитивно-бытовой безопасности не задумываются особо. А надо бы.