Защита сайта и сервера

Добрый вечер
есть vps на дебиан 7 ,установлен lampp+ phpmyadmin + форум на xenforo
Кроме защиты админки ничего больше не делал
Хотелось бы узнать как лучше организовать защиту сайта и сервера
Что думаете насчет fail2ban, sftp и сервисах вроде cloudflare

 

1. Лучше использовать nginx+php5-fpm вместо апача и модуля php. Все ставится из репозиториев, поэтому проблем возникнуть не должно.
2. Я бы рекомендовал убрать phpmyadmin вообще. Вместо него лучше использовать dbForge Studio for MySQL (для винды, русский, бесплатный), который умеет работать через SSH.
3. При наличии SSH (а для VPS он все равно нужен) автоматически есть и SFTP.
4. Однозначно устанавливайте fail2ban. Он никак не помешает, но пресекает много атак.
5. Cloudflare к безопасности не имеет никакого отношения.

 

infis, Я так понимаю,что если я пропишу в настройках fail2ban доступ с одного айпи,то и sftp также будет доступный только с него?
Получается, если у меня статический айпи и я поставлю доступ в админку и fail2ban только для него,то единственной возможной уязвимостью останется сам движок?

 

Вы совсем не правильно понимаете, как работает fail2ban. Он отслеживает логи различных сервисов (демонов). Если в логах появляются критичные записи, то на основании этих записей fail2ban блокирует конкретный ip адрес (который в этих логах и фигурировал). Блокировка производится с помощью iptables.
Если Вам нужно обеспечить доступ к SSH (SFTP) с определенного IP адреса, то это элементарно делается через тот же iptables. Но вообще при желании спрятать SSH лучше перенести его на другой порт. Тогда Вы сохраните возможность подключить к Вашему серверу откуда бы то ни было, но при этом защититесь от атак через 22-й порт.
Уязвимости - это открытые порты наружу. Но для Linux это не так и страшно. В Вашем случае, если перенесете SSH на другой порт, останется торчать наружу только 80-й порт. Но без этого не обойдетесь, так как именно он и обеспечивает работу Вашего веб-сервера. Ну а взлом через движок - это уже удел движка, плагинов и кривых рук администратора.

 

infis, а если я заблокирую доступ с других айпи таким способом, sftp тоже будет доступен только с одного айпи?

 

SFTP - это просто передача файлов в рамках сессии SSH. Поэтому и настраивается не он, а демон SSH. Но я же дал Вам более правильное решение - смените порт сервиса. Тогда при изменении ip (а это может произойти неожиданно по разным причинам) Вы не окажетесь без доступа к консоли. Да и в этом случае можно хоть с телефона зайти в консоль.

Да, можно блокировать доступ способом по ссылке.

P.S. Кстати, fail2ban замечательно пресекает попытки подбора пароля по ssh.

 

infis, Спасибо, уже сменил порт
а порт разные бруты не подбирают?

 

Подобрать можно все, что угодно. Но надо понимать, что перебор портов - задача узконаправленная. Перебирать порты на всех серверах в общем будет глупостью. Это слишком долго. Для обычного "подбиральщика" паролей это не характерно. Поэтому, убрав ssh подальше, вероятность атаки через него будет мизерно мала.

 

обновляем дистрибутив до актуального состояния
аудит и настройка конфигов
ssh + рандомный порт + авторизация по ключам + тот же fail2ban
логи_куда_не_надо_лезть + cloudflare + api + fail2ban
Logwatch + отчеты на почту
Почтовик - только c 127.0.0.1
Не забываем iptables/pf/ipfw

phpmyadmin/supex dumper прячем, бекапы прячем, supex dumper делаем дамп базы + c rsync по ssh выносим в безопасное место.

 

Зачем? Чтобы создать проблемы, а затем их мужественно преодолевать? И не надо рассказывать, что это безопаснее. Это не безопаснее, так как в некоторых случаях оно может быть более опасно, а в некоторых - менее. При работе серверов друг с другом, безусловно, авторизация по ключам. А при работе с различных клиентов, не всегда есть возможность использовать авторизацию по ключам.
Объясню, чтобы было понятнее. У меня возникала несколько раз ситуация, когда сервер по тем или иным причинам не был мне доступен напрямую. Включая и то, что у меня не было даже прямого доступа к интернету. В этом случае элементарно можно использовать доступные серверы через ssh, по которым по цепочке можно выйти в интернет, а затем и попасть на нужный сервер. Более того, можно использовать ssh и таких устройств, как роутер mikrotik, например. Я через цепочку из трех штук и через два сервера так добирался до нужного сервера. А, если бы авторизация была по ключам? Да было бы легче застрелиться, а то и вообще фиг бы попал.
Также авторизация по ключам не всегда поддерживается клиентским ПО.
В общем авторизация по ключам - это довольно спорно.

А это зачем?

Phpmyadmin вообще сносим и не пользуемся.
Sypex Dumper лучше всего просто иметь под рукой и в нужный момент элементарно скопировать на сайт, либо мягкой ссылкой. Но держать его постоянно доступным не надо. Он нужен очень редко, вплоть до никогда. Если есть консоль, то проще через консоль и дамп снять и базу восстановить.
Бэкапы замечательно делаются backupninja. Начиная от бэкапов базы данных, инкрементальных бэкапов файлов и заканчивая синхронизацией с AWS S3.

 

infis, а через SSH разве есть проблемы с импортом/експортом баз?

 

Доступ к консоли через SSH. Поэтому я и указал на то, что проще через консоль делать экспорт/импорт.

 

Отсечь минимально трафик нежелательных ботов? Плюсом очень удобный DNS, с кучей дополнительных примочек вроде бесплатного SSL.

 

А... Понятно. Но мне это совсем не интересно. Ибо оно не в России. Это раз. Во-вторых, из-за одного идиота можно запросто лишиться на территории России доступности сервиса (Роскомнадзор не дремлет). Ну и в третьих, оно увеличит пинг моих клиентов раза в два, что совсем будет глупо.

P.S. Вообще Cloudflare, если ресурс предназначен для пользователей, находящихся на территории России, не очень подходит в основном как раз из-за удаленности их датацентров от наших пользователей. Ну и угроза бана из-за одного пользователя тоже сводит на нет удобства сервиса.

 

Почему, кстати? Чем авторизация по паролю отличается от авторизации по ключу в этом смысле? Для putty, мне кажется, что ключ, что пароль - один фиг. Сделать туннель до любого сервера, а потом через этот туннель подключиться к другому - тоже вроде несложно. Что с ключом, что с паролем.

 

Потому что ключ необходимо было иметь. У меня его на тот момент не было под рукой. Я был достаточно далеко и физически и виртуально. Машина, к котором потребовался срочный доступ, находилась внутри локальной сети, к которой у меня был доступ только через промежуточные узлы. Все узлы также были внутри локальных сетей. Извне доступ накрылся, вот и пришлось скакать через обходной вариант.
И еще. Не все мобильные клиенты поддерживают авторизацию по ключу. И тоже пару раз понадобилось со смарта лезть.

Если пароль адекватен, то он ничем не хуже авторизации по ключам. Более того, если злоумышленник получит доступ к машине с ключами, то он автоматически получит доступ ко всем хостам с этими ключами. При парольной защите компрометация одного сервера не приводит к компрометации остальных. Парольная защита позволяет подключаться с любого клиента.

 

Понимаю. Однако я все же остаюсь сторонником авторизации по ключам. Для меня это проще и удобнее. Особенно с большим количеством серверов под контролем.