Защита нового сервера Ubuntu [закрыто]
Я не могу думать ни о каких определенных для Ubuntu тонких настройках, но здесь являюсь некоторыми, которые обращаются ко всем дистрибутивам:
- Удалите все ненужные пакеты
- Используйте открытый ключ только аутентификация в SSH
- Отключите корневые логины через SSH (не относится к Ubuntu),
- Используйте производственные настройки для (php.ini-рекомендуемого) PHP
- Настройте MySQL для использования сокетов только
Конечно, этот список не полон, и Вы никогда не будете абсолютно в безопасности, но он покрывает все использование, которое я видел в реальной жизни.
Кроме того, использование, которое я видел, почти всегда связывалось для необеспечения пользовательского кода, не небезопасной конфигурации. Конфигурации по умолчанию в минимальном, дистрибутивы сервера имеют тенденцию быть довольно безопасными.
-
1Измените порт для сервисов как MySQL (бесполезный, если настроить его для использования только сокетов), FTP (хотя, если Вы безопасны, Вы не должны использовать FTP вообще), SSH и все виды. – Josh Hunt 30 April 2009 в 14:52
-
2" Удалите весь ненужный packages". хорошо. Это довольно неопределенно. Какой ' unnecessary' пакеты? – Luke 13 June 2009 в 08:18
-
3@Luke: Что-либо you' ре, не используя является ненужным. Более определенные, рабочие сервисы, что Вы don' t должны поместить машины в ненужный риск. – Andrioid 11 July 2009 в 18:23
Одной быстрой вещью, которую я делаю вначале, является установка DenyHosts. Это будет регулярно просматривать/var/log/secure, ища неудавшиеся логины, и после нескольких отказов, блокировать IP. Я установил его для блокирования после первого no-such-user на второй попытке корня, и после нескольких попыток реальных пользователей (в случае, если Вы портите, но необходимо использовать открытый ключ SSH для входа в систему).
-
1поскольку Вы связываетесь с домашней страницей SourceForge - denyhosts, также доступно в репозитории (вселенная) через " способность sudo устанавливает denyhosts" – Olaf 11 May 2009 в 23:12
-
2положительная сторона @olaf. Большинство серверов, на которых я установил его, было RHEL, где it' s также в DAG' s repo. – Alister Bulman 12 May 2009 в 00:55
Ubuntu базируется от Debian, и я нашел Обеспечение Руководством Debian, чтобы быть очень полезным в находящихся в Debian дистрибутивах в завершенном обходе Вас через Вашу систему и проверку каждой части. Это в основном действительно, действительно всесторонний ответ на Ваш вопрос.
-
1
-
2Извините, мысль ссылка была в сообщении. It' s в: debian.org/doc/manuals/securing-debian-howto – Mike McQuaid 6 May 2009 в 16:32
Я обычно устанавливаю RKHunter, который сканирует для руткитов и делает проверки целостности различных важных системных двоичных файлов. Это находится в стандарте repo и будет ежедневно работать от крона. Это не прекрасно, securitywise, но это - объект низкого усилия для добавления, и это обеспечивает меру защиты.
Установите logcheck, но тонкая настройка так, чтобы Вы никогда не получали сообщения от регулярных событий, иначе Вы привыкнете игнорировать электронные письма.
Проверьте, который процессы слушают с помощью netstat и удостоверяются, что ничто не работает, который не должен работать. Многие демоны могут быть настроены только для слушания на внутреннем IP (или localhost) вместо всех интерфейсов.
Сделайте то, что Может предлагать...
Nmap хост и отключают все несущественные сервисы. Используйте iptables при необходимости.
-
1На любом сервере, который доступен через Интернет, iptables всегда необходим.;-) – Christopher Cashell 27 May 2009 в 21:28
Если Вы идете в какой-либо степени Интернет с сервером, устанавливаете систему обнаружения проникновения как фырканье.
А также другие предложения здесь, которые я упомяну три, которые очевидны, но возможно стоит упомянуть для полноты:
- Если Вы не думаете, что Вам нужен брандмауэр, думайте снова. ufw прост, но разработан для Ubuntu и на основе iptables
- Обновите пакеты: как минимум применяют все патчи безопасности
- Документ, что Вы сделали для обеспечения сервера и почему. Включайте (автоматизированные) процессы конфигурирования, чтобы контролировать журналы, протестировать конфигурацию и сообщить об обновлениях системы защиты, которые необходимы.
Некоторые предложения брандмауэра.
Учитесь использовать брандмауэр и понятие надлежащей блокировки поля вниз. Изменение портов по умолчанию является в основном бесполезной вещью; надлежащее приложение и конфигурация брандмауэра намного более важны.
Оба находятся в Ubuntu repos:
FireHOL
имеет потрясающую документацию и очень легкий изучить синтаксис. Я смог настроить шлюз/брандмауэр через двадцать минут. Единственная причина, которую я отодвинул от этого, состоит в том, что это, кажется, не сохраняется (последний выпуск 2 yrs назад). Не означает, что это не работает, но...
Ferm
другой. Больше подобного iptables синтаксиса, но то же понятие. Больше сообщества, сохраняемого, чем FireHOL, но, занимает больше времени для взятия.
Shorewall
то, что я в настоящее время использую. Его документация обширна, и его формат конфигурации является табличным. Мне потребовались приблизительно полтора часа, чтобы понять, что всем файлам было нужно (6) для получения рабочего выполнения брандмауэра/конфигурации шлюза. Это довольно мощно. ПОДСКАЗКА: страницы справочника для различных файлов конфигурации ДЕЙСТВИТЕЛЬНО полезны!
Все эти конфигурации брандмауэра загрузки из файла конфигурации. Очень эффективный, легче использовать, чем iptables прямо, и (по-моему) легче использовать и справиться, чем ufw.
Другое:
Я второй рекомендации для ключевого использования SSH.
Настройте IDS.
Узнайте о AppArmor. Это ограничивает доступ к файлу исполняемых файлов только к указанным каталогам и файлам, в которых это нуждается. Подобный SELinux в мире RHEL. Это установлено и включено с предварительно сконфигурированными 'профилями' для многих хорошо используемых программ.