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, не помню.
А вот ключи — очень удобная фича. Как раз стоит вообще отключить доступ по паролю, а разрешить только ключи. И можно не бояться брутфорсов.
+8
Я не предлагаю переносить например 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
+8
для ssh есть bruteblock и fail2ban
+3
Ага, знаю. Да и Snort я думаю умеет реагировать на брутфорсы.
Я намеренно не стал описывать применение конкретных решений — не хотел сильно увеличивать статью.
Я намеренно не стал описывать применение конкретных решений — не хотел сильно увеличивать статью.
+2
можно через 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 в течении какого временного промежутка
+1
Я имел ввиду, что смена портов — это высокоспецифичный трюк. А вы, вместо списка тех нескольких сервисов, для которых это имеет смысл, привели в пример ssh, для которого его полезность сомнительна. К тому же, все эти несколько сервисов наверняка правильнее закрыть файерволлом, чем перевешивать на другие порты.
Этот трюк годится для OpenVPN. А больше я что-то и не могу сходу придумать примеров.
Этот трюк годится для OpenVPN. А больше я что-то и не могу сходу придумать примеров.
-1
Файрволом, к сожалению, не всегда возможно, хотя это конечно лучшее решение. Часто у пользователей динамические ip адреса, а прописывать в файрволе /10 диапазоны их провайдеров нет никакого смысла.
А так, да для этого и нужны комментарии — для исправления и уточнения статьи.
А так, да для этого и нужны комментарии — для исправления и уточнения статьи.
0
Прописать /10 или /16 это лучше чем для всего инета доступ открывать.
0
Для меня почти нет разницы если честно.
Лучше уж vpn настроить для доступа к критичному сервису, если у его пользователей нет статичных ip адресов.
Лучше уж vpn настроить для доступа к критичному сервису, если у его пользователей нет статичных ip адресов.
0
Я обычно vpn не ставлю, а обучаю юзеров делать port forwarding через ssh, чтобы работать с сервисами внутренней сети. При большом количестве сервисов и т.п. — однозначно vpn, но пока только один случай был, когда ssh не хватило.
У меня принцип — меньше служб, выше безопасность. Т.е. там где возможно, как минимум вместо vpn и ftp используется ssh.
У меня принцип — меньше служб, выше безопасность. Т.е. там где возможно, как минимум вместо vpn и ftp используется ssh.
0
я вот недавно зафаерволил SMB/CIFS на одном сервачке на /64 :)
0
Порты полезно менять, если наш провайдер по дефолту блочит 22 порт. Это отголоски того самого бага в SSHv1. Плюс у нескольких хостеров встречал, что ssh открывается только для определенных адресов. Я предпочитаю делать это сам, поэтому перевешиваю ssh.
Плюс на всех серверах обычно ssh смотрит только в межсерверную сеть, либо доступ к порту ssh открыт только с наших серверов, если нет межсерверной сети. Плюс отдельная машинка, возможно виртуальная, на которой кроме ssh вообще ничего нет. Т.е. с нее либо транзитом на остальные сервера прыгаем, либо делаем проброс портов через ssh-тоннель. Ну и по ситуации — если провайдеры админов дают статические адреса, то открываем доступ только с адресов с админов, если нет то только с сетей провайдеров админов, и навешиваем дополнительную защиту типа fail2ban или стука по портам, прежде чем нам откроется порт ssh.
Плюс на всех серверах обычно ssh смотрит только в межсерверную сеть, либо доступ к порту ssh открыт только с наших серверов, если нет межсерверной сети. Плюс отдельная машинка, возможно виртуальная, на которой кроме ssh вообще ничего нет. Т.е. с нее либо транзитом на остальные сервера прыгаем, либо делаем проброс портов через ssh-тоннель. Ну и по ситуации — если провайдеры админов дают статические адреса, то открываем доступ только с адресов с админов, если нет то только с сетей провайдеров админов, и навешиваем дополнительную защиту типа fail2ban или стука по портам, прежде чем нам откроется порт ssh.
0
Еще есть port knocking. На мой взгляд лучше, чем менять порты.
0
Забыл ответить по ключам.
Ключи очень удобная вещь, согласен, сам ими пользуюсь чтобы не вводить каждый раз пароли, но с тем, что они повышают защищённость я бы не согласился.
Просто меняется точка уязвимости, до этого это был пароль, теперь стал файл с ключом.
Также остаётся открытым вопрос — что делать в случае утери ключа? Как зайти на сервер, чтобы заменить ключ на новый?
Ключи очень удобная вещь, согласен, сам ими пользуюсь чтобы не вводить каждый раз пароли, но с тем, что они повышают защищённость я бы не согласился.
Просто меняется точка уязвимости, до этого это был пароль, теперь стал файл с ключом.
Также остаётся открытым вопрос — что делать в случае утери ключа? Как зайти на сервер, чтобы заменить ключ на новый?
0
Ключи безопасность однозначно повышают. Сравните: при брутфорсе будут подбирать ~20 символов пароля, по ~4 бита энтропии каждый, или же 1024 или 2048 бит закрытого ключа?
Кроме того, пока что я не видел, чтобы по ключам брутфорсили. А по паролям — только так.
Файлик не так-то просто стырить. Кроме того, он шифруется с парольной фразой. Т.е. на худой конец, даже если пароль стырили, не сразу расшифруют, и ещё надо понять, от чего он.
А про потерю — встречный вопрос: что вы будете делать, если забыли пароль?
Кроме того, пока что я не видел, чтобы по ключам брутфорсили. А по паролям — только так.
Файлик не так-то просто стырить. Кроме того, он шифруется с парольной фразой. Т.е. на худой конец, даже если пароль стырили, не сразу расшифруют, и ещё надо понять, от чего он.
А про потерю — встречный вопрос: что вы будете делать, если забыли пароль?
+4
смена пароля — физический доступ или IP KVM
+1
1) для взлома ключа вам нужен будет [файл ключа] + [пароль от него]
2) Повышает безопасность необходимостью подбора более длинного ключа в отличии от пароля, защищает от совпадений md5
3) Позволяет ввести пароль только один раз
4) Позволяет Agent Forwarding для доступа далее — можно лазить через цепочку ssh, при этом ключ будет только у вас на машине.
5) Позволяет отключить авторизацию по паролю.
Что делать в случае утери ключа? То же самое, что в случае забывания пароля.
— примонтировать диск и заменить ~/.ssh/authorized_keys нужным
— зайти по паролю через физическую консоль
— иметь запасной ключ (можно на одну учетку ведь и несколько ключей повесить)
— свой вариант решения проблемы
2) Повышает безопасность необходимостью подбора более длинного ключа в отличии от пароля, защищает от совпадений md5
3) Позволяет ввести пароль только один раз
4) Позволяет Agent Forwarding для доступа далее — можно лазить через цепочку ssh, при этом ключ будет только у вас на машине.
5) Позволяет отключить авторизацию по паролю.
Что делать в случае утери ключа? То же самое, что в случае забывания пароля.
— примонтировать диск и заменить ~/.ssh/authorized_keys нужным
— зайти по паролю через физическую консоль
— иметь запасной ключ (можно на одну учетку ведь и несколько ключей повесить)
— свой вариант решения проблемы
+8
Перенос ssh на другой порт отсеивает в первую очередь ботов. Так же, как и грейлист на smtp отсеивает в первую очередь завирусованные винды. К счастью, тупых ботов намного больше, чем целенаправленных попыток проникновения, поэтому один только перенос уже значительно улучшает ситуацию.
Например, я у себя держу ssh на стандартном порту на интерфейсах, смотрящих в локальную сеть и на нестандартном на внешних, смотрящих в интернеты.
Например, я у себя держу ssh на стандартном порту на интерфейсах, смотрящих в локальную сеть и на нестандартном на внешних, смотрящих в интернеты.
0
IMHO отключение рута (если был) и настройка входа только по ключу — первые действия после установки sshd. Тот, кто это пройдёт, и порты просканировать не поленится.
Нестандартный порт для часто используемого хоста стоит в .ssh/config указать, там его и scp подберёт.
Нестандартный порт для часто используемого хоста стоит в .ssh/config указать, там его и scp подберёт.
0
Уже обсуждалост в комментах к одному из топиков. Какая разница — пароль юзера 8 символов и 8 символов пароль рута или пароль только на рута, но 16 символов? Это при использовании паролей. При использовании ключей все равно админы любят sudo без паролей делать — толку в таком случае рута закрывать?
0
~/.ssh/config
0
На тему не стандартного порта SSH. поможет файл конфига в домашнем каталоге.
scp,svn, и так далее все будут ходить по определенному порту
~/.ssh/config
Host xxx.com
Port xx
scp,svn, и так далее все будут ходить по определенному порту
~/.ssh/config
Host xxx.com
Port xx
0
> Маны и гугл никто не отменял
Вот это коварно может быть. Бывало, и не раз на дебиан (и не только):
Проблема: %software% не полностью решает задачу X.
Правильное решение: apt-get install %software%-чегототам
Решение любезно подсунутое гуглом: выкачать, пропатчить и собрать %software%
На старой работе админ так с php развлекался.
Вот это коварно может быть. Бывало, и не раз на дебиан (и не только):
Проблема: %software% не полностью решает задачу X.
Правильное решение: apt-get install %software%-чегототам
Решение любезно подсунутое гуглом: выкачать, пропатчить и собрать %software%
На старой работе админ так с php развлекался.
0
Конкретно по дебиану много различных копи-пейст ресурсов, на том же www.howtoforge.com/ много примеров на базе дебиан. И большинство из них без компиляции.
Вообще не очень люблю собирать из исходников, прибегаю к этому в самом крайнем случае.
Как минимум потом придется подписываться на security рассылку скомпилированного софта и мониторить наличие в нём уязвимостей (что в стандартном случае делает debian security team).
Плюс теряется связность скомпилированного ПО с остальным системным софтом и можно случайно нарушить его работу, удалив казалось бы ненужный пакет (такого у меня пока не было, но думаю опасность вполне реальная).
Ещё минус — для сборки придется ставить много -dev пакетов, которые в обычной системе совсем не нужны.
Вообще не очень люблю собирать из исходников, прибегаю к этому в самом крайнем случае.
Как минимум потом придется подписываться на security рассылку скомпилированного софта и мониторить наличие в нём уязвимостей (что в стандартном случае делает debian security team).
Плюс теряется связность скомпилированного ПО с остальным системным софтом и можно случайно нарушить его работу, удалив казалось бы ненужный пакет (такого у меня пока не было, но думаю опасность вполне реальная).
Ещё минус — для сборки придется ставить много -dev пакетов, которые в обычной системе совсем не нужны.
+1
Сборка чего не надо — это лишь один частный случай из многих.
Каждый 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%»
Впрочем, сам я даже не начинающий админ, просто мимо пробегал. Но на форумах много раз видел, как новичкам любезно подкладывают грабли (из лучших побуждений!)
+1
UFO just landed and posted this here
Меня очень и очень задолбали люди, которые первым советом при настройке CentOS пишут «Отключите SELinux...» вместо нормальной настройки под их изменения.
При этом найти информации по SELinux очень сложно. Методом проб и ребутов его приходится точить под изменения :)
При этом найти информации по SELinux очень сложно. Методом проб и ребутов его приходится точить под изменения :)
0
Вот полезные ссылки из статьи в моей 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
+4
Мне не нравится статья. В ней, как я понимаю, речь идет о защите серверного Линукса.
Во-первых, нигде не рассказано про то, как изолировать потенциально опасные сервисы вроде веб-сервера с большим количеством сайтов, или демона Samba от системы, таким образом, что даже при уязвимости в одном из приложений, злоумыленник не сможет запустить свой код, нарушить работут системы, а также других веб-приложений.
Во-вторых, что касается SELinux — как я понимаю, вещь в теории мощная, но в реальности конфиги к нему устанешь писать быстро.
В-третьих, непонятно, зачем отключать прием/отправку и форвардинг пакетов. Если у вас один сетевой интерфейс, никаого форвардинга не будет, а отключив прием/отправку пакетов, вы во-первых, сломаете все сервисы, во-вторых, нельзя будет скачивать обновления и устанавливать пакеты. Конечно, можно прописать разрешительные правила, но зачем запрещать чтобы снова потом разрешить? Я не понимаю. Вы видимо тоже.
В-четвертых, изменение порта на котором слушает сервис, не обманет даже популярный nmap — e всех сервисов есть характерные сигнатуры. Разве что это спасет от тупых скриптов, которые брутят пароли на 22 порту у всех машин подряд.
В-пятых, пара строчек про HIDS и NIDS несет нулевую ценность. Никто конечно конфиг выложить не просит, но рассказали бы хоть в общих словах.как их настраивать.
И про бекап MySQL, опять же, вы не написали даже каковы подводные камни установки слейва на той же машине.
В общем, статья не содержит никаких конкретных рекомендаций. То, что бекапы надо делать и лишние сервисы отключить, это и так всем понятно.
Во-первых, нигде не рассказано про то, как изолировать потенциально опасные сервисы вроде веб-сервера с большим количеством сайтов, или демона Samba от системы, таким образом, что даже при уязвимости в одном из приложений, злоумыленник не сможет запустить свой код, нарушить работут системы, а также других веб-приложений.
Во-вторых, что касается SELinux — как я понимаю, вещь в теории мощная, но в реальности конфиги к нему устанешь писать быстро.
В-третьих, непонятно, зачем отключать прием/отправку и форвардинг пакетов. Если у вас один сетевой интерфейс, никаого форвардинга не будет, а отключив прием/отправку пакетов, вы во-первых, сломаете все сервисы, во-вторых, нельзя будет скачивать обновления и устанавливать пакеты. Конечно, можно прописать разрешительные правила, но зачем запрещать чтобы снова потом разрешить? Я не понимаю. Вы видимо тоже.
В-четвертых, изменение порта на котором слушает сервис, не обманет даже популярный nmap — e всех сервисов есть характерные сигнатуры. Разве что это спасет от тупых скриптов, которые брутят пароли на 22 порту у всех машин подряд.
В-пятых, пара строчек про HIDS и NIDS несет нулевую ценность. Никто конечно конфиг выложить не просит, но рассказали бы хоть в общих словах.как их настраивать.
И про бекап MySQL, опять же, вы не написали даже каковы подводные камни установки слейва на той же машине.
В общем, статья не содержит никаких конкретных рекомендаций. То, что бекапы надо делать и лишние сервисы отключить, это и так всем понятно.
-1
Во-1х, статья идёт об усилении простого сервера, подъём jail/vserver это второй уровень защиты.
Во-2х, для SELinux конфиги обычно не руками пишут, а корректируют автогенерённый в процессе 100% чистого запуска в тест режиме.
В-3их, список разрешенных портов гораздо уже, чем запрещенных, и открыть только нужные дырки обнаружив что что-то не работает (причем еще в процессе настройки!) проще, чем потом обнаружить, что у тебя что-то вскрыли.
В-4ых, изменение порта делается не для обмана, а именно для выхода из-под «масс-хак» атак, что снизит вероятность появления очередного ботнета на сайте из-за дырявого сервиса до момента обновления; а не против «персональной» атаки.
В-5ых, самые умные будут грузить чугуний.
Во-2х, для SELinux конфиги обычно не руками пишут, а корректируют автогенерённый в процессе 100% чистого запуска в тест режиме.
В-3их, список разрешенных портов гораздо уже, чем запрещенных, и открыть только нужные дырки обнаружив что что-то не работает (причем еще в процессе настройки!) проще, чем потом обнаружить, что у тебя что-то вскрыли.
В-4ых, изменение порта делается не для обмана, а именно для выхода из-под «масс-хак» атак, что снизит вероятность появления очередного ботнета на сайте из-за дырявого сервиса до момента обновления; а не против «персональной» атаки.
В-5ых, самые умные будут грузить чугуний.
+1
Начну отвечать с конца.
Смотря что поднимать под конкретными рекомендациями.
Если вы о примерах конфигурации, то об этом я предупредил в самом начале статьи.
Я уверен, что это понятно не всем. Статья больше ориентирована на начинающих администраторов, цель была предоставить некий checklist по настройке сервера и подсказать направления для дальнейшего развития.
Это да, конфигурировать его дело муторное, но делать это надо один раз и на одном сервере, а потом можно просто копировать скомпилированные модули с исключениями на остальные сервера.
Бэкапы принято выносить за пределы основной площадки в целях обеспечения их доступности при крупной аварии на этой (основной) площадке.
Или вы о каких-то ещё подводных камнях? Возможно я о них и не знаю или забыл написать.
Да, вы правы. Про chroot я совсем забыл.
Хотя в последнее время я предпочитаю выносить такого рода сервисы в виртуальные машины на базе xen.
Так что моя рекомендация — chroot и/или xen, смотря по обстоятельствам.
При политике файрвола по умолчанию ACCEPT администратору придётся явно запрещать весь нежелательный трафик.
Это приведёт к большому количеству правил, а соответственно к усложнению системы и замедлению её работы.
Гораздо проще запретить все пакеты и разрешить лишь нужные.
Никакие сервисы не поломаются если следовать описанному мной алгоритму с логгированием пакетов. Вот кстати нашел у себя недочет, забыл написать в этом алгоритме о том, что политику DROP надо включать в самом конце, когда в сислоге уже нет записей. Сейчас исправлю.
в общем, статья не содержит никаких конкретных рекомендаций
Смотря что поднимать под конкретными рекомендациями.
Если вы о примерах конфигурации, то об этом я предупредил в самом начале статьи.
То, что бекапы надо делать и лишние сервисы отключить, это и так всем понятно
Я уверен, что это понятно не всем. Статья больше ориентирована на начинающих администраторов, цель была предоставить некий checklist по настройке сервера и подсказать направления для дальнейшего развития.
что касается SELinux — как я понимаю, вещь в теории мощная, но в реальности конфиги к нему устанешь писать быстро.
Это да, конфигурировать его дело муторное, но делать это надо один раз и на одном сервере, а потом можно просто копировать скомпилированные модули с исключениями на остальные сервера.
И про бекап MySQL, опять же, вы не написали даже каковы подводные камни установки слейва на той же машине.
Бэкапы принято выносить за пределы основной площадки в целях обеспечения их доступности при крупной аварии на этой (основной) площадке.
Или вы о каких-то ещё подводных камнях? Возможно я о них и не знаю или забыл написать.
Во-первых, нигде не рассказано про то, как изолировать потенциально опасные сервисы вроде веб-сервера с большим количеством сайтов, или демона Samba от системы
Да, вы правы. Про chroot я совсем забыл.
Хотя в последнее время я предпочитаю выносить такого рода сервисы в виртуальные машины на базе xen.
Так что моя рекомендация — chroot и/или xen, смотря по обстоятельствам.
В-третьих, непонятно, зачем отключать прием/отправку и форвардинг пакетов. Если у вас один сетевой интерфейс, никаого форвардинга не будет, а отключив прием/отправку пакетов, вы во-первых, сломаете все сервисы, во-вторых, нельзя будет скачивать обновления и устанавливать пакеты. Конечно, можно прописать разрешительные правила, но зачем запрещать чтобы снова потом разрешить?
При политике файрвола по умолчанию ACCEPT администратору придётся явно запрещать весь нежелательный трафик.
Это приведёт к большому количеству правил, а соответственно к усложнению системы и замедлению её работы.
Гораздо проще запретить все пакеты и разрешить лишь нужные.
Никакие сервисы не поломаются если следовать описанному мной алгоритму с логгированием пакетов. Вот кстати нашел у себя недочет, забыл написать в этом алгоритме о том, что политику DROP надо включать в самом конце, когда в сислоге уже нет записей. Сейчас исправлю.
0
>При политике файрвола по умолчанию ACCEPT администратору придётся явно запрещать весь нежелательный трафик.
>Это приведёт к большому количеству правил, а соответственно к усложнению системы и замедлению её работы.
>Гораздо проще запретить все пакеты и разрешить лишь нужные.
Про полный запрет инпута опять же упоминалось в комментах прошлой статьи. Для апдейтов будете по ip-адресам апдейт-серверов разрешать или по порту все-таки откроете? Проще сделать разрешение на прием ответов для соединений, которые мы же сами и инициировали.
>Это приведёт к большому количеству правил, а соответственно к усложнению системы и замедлению её работы.
>Гораздо проще запретить все пакеты и разрешить лишь нужные.
Про полный запрет инпута опять же упоминалось в комментах прошлой статьи. Для апдейтов будете по ip-адресам апдейт-серверов разрешать или по порту все-таки откроете? Проще сделать разрешение на прием ответов для соединений, которые мы же сами и инициировали.
0
> Это да, конфигурировать его дело муторное, но делать это надо один раз и на одном сервере, а потом можно просто копировать скомпилированные модули с исключениями на остальные сервера.
А потом какой-нибудь сервис обновится, или поменяется имя конфига, или веб-приложению надо будет файлы куда-нибудь сохранять или место хранения каких-то временных файлов поменяется, и опять все переконфигурировать… да и можно с дури ssh сломать неудачной конфигурацией. По моему, тут возни больше.
> Да, вы правы. Про chroot я совсем забыл.
Ну тогда скорее Xen (что, видимо, дорого в плане нагрузки) или Vserver, так как chroot в Линукс никогда не предназначался для повышения безопасности, а только для смены корневого каталога, о чем в его мануале и написано.
И по поводу фаерволла — вам поднадобится что-то wget скачать, вы отдельное правило напишете? Или зафаерволлите какой-нибудь ftp, он не сможет посылать ДНС запросы, будет необъяснимо тормозить в случайные моменты времени, и т.д. По моему, проще ограничиться минимумом служб, чем тратить дополнительно время на настройку и перенастройку фаерволла. Отключить службу выгоднее чем зафаерволлить.
Единственное полезное (по моему) применение iptables — бывает, когда надо ограничить доступ к службе например только той же подсетью, но и тут лучше какую-нибудь авторизацию предусмотреть, чем менять конфиги фаерволла на десятках машин при изменении конфигурации, или добавлении серверов, разве нет? И мучаться, при отладке, когда разработчики к этой же службе не смогут подключиться из-за фаерволла.
А исходящие соединения фаерволлить по моему больше проблем вызывает, чем пользы. Ну может, конечно, я и ошибаюсь.
А потом какой-нибудь сервис обновится, или поменяется имя конфига, или веб-приложению надо будет файлы куда-нибудь сохранять или место хранения каких-то временных файлов поменяется, и опять все переконфигурировать… да и можно с дури ssh сломать неудачной конфигурацией. По моему, тут возни больше.
> Да, вы правы. Про chroot я совсем забыл.
Ну тогда скорее Xen (что, видимо, дорого в плане нагрузки) или Vserver, так как chroot в Линукс никогда не предназначался для повышения безопасности, а только для смены корневого каталога, о чем в его мануале и написано.
И по поводу фаерволла — вам поднадобится что-то wget скачать, вы отдельное правило напишете? Или зафаерволлите какой-нибудь ftp, он не сможет посылать ДНС запросы, будет необъяснимо тормозить в случайные моменты времени, и т.д. По моему, проще ограничиться минимумом служб, чем тратить дополнительно время на настройку и перенастройку фаерволла. Отключить службу выгоднее чем зафаерволлить.
Единственное полезное (по моему) применение iptables — бывает, когда надо ограничить доступ к службе например только той же подсетью, но и тут лучше какую-нибудь авторизацию предусмотреть, чем менять конфиги фаерволла на десятках машин при изменении конфигурации, или добавлении серверов, разве нет? И мучаться, при отладке, когда разработчики к этой же службе не смогут подключиться из-за фаерволла.
А исходящие соединения фаерволлить по моему больше проблем вызывает, чем пользы. Ну может, конечно, я и ошибаюсь.
0
А потом какой-нибудь сервис обновится, или поменяется имя конфига, или веб-приложению надо будет файлы куда-нибудь сохранять или место хранения каких-то временных файлов поменяется, и опять все переконфигурировать… да и можно с дури ssh сломать неудачной конфигурацией. По моему, тут возни больше.
Возни немало, но у нас и цель достойная.
Что касается изменений — само по себе ничего не меняется, всё происходит в результате действий администратора. Просто необходимо взять за правило при любых изменениях на сервере не забывать про соответствующие изменения в его системе безопасности. И всё это документировать.
И по поводу фаерволла — вам поднадобится что-то wget скачать, вы отдельное правило напишете?
Если это разовая необходимость, просто временно сделаю ACCEPT в цепочке FORWARD для нужного сервера. Если скачивание будет периодичным, то да, напишу новое правило.
Или зафаерволлите какой-нибудь ftp, он не сможет посылать ДНС запросы, будет необъяснимо тормозить в случайные моменты времени, и т.д.
Необходимо хоть немного представлять себе структуру сети, в которой настраиваешь файрвол, тогда таких сюрпризов будет меньше.
Кроме того я добавил к пункту про iptables дополнение, о котором просто забыл написать сразу — политику DROP надо включать после полной отладки файрвола и исчезновения записей в сислоге.
0
Что касается 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
Ну и собственно для начала более чем достаточно. По крайней мере при взломе апача по серверу уже свободно не погуляют :)
+1
Полиси iptables по дефолту в DROP не стоит ставить. В прошлом топике обсуждали почему. Лучше оттуда примеры скопируйте, т.е. REJECT с корректным отлупом.
0
Я считаю DROP более безопасным. Незачем давать злоумышленнику лишние данные.
0
Какие интересно лишние данные? В случае с корректным REJECT мы по всем портам — открытым или не открытым даем одинаковый отлуп, т.е. определить есть ли служба сканер не сможет, если он не находится в списке разрешенных хостов. А вот головную боль нормальным юзерам обеспечим, особенно с наличием нестандартных портов. Ошибся портом — и сиди жди тайм-аута.
0
Освежив теорию соглашусь с вами, наиболее идеологически правильный вариант это политика ACCEPT по умолчанию + последнее правило в цепочке -j REJECT
Единственное возражение по вашему комменту в предыдущем топике — я думаю, что независимо от протокола нужно отвечать с port-unreachable (что кстати является ответом по умолчанию для REJECT если не указывать дополнительные ключи) т.к при реальной попытке подключения к неиспользуемому порту удалённый хост получит именно такое сообщение. Если отвечать с tcp-reset, злоумышленнику станет ясно, что порт защищён файрволом, а наша цель — выдать минимум информации о нашей системе.
Единственное возражение по вашему комменту в предыдущем топике — я думаю, что независимо от протокола нужно отвечать с port-unreachable (что кстати является ответом по умолчанию для REJECT если не указывать дополнительные ключи) т.к при реальной попытке подключения к неиспользуемому порту удалённый хост получит именно такое сообщение. Если отвечать с tcp-reset, злоумышленнику станет ясно, что порт защищён файрволом, а наша цель — выдать минимум информации о нашей системе.
+1
Плюс я бы еще добавил в статью:
Все службы, которые нужны только для администрирования, вешаем на 127.0.0.1 и ходим на них через ssh port-forwarding. Плюс также можно перевесить скрипты для администрирования на вторую копию апача, которая также на localhost слушает и работать с ним аналогично.
Все службы, которые нужны только для администрирования, вешаем на 127.0.0.1 и ходим на них через ssh port-forwarding. Плюс также можно перевесить скрипты для администрирования на вторую копию апача, которая также на localhost слушает и работать с ним аналогично.
0
Ну не знаю, мне кажется это уже излишнее усложнение.
Либо привязка по ip (т.е firewall) либо впн для себя любимого.
Но в этом вопросе думаю все очень индивидуально, и ваш и мой варианты вполне безопасны.
Либо привязка по ip (т.е firewall) либо впн для себя любимого.
Но в этом вопросе думаю все очень индивидуально, и ваш и мой варианты вполне безопасны.
0
Согласен, но ssh все же немного безопаснее. Типичный сценарий:
1. Админ с разрешенного адреса заливает файлы по фтп или пользуется другой службой без шифрования трафика.
2. Трафик идет по открытой сети. Сосед или комп жены/ребенка ловит вирусню, которая начинает шмалять пакеты в сеть о том, что мак шлюза изменился на мак вирусованного компа. Все — пароль уплыл.
Либо по дороге стоит машина со снифером.
3. Хакер с утянутым паролем заходит на общедоступную службу нашего сервака и читает почту админа, или еще как-нибудь пакостит.
Ну и опять же возможен случай, когда хакер зайдет на сервер с вирусованной машины из доверенной сети.
Т.е. фаервол в данном случае не панацея. Редхат в половине своих курсов не зря постоянно повторяет — не передавайте в чистом виде данные с логином/паролем по открытым сетям.
То что я использую, на самом деле логическое продолжение парадигмы об отключении лишних сервисов. Все что нужно админам или ограниченному кругу лиц не должно висеть на внешнем интерфейсе, а быть доступным только через ssh или vpn.
1. Админ с разрешенного адреса заливает файлы по фтп или пользуется другой службой без шифрования трафика.
2. Трафик идет по открытой сети. Сосед или комп жены/ребенка ловит вирусню, которая начинает шмалять пакеты в сеть о том, что мак шлюза изменился на мак вирусованного компа. Все — пароль уплыл.
Либо по дороге стоит машина со снифером.
3. Хакер с утянутым паролем заходит на общедоступную службу нашего сервака и читает почту админа, или еще как-нибудь пакостит.
Ну и опять же возможен случай, когда хакер зайдет на сервер с вирусованной машины из доверенной сети.
Т.е. фаервол в данном случае не панацея. Редхат в половине своих курсов не зря постоянно повторяет — не передавайте в чистом виде данные с логином/паролем по открытым сетям.
То что я использую, на самом деле логическое продолжение парадигмы об отключении лишних сервисов. Все что нужно админам или ограниченному кругу лиц не должно висеть на внешнем интерфейсе, а быть доступным только через ssh или vpn.
+1
Я бы отметил, что перечисленное в разделах
«Ужесточение настроек системы» (кроме пункта 4) и «Бэкапы» применимо вообще к любой современной ОС, в независимости от ядра, лицензии или вероисповедания.
Раздел «Мониторинг» также прекрасно может быть адаптирован под конкретную ОС, нужно лишь найти функциональный аналог.
«Ужесточение настроек системы» (кроме пункта 4) и «Бэкапы» применимо вообще к любой современной ОС, в независимости от ядра, лицензии или вероисповедания.
Раздел «Мониторинг» также прекрасно может быть адаптирован под конкретную ОС, нужно лишь найти функциональный аналог.
0
я бы еще добавил прекрасном сервисе CSF
0
я бы еще добавил о прекрасном сервисе CSF
0
Sign up to leave a comment.
Надёжный и безопасный Linux (наш ответ Чемберлену)