Назад | Перейти на главную страницу

Реальный опыт взлома на Linux?

Я хотел бы услышать реальные истории о том, как ваш Linux-сервер / сервер был взломан и что вы делаете, чтобы снова не попасть в ту же дыру.

Около 2 лет назад один из моих совместных веб-серверов был взломан. Я обнаружил уязвимость в запущенном мной php-скрипте, старой версии PHPBB. Хакер в основном использовал дыру, чтобы разместить сценарий на моем сервере и выполнить его, что дало ему полный доступ к серверу.

К счастью, он не причинил вреда, он просто установил новый веб-сайт, который будет обслуживать меня.

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

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

Я очистил его следы и начал защищать свой сервер.

В результате я много узнал о безопасности Linux и сделал несколько вещей:

  • Усилена моя безопасность SSH, в том числе запущена на нестандартном порту.
  • chrooted apache
  • Установлен и настроен apache mod_security (что потрясающе)
  • Начат запуск некоторых скриптов мониторинга журналов / обнаружения вторжений
  • Убил все процессы, запущенные на портах, которые я не использовал активно

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

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

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

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

Решение для хостинга (неподдерживаемый выделенный сервер) было дешевым и звучало круто, я действительно не знал, что делаю, не обновлял систему и, вероятно, сделал что-то плохое с конфигурацией iptables / ipchains. Однажды, путешествуя по Западной Европе, я зажег это место, но там ничего не было.

Мое решение состояло в том, чтобы отказаться от всего и доверять кому-то еще до тех пор, пока я не приобрету больше опыта администрирования сервера; это было около 7 лет назад, и я до сих пор доверяю другому парню!

~ 5 лет назад я работал системным администратором в нашем университете, и наши рабочие станции, на которых была установлена ​​устаревшая версия suse (это была не моя вина!), Были взломаны с помощью эксплойта ssh, который также использовался в матрице, кстати.

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

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

Недостаток безопасности в bind позволил кому-то проникнуть в систему и получить root-права. Они использовали систему для рассылки спама и настроили веб-сервер. Хотя bind был установлен в системе, на самом деле он ни для чего не использовался

Результаты вторжения

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

В декабре прошлого года на мой основной сервер Linux поступило много жалоб через инструмент selinux. setroubleshooter. Две категории были

  • SELinux предотвращает использование sh потенциально неправильно помеченных файлов (./x).
  • SELinux не позволяет демону http подключиться к самому себе или к портам реле.

Заглянув в журналы доступа HTTP, я увидел строки вроде

74.247.251.227 - - [05/Dec/2008:04:32:11 -0600] "POST /wordtrans/wordtrans.php HTTP/1.1" 200 1348 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"

Заглянув в журнал ошибок HTTP, я тоже увидел жалобы. Затем я сам использовал wordtrans, чтобы сравнить истинное использование с тем, что было в моих журналах; У меня был установлен wordtrans как игрушка, в которой я действительно не нуждался. У истинного использования wordtrans было много GET и несколько POST. У атаки были только POST-сообщения.

Я искал в Google "http-атака wordtrans" и обнаружил, что установленная мною версия может быть атакована, поэтому я немедленно удалил wordtrans-web пакет.

Если бы я не запускал selinux, атака наверняка была бы успешной, и я бы не узнал.

Это еще один урок, чтобы не запускать какие-либо службы (доступные в общедоступном Интернете), которые вам действительно не нужны. Каждая установленная служба, даже небольшая, включая пакеты PHP, веб-службы и т. Д., Является потенциальным вектором атаки. Кроме того, мое решение включить selinux с этой установкой месяцами ранее было правильным.

Несколько лет назад мы установили систему в кампусе колледжа (подключенном к сети колледжа). Укоренился примерно за 2 дня. Поскольку мы могли легко заменить его, мы просто перезаписали диск и запустили Nmap в системе перед повторным подключением к сети университетского городка.