Comments 15
Ну о какой безопасности можно говорить, если:
GRANT ALL ON foo.* TO bar@192.168.1.10 IDENTIFIED BY 'mypassword'
GRANT ALL ON foo.* TO bar@192.168.1.10 IDENTIFIED BY 'mypassword'
Вообще-то если уж на то пошло, то я бы сделал следующее:
1 — Перевесить Mysql на другой порт. При этом все, что ломиться на стандартный — в лог iptables.
2 — Права на БД — сразу минимальные. Потом поднимать в случае возникновения ошибок.
3 — Убрал бы вообще mysql с 127.0.0.1 — у меня на всех серверах стоит лог+дроп всего, что идет на localhost.
4 — Ну и да — саму базу я бы перенес на отдельный раздел(проще всего и удобнее всего — симлинком) + изменение имени пользователя.
1 — Перевесить Mysql на другой порт. При этом все, что ломиться на стандартный — в лог iptables.
2 — Права на БД — сразу минимальные. Потом поднимать в случае возникновения ошибок.
3 — Убрал бы вообще mysql с 127.0.0.1 — у меня на всех серверах стоит лог+дроп всего, что идет на localhost.
4 — Ну и да — саму базу я бы перенес на отдельный раздел(проще всего и удобнее всего — симлинком) + изменение имени пользователя.
Интересное замечание. Можно уточнить?
У нас БД висит на виртуалке 192.168.1.13/vm04,
доступ к ней есть у пользователя foo с трех машин:
В iptables забит доступ к машине с БД
1. В самих конфигах приложения (допустим установлен WPress) порт/логин/пароль будут фигурировать явным образом. Т.е. не понятно, от кого/чего мы защитимся, перевесив порты. Я вот пока не понимаю, зачем серверу статики доступ к БД, но это видимо станет ясно по ходу перевода. Ну или вернемся сюда позднее и внесем дополнительные примечания. Ваш коммент будет свидетелем. ;)
Логирование — предложение более чем интересное. Я бы добавил к ссылке в статье об iptables, предложенной авторами оригинального материала, свой перевод. Как вам? Замечания/предложения?
2. По поводу минимальных прав. Если пользователь foo — админ, то может быть пусть будут у него эти права? Он у нас удаленно может зайти только через phpMyAdmin на фронт/бэкэнд серверах апача и Nginx.
Можно внести это в примечание к статье и дать ссылку или перевод на доп.статьи о правах. Авторы оригинального перевода тупо отослали к доками MySQL. А на хабре по этой теме ничего нет, вроде бы. Или я не нашел. Может вы какой-то материал/ссылку на эту тему видели? Или из перечисленного что-то хотелось бы иметь в переводном виде?
www.greensql.com/articles/mysql-security-best-practices
dev.mysql.com/doc/mysql-security-excerpt/5.6/en/index.html
dev.mysql.com/doc/mysql-security-excerpt/5.6/en/topic-mysql-security-faq.html
3. Вы предлагаете запретить доступ к БД с сервера БД? Уточните, я не совсем понимаю.
4. Я так понял, вы предлагаете сделать так, как это описано в 7-м пункте приведенной чуть выше ссылки?
У нас БД висит на виртуалке 192.168.1.13/vm04,
доступ к ней есть у пользователя foo с трех машин:
192.168.1.13 - сам сервер БД
192.168.1.10 - LightHTTPD/Nginx под статику
192.168.1.11 - бэкенд Apache+php+...
В iptables забит доступ к машине с БД
-A INPUT -m state --state NEW -s 192.168.1.10 -m tcp -p tcp --dport 3306 -j ACCEPT
-A INPUT -m state --state NEW -s 192.168.1.11 -m tcp -p tcp --dport 3306 -j ACCEPT
1. В самих конфигах приложения (допустим установлен WPress) порт/логин/пароль будут фигурировать явным образом. Т.е. не понятно, от кого/чего мы защитимся, перевесив порты. Я вот пока не понимаю, зачем серверу статики доступ к БД, но это видимо станет ясно по ходу перевода. Ну или вернемся сюда позднее и внесем дополнительные примечания. Ваш коммент будет свидетелем. ;)
Логирование — предложение более чем интересное. Я бы добавил к ссылке в статье об iptables, предложенной авторами оригинального материала, свой перевод. Как вам? Замечания/предложения?
2. По поводу минимальных прав. Если пользователь foo — админ, то может быть пусть будут у него эти права? Он у нас удаленно может зайти только через phpMyAdmin на фронт/бэкэнд серверах апача и Nginx.
Можно внести это в примечание к статье и дать ссылку или перевод на доп.статьи о правах. Авторы оригинального перевода тупо отослали к доками MySQL. А на хабре по этой теме ничего нет, вроде бы. Или я не нашел. Может вы какой-то материал/ссылку на эту тему видели? Или из перечисленного что-то хотелось бы иметь в переводном виде?
www.greensql.com/articles/mysql-security-best-practices
dev.mysql.com/doc/mysql-security-excerpt/5.6/en/index.html
dev.mysql.com/doc/mysql-security-excerpt/5.6/en/topic-mysql-security-faq.html
3. Вы предлагаете запретить доступ к БД с сервера БД? Уточните, я не совсем понимаю.
4. Я так понял, вы предлагаете сделать так, как это описано в 7-м пункте приведенной чуть выше ссылки?
1 — Ну с одной стороны да — вроде бы перевешивание портов — дело крайне не обязательное, но в плане безопасности все просто:
В случае каких-то косяков — первым делом ломиться будут по стандартным портам. В купе с логированием трафика — очень просто отследить, кто и откуда ломиться посмотреть нашу базу(пару раз я вылавливал таких интересующихся в совершенно неожиданных местах).
2 — Тут тоже спорный вопрос по поводу прав — лично я видел довольно мало приложений, которым требуется дроп итд. Я предпочитаю забирать права на удаление, и отлавливать ошибки в логах — если есть ошибки и они по делу — тогда да — можно разрешить.(абсолютно аналогично я поступаю и с правами на файлы — давая минимальные права на группу, забирая право владения у пользователя).
3 — Немного не так — я просмотрел в статье, что настраивается биндинг на ip. Просто к этому я бы еще добавил лог на 127.0.0.1 на необходимый порт, тк правильная ситуация — когда подключение идет с внешнего Ip, а не через шелл на сервере :)
4 — Грубо говоря да. Тут еще довольно неосвещенный момент — обычно для баз, лично я использую отдельную хранилку, лун, раздел и прочее чтобы разделять I/O системы и базы.
P.S. Вообще спасибо за проявленный интерес — я думаю, если добавить вышеприведенные ссылки, ваш топик будет крайне содержателен и полезен.
В случае каких-то косяков — первым делом ломиться будут по стандартным портам. В купе с логированием трафика — очень просто отследить, кто и откуда ломиться посмотреть нашу базу(пару раз я вылавливал таких интересующихся в совершенно неожиданных местах).
2 — Тут тоже спорный вопрос по поводу прав — лично я видел довольно мало приложений, которым требуется дроп итд. Я предпочитаю забирать права на удаление, и отлавливать ошибки в логах — если есть ошибки и они по делу — тогда да — можно разрешить.(абсолютно аналогично я поступаю и с правами на файлы — давая минимальные права на группу, забирая право владения у пользователя).
3 — Немного не так — я просмотрел в статье, что настраивается биндинг на ip. Просто к этому я бы еще добавил лог на 127.0.0.1 на необходимый порт, тк правильная ситуация — когда подключение идет с внешнего Ip, а не через шелл на сервере :)
4 — Грубо говоря да. Тут еще довольно неосвещенный момент — обычно для баз, лично я использую отдельную хранилку, лун, раздел и прочее чтобы разделять I/O системы и базы.
P.S. Вообще спасибо за проявленный интерес — я думаю, если добавить вышеприведенные ссылки, ваш топик будет крайне содержателен и полезен.
1. Если не скомпрометирован сервер приложения, то маловероятно, что мы дадим ломиться на машину с БД человеку извне. Если наше приложение — «говно дыряво», то пиши-пропало, на каком бы оно порту не весело. Либо делать пользователя БД «SELECT-only» с репликацией из сторонней админской базы. Ну это вообще я от балды сейчас говорю, так как не вижу вариантов защиты.
2. Не представляю организации подобного в рамках классических open-source движков CMS. Или же это получится бредовариант из пункта №1 с зеркалированием «тайного сервера из бункера гитлера».
3. Интересное замечание. Надо думать, как это провернуть с «динамическими разработчиками».
4. Мне уже страшно подумать о том, какой оверхед и latency обретет такая система. А какие-то best-practics на эту тему есть почитать?
Вы только не прощайтесь, разговор-то какой получился положительный. ;) А то я уже на шизофреника стал похож, рассуждая сам с собой, как можно это все поломать и защитить. «Сам себе пентест». ))
Цитирую одного пользователя, очень он из интернета похож на приличного администратора, я потревожил его вопросом о качестве «построяемой» авторами туториала системы:
«В статье фигня какая то, ну скомпроментировал я ваш сервер с исходниками сайта и апачем, ну посмотрел я пароли к mysql и кешу, ну написал простой скрипт и сделал дамп все себе на почту, какой-то защиты я там не вижу.
Разделение на виртуальные машины хороший прием, так как позволяет распределять нагрузку, и более четко контролировать сервисы, а защитой от компрометации это не является, хотя и является шагом для её реализации. А вообще сложные пароли, хороший код, обновление по и защита по ip довольно хорошо защищают».
Первый шаг. Хорошо, что не «последнее дело». Значит нужно искать второй шаг. 8) Хорошим топиком считаю те, где есть хорошие комментарии. Так что затея уже удалась и спасибо за участие, 0Lexx0.
2. Не представляю организации подобного в рамках классических open-source движков CMS. Или же это получится бредовариант из пункта №1 с зеркалированием «тайного сервера из бункера гитлера».
3. Интересное замечание. Надо думать, как это провернуть с «динамическими разработчиками».
4. Мне уже страшно подумать о том, какой оверхед и latency обретет такая система. А какие-то best-practics на эту тему есть почитать?
Вы только не прощайтесь, разговор-то какой получился положительный. ;) А то я уже на шизофреника стал похож, рассуждая сам с собой, как можно это все поломать и защитить. «Сам себе пентест». ))
Цитирую одного пользователя, очень он из интернета похож на приличного администратора, я потревожил его вопросом о качестве «построяемой» авторами туториала системы:
«В статье фигня какая то, ну скомпроментировал я ваш сервер с исходниками сайта и апачем, ну посмотрел я пароли к mysql и кешу, ну написал простой скрипт и сделал дамп все себе на почту, какой-то защиты я там не вижу.
Разделение на виртуальные машины хороший прием, так как позволяет распределять нагрузку, и более четко контролировать сервисы, а защитой от компрометации это не является, хотя и является шагом для её реализации. А вообще сложные пароли, хороший код, обновление по и защита по ip довольно хорошо защищают».
Первый шаг. Хорошо, что не «последнее дело». Значит нужно искать второй шаг. 8) Хорошим топиком считаю те, где есть хорошие комментарии. Так что затея уже удалась и спасибо за участие, 0Lexx0.
1 — А вот это кстати довольно спорный момент — во время работы на одном белорусском сотовом операторе я был вынужден проводить аудит юниксовых серверов. Так вот был там один такой оракловый кластер, к которому кто-то снатил 22 порт. И в итоге раз в минуту туда шел коннект по ssh откуда-то из-за великого китайского файрволла. Я думаю, что никто не застрахован от такой ошибки.
Или же допустим внутри dmz была сломана машинка на которой крутился VHCS для каких-то там хостинговых целей — если бы не снорт, думаю можно было огрести реальных проблем.
2 — Из последнего — настраивал я с пол-года назад atlassian стек для одной конторы. Эти продукты использовали mysql. Ставил как было написано в мануале. После завершения инсталяции я там радостно ревоукнул половину прав(вот счас уже и не вспомню, что именно). Ругалась соотвественно только jira, а всякие fisheye, confluence и прочее — радостно продолжили работать. С одной стороны это все черевато проблемами и кучей потраченого времени на тюнинг, но с другой стороны — насколько приятнее на душе, когда ты знаешь, что у тебя все вылизано до предела.
По поводу лэтенси — сложно сказать для малых баз это может быть безразлично, но на нагруженых — это не так. В любом случае — база должна висеть на быстром диске(очень быстром :) )Навряд ли целесообразно заниматься страйпингом для /var что-то там. Опять же — если это nas, das или еще -то что внешнее — скорее всего есть возможность адаптивной оптимизации либо же снапшотов и прочих вкусностей, что также бывает очень полезно. (ну это уже совсем не безопасность).
А вообще — нет предела совершенству: Если есть время и есть деньги — виртуалки с разделением по сервисам + dmz с IDS или уже стразу IPS, но это уже совсем другая история, и такие телодвижения требуют значительно больших трудозатрат, чем перенос сервиса на другие порты.
Для меня было очень познавательным выкидывание виртуальной машинки со снортом в интернет с днс записью admin.xxx.com. Божымой — чего я там насмотрелся.
Или же допустим внутри dmz была сломана машинка на которой крутился VHCS для каких-то там хостинговых целей — если бы не снорт, думаю можно было огрести реальных проблем.
2 — Из последнего — настраивал я с пол-года назад atlassian стек для одной конторы. Эти продукты использовали mysql. Ставил как было написано в мануале. После завершения инсталяции я там радостно ревоукнул половину прав(вот счас уже и не вспомню, что именно). Ругалась соотвественно только jira, а всякие fisheye, confluence и прочее — радостно продолжили работать. С одной стороны это все черевато проблемами и кучей потраченого времени на тюнинг, но с другой стороны — насколько приятнее на душе, когда ты знаешь, что у тебя все вылизано до предела.
По поводу лэтенси — сложно сказать для малых баз это может быть безразлично, но на нагруженых — это не так. В любом случае — база должна висеть на быстром диске(очень быстром :) )Навряд ли целесообразно заниматься страйпингом для /var что-то там. Опять же — если это nas, das или еще -то что внешнее — скорее всего есть возможность адаптивной оптимизации либо же снапшотов и прочих вкусностей, что также бывает очень полезно. (ну это уже совсем не безопасность).
А вообще — нет предела совершенству: Если есть время и есть деньги — виртуалки с разделением по сервисам + dmz с IDS или уже стразу IPS, но это уже совсем другая история, и такие телодвижения требуют значительно больших трудозатрат, чем перенос сервиса на другие порты.
Для меня было очень познавательным выкидывание виртуальной машинки со снортом в интернет с днс записью admin.xxx.com. Божымой — чего я там насмотрелся.
Или перевести в конце всех частей следующие материалы:
www.symantec.com/connect/articles/securing-apache-step-step
www.symantec.com/connect/articles/securing-mysql-step-step
www.symantec.com/connect/articles/securing-php-step-step
www.symantec.com/connect/articles/securing-apache-step-step
www.symantec.com/connect/articles/securing-mysql-step-step
www.symantec.com/connect/articles/securing-php-step-step
И еще с хабры момент один прощелкан: ~/mysql_history и безопасность
Факультативно2: запретить сайту вылезти из своей папки
Буду кэпом… Зачем в iptables эти правила, если в конце нет правила с -j DROP?
Sign up to leave a comment.
Повышаем безопасность стека web-приложений (виртуализация LAMP, шаг 2/6)