Comments 59
Перенёс сервис на левый порт = нажил себе геморрой в будущем. А лучше не стало. Так что так делать не стоит, кроме особых отдельных случаев.
А уже если вы сервис публичный делаете, то на какой-нибудь другой порт вы его вообще не сможете перевесить.
На примере ssh: простым сканированием портов однозначно определяется — он первым делом после установления клиенту сообщает, что он какой-нибудь «SSH-2.0-OpenSSH_5.6p1-hpn13v10». Так что переноси, не переноси — один фиг, безопасности ни капли не добавится.
А удобства сильно меньше, вместо ssh system.dns.name приходится ещё указывать порт; а scp так и вообще неудобно — порт указывается в отдельном ключике и то ли -P, то ли -p, не помню.
А вот ключи — очень удобная фича. Как раз стоит вообще отключить доступ по паролю, а разрешить только ключи. И можно не бояться брутфорсов.
А уже если вы сервис публичный делаете, то на какой-нибудь другой порт вы его вообще не сможете перевесить.
На примере ssh: простым сканированием портов однозначно определяется — он первым делом после установления клиенту сообщает, что он какой-нибудь «SSH-2.0-OpenSSH_5.6p1-hpn13v10». Так что переноси, не переноси — один фиг, безопасности ни капли не добавится.
А удобства сильно меньше, вместо ssh system.dns.name приходится ещё указывать порт; а scp так и вообще неудобно — порт указывается в отдельном ключике и то ли -P, то ли -p, не помню.
А вот ключи — очень удобная фича. Как раз стоит вообще отключить доступ по паролю, а разрешить только ключи. И можно не бояться брутфорсов.
Я не предлагаю переносить например nginx с 80-го порта на порт 12345.
В плане изменения порта речь шла о довольно узком круге сервисов, поэтому я и написал
Возможно это или нет — решать системному администратору.
Насчёт sshd:
1) Я меняю порт на нестандартный по той причине, что огромное количество скриптов сканируют онлайн хосты каждую секунду.
Получать на почту горы сообщений о том, что была неудачная попытка входа под логином root и паролем toor мне не очень улыбается. Смена порта это не защита от серьёзного злоумышленника, это отсечение простых ботов.
2) Касательно неудобства использования нестандартного порта для логина по ssh. Я один раз прописываю сервер в /etc/ssh/ssh_config и забываю о нём.
Запись делается такого рода:
В плане изменения порта речь шла о довольно узком круге сервисов, поэтому я и написал
"Если это возможно, то изменить стандартные порты ...". Возможно это или нет — решать системному администратору.
Насчёт sshd:
1) Я меняю порт на нестандартный по той причине, что огромное количество скриптов сканируют онлайн хосты каждую секунду.
Получать на почту горы сообщений о том, что была неудачная попытка входа под логином root и паролем toor мне не очень улыбается. Смена порта это не защита от серьёзного злоумышленника, это отсечение простых ботов.
2) Касательно неудобства использования нестандартного порта для логина по ssh. Я один раз прописываю сервер в /etc/ssh/ssh_config и забываю о нём.
Запись делается такого рода:
Host 1.2.3.4
Port 22122
для ssh есть bruteblock и fail2ban
Ага, знаю. Да и Snort я думаю умеет реагировать на брутфорсы.
Я намеренно не стал описывать применение конкретных решений — не хотел сильно увеличивать статью.
Я намеренно не стал описывать применение конкретных решений — не хотел сильно увеличивать статью.
можно через iptables простым правилом по кол-ву соединений на единицу времени
iptables -I INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
iptables -I INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 4 --name DEFAULT --rsource -j DROP
hitcount сколько соединений
seconds в течении какого временного промежутка
iptables -I INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
iptables -I INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 4 --name DEFAULT --rsource -j DROP
hitcount сколько соединений
seconds в течении какого временного промежутка
Я имел ввиду, что смена портов — это высокоспецифичный трюк. А вы, вместо списка тех нескольких сервисов, для которых это имеет смысл, привели в пример ssh, для которого его полезность сомнительна. К тому же, все эти несколько сервисов наверняка правильнее закрыть файерволлом, чем перевешивать на другие порты.
Этот трюк годится для OpenVPN. А больше я что-то и не могу сходу придумать примеров.
Этот трюк годится для OpenVPN. А больше я что-то и не могу сходу придумать примеров.
Файрволом, к сожалению, не всегда возможно, хотя это конечно лучшее решение. Часто у пользователей динамические ip адреса, а прописывать в файрволе /10 диапазоны их провайдеров нет никакого смысла.
А так, да для этого и нужны комментарии — для исправления и уточнения статьи.
А так, да для этого и нужны комментарии — для исправления и уточнения статьи.
Прописать /10 или /16 это лучше чем для всего инета доступ открывать.
Для меня почти нет разницы если честно.
Лучше уж vpn настроить для доступа к критичному сервису, если у его пользователей нет статичных ip адресов.
Лучше уж vpn настроить для доступа к критичному сервису, если у его пользователей нет статичных ip адресов.
Я обычно vpn не ставлю, а обучаю юзеров делать port forwarding через ssh, чтобы работать с сервисами внутренней сети. При большом количестве сервисов и т.п. — однозначно vpn, но пока только один случай был, когда ssh не хватило.
У меня принцип — меньше служб, выше безопасность. Т.е. там где возможно, как минимум вместо vpn и ftp используется ssh.
У меня принцип — меньше служб, выше безопасность. Т.е. там где возможно, как минимум вместо vpn и ftp используется ssh.
я вот недавно зафаерволил SMB/CIFS на одном сервачке на /64 :)
Порты полезно менять, если наш провайдер по дефолту блочит 22 порт. Это отголоски того самого бага в SSHv1. Плюс у нескольких хостеров встречал, что ssh открывается только для определенных адресов. Я предпочитаю делать это сам, поэтому перевешиваю ssh.
Плюс на всех серверах обычно ssh смотрит только в межсерверную сеть, либо доступ к порту ssh открыт только с наших серверов, если нет межсерверной сети. Плюс отдельная машинка, возможно виртуальная, на которой кроме ssh вообще ничего нет. Т.е. с нее либо транзитом на остальные сервера прыгаем, либо делаем проброс портов через ssh-тоннель. Ну и по ситуации — если провайдеры админов дают статические адреса, то открываем доступ только с адресов с админов, если нет то только с сетей провайдеров админов, и навешиваем дополнительную защиту типа fail2ban или стука по портам, прежде чем нам откроется порт ssh.
Плюс на всех серверах обычно ssh смотрит только в межсерверную сеть, либо доступ к порту ssh открыт только с наших серверов, если нет межсерверной сети. Плюс отдельная машинка, возможно виртуальная, на которой кроме ssh вообще ничего нет. Т.е. с нее либо транзитом на остальные сервера прыгаем, либо делаем проброс портов через ssh-тоннель. Ну и по ситуации — если провайдеры админов дают статические адреса, то открываем доступ только с адресов с админов, если нет то только с сетей провайдеров админов, и навешиваем дополнительную защиту типа fail2ban или стука по портам, прежде чем нам откроется порт ssh.
Еще есть port knocking. На мой взгляд лучше, чем менять порты.
Забыл ответить по ключам.
Ключи очень удобная вещь, согласен, сам ими пользуюсь чтобы не вводить каждый раз пароли, но с тем, что они повышают защищённость я бы не согласился.
Просто меняется точка уязвимости, до этого это был пароль, теперь стал файл с ключом.
Также остаётся открытым вопрос — что делать в случае утери ключа? Как зайти на сервер, чтобы заменить ключ на новый?
Ключи очень удобная вещь, согласен, сам ими пользуюсь чтобы не вводить каждый раз пароли, но с тем, что они повышают защищённость я бы не согласился.
Просто меняется точка уязвимости, до этого это был пароль, теперь стал файл с ключом.
Также остаётся открытым вопрос — что делать в случае утери ключа? Как зайти на сервер, чтобы заменить ключ на новый?
Ключи безопасность однозначно повышают. Сравните: при брутфорсе будут подбирать ~20 символов пароля, по ~4 бита энтропии каждый, или же 1024 или 2048 бит закрытого ключа?
Кроме того, пока что я не видел, чтобы по ключам брутфорсили. А по паролям — только так.
Файлик не так-то просто стырить. Кроме того, он шифруется с парольной фразой. Т.е. на худой конец, даже если пароль стырили, не сразу расшифруют, и ещё надо понять, от чего он.
А про потерю — встречный вопрос: что вы будете делать, если забыли пароль?
Кроме того, пока что я не видел, чтобы по ключам брутфорсили. А по паролям — только так.
Файлик не так-то просто стырить. Кроме того, он шифруется с парольной фразой. Т.е. на худой конец, даже если пароль стырили, не сразу расшифруют, и ещё надо понять, от чего он.
А про потерю — встречный вопрос: что вы будете делать, если забыли пароль?
смена пароля — физический доступ или IP KVM
1) для взлома ключа вам нужен будет [файл ключа] + [пароль от него]
2) Повышает безопасность необходимостью подбора более длинного ключа в отличии от пароля, защищает от совпадений md5
3) Позволяет ввести пароль только один раз
4) Позволяет Agent Forwarding для доступа далее — можно лазить через цепочку ssh, при этом ключ будет только у вас на машине.
5) Позволяет отключить авторизацию по паролю.
Что делать в случае утери ключа? То же самое, что в случае забывания пароля.
— примонтировать диск и заменить ~/.ssh/authorized_keys нужным
— зайти по паролю через физическую консоль
— иметь запасной ключ (можно на одну учетку ведь и несколько ключей повесить)
— свой вариант решения проблемы
2) Повышает безопасность необходимостью подбора более длинного ключа в отличии от пароля, защищает от совпадений md5
3) Позволяет ввести пароль только один раз
4) Позволяет Agent Forwarding для доступа далее — можно лазить через цепочку ssh, при этом ключ будет только у вас на машине.
5) Позволяет отключить авторизацию по паролю.
Что делать в случае утери ключа? То же самое, что в случае забывания пароля.
— примонтировать диск и заменить ~/.ssh/authorized_keys нужным
— зайти по паролю через физическую консоль
— иметь запасной ключ (можно на одну учетку ведь и несколько ключей повесить)
— свой вариант решения проблемы
Перенос ssh на другой порт отсеивает в первую очередь ботов. Так же, как и грейлист на smtp отсеивает в первую очередь завирусованные винды. К счастью, тупых ботов намного больше, чем целенаправленных попыток проникновения, поэтому один только перенос уже значительно улучшает ситуацию.
Например, я у себя держу ssh на стандартном порту на интерфейсах, смотрящих в локальную сеть и на нестандартном на внешних, смотрящих в интернеты.
Например, я у себя держу ssh на стандартном порту на интерфейсах, смотрящих в локальную сеть и на нестандартном на внешних, смотрящих в интернеты.
IMHO отключение рута (если был) и настройка входа только по ключу — первые действия после установки sshd. Тот, кто это пройдёт, и порты просканировать не поленится.
Нестандартный порт для часто используемого хоста стоит в .ssh/config указать, там его и scp подберёт.
Нестандартный порт для часто используемого хоста стоит в .ssh/config указать, там его и scp подберёт.
~/.ssh/config
На тему не стандартного порта SSH. поможет файл конфига в домашнем каталоге.
scp,svn, и так далее все будут ходить по определенному порту
~/.ssh/config
Host xxx.com
Port xx
scp,svn, и так далее все будут ходить по определенному порту
~/.ssh/config
Host xxx.com
Port xx
> Маны и гугл никто не отменял
Вот это коварно может быть. Бывало, и не раз на дебиан (и не только):
Проблема: %software% не полностью решает задачу X.
Правильное решение: apt-get install %software%-чегототам
Решение любезно подсунутое гуглом: выкачать, пропатчить и собрать %software%
На старой работе админ так с php развлекался.
Вот это коварно может быть. Бывало, и не раз на дебиан (и не только):
Проблема: %software% не полностью решает задачу X.
Правильное решение: apt-get install %software%-чегототам
Решение любезно подсунутое гуглом: выкачать, пропатчить и собрать %software%
На старой работе админ так с php развлекался.
Конкретно по дебиану много различных копи-пейст ресурсов, на том же www.howtoforge.com/ много примеров на базе дебиан. И большинство из них без компиляции.
Вообще не очень люблю собирать из исходников, прибегаю к этому в самом крайнем случае.
Как минимум потом придется подписываться на security рассылку скомпилированного софта и мониторить наличие в нём уязвимостей (что в стандартном случае делает debian security team).
Плюс теряется связность скомпилированного ПО с остальным системным софтом и можно случайно нарушить его работу, удалив казалось бы ненужный пакет (такого у меня пока не было, но думаю опасность вполне реальная).
Ещё минус — для сборки придется ставить много -dev пакетов, которые в обычной системе совсем не нужны.
Вообще не очень люблю собирать из исходников, прибегаю к этому в самом крайнем случае.
Как минимум потом придется подписываться на security рассылку скомпилированного софта и мониторить наличие в нём уязвимостей (что в стандартном случае делает debian security team).
Плюс теряется связность скомпилированного ПО с остальным системным софтом и можно случайно нарушить его работу, удалив казалось бы ненужный пакет (такого у меня пока не было, но думаю опасность вполне реальная).
Ещё минус — для сборки придется ставить много -dev пакетов, которые в обычной системе совсем не нужны.
Сборка чего не надо — это лишь один частный случай из многих.
Каждый 3-й совет из интернета — записать свои труды в rc.local — тем самым превращая rc.local в хренов autoexec.bat. Например записать туда echo «1» > /proc/sys/net/ipv4/ip_forward, вместо разкомментирования строчки в /etc/sysctl.conf
Можно навалить еще кучу примеров.
Важно знать, что хорошо в слаке — то в генту смерть. Вообщем основная моя мысль такая: искать в интернете не «сделать что-то в Linux», а «сделать что-то в %disributive% %version%»
Впрочем, сам я даже не начинающий админ, просто мимо пробегал. Но на форумах много раз видел, как новичкам любезно подкладывают грабли (из лучших побуждений!)
Каждый 3-й совет из интернета — записать свои труды в rc.local — тем самым превращая rc.local в хренов autoexec.bat. Например записать туда echo «1» > /proc/sys/net/ipv4/ip_forward, вместо разкомментирования строчки в /etc/sysctl.conf
Можно навалить еще кучу примеров.
Важно знать, что хорошо в слаке — то в генту смерть. Вообщем основная моя мысль такая: искать в интернете не «сделать что-то в Linux», а «сделать что-то в %disributive% %version%»
Впрочем, сам я даже не начинающий админ, просто мимо пробегал. Но на форумах много раз видел, как новичкам любезно подкладывают грабли (из лучших побуждений!)
UFO just landed and posted this here
Меня очень и очень задолбали люди, которые первым советом при настройке CentOS пишут «Отключите SELinux...» вместо нормальной настройки под их изменения.
При этом найти информации по SELinux очень сложно. Методом проб и ребутов его приходится точить под изменения :)
При этом найти информации по SELinux очень сложно. Методом проб и ребутов его приходится точить под изменения :)
Вот полезные ссылки из статьи в моей wiki про SELinux:
wiki.debian.org/SELinux
wiki.debian.org/SELinux/Notes
wiki.centos.org/HowTos/SELinux
wiki.debian.org/SELinux
wiki.debian.org/SELinux/Notes
wiki.centos.org/HowTos/SELinux
Мне не нравится статья. В ней, как я понимаю, речь идет о защите серверного Линукса.
Во-первых, нигде не рассказано про то, как изолировать потенциально опасные сервисы вроде веб-сервера с большим количеством сайтов, или демона Samba от системы, таким образом, что даже при уязвимости в одном из приложений, злоумыленник не сможет запустить свой код, нарушить работут системы, а также других веб-приложений.
Во-вторых, что касается SELinux — как я понимаю, вещь в теории мощная, но в реальности конфиги к нему устанешь писать быстро.
В-третьих, непонятно, зачем отключать прием/отправку и форвардинг пакетов. Если у вас один сетевой интерфейс, никаого форвардинга не будет, а отключив прием/отправку пакетов, вы во-первых, сломаете все сервисы, во-вторых, нельзя будет скачивать обновления и устанавливать пакеты. Конечно, можно прописать разрешительные правила, но зачем запрещать чтобы снова потом разрешить? Я не понимаю. Вы видимо тоже.
В-четвертых, изменение порта на котором слушает сервис, не обманет даже популярный nmap — e всех сервисов есть характерные сигнатуры. Разве что это спасет от тупых скриптов, которые брутят пароли на 22 порту у всех машин подряд.
В-пятых, пара строчек про HIDS и NIDS несет нулевую ценность. Никто конечно конфиг выложить не просит, но рассказали бы хоть в общих словах.как их настраивать.
И про бекап MySQL, опять же, вы не написали даже каковы подводные камни установки слейва на той же машине.
В общем, статья не содержит никаких конкретных рекомендаций. То, что бекапы надо делать и лишние сервисы отключить, это и так всем понятно.
Во-первых, нигде не рассказано про то, как изолировать потенциально опасные сервисы вроде веб-сервера с большим количеством сайтов, или демона Samba от системы, таким образом, что даже при уязвимости в одном из приложений, злоумыленник не сможет запустить свой код, нарушить работут системы, а также других веб-приложений.
Во-вторых, что касается SELinux — как я понимаю, вещь в теории мощная, но в реальности конфиги к нему устанешь писать быстро.
В-третьих, непонятно, зачем отключать прием/отправку и форвардинг пакетов. Если у вас один сетевой интерфейс, никаого форвардинга не будет, а отключив прием/отправку пакетов, вы во-первых, сломаете все сервисы, во-вторых, нельзя будет скачивать обновления и устанавливать пакеты. Конечно, можно прописать разрешительные правила, но зачем запрещать чтобы снова потом разрешить? Я не понимаю. Вы видимо тоже.
В-четвертых, изменение порта на котором слушает сервис, не обманет даже популярный nmap — e всех сервисов есть характерные сигнатуры. Разве что это спасет от тупых скриптов, которые брутят пароли на 22 порту у всех машин подряд.
В-пятых, пара строчек про HIDS и NIDS несет нулевую ценность. Никто конечно конфиг выложить не просит, но рассказали бы хоть в общих словах.как их настраивать.
И про бекап MySQL, опять же, вы не написали даже каковы подводные камни установки слейва на той же машине.
В общем, статья не содержит никаких конкретных рекомендаций. То, что бекапы надо делать и лишние сервисы отключить, это и так всем понятно.
Во-1х, статья идёт об усилении простого сервера, подъём jail/vserver это второй уровень защиты.
Во-2х, для SELinux конфиги обычно не руками пишут, а корректируют автогенерённый в процессе 100% чистого запуска в тест режиме.
В-3их, список разрешенных портов гораздо уже, чем запрещенных, и открыть только нужные дырки обнаружив что что-то не работает (причем еще в процессе настройки!) проще, чем потом обнаружить, что у тебя что-то вскрыли.
В-4ых, изменение порта делается не для обмана, а именно для выхода из-под «масс-хак» атак, что снизит вероятность появления очередного ботнета на сайте из-за дырявого сервиса до момента обновления; а не против «персональной» атаки.
В-5ых, самые умные будут грузить чугуний.
Во-2х, для SELinux конфиги обычно не руками пишут, а корректируют автогенерённый в процессе 100% чистого запуска в тест режиме.
В-3их, список разрешенных портов гораздо уже, чем запрещенных, и открыть только нужные дырки обнаружив что что-то не работает (причем еще в процессе настройки!) проще, чем потом обнаружить, что у тебя что-то вскрыли.
В-4ых, изменение порта делается не для обмана, а именно для выхода из-под «масс-хак» атак, что снизит вероятность появления очередного ботнета на сайте из-за дырявого сервиса до момента обновления; а не против «персональной» атаки.
В-5ых, самые умные будут грузить чугуний.
Начну отвечать с конца.
Смотря что поднимать под конкретными рекомендациями.
Если вы о примерах конфигурации, то об этом я предупредил в самом начале статьи.
Я уверен, что это понятно не всем. Статья больше ориентирована на начинающих администраторов, цель была предоставить некий checklist по настройке сервера и подсказать направления для дальнейшего развития.
Это да, конфигурировать его дело муторное, но делать это надо один раз и на одном сервере, а потом можно просто копировать скомпилированные модули с исключениями на остальные сервера.
Бэкапы принято выносить за пределы основной площадки в целях обеспечения их доступности при крупной аварии на этой (основной) площадке.
Или вы о каких-то ещё подводных камнях? Возможно я о них и не знаю или забыл написать.
Да, вы правы. Про chroot я совсем забыл.
Хотя в последнее время я предпочитаю выносить такого рода сервисы в виртуальные машины на базе xen.
Так что моя рекомендация — chroot и/или xen, смотря по обстоятельствам.
При политике файрвола по умолчанию ACCEPT администратору придётся явно запрещать весь нежелательный трафик.
Это приведёт к большому количеству правил, а соответственно к усложнению системы и замедлению её работы.
Гораздо проще запретить все пакеты и разрешить лишь нужные.
Никакие сервисы не поломаются если следовать описанному мной алгоритму с логгированием пакетов. Вот кстати нашел у себя недочет, забыл написать в этом алгоритме о том, что политику DROP надо включать в самом конце, когда в сислоге уже нет записей. Сейчас исправлю.
в общем, статья не содержит никаких конкретных рекомендацийСмотря что поднимать под конкретными рекомендациями.
Если вы о примерах конфигурации, то об этом я предупредил в самом начале статьи.
То, что бекапы надо делать и лишние сервисы отключить, это и так всем понятноЯ уверен, что это понятно не всем. Статья больше ориентирована на начинающих администраторов, цель была предоставить некий checklist по настройке сервера и подсказать направления для дальнейшего развития.
что касается SELinux — как я понимаю, вещь в теории мощная, но в реальности конфиги к нему устанешь писать быстро.Это да, конфигурировать его дело муторное, но делать это надо один раз и на одном сервере, а потом можно просто копировать скомпилированные модули с исключениями на остальные сервера.
И про бекап MySQL, опять же, вы не написали даже каковы подводные камни установки слейва на той же машине.Бэкапы принято выносить за пределы основной площадки в целях обеспечения их доступности при крупной аварии на этой (основной) площадке.
Или вы о каких-то ещё подводных камнях? Возможно я о них и не знаю или забыл написать.
Во-первых, нигде не рассказано про то, как изолировать потенциально опасные сервисы вроде веб-сервера с большим количеством сайтов, или демона Samba от системыДа, вы правы. Про chroot я совсем забыл.
Хотя в последнее время я предпочитаю выносить такого рода сервисы в виртуальные машины на базе xen.
Так что моя рекомендация — chroot и/или xen, смотря по обстоятельствам.
В-третьих, непонятно, зачем отключать прием/отправку и форвардинг пакетов. Если у вас один сетевой интерфейс, никаого форвардинга не будет, а отключив прием/отправку пакетов, вы во-первых, сломаете все сервисы, во-вторых, нельзя будет скачивать обновления и устанавливать пакеты. Конечно, можно прописать разрешительные правила, но зачем запрещать чтобы снова потом разрешить? При политике файрвола по умолчанию ACCEPT администратору придётся явно запрещать весь нежелательный трафик.
Это приведёт к большому количеству правил, а соответственно к усложнению системы и замедлению её работы.
Гораздо проще запретить все пакеты и разрешить лишь нужные.
Никакие сервисы не поломаются если следовать описанному мной алгоритму с логгированием пакетов. Вот кстати нашел у себя недочет, забыл написать в этом алгоритме о том, что политику DROP надо включать в самом конце, когда в сислоге уже нет записей. Сейчас исправлю.
>При политике файрвола по умолчанию ACCEPT администратору придётся явно запрещать весь нежелательный трафик.
>Это приведёт к большому количеству правил, а соответственно к усложнению системы и замедлению её работы.
>Гораздо проще запретить все пакеты и разрешить лишь нужные.
Про полный запрет инпута опять же упоминалось в комментах прошлой статьи. Для апдейтов будете по ip-адресам апдейт-серверов разрешать или по порту все-таки откроете? Проще сделать разрешение на прием ответов для соединений, которые мы же сами и инициировали.
>Это приведёт к большому количеству правил, а соответственно к усложнению системы и замедлению её работы.
>Гораздо проще запретить все пакеты и разрешить лишь нужные.
Про полный запрет инпута опять же упоминалось в комментах прошлой статьи. Для апдейтов будете по ip-адресам апдейт-серверов разрешать или по порту все-таки откроете? Проще сделать разрешение на прием ответов для соединений, которые мы же сами и инициировали.
> Это да, конфигурировать его дело муторное, но делать это надо один раз и на одном сервере, а потом можно просто копировать скомпилированные модули с исключениями на остальные сервера.
А потом какой-нибудь сервис обновится, или поменяется имя конфига, или веб-приложению надо будет файлы куда-нибудь сохранять или место хранения каких-то временных файлов поменяется, и опять все переконфигурировать… да и можно с дури ssh сломать неудачной конфигурацией. По моему, тут возни больше.
> Да, вы правы. Про chroot я совсем забыл.
Ну тогда скорее Xen (что, видимо, дорого в плане нагрузки) или Vserver, так как chroot в Линукс никогда не предназначался для повышения безопасности, а только для смены корневого каталога, о чем в его мануале и написано.
И по поводу фаерволла — вам поднадобится что-то wget скачать, вы отдельное правило напишете? Или зафаерволлите какой-нибудь ftp, он не сможет посылать ДНС запросы, будет необъяснимо тормозить в случайные моменты времени, и т.д. По моему, проще ограничиться минимумом служб, чем тратить дополнительно время на настройку и перенастройку фаерволла. Отключить службу выгоднее чем зафаерволлить.
Единственное полезное (по моему) применение iptables — бывает, когда надо ограничить доступ к службе например только той же подсетью, но и тут лучше какую-нибудь авторизацию предусмотреть, чем менять конфиги фаерволла на десятках машин при изменении конфигурации, или добавлении серверов, разве нет? И мучаться, при отладке, когда разработчики к этой же службе не смогут подключиться из-за фаерволла.
А исходящие соединения фаерволлить по моему больше проблем вызывает, чем пользы. Ну может, конечно, я и ошибаюсь.
А потом какой-нибудь сервис обновится, или поменяется имя конфига, или веб-приложению надо будет файлы куда-нибудь сохранять или место хранения каких-то временных файлов поменяется, и опять все переконфигурировать… да и можно с дури ssh сломать неудачной конфигурацией. По моему, тут возни больше.
> Да, вы правы. Про chroot я совсем забыл.
Ну тогда скорее Xen (что, видимо, дорого в плане нагрузки) или Vserver, так как chroot в Линукс никогда не предназначался для повышения безопасности, а только для смены корневого каталога, о чем в его мануале и написано.
И по поводу фаерволла — вам поднадобится что-то wget скачать, вы отдельное правило напишете? Или зафаерволлите какой-нибудь ftp, он не сможет посылать ДНС запросы, будет необъяснимо тормозить в случайные моменты времени, и т.д. По моему, проще ограничиться минимумом служб, чем тратить дополнительно время на настройку и перенастройку фаерволла. Отключить службу выгоднее чем зафаерволлить.
Единственное полезное (по моему) применение iptables — бывает, когда надо ограничить доступ к службе например только той же подсетью, но и тут лучше какую-нибудь авторизацию предусмотреть, чем менять конфиги фаерволла на десятках машин при изменении конфигурации, или добавлении серверов, разве нет? И мучаться, при отладке, когда разработчики к этой же службе не смогут подключиться из-за фаерволла.
А исходящие соединения фаерволлить по моему больше проблем вызывает, чем пользы. Ну может, конечно, я и ошибаюсь.
А потом какой-нибудь сервис обновится, или поменяется имя конфига, или веб-приложению надо будет файлы куда-нибудь сохранять или место хранения каких-то временных файлов поменяется, и опять все переконфигурировать… да и можно с дури ssh сломать неудачной конфигурацией. По моему, тут возни больше.Возни немало, но у нас и цель достойная.
Что касается изменений — само по себе ничего не меняется, всё происходит в результате действий администратора. Просто необходимо взять за правило при любых изменениях на сервере не забывать про соответствующие изменения в его системе безопасности. И всё это документировать.
И по поводу фаерволла — вам поднадобится что-то wget скачать, вы отдельное правило напишете?
Если это разовая необходимость, просто временно сделаю ACCEPT в цепочке FORWARD для нужного сервера. Если скачивание будет периодичным, то да, напишу новое правило.
Или зафаерволлите какой-нибудь ftp, он не сможет посылать ДНС запросы, будет необъяснимо тормозить в случайные моменты времени, и т.д.
Необходимо хоть немного представлять себе структуру сети, в которой настраиваешь файрвол, тогда таких сюрпризов будет меньше.
Кроме того я добавил к пункту про iptables дополнение, о котором просто забыл написать сразу — политику DROP надо включать после полной отладки файрвола и исчезновения записей в сислоге.
Что касается SELinux.
man getsebool
getsebool |grep http/ftp и т.п.
setsebool value=on/off
man chcon
Ну и собственно для начала более чем достаточно. По крайней мере при взломе апача по серверу уже свободно не погуляют :)
man getsebool
getsebool |grep http/ftp и т.п.
setsebool value=on/off
man chcon
Ну и собственно для начала более чем достаточно. По крайней мере при взломе апача по серверу уже свободно не погуляют :)
Полиси iptables по дефолту в DROP не стоит ставить. В прошлом топике обсуждали почему. Лучше оттуда примеры скопируйте, т.е. REJECT с корректным отлупом.
Я считаю DROP более безопасным. Незачем давать злоумышленнику лишние данные.
Какие интересно лишние данные? В случае с корректным REJECT мы по всем портам — открытым или не открытым даем одинаковый отлуп, т.е. определить есть ли служба сканер не сможет, если он не находится в списке разрешенных хостов. А вот головную боль нормальным юзерам обеспечим, особенно с наличием нестандартных портов. Ошибся портом — и сиди жди тайм-аута.
Освежив теорию соглашусь с вами, наиболее идеологически правильный вариант это политика ACCEPT по умолчанию + последнее правило в цепочке -j REJECT
Единственное возражение по вашему комменту в предыдущем топике — я думаю, что независимо от протокола нужно отвечать с port-unreachable (что кстати является ответом по умолчанию для REJECT если не указывать дополнительные ключи) т.к при реальной попытке подключения к неиспользуемому порту удалённый хост получит именно такое сообщение. Если отвечать с tcp-reset, злоумышленнику станет ясно, что порт защищён файрволом, а наша цель — выдать минимум информации о нашей системе.
Единственное возражение по вашему комменту в предыдущем топике — я думаю, что независимо от протокола нужно отвечать с port-unreachable (что кстати является ответом по умолчанию для REJECT если не указывать дополнительные ключи) т.к при реальной попытке подключения к неиспользуемому порту удалённый хост получит именно такое сообщение. Если отвечать с tcp-reset, злоумышленнику станет ясно, что порт защищён файрволом, а наша цель — выдать минимум информации о нашей системе.
Плюс я бы еще добавил в статью:
Все службы, которые нужны только для администрирования, вешаем на 127.0.0.1 и ходим на них через ssh port-forwarding. Плюс также можно перевесить скрипты для администрирования на вторую копию апача, которая также на localhost слушает и работать с ним аналогично.
Все службы, которые нужны только для администрирования, вешаем на 127.0.0.1 и ходим на них через ssh port-forwarding. Плюс также можно перевесить скрипты для администрирования на вторую копию апача, которая также на localhost слушает и работать с ним аналогично.
Ну не знаю, мне кажется это уже излишнее усложнение.
Либо привязка по ip (т.е firewall) либо впн для себя любимого.
Но в этом вопросе думаю все очень индивидуально, и ваш и мой варианты вполне безопасны.
Либо привязка по ip (т.е firewall) либо впн для себя любимого.
Но в этом вопросе думаю все очень индивидуально, и ваш и мой варианты вполне безопасны.
Согласен, но ssh все же немного безопаснее. Типичный сценарий:
1. Админ с разрешенного адреса заливает файлы по фтп или пользуется другой службой без шифрования трафика.
2. Трафик идет по открытой сети. Сосед или комп жены/ребенка ловит вирусню, которая начинает шмалять пакеты в сеть о том, что мак шлюза изменился на мак вирусованного компа. Все — пароль уплыл.
Либо по дороге стоит машина со снифером.
3. Хакер с утянутым паролем заходит на общедоступную службу нашего сервака и читает почту админа, или еще как-нибудь пакостит.
Ну и опять же возможен случай, когда хакер зайдет на сервер с вирусованной машины из доверенной сети.
Т.е. фаервол в данном случае не панацея. Редхат в половине своих курсов не зря постоянно повторяет — не передавайте в чистом виде данные с логином/паролем по открытым сетям.
То что я использую, на самом деле логическое продолжение парадигмы об отключении лишних сервисов. Все что нужно админам или ограниченному кругу лиц не должно висеть на внешнем интерфейсе, а быть доступным только через ssh или vpn.
1. Админ с разрешенного адреса заливает файлы по фтп или пользуется другой службой без шифрования трафика.
2. Трафик идет по открытой сети. Сосед или комп жены/ребенка ловит вирусню, которая начинает шмалять пакеты в сеть о том, что мак шлюза изменился на мак вирусованного компа. Все — пароль уплыл.
Либо по дороге стоит машина со снифером.
3. Хакер с утянутым паролем заходит на общедоступную службу нашего сервака и читает почту админа, или еще как-нибудь пакостит.
Ну и опять же возможен случай, когда хакер зайдет на сервер с вирусованной машины из доверенной сети.
Т.е. фаервол в данном случае не панацея. Редхат в половине своих курсов не зря постоянно повторяет — не передавайте в чистом виде данные с логином/паролем по открытым сетям.
То что я использую, на самом деле логическое продолжение парадигмы об отключении лишних сервисов. Все что нужно админам или ограниченному кругу лиц не должно висеть на внешнем интерфейсе, а быть доступным только через ssh или vpn.
Я бы отметил, что перечисленное в разделах
«Ужесточение настроек системы» (кроме пункта 4) и «Бэкапы» применимо вообще к любой современной ОС, в независимости от ядра, лицензии или вероисповедания.
Раздел «Мониторинг» также прекрасно может быть адаптирован под конкретную ОС, нужно лишь найти функциональный аналог.
«Ужесточение настроек системы» (кроме пункта 4) и «Бэкапы» применимо вообще к любой современной ОС, в независимости от ядра, лицензии или вероисповедания.
Раздел «Мониторинг» также прекрасно может быть адаптирован под конкретную ОС, нужно лишь найти функциональный аналог.
я бы еще добавил прекрасном сервисе CSF
я бы еще добавил о прекрасном сервисе CSF
Sign up to leave a comment.
Надёжный и безопасный Linux (наш ответ Чемберлену)