Нет – взломам серверов! Советы по проверке и защите

[Andrusha]

А почему для просмотра логов vi, а не less?

[v0rdych]

Чтобы сразу удалить за собой следы.

[foxmuldercp]

Интересно, как долго у меня будет открываться вечером apache.log размеров в пару гигабайт на один виртуалхост?.. и через сколько я в соседней консоли этот vim прибью.

Пополнил свою коллекцию вредных советов.
Интересно, с сервисом у компании так же, как с этим постом?

[revko]

Интересно, зачем держать лог в пару гигабайт, когда давно придумали logrotate? Попробуйте, говорят, помогает

[MasMaX]

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

[foxmuldercp]

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

Как вы себе представляете работу инженера поддержки, которому приходит тикет на "у меня тут вот на сайте что-то не работает", и как Вы себе представляете моё предложение клиентам разбить логи на location, например, в плеске, cpanel или даже просто, средствами обычного вордпресса? и работу саппорта в таком режиме "найти бог знает что в бог знает каком логе для воот этого домена"

[farcaller]

Подозреваете, что Linux-сервер взломан?

wipe, re-image.

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

[igorch96]

И неплохо бы еще биос проверить :)

[farcaller]

Таки да, я хотел написать, но решил не усложнять :-)

[lorc]

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

[farcaller]

согласен.

[Splo1ter]

А можно тоже самое, только для windows?

[KorP]

А что — уже каникулы?

[kp580]

Сегодня вроде как начались.

[KorP]

Ну тогда нормальный пост, как школьникам с хоумпэйджами на vps защититься от других школьников

[chemtech]

Смените порт SSH

[kotomyava]

И какой цели это волшебство послужит, особенно в свете того, что уже установлен fail2ban, и тупые боты не мешают. А не тупых и не ботов смена порта не запутает ни сколько…

[KorP]

Вроде такой солидный человек, в костюме, что то там про безопасность пишет/переводит и такой совет… да я покурить не успею пока сканер найдёт нестандартный ssh порт. как правильно ниже говорят — fail2ban, ключи и/или сложные пароли — вот отличный вариант, а не порт менять.

[KorP]

И это правильно, курить вредно

[akubintsev]

Как показал мой личный опыт, смена порта sshd на нестандартный на порядки уменьшило в логах auth.log кол-во записей. Это помогает отсеивать не целенаправленные атаки.

[inakrin]

Теперь ясно что ни за что не стоит брать вдс в этой компании.

[Awento]

Почему? Цены у них нормальные, но вот защита от ддос атак — мало верю.

[Awento]

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

[Scf]

Добавлю советов и я:

• сменить порт ssh. Как ни возмущались бы выше, но большая часть взломов — это автоматические сканеры уязвимостей. другой порт -> меньше попыток взлома -> меньше шанс словить свежий эксплойт.
• отключить аутентификацию по паролю и использовать только аутентификацию по ключам. Хранить приватный ключ в зашифрованном виде. Это сделает бессмысленным брутфорс и кражу приватных ключей с машины администратора.
• (для параноиков) добавить в sshd двухфакторную аутентификацию по TOTP
• (для рисковых параноиков) настроить на сервере файрволл, чтобы он разрешал подключения по SSH только с ваших IP адресов.

[GhOsT_MZ]

Вопрос по проверке cron'а, что делать, если злоумышленник менял не пользовательскую конфигурацию, а системную? А если и пользовательскую, но создал еще одного root'а? А если изменил login shell для любого системного пользователя (плюс добавил пароль, разумеется), добавил его в sudoers и таким образом имеет backdoor с root'ом? Также, он мог банально повесить SUID-бит на /bin/bash, либо положить wrapper для оболочки с этим битом, чтобы иметь root'а при логине под любым пользователем.

Собственно, исходя из этого на мой взгляд нужно как минимум:

• Ежедневно проверять список файлов с SUID-битом (интересно, но во FreeBSD есть periodic-задание для этого)
• Проверять не crontab -l, а /var/spool/cron, /etc/crontab и /etc/cron.*
• Регулярно проверять изменения в /etc/passwd, возможно даже настроить мониторинг на изменение этого файла (по дефолту в zabbix'е есть даже триггер на это)
• Проверять /etc/sudoers
• Диски, на которые происходит заливка файлов с внешнего мира, монтировать с флагами nosuid и noexec

[lorc]

Нужно исходить из того, что если злоумышленник получил рута хоть на 5 секунд — вы больше не контролируете систему. Потому что уже руткит уже загружен прямо в ядро и вы никогда даже не узнаете о его существовании.
stat() будет показывать правильные права для нужных файлов, никаких лишних записей в /etc/passwd вы не увидите, в /proc/ тоже не будет видно лишних процессов и т.д. И при этом машина будет вовсю DDOSить кого-нибудь и рассылать спам в промежутках между атаками.

Разве что физически снимете винчестер, подключите его к другой системе и очень детально проанализируете данные (не файлы!) на нём. Тогда да, вы сможете понять что машина была заражена.
А это мы ещё не затрагивали UEFI. Вирус в биосе — это больше не фантастика.

[GhOsT_MZ]

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

[dim2r]

Еще рекомендую делать «rpm -V» — сверяет контрольные суммы файлов на диске с эталонными. Можно смотреть какие конфиги или бинарники изменлись.

[dim2r]

Мне мое знание помогало пару раз найти атаки. А Вам ваше знание помогло?

[dim2r]

я тоже не понял вас. предлагаю закончить диспут