Небезопасная авторизация x window ubuntu. Руководство по настройке интернет-соединения в Ubuntu

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

Linux представляет собой свободно распространяемое ядро Unix-подобной системы, написанное Линусом Торвалдсом (1991 г., Финляндия) при помощи большого числа добровольцев со всей сети Internet. Linux обладает всеми свойствами современной Unix-системы, включая настоящую многозадачность, развитую подсистему управления памятью и сетевую подсистему. Большую часть базовых системных компонентов Linux унаследовала от проекта GNU, целью которого является создание свободной микроядерной операционной системы (ОС) с лицом Unix.

ОС Linux создавалась сумбурной командой Unix-экспертов, хакеров и случайно прибившихся еще более подозрительных личностей. Хотя система невольно отражает эту тяжелую наследственность и хотя процесс создания Linux выглядел как дезорганизованные усилия добровольцев, система получилась на удивление мощной, надежной, быстрой и к тому же бесплатной.

На сегодняшний день существует множество различных поставок Linux, дистрибутивов, которые можно разделить на дистрибутивы общего назначения и специализированные (например, Linux Router - урезанная поставка Linux для создания дешевого маршрутизатора на базе старого PC и др.). В настоящей статье под словосочетанием <ОС Linux> будем понимать дистрибутивы Linux общего назначения.

Большая часть ядра Linux написана на языке С, благодаря чему система достаточно легко переносится на различные аппаратные архитектуры. Сегодня официальное ядро Linux работает на платформе Intel (начиная с i386), Digital Alpha (64-bit), Motorolla 68k, Mips, PowerPC, Sparc, Sparc64, StrongArm. Ядро Linux способно работать на многопроцессорных SMP-системах, обеспечивая эффективное использование всех процессоров. Разработчики Linux стараются соблюдать стандарты POSIX и Open Group, обеспечивая тем самым переносимость программного обеспечения (ПО) с другими Unix-платформами.

Диапазон применения Linux очень широк: от создания спецэффектов в фильме <Титаник> Джеймса Камерона до создания фирмой Intel в ближайшем будущем Internet-терминалов на базе именно этой ОС. Конечно, одной из причин огромной популярности Linux является ее бесплатность, что, безусловно, снижает себестоимость продуктов, для создания которых она применяется. Но не только в этом дело. Главная причина ее популярности состоит в том, что это действительно мощная и надежная, многопользовательская и многозадачная ОС.

Существует расхожее мнение о том, что Linux характеризуется слабой безопасностью. Но это в корне не верно. Linux - детище глобальной сети Internet и именно поэтому безопасности при ее разработке всегда уделялось огромное внимание. Не случайно в вопросах защищенности Linux всегда выгодно отличалась от многих современных ОС, в том числе многих коммерческих версий Unix.

В настоящее время существуют два основных подхода, используемых для обеспечения безопасности ОС: над слабо защищенной ОС <навешивается> для усиления защитный экран (firewall), или firewall наряду с десятком других средств защиты интегрируется на уровне ядра системы.

Первый подход использует фирма Microsoft и это подтверждает анализ последних версий Windows NT. Разработчики Linux выбрали для себя второй подход (код firewall встроен непосредственно в ядро Linux, начиная с версии 2.0). В результате была получена мощная интегрированная система защиты. Краткому знакомству с этой системой и посвящена данная статья.

При создании системы защиты для любой ОС нужно четко понимать, что реализовать на практике полностью безопасную компьютерную систему невозможно. Можно создать лишь дополнительные препятствия для злоумышленника, пытающегося проникнуть в систему. Причем объем и качество реализованных средств защиты зависят от области использования Linux. Кроме того, необходимо брать в расчет, что с ростом количества установленных средств защиты система становится все более враждебной для рядового пользователя. Поэтому главная задача при создании системы защиты - нащупать ту точку баланса, которая будет приемлемой для политики управления Linux-системой.

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

Для того чтобы оценить эффективность системы защиты ОС Linux, необходимо четко разобраться с тем, какие же угрозы могут быть реализованы злоумышленниками на уровне ОС в той или иной конкретной ситуации.

Атаки на уровне ОС

На уровне ОС происходит большое количество хакерских атак. Это объясняется очень просто: ведь взломав защиту ОС, злоумышленник может получить доступ к любым ресурсам сети (вплоть до баз данных).

Среди людей несведущих бытует мнение, что самые эффективные атаки на ОС организуются с помощью сложнейших средств, использующих последние достижения науки и техники, а хакер должен быть программистом высочайшей квалификации. Это не совсем так. Конечно, хорошо быть в курсе всех новинок в области компьютерной техники. Да и высокая квалификация никогда не бывает лишней. Однако искусство хакера состоит отнюдь не в том, чтобы разрушать любую, самую <крутую> компьютерную защиту. Взломщику нужно просто найти слабое место в конкретной защитной системе и с максимальной выгодой для себя воспользоваться им. При этом простейшие методы атаки оказываются ничуть не хуже самых изощренных, поскольку простой алгоритм реже порождает ошибки и сбои.

Успех реализации того или иного алгоритма хакерской атаки на практике в значительной степени зависит от архитектуры и конфигурации конкретной ОС - объекта атаки. Рассмотрим, какие механизмы противодействия различным атакам применяются в ОС Linux.

Традиционные способы защиты, используемые в Linux

Традиционные способы защиты ОС в основном связаны с физической безопасностью. Физическая безопасность - это первый уровень безопасности, который необходимо обеспечить для любой компьютерной системы. Причем к очевидным методам обеспечения физической безопасности относятся замки на дверях, кабели в коробах, закрытые ящики столов, средства видеонаблюдения и т. п. Для усиления этих проверенных временем мероприятий можно использовать также компьютерные замки различных конструкций, основное назначение которых сводится к следующему:

Предотвращение хищения компьютера и его комплектующих;

Предотвращение возможности перезагрузки компьютера посторонним, а также использования собственных дисководов или иного периферийного оборудования;

Прерывание работы компьютера при вскрытии корпуса;

Блокировка работы с клавиатурой и мышью.

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

Некоторые загрузчики Linux позволяют установить пароль, запрашиваемый при загрузке системы. Так, при работе с LILO (Linux Loader) можно использовать параметры (позволяет установить пароль для начальной загрузки) и (разрешает загрузку после указания определенных опций в ответ на запрос LILO).

Периодически появляется необходимость отлучаться от компьютера. В таких ситуациях полезно заблокировать консоль, чтобы исключить возможность ознакомления с вашим именем и результатами работы. Для решения этой задачи в Linux используются программы xlock и vlock. С помощью xlock блокируется доступ для X дисплея (для восстановления доступа необходимо ввести регистрационный пароль). В отличие от xlock vlock позволяет заблокировать работу отдельных (или всех) виртуальных консолей Linux-машины. При использовании этих полезных программ нужно четко понимать, что они не защищают от перезагрузки или других способов прерывания работы системы.

Большинство методов, с помощью которых злоумышленник может получить доступ к ресурсам, требуют перезагрузки или выключения питания машины. В связи с этим нужно очень серьезно относиться к любым признакам взлома как на корпусе, так и внутри компьютера, фиксировать и анализировать все странности и несоответствия в системном журнале. При этом нужно исходить из того, что любой взломщик всегда пытается скрыть следы своего присутствия. Для просмотра системного журнала обычно достаточно проверить содержимое файлов syslog, messages, faillog и maillog в каталоге /var/log. Полезно также установить скрипт ротации журнальных файлов или демона, который сохраняет журналы на заданную глубину (в последних дистрибутивах Red Hat для этого используется пакет logrotate).

Несколько слов о локальной безопасности Linux-систем. Она обычно связана с двумя моментами: защита от локальных пользователей и защита от администратора системы. Не секрет, что получение доступа к счетам локальных пользователей - это первая задача, которую ставит перед собой злоумышленник, пытаясь проникнуть в систему. Если надежные средства локальной защиты отсутствуют, то, используя ошибки в ОС и/или неверно сконфигурированные службы, злоумышленник может легко изменить полномочия в сторону увеличения, что чревато тяжелыми последствиями. Общие правила, которые необходимо соблюдать для повышения локальной защиты состоят в следующем: предоставление минимально необходимого уровня привилегий; контроль за регистрацией всех пользователей; своевременное изъятие счетов пользователей. Нужно постоянно помнить о том, что неконтролируемые счета - идеальный плацдарм для проникновения в систему.

Необдуманные и некорректные действия администратора также представляют серьезную опасность для Linux-системы. Поэтому администратор всегда должен помнить о том, что постоянная работа со счетом суперпользователя (root) - очень опасный стиль (в качестве компромисса лучше использовать команды su или sudo). Права суперпользователя он должен использовать только для решения специфических задач, в остальных случаях рекомендуется использовать обычный пользовательский счет. В дополнение к этому при выполнении сложных команд администратор должен использовать такие режимы, которые не приведут к потере данных. И последнее: администратор не должен забывать о существовании <троянских коней>, так как программы этого типа при запуске с правами суперпользователя могут внести серьезные нарушения в систему защиты. Для исключения этого необходимо тщательно контролировать процесс установки программ на компьютере (в частности, дистрибутив RedHat предусматривает использование цифровых подписей md5 и pgp для проверки целостности rmp-файлов во время установки системы).

Защита Linux с помощью паролей

Анализ рисков на уровне ОС показывает, что наибольшую опасность представляют действия злоумышленников, связанные с кражей или подбором паролей. Защита паролей поэтому должна занимать ведущее место в системе защиты любой ОС.

Защита паролей - область, в которой Linux существенно отличается от многих коммерческих версий Unix и других ОС, причем в лучшую сторону.

В большинстве современных реализаций Linux программа passwd не позволяет пользователю вводить легко разгадываемые пароли путем предупреждения о потенциальной опасности пароля (ввод пароля при этом, к сожалению, не блокируется). Для проверки устойчивости ансамбля конкретного пароля к подбору существует немало программ. Причем используются они с успехом как системными администраторами, так и взломщиками. Наиболее распространенные представители этого класса программ - Crack и John Ripper. Стоит отметить, что эти программы требуют дополнительного процессорного времени, но эта потеря вполне оправдана - замена слабых паролей значительно снижает вероятность проникновения в систему.

Linux обеспечивает защиту паролей с помощью трех основных механизмов:

1. Шифрование паролей.

2. Механизм <теневых паролей>.

3. Механизм подключаемых модулей аутентификации PAM (Pluggable Authentication Modules).

Кратко рассмотрим суть этих механизмов.

Шифрование паролей.

В Linux для шифрования паролей традиционно используется алгоритм DES. Зашифрованный пароль обычно помещается в файл /etc/passwd. При попытке пользователя зарегистрироваться в системе введенный им пароль шифруется и затем сравнивается с записью в парольном файле. При совпадении система разрешает доступ. В программе шифрования паролей используется однонаправленное шифрование (достигается за счет того, что ключом для шифрования пароля является сам пароль). К сожалению, в настоящее время алгоритм DES уязвим к атаке со стороны мощных компьютеров (использование прямого перебора или подбора в большинстве случаев приводит к отгадыванию паролей). Поэтому для Linux были разработаны дополнительно к шифрованию еще два мощных механизма защиты.

Механизм <теневых паролей>.

Суть этого механизма проста: парольный файл, даже зашифрованный, доступен только системному администратору. Для этого он помещается в файл /etc/shadow, права на чтение которого принадлежат только суперпользователям. Для реализации подобной схемы защиты в Linux используется набор программных средств Shadow Suite. В большинстве дистрибутивов Linux механизм <теневых паролей> по умолчанию не задействован (кроме, пожалуй, RedHat). Но именно Linux выгодно отличает наличие новейшего механизма, с помощью которого можно легко организовать мощную систему защиты. Это технология подключаемых модулей аутентификации (PAM).

Механизм PAM.

Модули безопасности - это набор открытых библиотек, предназначенных для выполнения набора функций (ввод пароля или проверка его подлинности). Любая программа, использующая систему защиты, может использовать PAM-модули и обеспечить в результате любой уровень безопасности. При использовании этого новейшего механизма программист концентрирует свое внимание на решении прикладной задачи. Ему не надо изобретать систему защиты, при этом также гарантируется, что он в этой системе не наставит <дыр>. Технология PAM позволяет реализовать некоторые новые возможности при создании системы защиты: в модулях безопасности применяются нестандартные процедуры шифрования (MD5 и им подобные); установка ограничений на использование пользователями системных ресурсов (предотвращение инициализации атак типа <Отказ в обслуживании>); установка разрешения отдельным пользователям регистрации только в фиксированные промежутки времени и только с определенных терминалов или узлов.

Дополнительные средства защиты Linux

Защита данных.

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

Безусловно, что для повышения конфиденциальности полезно хранить данные на дисках в зашифрованном виде. Для обеспечения сквозного шифрования всей файловой системы в Linux используются криптографические файловые системы CFS (Cryptographic File System) и TCFS (Transparent Cryptographic File System).

Защита дисплеев.

Защита графического дисплея - важный момент в обеспечении безопасности системы. Она направлена на исключение возможности перехвата пароля, ознакомления с информацией, выводимой на экран, и т. п. Для организации этой защиты в Linux предусмотрены следующие средства:

Программа xhost (позволяет указать, каким узлам разрешен доступ к вашему дисплею);

Регистрация с использованием xdm (x display manager) - для каждого пользователя генерируется 128-битный ключ (cookie);

Организация обмена с помощью защищенной оболочки ssh (secure shell) - в сети исключается поток незашифрованных данных.

Дополнительно к этому для организации контроля доступа к видеоподсистеме компьютера в рамках Linux разработан проект GGI (Generic Graphics Interface). Идея GGI состоит в переносе части кода, обслуживающего видеоадаптеры, в ядро Linux. С помощью GGI практически исключается возможность запуска на вашей консоли фальшивых программ регистрации.

Сетевая защита. По мере развития сетевых технологий вопросы безопасности при работе в сети становятся все более актуальными. Практика показывает, что зачастую именно сетевые атаки проходят наиболее успешно. Поэтому в современных ОС сетевой защите уделяется очень серьезное внимание. В Linux для обеспечения сетевой безопасности тоже применяется несколько эффективных средств:

Защищенная оболочка ssh для предотвращения атак, в которых для получения паролей используются анализаторы протоколов;

Программы tcp_wrapper для ограничения доступа к различным службам вашего компьютера;

Сетевые сканеры для выявления уязвимых мест компьютера;

Демон tcpd для обнаружения попыток сканирования портов со стороны злоумышленников (в дополнение к этому средству полезно регулярно просматривать файлы системного журнала);

Системашифрования PGP (Pretty Good Privacy);

Программа stelnet (защищенная версия хорошо известной программы telnet);

Программа qmail (защищенная доставка электронной почты);

Программа ipfwadm для настройки межсетевых экранов (firewall);

Режим проверки паролей входных соединений для систем, разрешающих подключение по внешним коммутируемым линиям связи или локальной сети.

Отрадно отметить, что многие из перечисленных средств включены в состав последних дистрибутивов Linux.

Заключение

Linux - это уникальная ОС, построенная на основе ОС Unix с двадцатипятилетней историей. На сегодняшний день это, пожалуй, единственный пример столь масштабного и плодотворного сотрудничества специалистов всего мира, объединенных сетью Internet. Именно поэтому любая подсистема этой ОС, в том числе и подсистема защиты, представляет большой практический интерес и содержит много особенностей, некоторые из них не нашли свое достаточное отражение в данной статье.

Несмотря на оголтелую пропаганду решений <от Microsoft>, ОС семейства Unix, к числу которых относится и Linux, получают все большее распространение и захватывают те области применения микроЭВМ, для которых важна надежность системы в целом, означающая не только безотказность работы в течение длительного времени (месяцы и годы), но также и защиту от несанкционированного доступа.

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

Специалисты по безопасности ОС считают, что будущее именно за технологией подключаемых модулей аутентификации (PAM), разработанной в ОС Linux. И снова Linux впереди и ждет, когда за ней последует весь мир

По данным cvedetails.com, с 1999 года в ядре Linux найдено 1305 уязвимостей, из которых 68 - в 2015-м. Большинство из них не несут особых проблем, помечены как Local и Low, а некоторые можно вызвать только с привязкой к определенным приложениям или настройкам ОС. В принципе, цифры небольшие, но ядро - это не вся ОС. Уязвимости находят и в GNU Coreutils, Binutils, glibs и, конечно же, в пользовательских приложениях. Разберем самые интересные.

УЯЗВИМОСТИ В ЯДРЕ LINUX

ОС: Linux
Уровень: Medium, Low
Вектор: Remote
CVE: CVE-2015-3331, CVE-2015-4001, CVE-2015-4002, CVE-2015-4003
Exploit: концепт, https://lkml.org/lkml/2015/5/13/740 , https://lkml.org/lkml/2015/5/13/744

Уязвимость, найденная в июне в ядре Linux до 3.19.3, в функции __driver_rfc4106_decrypt в файле arch/x86/crypto/aesni-intel_glue.c связана с тем, что реализация RFC4106 для процессоров x86, поддерживающих расширение системы команд AES AES-NI (предложена Intel, Intel Advanced Encryption Standard Instructions), в некоторых случаях неправильно вычисляет адреса буферов. Если IPsec-туннель настроен на использование этого режима (алгоритм AES - CONFIG_CRYPTO_AES_NI_INTEL), уязвимость может приводить к повреждению содержимого памяти, аварийным остановкам и потенциально к удаленному выполнению кода CryptoAPI. Причем самое интересное, что проблема может возникнуть сама по себе, на вполне легальном трафике, без вмешательства извне. На момент публикации проблема была устранена.

В драйвере Linux 4.0.5 ozwpan, имеющем статус экспериментального, выявлено пять уязвимостей, четыре из них позволяют организовать DoS-атаку через крах ядра, отправив специально оформленные пакеты. Проблема связана с выходом за границы буфера из-за некорректной обработки знаковых целых чисел, при котором вычисление в memcpy между required_size и offset возвращало отрицательное число, в итоге данные копируются в кучу.

Находится в функции oz_hcd_get_desc_cnf в drivers/staging/ozwpan/ozhcd.c и в функциях oz_usb_rx и oz_usb_handle_ep_data файла drivers/staging/ozwpan/ozusbsvc1.c. В других уязвимостях возникала ситуация возможного деления на 0, зацикливания системы или возможность чтения из областей вне границ выделенного буфера.

Драйвер ozwpan, одна из новинок Linux, может быть сопряжен с существующими беспроводными устройствами, совместимыми с технологией Ozmo Devices (Wi-Fi Direct). Предоставляет реализацию хост-контроллера USB, но фишка в том, что вместо физического подключения периферия взаимодействует через Wi-Fi. Драйвер принимает сетевые пакеты c типом (ethertype) 0x892e, затем разбирает их и переводит в различную функциональность USB. Пока используется в редких случаях, поэтому его можно отключить, выгрузив модуль ozwpan.ko.

LINUX UBUNTU

ОС: Linux Ubuntu 12.04–15.04 (ядро до 15 июня 2015 года)
Уровень: Critical
Вектор: Local
CVE: CVE-2015-1328
Exploit: https://www.exploit-db.com/exploits/37292/

Критическая уязвимость в файловой системе OverlayFS позволяет получить права root в системах Ubuntu, в которых разрешено монтирование разделов OverlayFS непривилегированным пользователем. Настройки по умолчанию, необходимые для эксплуатации уязвимости, используются во всех ветках Ubuntu 12.04–15.04. Сама OverlayFS появилась в ядре Linux относительно недавно - начиная с 3.18-rc2 (2014 год), это разработка SUSE для замены UnionFS и AUFS. OverlayFS позволяет создать виртуальную многослойную файловую систему, объединяющую несколько частей других файловых систем.

ФС создается из нижнего и верхнего слоев, каждый из которых прикрепляется к отдельным каталогам. Нижний слой используется только для чтения в каталогах любых поддерживаемых в Linux ФС, включая сетевые. Верхний слой обычно доступен на запись и перекрывает данные нижнего слоя, если файлы дублируются. Востребована в Live-дистрибутивах, системах контейнерной виртуализации и для организации работы контейнеров некоторых настольных приложений. Пространства имен для пользователей (user namespaces) позволяют создавать в контейнерах свои наборы идентификаторов пользователей и групп. Уязвимость вызвана некорректной проверкой прав доступа при создании новых файлов в каталоге нижележащей ФС.

Если ядро собрано с параметром CONFIG_USER_NS=y (включение пользовательского пространства имен), а при монтировании указан флаг FS_USERNS_MOUNT, OverlayFS может быть смонтирована обычным пользователем в другом пространстве имен, в том числе там, где допускаются операции с правами root. При этом операции с файлами с правами root, выполненные в таком namespaces, получают те же привилегии и при выполнении действий с нижележащей ФС. Поэтому можно смонтировать любой раздел ФС и просмотреть или модифицировать любой файл или каталог.

На момент публикации уже было доступно обновление ядра с исправленным модулем OverlayFS от Ubuntu. И если система обновлена, проблем быть не должно. В том же случае, когда обновление невозможно, в качестве временной меры следует отказаться от использования OverlayFS, удалив модуль overlayfs.ko.

УЯЗВИМОСТИ В ОСНОВНЫХ ПРИЛОЖЕНИЯХ

ОС: Linux
Уровень: Critical
Вектор: локальная, удаленная
CVE: CVE-2015-0235
Exploit: https://www.qualys.com/research/security-advisories/exim_ghost_bof.rb

Опасная уязвимость в стандартной библиотеке GNU glibc, которая является основной частью ОС Linux, и в некоторых версиях Oracle Communications Applications и Oracle Pillar Axiom, обнаруженная во время аудита кода хакерами из Qualys. Получила кодовое имя GHOST. Заключается в переполнении буфера внутри функции __nss_hostname_digits_dots(), которую используют для получения имени узла такие функции glibc, как gethostbyname() и gethostbyname2() (отсюда и название GetHOST). Для эксплуатации уязвимости нужно вызвать переполнение буфера при помощи недопустимого аргумента имени хоста приложению, выполняющему разрешение имени через DNS. То есть теоретически эту уязвимость можно применить для любого приложения, использующего в той или иной мере сеть. Может быть вызвано локально и удаленно, позволяет выполнить произвольный код.

Самое интересное, что ошибка была исправлена еще в мае 2013 года, между релизами glibc 2.17 и 2.18 был представлен патч, но проблему не классифицировали как патч безопасности, поэтому на нее внимания не обратили. В итоге многие дистрибутивы оказались уязвимы. Вначале сообщалось, что самая первая уязвимая версия - 2.2 от 10 ноября 2000 года, но есть вероятность ее появления вплоть до 2.0. Среди прочих уязвимости были подвержены дистрибутивы RHEL/CentOS 5.x–7.x, Debian 7 и Ubuntu 12.04 LTS. В настоящее время доступны исправления. Сами хакеры предложили утилиту, поясняющую суть уязвимости и позволяющую проверить свою систему. В Ubuntu 12.04.4 LTS все нормально:

$ wget https : //goo.gl/RuunlE $ gcc gistfile1 . c - o CVE - 2015 - 0235 $ . / CVE - 2015 - 0235 not vulnerable

Проверяем систему на GHOST

Практически сразу был выпущен модуль к , позволяющий удаленно выполнить код на x86 и x86_64 Linux с работающим почтовым сервером Exim (с включенным параметром helo_try_verify_hosts или helo_verify_hosts). Позже появились и другие реализации, например модуль Metasploit для проверки блога на WordPress.

Чуть позже, в 2015 году, в GNU glibc были обнаружены еще три уязвимости, позволяющие удаленному пользователю произвести DoS-атаку или переписать ячейки памяти за пределами границы стека: CVE-2015-1472, CVE-2015-1473, CVE-2015-1781.

ОС: Linux (GNU Coreutils)
Уровень: Low
Вектор: Local, Remote
CVE: CVE-2014-9471
Exploit: нет

GNU Сoreutils - один из основных пакетов *nix, включающий практически все базовые утилиты (cat, ls, rm, date…). Проблема найдена в date. Ошибка в функции parse_datetime позволяет удаленному атакующему, не имеющему учетной записи в системе, вызвать отказ в обслуживании и, возможно, выполнить произвольный код, используя специально сформированную строку даты с использованием timezone. Уязвимость выглядит так:

$ touch ‘-- date = TZ = ”123 ”345 ”@ 1 ’ Segmentation fault $ date - d ‘TZ = ”Europe / Moscow ”“00 : 00 + 1 hour ”’ Segmentation fault $ date ‘-- date = TZ = ”123 ”345 ”@ 1 ’ * * * Error in ` date ’: free () : invalid pointer : 0xbfc11414 * * *

Уязвимость в GNU Сoreutils

Если уязвимости нет, получим сообщение о неверном формате даты. О наличии уязвимости отчитались практически все разработчики дистрибутивов Linux. В настоящее время доступно обновление.

Нормальный вывод патченного GNU Сoreutils

ОС: Linux (grep 2.19–2.21)
Уровень: Low
Вектор: Local
CVE: CVE-2015-1345
Exploit: нет

В утилите grep, которая используется для поиска текста по шаблону, редко находят уязвимости. Но эту утилиту часто вызывают другие программы, в том числе и системные, поэтому наличие уязвимостей гораздо проблематичнее, чем кажется на первый взгляд. Ошибка в bmexec_trans function в kwset.c может привести к чтению неинициализированных данных из области за пределами выделенного буфера или краху приложения. Этим может воспользоваться хакер, создав специальный набор данных, подаваемых на вход приложения при помощи grep -F. В настоящее время доступны обновления. Эксплоитов, использующих уязвимость, или модуля к Metasploit нет.

УЯЗВИМОСТЬ В FREEBSD

ОС: FreeBSD
Уровень: Low
Вектор: Local, Remote
CVE: CVE-2014-0998, CVE-2014-8612, CVE-2014-8613
Exploit: https://www.exploit-db.com/exploits/35938/

В базе CVE за 2015 год не так уж много уязвимостей, если точнее - всего шесть. Сразу три уязвимости были найдены в FreeBSD 8.4–10.х в конце января 2015-го исследователями из Core Exploit Writers Team. CVE-2014-0998 связана с реализацией драйвера консоли VT (Newcons), который предоставляет несколько виртуальных терминалов, включаемых параметром kern.vty=vt в /boot/loader.conf.
CVE-2014-8612 проявлялась при использовании протокола SCTP и вызвана ошибкой в коде проверки идентификатора потока SCTP, реализующего SCTP-сокеты (локальный порт 4444). Суть в ошибке выхода за пределы памяти в функции sctp_setopt() (sys/netinet/sctp_userreq.c). Это дает локальному непривилегированному пользователю возможность записать или прочитать 16 бит данных памяти ядра и повысить свои привилегии в системе, раскрыть конфиденциальные данные или положить систему.

CVE-2014-8613 позволяет инициировать разыменование нулевого указателя при обработке полученного извне SCTP-пакета, при установке SCTP_SS_VALUE опции сокета SCTP. В отличие от предыдущих, CVE-2014-8613 может быть использована для удаленного вызова краха ядра через отправку специально оформленных пакетов. В FreeBSD 10.1 защититься можно, установив переменную net.inet.sctp.reconfig_enable в 0, тем самым запретив обработку блоков RE_CONFIG. Или просто запретить использовать SCTP-соединения приложениям (браузерам, почтовым клиентам и так далее). Хотя на момент публикации разработчики уже выпустили обновление.

Статистика уязвимостей в FreeBSD

УЯЗВИМОСТЬ В OPENSSL

ОС: OpenSSL
Уровень: Remote
Вектор: Local
CVE: CVE-2015-1793
Exploit: нет

В 2014 году в OpenSSL, широко используемом криптографическом пакете для работы с SSL/TLS, была найдена критическая уязвимость Heartbleed. Инцидент в свое время вызвал массовую критику качества кода, и, с одной стороны, это привело к появлению альтернатив вроде LibreSSL, с другой - сами разработчики наконец взялись за дело.

Топ вендоров по уязвимостям

Критическая уязвимость обнаружена Адамом Лэнгли из Google и Дэвидом Бенджамином из BoringSSL. Изменения, внесенные в OpenSSL версий 1.0.1n и 1.0.2b, привели к тому, что OpenSSL пытается найти альтернативную цепочку верификации сертификата, если первая попытка построить цепочку подтверждения доверия не увенчалась успехом. Это позволяет обойти процедуру проверки сертификата и организовать подтвержденное соединение с использованием подставного сертификата, говоря другими словами - спокойно заманивать пользователя на поддельные сайты или сервер электронной почты или реализовать любую MITM-атаку там, где используется сертификат.

После обнаружения уязвимости разработчики 9 июля выпустили релизы 1.0.1p и 1.0.2d, в которых эта проблема устранена. В версиях 0.9.8 или 1.0.0 этой уязвимости нет.

Linux.Encoder

Конец осени ознаменовался появлением целого ряда вирусов-шифровальщи ков, вначале Linux.Encoder.0, затем последовали модификации Linux.Encoder.1 и Linux.Encoder.2, заразивших более 2500 сайтов. По данным антивирусных компаний, атаке подвергаются серверы на Linux и FreeBSD с веб-сайтами, работающими с использованием различных CMS - WordPress, Magento CMS, Joomla и других. Хакеры используют неустановленную уязвимость. Далее размещался шелл-скрипт (файл error.php), при помощи которого и выполнялись любые дальнейшие действия (через браузер). В частности, запускался троян-энкодер Linux.

Encoder, который определял архитектуру ОС и запускал шифровальщик. Энкодер запускался с правами веб-сервера (Ubuntu - www-data), чего вполне достаточно, чтобы зашифровать файлы в каталоге, в котором хранятся файлы и компоненты CMS. Зашифрованные файлы получают новое расширение.encrypted.

Также шифровальщик пытается обойти и другие каталоги ОС, если права настроены неправильно, то он вполне мог выйти за границы веб-сайта. Далее в каталоге сохранялся файл README_FOR_DECRYPT.txt, содержащий инструкции по расшифровке файлов и требования хакера. На данный момент антивирусные компании представили утилиты, позволяющие расшифровать каталоги. Например, набор от Bitdefender. Но нужно помнить, что все утилиты, предназначенные для расшифровки файлов, не удаляют шелл-код и все может повториться.

Учитывая, что многие пользователи, занимающиеся разработкой или экспериментирующие с администрированием веб-сайтов, часто устанавливают веб-сервер на домашнем компьютере, следует побеспокоиться о безопасности: закрыть доступ извне, обновить ПО, эксперименты устраивать на VM. Да и сама идея может в будущем использоваться при атаке на домашние системы.

ВЫВОД

Сложного ПО без ошибок физически не существует, поэтому придется мирить ся с тем фактом, что уязвимости будут обнаруживаться постоянно. Но не все они могут представлять действительно проблемы. И можно себя обезопасить, предприняв простые шаги: удалить неиспользуемое ПО, отслеживать новые уязвимости и обязательно устанавливать обновления безопасности, настроить брандмауэр, установить антивирус. И не забывать о специальных технологиях вроде SELinux, которые вполне справляются при компрометации демона или пользовательского приложения.

Многие пользователи считают Ubuntu попсовой, а Ubuntu Server не серьёзным. Многие забывают, что Ubuntu Server поддерживается 5 лет, а папа Debian 5.0 был на рынке 3 года - с 2009 по 2012 г.

По ценам поддержки - Ubuntu Server по сравнению с Red Hat можно и нужно сказать - достался вам даром, даже если вы закажете круглосуточную поддержку 24х7х365.

Посмотрите какие решения в плане безопасности внедрены во все версии Ubuntu и делают её безопасной и надёжной.

Возможности

Матрица возможностей безопасности

Возможность	8.04 LTS (Hardy Heron)	10.04 LTS (Lucid Lynx)	11.04 (Natty Narwhal)	11.10 (Oneiric Ocelot)	12.04 LTS (Precise Pangolin)	12.10 (Quantal Quetzal)
Нет открытых портов	policy	policy	policy	policy	policy	policy
Хеш пароля	md5	sha512	sha512	sha512	sha512	sha512
SYN cookies	--	kernel & sysctl	kernel & sysctl	kernel & sysctl	kernel & sysctl	kernel & sysctl
Возможности файловой системы	--	kernel	kernel	kernel	kernel	kernel
Конфигурируемый файрвол	ufw	ufw	ufw	ufw	ufw	ufw
PR_SET_SECCOMP	kernel	kernel	kernel	kernel	kernel	kernel
AppArmor	2.1	2.5	2.6.1	2.7.0~beta1	2.7.0	2.7.0
SELinux	universe	universe	universe	universe	universe	universe
SMACK	--	kernel	kernel	kernel	kernel	kernel
Шифрованный LVM	alt installer	alt installer	alt installer	alt installer	alt installer	alt installer
eCryptfs	--	~/Private or ~, filenames	~/Private or ~, filenames	~/Private or ~, filenames	~/Private or ~, filenames	~/Private or ~, filenames
Защита стека	gcc patch	gcc patch	gcc patch	gcc patch	gcc patch	gcc patch
Защита кучи	glibc	glibc	glibc	glibc	glibc	glibc
Обфусцированный указатель	glibc	glibc	glibc	glibc	glibc	glibc
Стек ASLR	kernel	kernel	kernel	kernel	kernel	kernel
Libs/mmap ASLR	kernel	kernel	kernel	kernel	kernel	kernel
Exec ASLR	kernel (-mm patch)	kernel	kernel	kernel	kernel	kernel
brk ASLR	kernel (exec ASLR)	kernel	kernel	kernel	kernel	kernel
VDSO ASLR	kernel	kernel	kernel	kernel	kernel	kernel
Сборка с PIE	--	package list	package list	package list	package list	package list
	--	gcc patch	gcc patch	gcc patch	gcc patch	gcc patch
Сборка с RELRO	--	gcc patch	gcc patch	gcc patch	gcc patch	gcc patch
Сборка с BIND_NOW	--	package list	package list	package list	package list	package list
Non-Executable Memory	PAE only		PAE, ia32 partial-NX-emulation	PAE, ia32 partial-NX-emulation	PAE, ia32 partial-NX-emulation	PAE, ia32 partial-NX-emulation
Защита /proc/$pid/maps	kernel & sysctl	kernel	kernel	kernel	kernel	kernel
Ограничения символьных ссылок	--	--	kernel	kernel	kernel	kernel
Ограничения жёстких ссылок	--	--	kernel	kernel	kernel	kernel
ptrace scope	--	--	kernel	kernel	kernel	kernel
Защита 0-address	kernel & sysctl	kernel	kernel	kernel	kernel	kernel
Защита /dev/mem	kernel (-mm patch)	kernel	kernel	kernel	kernel	kernel
Отключён /dev/kmem	kernel (-mm patch)	kernel	kernel	kernel	kernel	kernel
Блокировка загрузки модулей	drop CAP_SYS_MODULES	sysctl	sysctl	sysctl	sysctl	sysctl
	kernel	kernel	kernel	kernel	kernel	kernel
Защита стека ядра	--	kernel	kernel	kernel	kernel	kernel
Модуль RO/NX	--	--	kernel	kernel	kernel	kernel
	--	--	kernel	kernel	kernel	kernel
	--	--	kernel	kernel	kernel	kernel
Фильтрация системных вызовов	--	--	--	kernel	kernel	kernel

Нет открытых портов

Установленная по умолчанию Ubuntu не имеет открытых портов, доступных извне в сети. Исключение из этого правила только для сервисов сетевой инфраструктуры, такие как DHCP клиент и mDNS (Avahi/ZeroConf).

Когда устанавливается Ubuntu Server, администратор может установить дополнительные сетевые сервисы, например веб-сервер Apache. Но по умолчанию, на только что установленной системе, если сделать netstat -an --inet | grep LISTEN | grep -v 127.0.0.1 , то можно легко убедиться, что в Ubuntu без надобности не открываются порты для доступа из сетей к системе.

Хеш пароля

Системный пароль, используемый для входа в Ubuntu сохраняется в /etc/shadow. Давным-давно хеш пароля в DES сохранялся в /etc/passwd. Но современные Linux уже с давних пор хранят хеши в /etc/shadow и первое время использовался хеш основанный на MD5 с солью (salted MD5-based hashes crypt id 1). Так как у одинаковых паролей были одинаковые хеши без применения соли, то внедрение соли позволяло улучшить безопасность и усложнить взлом паролей множества пользователей системы.

Сейчас MD5 считается не надёжным и с ростом вычислительных возможностей компьютеров, с Ubuntu 8.10 применяется хеш SHA-512 с солью (salted SHA-512 based password hashes crypt id 6). Это делает взлом грубой силой с помощью перебора всех вариантов - невероятно сложным и долгим.

Подробнее man crypt.

Используйте test-glibc-security.py для тестов.

SYN cookies

Когда систему переполняют новыми сетевыми соединениями, механизм SYN cookie помогает снизить урон от SYN-flood атак.

Возможности файловой системы

Необходимость в setuid приложениях, которые работают с правами выше, чем тот кто их запустил, может быть уменьшена с применением возможностей файловых систем, таких как xattrs. Такие возможности снижают риск злоупотреблений над потенциально опасными setuid приложениями.

Ядро Linux поддерживает поддержку и есть инструментарий libcap2-bin для использования файловых возможностей типа xattrs для усиления безопасности setuid приложений.

Используйте для тестов test-kernel-security.py.

Конфигурируемый файрвол

ufw это фронтенд для iptables, который установлен и используется в Ubuntu, но включить его пользователь должен самостоятельно. UFW призван обеспечить лёгкий в использовании интерфейс для людей не знакомых с концепциями файрвола iptables, с его цепочками и таблицами.

В то же время UFW упрощает сложные команды iptables, чтобы помочь администратору, который знает что он делает.

UFW является помощником и основой уже для графических фронтендов.

Используйте для тестов ufw tests.

PR_SET_SECCOMP

AppArmor

SELinux

SELinux - система мандатного управления доступом, основанная на понятие inode - индексного дескриптора файловой системы.

Установка пакета selinux сделает нужные изменения и корректировки во время загрузки ПК.

Используйте для тестов test-kernel-security.py.

SMACK

SMACK - гибкая система мандатного управления доступом, основанная на понятие inode - индексного дескриптора файловой системы.

Используйте для тестов test-kernel-security.py.

Шифрование файловых систем

Шифрование LVM

Пользователи с помощью Alternate установщика могут установить Ubuntu на шифрованный LVM (Logical Volume Manage - Менеджер логических томов), который все разделы зашифрует, включая раздел подкачки swap.

eCryptfs

Шифрованные папки были впервые реализованы в Ubuntu 8.10 как безопасное место хранения важной информации пользователя.

Установщик диска Alternate и Server позволяет настроить шифрованные папки для первого пользователя.

В Ubuntu 9.04 поддержка шифрования папок была расширена и пользователь мог зашифровать всю домашнюю папку. Шифрование домашней папки поддерживается в Alternate установщике и Desktop установщике через параметр user-setup/encrypt-home=true.

Усиление безопасности пользовательского пространства

Множество возможностей по безопасности реализуются через флаги компиляции при построении пакетов программ и ядра.

Защита стека

Флаг gcc -fstack-protector обеспечивает защиту от переполнения стека, помещая маленькое случайное число в качестве маркера. Этот метод усложняет переполнение стека различными эксплойтами.

Не большое количество программ плохо работают, если собраны с данным параметром и для них -fstack-protector отключен.

Используйте для тестов test-gcc-security.py.

Защита кучи

GNU C Library защита кучи (автоматически ptmalloc и в ручную) обеспечивает защиту corrupted-list/unlink/double-free/overflow в менеджере памяти glibc.

Это предотвращает возможность выполнения произвольного кода через переполнение памяти кучи, тем самым повредив структуру области кучи.

Эта защита развивалась со временем, добавляя всё больше и больше вариантов защиты. В текущем состоянии glibc 2.10 успешно противостоит даже трудно уловимым условиям атаки.

Обфусцированный указатель

Некоторые указатели glibc обфусцированны через PTR_MANGLE/PTR_UNMANGLE макросы внутри в glibc, предотвращая от перезаписи указатели во время исполнения.

Используйте тесты test-glibc-security.py.

Случайное размещение в адресном пространстве. Address Space Layout Randomisation (ASLR)

ASLR реализован в ядре и загрузчик ELF размещает в случайных адресах важнейшие структуры: стек, кучу, общие библиотеки и другое.

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

ASLR изменяется глобально через /proc/sys/kernel/randomize_va_space. До Ubuntu 8.10 значение было "1" (включено). В поздних релиза, который включает brk ASLR, значение выставлено в "2" (включено с brk ASLR).

Стек ASLR

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

Libs/mmap ASLR

Библиотеки загружаются динамически в различные участки памяти, что делает сложным для атакующего поиск точки возврата.

Защита доступна с ядра 2.6.15 (Ubuntu 6.06).

Exec ASLR

Программы, собранные с параметром "-fPIE -pie", загружаются в разные участки памяти. Это усложняет атаку или прыжок по адресу для проведения атаки, приводящей к изменению памяти.

Защита доступна с ядра 2.6.25 (Ubuntu 8.04 LTS).

brk ASLR

Подобно exec ASLR, brk ASLR регулирует адреса памяти между exec и brk для маленьких запросов на выделение памяти. Рандомизация brk смещения exec памяти была добавлена в ядро 2.6.26 (Ubuntu 8.10).

VDSO ASLR

Каждый раз запуск программы размещает результаты в различных vdso. Впервые появилось в ядре 2.6.18 (x86, PPC) и 2.6.22 (x86_64), но не был включён в Ubuntu 6.10 из-за COMPAT_VDSO, который удалили в Ubuntu 8.04 LTS.

Защищает от jump-into-syscall атак.

Только x86 поддерживалось glibc 2.6. glibc 2.7 (Ubuntu 8.04 LTS) уже поддерживало x86_64 ASLR vdso.

Тем кому необходимо древнее статичное pre-libc6 vdso могут использовать "vdso=2" как параметр ядра и получить снова COMPAT_VDSO.

Сборка с PIE

Все программы, которые собраны с Position Independent Executables (PIE) параметром "-fPIE -pie" могут воспользоваться защитой exec ASLR.

Это защищает от "return-to-text" атак и делает бесполезными обычные атаки, рассчитанные на изменение памяти.

Из-за PIE наблюдается большое падение производительности (5-10%) на архитектурах с небольшим количеством регистров общего назначения (типа x86).

Поэтому PIE используется для небольшого количества критически важных в плане безопасности пакетов.

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

Пакет	8.04 LTS	9.04	9.10	10.04 LTS	10.10	11.04	11.10
openssh	да	да	да	да	да	да	да
apache2	--	да	да	да	да	да	да
bind9	--	да	да	да	да	да	да
openldap	--	да	да	да	да	да	да
postfix	--	да	да	да	да	да	да
cups	--	да	да	да	да	да	да
postgresql-8.3	--	да	да	да	да	да	да
samba	--	да	да	да	да	да	да
dovecot	--	да	да	да	да	да	да
dhcp3	--	да	да	да	да	да	да
ntp	--	--	да	да	да	да	да
amavisd-new	--	--	да	да	да	да	да
squid	--	--	да	да	да	да	да
cyrus-sasl2	--	--	да	да	да	да	да
exim4	--	--	да	да	да	да	да
nagios3	--	--	да	да	да	да	да
nagios-plugins	--	--	да	да	да	да	да
xinetd	--	--	да	да	да	да	да
ipsec-tools	--	--	да	да	да	да	да
mysql-dfsg-5.1	--	--	да	да	да	да	да
evince	--	--	--	да	да	да	да
firefox	--	--	--	да	да	да	да
gnome-control-center	--	--	--	--	--	да	да
tiff	--	--	--	--	--	да	да
totem	--	--	--	--	--	да	да
qemu-kvm	--	--	--	--	--	--	да
pidgin	--	--	--	--	--	--	да

Сборка с Fortify Source

Программы, собранные с параметром "-D_FORTIFY_SOURCE=2" (и -O1 или выше), включают несколько защит в режиме компиляции и исполнения в glibc:

• заменяются вызовы "sprintf", "strcpy" с их неопределёнными границами на родственные функции с ограниченным N, когда размер буфера известен заранее. Это защищает от переполнения памяти (memory overflows).
• прекращение атаки через формат строки "%n", когда строка находится в сегменте памяти с доступом на запись.
• требуют проверку кодов возврата важнейших функций и аргументов (например для system, write, open).
• требуют явного указания маски при создании файла.

Сборка с RELRO

Ужесточение для ELF программ по борьбе с перезаписью памяти загрузчика. Уменьшает вероятность атаки GOT-overwrite-style.

Используйте тесты test-gcc-security.py.

Сборка с BIND_NOW

Помечает ELF программы для разрешения динамических символов на этапе старта, вместо по требованию (on-demand), так же известное как "immediate binding".

Это делает GOT полностью доступной только для чтения, в сочетании с параметром RELRO.

Используйте тесты test-built-binaries.py.

Non-Executable Memory

Современные процессоры защищают от исполнения кода области памяти данных (кучу, стек).

Эта технология известна как Non-eXecute (NX) или eXecute-Disable (XD). Защита уменьшает возможности злоумышленника по размещению произвольного кода.

Защита требует "PAE", которая так же позволяет адресовать выше 3 Гб ОЗУ. 64битные и 32битные -server и -generic-pae ядра уже собраны с PAE.

Начиная с Ubuntu 9.10, защита частично эмулируется на 32битных ядрах для процессоров, которые не поддерживают аппаратно NX.

После загрузки можно увидеть степень поддержки NX защиты:

• Аппаратная: [ 0.000000] NX (Execute Disable) protection: active
• Эмуляция:
  [ 0.000000] Using x86 segment limits to approximate NX protection

Если вы не видите упоминаний о NX, то проверьте свои BIOS настройки. Начиная с Ubuntu 11.04, BIOS настройки для NX игнорируются ядром.

Ubuntu 9.04 и ранее
		CPU поддерживает NX		CPU не поддерживает NX
		В BIOS включён NX	В BIOS отключён NX
i386	-386, -generic ядро (non-PAE)	nx не поддерживается	nx не поддерживается	nx не поддерживается
	-server ядро (PAE)	настоящий nx	nx не поддерживается	nx не поддерживается
amd64	любое ядро (PAE)	настоящий nx	nx не поддерживается	nx не поддерживается

Используйте тесты test-kernel-security.py.

Защита /proc/$pid/maps

Когда работает ASLR, текущие карты памяти процессов становятся очень ценными для атакующего. Файл карт доступен на чтение только самому процессу и владельцу процесса.

Доступно, начиная с ядра 2.6.22.

Используйте тесты test-kernel-security.py.

Ограничения символьных ссылок

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

Начиная с Ubuntu 10.10, по символическим ссылкам в каталогах типа /tmp нельзя пройти, если "идущий по ссылке" и владелец каталога не совпадают с владельцем символической ссылки.

Данный механизм контролируется механизмом Yama /proc/sys/kernel/yama/protected_sticky_symlinks. Yama разработана в Canonical.

Используйте тесты test-kernel-security.py.

Ограничения жёстких ссылок

Если /etc/ и /home/ каталоги располагаются на одном разделе, обычный пользователь может создать жёсткую ссылку на файл с хешами паролей /etc/shadow в своей домашней папке. Разумеется, если некоторый файл недоступен на чтение либо запись для какого-либо пользователя, жесткая ссылка на данный файл будет иметь те же права и поэтому также будет недоступна этому пользователю. Однако, используя жесткие ссылки, злоумышленник может "подсунуть" такой файл приложению, которое имеет права на доступ к нему.

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

Поведение контролируется /proc/sys/kernel/yama/protected_nonaccess_hardlinks Yama.

ptrace scope

Без использования соответствующей защиты Yama, любой процесс с привилегией CAP_SYS_PTRACE может обращаться к памяти всех процессов с тем же UID"ом. При использовании Yama, можно ограничить область доступа только памятью, принадлежащей потомкам такого процесса.

В Ubuntu 10.10 и старше, пользователи не могут отлаживать процессы с помощью ptrace, если они не его потомки.

Поведение контролируется /proc/sys/kernel/yama/ptrace_scope Yama.

Используйте тесты test-kernel-security.py.

Усиление защиты ядра

Включённые защитные механизмы ядра для усложнения атак.

Защита 0-address

Так как ядро и пользовательское пространство делят виртуальные адреса памяти, "NULL" память должна быть защищена и "пользовательская" память не может начинаться с адреса 0, тем самым предотвращая разыменование адресов ядра - атака "NULL dereference".

Защита доступна с ядра 2.6.22 через параметр sysctl "mmap_min_addr". С Ubuntu 9.04 mmap_min_addr встроен в ядро - адрес 64k для x86, 32k для ARM.

Используйте тесты test-kernel-security.py.

Защита /dev/mem

Некоторым приложениям, типа Xorg, требуется прямой доступ к физической памяти в пользовательском пространстве. Специальный файл /dev/mem обеспечивает такой доступ.

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

Опция CONFIG_STRICT_DEVMEM была введена, чтобы блокировать такие попытки (первоначально опция назвалась CONFIG_NONPROMISC_DEVMEM).

Используйте тесты test-kernel-security.py.

Отключён /dev/kmem

Для современного пользователя /dev/kmem не актуален, так как в большинстве своём использовался злоумышленниками для загрузки руткитов.

Теперь CONFIG_DEVKMEM установлен "n".

Файл /dev/kmem существует в релизах от Ubuntu 8.04 LTS до Ubuntu 9.04, но в ядре ни с чем не был связан и не используется.

Используйте тесты test-kernel-security.py.

Блокировка загрузки модулей

В Ubuntu 8.04 LTS и ранее, можно было удалить возможность CAP_SYS_MODULES и тем самым запретить загрузку новых модулей ядра.

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

В ядре 2.6.25 (Ubuntu 8.10) этот функционал исчез. Начиная с Ubuntu 9.10, теперь снова можно блокировать модули, установив в "1" /proc/sys/kernel/modules_disabled.

Используйте тесты test-kernel-security.py.

Секция данных только для чтения

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

Используйте тесты test-kernel-security.py.

Защита стека ядра

Как и защита ELF программ в пользовательском пространстве, ядро может защитить свой внутренний стек через параметр CONFIG_CC_STACKPROTECTOR.

Используйте тесты test-kernel-security.py.

Модуль RO/NX

Эта возможность расширяет CONFIG_DEBUG_RODATA, включая ограничения для загруженных модулей ядра. Это помогает противостоять эксплойтам. Включается через параметр CONFIG_DEBUG_MODULE_RONX.

Используйте тесты test-kernel-security.py.

Kernel Address Display Restriction

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

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

Начиная с Ubuntu 11.04, /proc/sys/kernel/kptr_restrict выставлен в "1" и блокирует утечки информации об адресах ядра.

Кроме того, различные файлы и каталоги сделаны для чтения только для root
/boot/vmlinuz*, /boot/System.map*, /sys/kernel/debug/, /proc/slabinfo

Используйте тесты test-kernel-security.py.

Чёрных список редких протоколов

Обычно ядро позволяет всем сетевым протоколам автоматически загружаться по требованию через MODULE_ALIAS_NETPROTO(PF_...) макросы.

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

В чёрном списке: ax25, netrom, x25, rose, decnet, econet, rds и af_802154.

Если любой из этих протоколов нужен, то может быть загружен через modprobe или редактируя /etc/modprobe.d/blacklist-rare-network.conf.

Используйте тесты test-kernel-security.py.

Фильтрация системных вызовов

Программы могут фильтровать вызовы ядра, используя seccomp_filter.

Это делается в контейнерах или песочницах, чтобы ещё больше ограничить потенциально ненадёжное ПО.

Используйте тесты test-kernel-security.py.

Итог

После прочитанного, видно, что в Canonical к безопасности Ubuntu относятся серьёзно . Два проекта, AppArmor и Yama, уже давно связаны с Ubuntu и помогают усилить защиту. Ubuntu по умолчанию не открывает лишние порты-двери в сети и не ждёт подключений-приключений на свою голову. Для ключевых программ, работающих с сетью, созданы профили AppArmor, которые держат программы в узде.

Ваш компьютер будет в безопасности с Ubuntu!

Установка и настройка инструментов администрирования, настройка сети

После того как мы установили базовую операционную систему ubuntu14.04 с минимального дистрибутива, первым делом нужно озаботится тем как ей комфортно управлять. В основном для конфигурирования и управления серверами на базе *nix используют ssh/telnet, но в последнее время для этого также появились вполне годные инструменты на базе web-интерфейсов. Я использую бесплатные решения Webmin и Ajenti . Oбе эти панели заслуживают внимания и не смотря на то что они по отдельности могут всё, для чего-то каждая из них подходит лучше, по этому лучше иметь их обе. Я должен заметить, что на боевых продакшн-серверах подобные решения не ставят исходя из безопасности. Всё-таки чем больше управляющих систем, тем больше вероятность найти в них уязвимость. По этому если ваши требования безопасности находятся на уровне «паранойя», то просто примите тот факт, что вам придётся работать с сервером только через ssh (через консоль).

Настройка сети в ubuntu 14.04

Чтобы связываться с нашим сервером по сети, для начала её нужно настроить. По умолчанию, при установке сеть настроилась автоматически и если инсталлятор обнаружил в сети DHCP-сервер, то скорее всего он уже настроил всё как нужно. Если в сети нет DHCP-сервера, то установщик всё равно настроил всё исходя из опроса маршрутизатора к которому подключена сетевая карта. Для того что-бы посмотреть, каким образом сейчас настроена сеть, достаточно в терминале набрать:

Что же мы тут видим:

У нас два сетевых интерфейса eth0 и lo где lo — это «интерфейс обратной петли loopback» а eth0 — это имя нашей сетевой карточки, и если lo — это неизменный сетевой интерфейс, то все остальные интерфейсы могут отличатся по имени. Если в системном блоке установлены две сетевые карты то их интерфейсы скорее всего будут выглядеть как eth0 и eth1 и так далее. Вид имени интерфейса зависит от типа сетевой карты, так например если сетевая карта работает по протоколу WiFi то скорее всего имя у неё будет wlan0.

Что-бы настроить сеть, отредактируем следующий файл:

sudo nano /etc/network/interfaces

Приведём его к такому виду:

iface eth0 inet static
address 192.168.0.184
netmask 255.255.255.0
gateway 192.168.0.1
auto eth0
dns-nameservers 8.8.8.8 8.8.4.4

Где: iface eth0 inet static — указывает, что интерфейс (iface eth0) находится в диапазоне адресов IPv4 (inet) со статическим ip (static);
address 192.168.0.184 — указывает что IP адрес (address) нашей сетевой карты 192.168.0.184;
netmask 255.255.255.0 — указывает что наша маска подсети (netmask) имеет значение 255.255.255.0;
gateway 192.168.0.1 — адрес шлюза (gateway) по умолчанию 192.168.0.254;
auto eth0 — указывет системе что интерфейс eth0 необходимо включать автоматически при загрузке системы с вышеуказанными параметрами.
eth0 — имя подключаемого своего интерфейса. Список интерфейсов можно посмотреть набрав ifconfig
dns-nameservers — DNS-сервера, пишутся через пробел.

Как видно в моём случае я решил задать статический ip 192.168.0.184

перезагружаем сервер командой

Пингуем наш сервер из сети и убеждаемся что он виден. Теперь пришла пора установить с ним связь по SSH, для этого собственно установим ssh-сервер:

sudo apt-get install ssh

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

ВСЕ КОМАНДЫ НИЖЕ ЭТОЙ СТРОЧКИ ВВОДЯТСЯ ОТ ИМЕНИ СУПЕРПОЛЬЗОВАТЕЛЯ , а для того что-бы войти в режим суперпользователя, нужно набрать:

Установка webmin

echo "deb https://download.webmin.com/download/repository sarge contrib" >> /etc/apt/sources.list echo "deb https://webmin.mirror.somersettechsolutions.co.uk/repository sarge contrib" >> /etc/apt/sources.list wget https://www.webmin.com/jcameron-key.asc apt-key add jcameron-key.asc apt-get update apt-get install -y webmin

echo "deb https://download.webmin.com/download/repository sarge contrib" >> echo "deb https://webmin.mirror.somersettechsolutions.co.uk/repository sarge contrib" >> / etc / apt / sources . list wget https : //www.webmin.com/jcameron-key.asc apt - key add jcameron - key . asc apt - get update apt - get install - y webmin

Всё! 6 последовательно введённых команд и webmin установлен и настроен. Теперь можно зайти через браузер по адресу:

https://192.168.0.184:10000

По умолчанию webmin выглядит минималистично, интерфейс по умолчанию отображается на английском языке, но всё настраивается!

Делаем вот так:

Получается вот так:

Никто из нас не хочет, чтобы личная информация попала в чужие руки. Но как защитить систему от атак и хищений данных? Неужели придется читать километровые мануалы по настройке и алгоритмам шифрования? Совсем не обязательно. В этой статье я расскажу, как сделать Linux-систему безопасной буквально за 30 минут.

Введение

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

Когда я потерял смартфон, мне сильно повезло, что установленный на него антивор оказался работоспособным и позволил удаленно стереть все данные из памяти девайса. Когда я по невнимательности открыл SSH-порт на домашней машине с юзером без пароля (!) во внешний мир (!!), мне сильно повезло, что на машину пробрались скрипт-кидди, которые кроме смешной истории шелла не оставили никаких серьезных следов своего пребывания в системе. Когда я случайно опубликовал в интернете листинг со своим паролем от Gmail, мне сильно повезло, что нашелся добрый человек, который предупредил меня об этом.

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

Эта статья - гайд параноидального юниксоида, посвященный тотальной защите Linux-машины от всего и вся. Я не решусь сказать, что все описанное здесь обязательно к применению. Совсем наоборот, это сборник рецептов, информацию из которого можно использовать для защиты себя и данных на тех рубежах, где это нужно именно в твоей конкретной ситуации.

Пароль!

Все начинается с паролей. Они везде: в окне логина в Linux-дистрибутиве, в формах регистрации на интернет-сайтах, на FTP- и SSH-серверах и на экране блокировки смартфона. Стандарт для паролей сегодня - это 8–12 символов в разном регистре с включением цифр. Генерировать такие пароли своим собственным умом довольно утомительно, но есть простой способ сделать это автоматически:

$ openssl rand -base64 6

Никаких внешних приложений, никаких расширений для веб-браузеров, OpenSSL есть на любой машине. Хотя, если кому-то будет удобней, он может установить и использовать для этих целей pwgen (поговаривают, пароль получится более стойким):

$ pwgen -Bs 8 1

Где хранить пароли? Сегодня у каждого юзера их так много, что хранить все в голове просто невозможно. Довериться системе автосохранения браузера? Можно, но кто знает, как Google или Mozilla будет к ним относиться. Сноуден рассказывал, что не очень хорошо. Поэтому пароли надо хранить на самой машине в зашифрованном контейнере. Отцы-основатели рекомендуют использовать для этого KeePassX. Штука графическая, что не сильно нравится самим отцам-основателям, но зато работает везде, включая известный гугль-зонд Android (KeePassDroid). Останется лишь перекинуть базу с паролями куда надо.

Шифруемся

Шифрование - как много в этом слове... Сегодня шифрование везде и нигде одновременно. Нас заставляют пользоваться HTTPS-версиями сайтов, а нам все равно. Нам говорят: «Шифруй домашний каталог», а мы говорим: «Потом настрою». Нам говорят: «Любимое занятие сотрудников Dropbox - это ржать над личными фотками юзеров», а мы: «Пусть ржут». Между тем шифрование - это единственное абсолютное средство защиты на сегодняшний день. А еще оно очень доступно и сглаживает морщины.

В Linux можно найти тонны средств шифрования всего и вся, от разделов на жестком диске до одиночных файлов. Три наиболее известных и проверенных временем инструмента - это dm-crypt/LUKS, ecryptfs и encfs. Первый шифрует целые диски и разделы, второй и третий - каталоги с важной информацией, каждый файл в отдельности, что очень удобно, если потребуется делать инкрементальные бэкапы или использовать в связке с Dropbox. Также есть несколько менее известных инструментов, включая TrueCrypt например.

Сразу оговорюсь, что шифровать весь диск целиком - задача сложная и, что самое важное, бесполезная. Ничего особо конфиденциального в корневом каталоге нет и быть не может, а вот домашний каталог и своп просто кладезь инфы. Причем второй даже больше, чем первый, так как туда могут попасть данные и пароли уже в расшифрованном виде (нормальные программеры запрещают системе скидывать такие данные в своп, но таких меньшинство). Настроить шифрование и того и другого очень просто, достаточно установить инструменты ecrypts:

$ sudo apt-get install ecryptfs-utils

И, собственно, включить шифрование:

$ sudo ecryptfs-setup-swap $ ecryptfs-setup-private

Далее достаточно ввести свой пароль, используемый для логина, и перезайти в систему. Да, все действительно так просто. Первая команда зашифрует и перемонтирует своп, изменив нужные строки в /etc/fstab. Вторая - создаст каталоги ~/.Private и ~/Private, в которых будут храниться зашифрованные и расшифрованные файлы соответственно. При входе в систему будет срабатывать PAM-модуль pam_ecryptfs.so, который смонтирует первый каталог на второй с прозрачным шифрованием данных. После размонтирования ~/Private окажется пуст, а ~/.Private будет содержать все файлы в зашифрованном виде.

Не возбраняется шифровать и весь домашний каталог целиком. Производительность при этом упадет не сильно, зато под защитой окажутся вообще все файлы, включая тот же сетевой каталог ~/Dropbox. Делается это так:

# ecryptfs-migrate-home -u vasya

Кстати, места на диске должно быть в 2,5 раза больше, чем данных у vasya, так что рекомендую заранее почиститься. После завершения операции следует сразу войти под юзером vasya и проверить работоспособность:

$ mount | grep Private /home/vasya/.Private on /home/vasya type ecryptfs ...

Если все ок, незашифрованную копию данных можно затереть:

$ sudo rm -r /home/vasya.*

Заметаем следы

ОK, пароли в надежном месте, личные файлы тоже, что теперь? А теперь мы должны позаботиться о том, чтобы какие-то куски наших личных данных не попали в чужие руки. Ни для кого не секрет, что при удалении файла его актуальное содержимое остается на носителе даже в том случае, если после этого произвести форматирование. Наши зашифрованные данные будут в сохранности даже после стирания, но как быть с флешками и прочими картами памяти? Здесь нам пригодится утилита srm, которая не просто удаляет файл, но и заполняет оставшиеся после него блоки данных мусором:

$ sudo apt-get install secure-delete $ srm секретный-файл.txt home-video.mpg

# dd if=/dev/zero of=/dev/sdb

Эта команда сотрет все данные на флешке sdb. Далее останется создать таблицу разделов (с одним разделом) и отформатировать в нужную ФС. Использовать для этого рекомендуется fdisk и mkfs.vfat, но можно обойтись и графическим gparted.

Предотвращение BruteForce-атак

Fail2ban - демон, который просматривает логи на предмет попыток подобрать пароли к сетевым сервисам. Если такие попытки найдены, то подозрительный IP-адрес блокируется средствами iptables или TCP Wrappers. Сервис способен оповещать владельца хоста об инциденте по email и сбрасывать блокировку через заданное время. Изначально Fail2ban разрабатывался для защиты SSH, сегодня предлагаются готовые примеры для Apache, lighttpd, Postfix, exim, Cyrus IMAP, named и так далее. Причем один процесс Fail2ban может защищать сразу несколько сервисов.

В Ubuntu/Debian для установки набираем:

# apt-get install fail2ban

Конфиги находятся в каталоге /etc/fail2ban. После изменения конфигурации следует перезапускать fail2ban командой:

# /etc/init.d/fail2ban restart

Угроза извне

Теперь позаботимся об угрозах, исходящих из недр всемирной паутины. Здесь я должен был бы начать рассказ об iptables и pf, запущенном на выделенной машине под управлением OpenBSD, но все это излишне, когда есть ipkungfu. Что это такое? Это скрипт, который произведет за нас всю грязную работу по конфигурированию брандмауэра, без необходимости составлять километровые списки правил. Устанавливаем:

$ sudo apt-get install ipkungfu

Правим конфиг:

$ sudo vi /etc/ipkungfu/ipkungfu.conf # Локальная сеть, если есть - пишем адрес сети вместе с маской, нет - пишем loopback-адрес LOCAL_NET="127.0.0.1" # Наша машина не является шлюзом GATEWAY=0 # Закрываем нужные порты FORBIDDEN_PORTS="135 137 139" # Блокируем пинги, 90% киддисов отвалится на этом этапе BLOCK_PINGS=1 # Дропаем подозрительные пакеты (разного рода флуд) SUSPECT="DROP" # Дропаем «неправильные» пакеты (некоторые типы DoS) KNOWN_BAD="DROP" # Сканирование портов? В трэш! PORT_SCAN="DROP"

Для включения ipkungfu открываем файл /etc/default/ipkungfu и меняем строку IPKFSTART = 0 на IPKFSTART = 1. Запускаем:

$ sudo ipkungfu

Дополнительно внесем правки в /etc/sysctl.conf:

$ sudo vi /etc/systcl.conf # Дропаем ICMP-редиректы (против атак типа MITM) net.ipv4.conf.all.accept_redirects=0 net.ipv6.conf.all.accept_redirects=0 # Включаем механизм TCP syncookies net.ipv4.tcp_syncookies=1 # Различные твики (защита от спуфинга, увеличение очереди «полуоткрытых» TCP-соединений и так далее) net.ipv4.tcp_timestamps=0 net.ipv4.conf.all.rp_filter=1 net.ipv4.tcp_max_syn_backlog=1280 kernel.core_uses_pid=1

Активируем изменения:

$ sudo sysctl -p

Выявляем вторжения

Snort - один из любимейших инструментов админов и главный фигурант всех руководств по безопасности. Штука с долгой историей и колоссальными возможностями, которой посвящены целые книги. Что он делает в нашем гайде по быстрой настройке безопасной системы? А здесь ему самое место, Snort можно и не конфигурировать:

$ sudo apt-get install snort $ snort -D

Все! Я не шучу, стандартных настроек Snort более чем достаточно для защиты типовых сетевых сервисов, если, конечно, они у тебя есть. Нужно только время от времени просматривать лог. А в нем можно обнаружить строки типа этих:

[**] MS-SQL probe response overflow attempt [**] http://www.securityfocus.com/bid/9407]

Упс. Кто-то пытался вызвать переполнение буфера в MySQL. Тут сразу есть и ссылочка на страницу с детальным описанием проблемы. Красота.

Кто-то наследил…

Кто-то особенно умный смог обойти наш брандмауэр, пройти мимо Snort, получить права root в системе и теперь ходит в систему регулярно, используя установленный бэкдор. Нехорошо, бэкдор надо найти, удалить, а систему обновить. Для поиска руткитов и бэкдоров используем rkhunter:

$ sudo apt-get install rkhunter

Запускаем:

$ sudo rkhunter -c --sk

Софтина проверит всю систему на наличие руткитов и выведет на экран результаты. Если зловред все-таки найдется, rkhunter укажет на место и его можно будет затереть. Более детальный лог располагается здесь: /var/log/rkhunter.log. Запускать rkhunter лучше в качестве cron-задания ежедневно:

$ sudo vi /etc/cron.daily/rkhunter.sh #!/bin/bash /usr/bin/rkhunter -c --cronjob 2>&1 | mail -s "RKhunter Scan Results" [email protected]

Заменяем email-адрес Васи на свой и делаем скрипт исполняемым:

$ sudo chmod +x /etc/cron.daily/rkhunter.sh

$ sudo rkhunter --update

Ее, кстати, можно добавить перед командой проверки в cron-сценарий. Еще два инструмента поиска руткитов:

$ sudo apt-get install tiger $ sudo tiger $ sudo apt-get install lynis $ sudo lynis -c

По сути, те же яйца Фаберже с высоты птичьего полета, но базы у них различные. Возможно, с их помощью удастся выявить то, что пропустил rkhunter. Ну и на закуску debsums - инструмент для сверки контрольных сумм файлов, установленных пакетов с эталоном. Ставим:

$ sudo apt-get install debsums

Запускаем проверку:

$ sudo debsums -ac

Как всегда? запуск можно добавить в задания cron.

За пределами

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

Чтобы спокойно ходить по сайтам и только в случае необходимости включать прокси, можно воспользоваться одним из множества расширений для Chrome и Firefox, которые легко находятся в каталоге по запросу proxy switcher. Устанавливаем, вбиваем список нужных прокси и переключаемся на нужный, увидев вместо страницы табличку «Доступ к странице ограничен по требованию господина Скумбриевича».

В тех ситуациях, когда под фильтр попал весь сайт и его адрес внесли в черный список на стороне DNS-серверов провайдеров, можно воспользоваться свободными DNS-серверами, адреса которых опубликованы . Просто берем два любых понравившихся адреса и добавляем в /etc/resolv.conf:

Nameserver 156.154.70.22 nameserver 156.154.71.22

Чтобы разного рода DHCP-клиенты и NetworkManager’ы не перезаписали файл адресами, полученными от провайдера или роутера, делаем файл неперезаписываемым с помощью расширенных атрибутов:

$ sudo chattr +i /etc/resolv.conf

После этого файл станет защищен от записи для всех, включая root.

Чтобы еще более анонимизировать свое пребывание в Сети, можно воспользоваться также демоном dnscrypt, который будет шифровать все запросы к DNS-серверу в дополнение к прокси-серверу, используемому для соединения с самим сайтом. Устанавливаем:

$ wget http://download.dnscrypt.org/dnscrypt-proxy/dnscrypt-proxy-1.3.2.tar.bz2 $ bunzip2 -cd dnscrypt-proxy-*.tar.bz2 | tar xvf - $ cd dnscrypt-proxy-* $ sudo apt-get install build-essential $ ./configure && make -j2 $ sudo make install

Указываем в /etc/resolv.conf loopback-адрес:

$ vi /etc/resolv.conf nameserver 127.0.0.1

Запускаем демон:

$ sudo dnscrypt-proxy --daemonize

Кстати, версии dnscrypt есть для Windows, iOS и Android.

Луковая маршрутизация

Что такое луковая маршрутизация? Это Tor. А Tor, в свою очередь, - это система, которая позволяет создать полностью анонимную сеть с выходом в интернет. Термин «луковый» здесь применен относительно модели работы, при которой любой сетевой пакет будет «обернут» в три слоя шифрования и пройдет на пути к адресату через три ноды, каждая из которых будет снимать свой слой и передавать результат дальше. Все, конечно, сложнее, но для нас важно только то, что это один из немногих типов организации сети, который позволяет сохранить полную анонимность.

Тем не менее, где есть анонимность, там есть и проблемы соединения. И у Tor их как минимум три: он чудовищно медленный (спасибо шифрованию и передаче через цепочку нод), он будет создавать нагрузку на твою сеть (потому что ты сам будешь одной из нод), и он уязвим для перехвата трафика. Последнее - естественное следствие возможности выхода в интернет из Tor-сети: последняя нода (выходная) будет снимать последний слой шифрования и может получить доступ к данным.

Тем не менее Tor очень легко установить и использовать:

$ sudo apt-get install tor

Все, теперь на локальной машине будет прокси-сервер, ведущий в сеть Tor. Адрес: 127.0.0.1:9050, вбить в браузер можно с помощью все того же расширения, ну или добавить через настройки. Имей в виду, что это SOCKS, а не HTTP-прокси.

INFO

Версия Tor для Android называется Orbot.

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

Именно ecryptfs используется для шифрования домашнего каталога в Ubuntu.

Борьба с флудом

Приведу несколько команд, которые могут помочь при флуде твоего хоста.

Подсчет количества коннектов на определенный порт:

$ netstat -na | grep ":порт\ " | wc -l

Подсчет числа «полуоткрытых» TCP-соединений:

$ netstat -na | grep ":порт\ " | grep SYN_RCVD | wc -l

Просмотр списка IP-адресов, с которых идут запросы на подключение:

$ netstat -na | grep ":порт\ " | sort | uniq -c | sort -nr | less

Анализ подозрительных пакетов с помощью tcpdump:

# tcpdump -n -i eth0 -s 0 -w output.txt dst port порт and host IP-сервера

Дропаем подключения атакующего:

# iptables -A INPUT -s IP-атакующего -p tcp --destination-port порт -j DROP

Ограничиваем максимальное число «полуоткрытых» соединений с одного IP к конкретному порту:

# iptables -I INPUT -p tcp --syn --dport порт -m iplimit --iplimit-above 10 -j DROP

Отключаем ответы на запросы ICMP ECHO:

# iptables -A INPUT -p icmp -j DROP --icmp-type 8

Выводы

Вот и все. Не вдаваясь в детали и без необходимости изучения мануалов мы создали Linux-box, который защищен от вторжения извне, от руткитов и прочей заразы, от непосредственно вмешательства человека, от перехвата трафика и слежки. Остается лишь регулярно обновлять систему, запретить парольный вход по SSH, убрать лишние сервисы и не допускать ошибок конфигурирования.