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

Какие службы или программы мне нужно посмотреть с точки зрения безопасности Linux

Я просто смотрел файлы журнала для своего веб-сервера и видел несколько записей журнала для SSHD. Я вижу, что кто-то постоянно пытается подключиться по ssh с неправильным именем пользователя и паролем.

я просто случайно увидел это.

Помимо журналов sshd, какие еще программы / службы / журналы мне следует отслеживать на предмет возможных попыток взлома.

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

Поскольку список служб, которые вы можете установить, огромен, на самом деле нет никакого способа дать вам единый список.

Например, если вы устанавливаете сервер базы данных, такой как mysql, и делаете его доступным для сети, вам следует следить за журналами mysql.

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

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

Какие услуги и программы?

Все они.

Нет, правда.

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

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

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

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

Что касается сетевых IDS? То же самое - на большинстве компьютеров, подключенных к Интернету, вы увидите столько неудачных атак, что вы не сможете их обнаружить, не говоря уже о том, чтобы отреагировать на настоящие.

Используйте IDS на основе хоста (средство проверки целостности файлов) для любых исполняемых файлов / библиотек. Это не предотвращает атаку, но если ваши системы действительно будут скомпрометированы, по крайней мере, есть шанс, что вы сможете оправиться от атаки.

В дополнение к чему-то вроде Tripwire или L5, если эта система действует как сервер в Интернете или хранит данные любого значительного значения, я бы рекомендовал регулярно запускать программу проверки руткитов (например, rkhunter).

Если ваша цель не в обеспечении безопасности вашей системы, а в том, чтобы лучше понять, как люди присоединяют системы, то это совсем другая история (но не пытайтесь это делать в системе, где есть что-то ценное). Да, вы можете получить полезную информацию из журналов (в частности, сообщения, безопасность и httpd / access.log, httpd / error.log).

Вас может заинтересовать /var/log/... (имена могут отличаться в зависимости от вашего Linux, я использую ubuntu 10.04)

  • auth.log регистрирует аутентификации, такие как вход в gdm, su, активность пользователя / группы, разблокировка заставки, соединения imap / pop3, cron сеансы ...

  • apparmor/* (если установлено приложение), которое показывает странное поведение программ (например, доступ к каталогу, в котором они не должны)

  • messages и syslog, в основном общие файлы журнала, когда не было предоставлено никакого конкретного файла журнала.

  • mail.log (или maillog), чтобы проверить активность вашего SMTP-сервера (если есть)

  • samba/* (если запущено), чтобы проверить, кто подключается к вашим акциям самбы

  • mysql/* (при необходимости), чтобы проверить список логинов

В зависимости от вашего дистрибутива у вас могут быть или не быть указанные выше файлы. Вы могли бы регулярно ls -lrt на ваше /var/log каталог, чтобы увидеть, какие файлы журналов были изменены, и проверить соответствующие.

Linux, ssh, Apache и другие базовые строительные блоки сервера достаточно безопасны, если у вас есть надежные пароли, ключи ssh и аналогичные средства защиты. Обязательно знать основы.

НО!

Гораздо более вероятно, что ваше приложение, такое как WordPress, Drupal или ваше собственное программное обеспечение, работающее поверх этих строительных блоков, имеет дыру в безопасности. В настоящее время многие взломы проходят через специально созданные URL-адреса с SQL, странными символами и тому подобным в них. ЭТО то, к чему вы должны действительно подготовиться. Подумайте о способах злоупотребления вашим сервером через http и попытайтесь остановить их до того, как это произойдет. Даже если кто-то не может получить root-права через какую-то дыру в безопасности веб-приложений, можно совершить множество злоупотреблений, таких как рассылка спама или DoSing, даже без конечного root-доступа.

Например, может быть хорошей идеей усилить безопасность PHP, сделав свой webroot и / tmp (или любой другой каталог temp, который вы определили для PHP) noexec, nosuid, nodev поэтому даже если кому-то удастся загрузить злой исходный файл C, он не сможет скомпилировать или, по крайней мере, легко запустить его с такими вещами, как system("./myevilrootgainer");. Эта простая мера предосторожности среди многих других связана не с тем, что сам PHP небезопасен (что иногда может быть, как и все программное обеспечение), а потому, что он позволяет использовать возможные дыры в безопасности в ваш приложение сложнее.

Я бы просто рекомендовал открытое программное обеспечение "SNORT". Программное обеспечение обеспечивает превосходную точку зрения для системных журналов Linux и действует как IPS против большинства попыток вторжения.

SNORT, вероятно, не лучший вариант для вас в настоящее время, пока вы не познакомитесь с основами, и даже тогда полезность SNORT для веб-сервера будет сомнительной, к тому же это все равно не IPS. Я бы пошел по маршруту WAF, если все, что делает система, - это обслуживание страниц приложения HTTP / S. В противном случае первый ответ - ваш лучший вариант на данном этапе. Ознакомьтесь с запущенными процессами и службами, а также с тем, что разрешает ваш брандмауэр.