Давайте поговорим о Linuxe и о небезопасных моментов. Часто можно встретить мнение, что 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), но для начала хватит и этого. Вот только производители софта, в том числе и системного, над вопросами такой вот примитивно-бытовой безопасности не задумываются особо. А надо бы.
