Я много раз использовал Fedora для хостинга серверов. Я никогда не сталкивался с какими-либо проблемами. Тем не менее, все новые пользователи приходят и говорят, что Fedora небезопасна. Мы должны использовать Ubuntu / CentOS или какой-то другой дистрибутив, но не Fedora. Я никогда не понимаю, в чем проблема Fedora. Что делает другие дистрибутивы более безопасными.
Несколько моментов: 1. Fedora поставляется с iptables, настроенными на разрешение только SSH. Плюс мы всегда можем настроить iptables даже на блокировку SSH, если захотим. Так что недостатка в брандмауэре нет.
Fedora регулярно выпускает обновления (как исправления безопасности, так и общие исправления).
Люди говорят, что дистрибутив X выпускает новую версию раз в 5 лет, а Fedora — раз в 6 месяцев. Как так получается, что выпуск раз в 5 лет делает что-то безопасным? ЕСЛИ вы считаете, что 5-летние вещи безопасны, установите пятилетнюю ОС или не обновляйтесь в течение 5 лет, даже если выйдет новая версия. Лично я считаю, что отсутствие выпуска новой версии в течение 5 лет не добавляет безопасности. Вам пришлось бы выпускать исправления в течение 5 лет по мере обнаружения ошибок. Поэтому использование очень старой ОС просто означает больше исправлений. Если мы используем недавно выпущенную версию, то нам придется применять меньше обновлений/исправлений. Как выпуск раз в 5 лет делает что-то безопасным, я никогда не понимал.
Все ОС используют похожие пакеты, такие как Gnome, Open-Office, KDE, Open-SSH, Apache. Тратят ли разработчики других дистрибутивов время на чтение исходного кода этих пакетов и исправление ошибок безопасности, если таковые имеются? Даже если они это делают, они публикуют эти недостатки, и все другие дистрибутивы выпускают исправления для них, включая Fedora. Или они защищают свои собственные дистрибутивы и не утруждают себя уведомлением других. Все это предполагает, что они читают все миллионы строк кода пакетов, таких больших, как apache, gcc, Open-Office. Если это одинаково в каждом дистрибутиве, что делает Fedora более уязвимой.
Fedora поставляется с предустановленным и хорошо настроенным seLinux.
Bind работает в chroot по умолчанию в fedora. Теперь в Fedora 11 поддержка DNSSEC также присутствует по умолчанию. Смотреть вопросDNS-сервер в Fedora 11где кто-то указал на Fedora как на неподходящую для хостинга DNS. Я не знаю почему.
На самом деле один из новых администраторов установил Cent-OS 5.3 на одну из тестовых машин. Я использовал его для пинга одного IP, которого там не было. Я получил ответы пинга. Я был удивлен, так как это было невозможно. Я попытался выяснить, откуда приходят ответы, но безуспешно. В конце, после попыток в течение часа, я отключил сетевой кабель от машины CentOS. Я все еще мог пинговать IP. Затем я попытался пинговать IP-адрес машины. Я мог пинговать и его. Таким образом, я смог пинговать два IP (не другие, я пробовал их тоже), когда машина была настроена на один IP и не было никаких псевдонимов (eth0:1 и т. д.). Я также проверил вывод ifconfig. Я полностью потерял доверие к так называемым серверным дистрибутивам и установил Fedora 11 на все тестовые машины. Теперь я не сталкиваюсь с такими странными проблемами для таких простых вещей, как пинг.
Я был бы очень признателен, если бы я мог получить реальные примеры, которые показывают, что Fedora небезопасна, и если бы в этом случае это был любой другой дистрибутив, все было бы в порядке. Не приводите примеры ошибок администратора. Мы не можем винить в этом дистрибутив. Также не приводите очень старые примеры Fedora 1, 2 или Fedora 3. Проект Fedora сейчас очень зрелый, особенно последние две версии 10, 11. Если вы столкнулись с проблемами безопасности, которые свойственны только им, пожалуйста, поделитесь своим опытом.
решение1
Нет ничего, что диктует, что Fedora не подходит для использования на серверах, и нет ничего, что диктует, что "серверные дистрибутивы" являются единственным выбором для серверов. Это зависит оттвойособые потребности.
Что вы можете получить от использования «серверных дистрибутивов»:
- долгосрочная поддержка
- стабильные API (практически нет обновлений версий библиотек и приложений)
- бэкпортированные исправления безопасности и исправления ошибок
- платная поддержка
Моя главная «претензия» к серверным дистрибутивам заключается в том, что программное обеспечение/библиотеки, как правило, несколько устарели, а спектр поддерживаемых пакетов гораздо меньше, чем предполагает сообщество.
То есть долгосрочная поддержка и неизменные API — это то, что любят поставщики коммерческого ПО, им не придется перестраивать свое приложение для новейших библиотек из-за того, что API внезапно изменилось. Они могут разрабатывать для поставщика Y Release X и знать, что эта платформа будет существовать еще несколько лет.
решение2
Я думал, что мне нечего добавить, но после почти двух лет эксплуатации Fedora в производственной среде (для моей очень важной системы мониторинга Zabbix!) похоже, мне есть что сказать.
Во-первых, это был не мой первый выбор. Обычно для чего-то даже неопределенно важного я выбираю CentOS/RHEL из-за преимуществ долгосрочной стабильности, которые предоставляют эти дистрибутивы. Однако для этого конкретного развертывания мне абсолютно необходимы функции Zabbix 2.0, в то время какЭПЕЛЬВ репозитории была только версия 1.8. (В EPEL теперь есть пакеты Zabbix 2.0 и 2.2 в дополнение к версии 1.8, хотя в то время их не было. Если бы они были, я бы никогда не попробовал это сделать.)
Итак, компромисс здесь таков: Fedora имеет новейшее программное обеспечение, но его релизы имеют очень короткий 13-месячный жизненный цикл, а новые релизы выпускаются примерно каждые шесть месяцев. Это означает, что мне пришлось запланировать окно обслуживания для обновления Fedora дважды в год, в дополнение к обычной периодической установке обновлений.
Для системы мониторинга, которая должна отслеживатьвсе остальное, жизненно важно, чтобы такие периоды обслуживания были как можно реже и как можно короче. При необходимости обновляться так часто это обычно исключало бы такое распространение, но помните, что у меня были более насущные проблемы; оно было бы бесполезным без необходимых мне функций. Так что это компромисс, на который я пошел с (почти) полным пониманием последствий.
Не так давно я сделал обновление Fedora 18-19 на этом сервере, используя новый инструмент обновления Fedora fedup. Я запланировал двухчасовой простой, а еще два часа ушло на то, чтобы разобраться с любой из отслеживаемых служб, которая могла бы умереть, и этот факт был упущен, поскольку Zabbix был недоступен.
TheдействительныйВремя простоя сервиса составило 11 минут. Это с момента остановки Zabbix перед перезагрузкой до момента его резервного копирования и мониторинга сервисов после завершенного обновления. Я не думал, что время простоя будет таким коротким!Я ожидал гораздо больших проблем., хотя я знаю по опыту, что серьезные проблемы с обновлением Fedora случаются редко. (И она была улучшена еще больше: когда я выполнил обновление Fedora 19-20, полное время простоя было поразительнымшесть минут. То же время для 20-21.)
Эта служба почти наверняка будет перенесена на RHEL 7, когда она станет доступной. После этого опыта я стал гораздо более уверен в Fedora как сервере и теперь намерен сохранить ее, даже при крупном обновлении каждые шесть месяцев. Переход на RHEL был бы гораздо более разрушительным и мог бы ограничить меня в будущем из-за следующего:
Жаль, что у Red Hat такой большой промежуток времени между основными релизами; похожая задержка между EL5 и EL6 заставила меня фактически запустить установку Ubuntu в производство, за что я до сих пор ругаю себя. (В качестве этой системы я рассматривал Fedora, но, как ни странно, в то время в ней вообще не было нужного мне программного обеспечения, несмотря на то, что старая версия находилась в EPEL.)
Одна из "проблем", о которой никто не упомянул при запуске Fedora, заключается в том, что вы увидите много новых вещей, как крупных программных проектов, так и небольших улучшений, задолго до их включения в RHEL. Поэтому, когда вы начнете управлять своими системами RHEL/CentOS, вы их пропустите. Например, в Fedora есть большое количество дополнений bash, которых по умолчанию нет в RHEL; одна из самых заметных — это дополнение tab для имен пакетов в yumкомандной строке.
Итак, Fedora, безусловно, можно использовать в производстве, если вы готовы пойти на компромиссы:
- Нет никаких контрактов на поддержку. У вас должен быть внутренний опыт, достаточный для управления сервером и его службами, а также для решения любых проблем, которые могут возникнуть; доступна только поддержка сообщества, и никаких гарантий здесь нет. Опыт RHEL помогает, так как они довольно похожи.
- У вас должно быть окно для технического обслуживанияобновлять не реже одного раза в год. Хотя лучше делать это каждые шесть месяцев; если вы обновляетесь ежегодно, вам придется обновлять два релиза одновременно, что удваивает количество потенциальных проблем, с которыми вам придется разбираться в 3 часа ночи.
- Обновления могут принести новые версии программного обеспечения, с которыми вам придется иметь дело; однако это будут точечные релизы, а не основные версии. В редких случаях могут быть добавлены значительные новые функции (например,БЗ#319901). Однако, как правило, программное обеспечение остается на одном и том же номере версии на протяжении всего срока действия релиза, а исправления переносятся обратно; только некоторые пакеты (например, PHP) отслеживают точечные релизы.
- Хотя нет существенной разницы в темпах обновлений безопасности, они не всегда могут быть изолированы от обновлений исправлений ошибок (опять же, таких как PHP). Является ли это проблемой, зависит от сервиса, который вы планируете запустить.
Учитывая все обстоятельства, Fedora все еще не является для меня выбором номер один в качестве серверной платформы и, вероятно, никогда таковым не станет. (Хотя я был счастлив использовать Fedoraрабочий стол(пользователем на протяжении всего срока его существования.) В случае, если вам абсолютно необходимы более свежие версии программного обеспечения, недоступные в более «корпоративном» дистрибутиве, и вы готовы пойти на компромиссы, то нет ничего плохого в использовании Fedora.
Наконец, поскольку вы спросили конкретно о безопасности, несколько слов об этом.
Как уже отмечалось, нет никакой реальной разницы в темпах обновлений безопасности между Fedora и любым другим дистрибутивом. Разработчики Fedora прилагают особые усилия длядержаться ближе к верховьюи выпускать подобные обновления как можно быстрее, иногда даже раньше, чем это сделает вышестоящий проект.
Как и его старший брат, Fedora также поставляется с довольно жесткой конфигурацией безопасности: службы (кроме ssh) поставляются по умолчанию отключенными; брандмауэр с запретом по умолчанию включен по умолчанию для IPv4 и IPv6; SELinux применяется по умолчанию. Кроме того,Fedora усилена рядом других способов.
С другой стороны, вы можете увидеть новые технологии безопасности очень рано; одним из примеров является недавнее внедрениеFirewallD, который, однако, все еще не совсем готов к показулегко вернуться к предыдущему брандмауэру.
решение3
Речь идет скорее о стабильности и скорости изменений, чем о безопасности как таковой. Fedora — это платформа для Red Hat, позволяющая развертывать новые функции и приложения, чтобы проверить их актуальность, предоставлять платформу для экспериментов и решать проблемы интеграции.
Обычно это не то, чего вы ждете от сервера — обычно вы хотите, чтобы сервер выполнял функцию максимально стабильным образом.
В зависимости от того, что вы делаете, Fedora может быть просто отличной. Если вы разрабатываете приложения для рабочего стола Linux, работа с передовыми технологиями может быть желательной. Аналогично, если вы работаете над школьным проектом длиной в семестр или каким-то другим проектом с ограниченной продолжительностью, где высокий темп изменений не является проблемой, Fedora также хороша.
решение4
Без поддержки.
У Fedora нет контрактов на техническую поддержку, как у Red Hat Enterprise. Некому позвонить, если у вас возникнет проблема, которая остановит шоу.