Какие лучшие практики настройки SSH для вебсервера?
Доброго дня!
Задался вопросом, как лучше настроить доступы SSH на сервере.
Имеется Debian 8 / EasyEngine (весь Web-стек [nginx, php, mariadb, redis] работает от имени .юзера www-data)
Есть root на debian сервере, но использовать его каждый раз не хочется по понятным причинам. Сейчас настроен доступ по открытому ключу.
Основной вопрос что делать с юзером www-data? Т/к это вебсервер понятно что нужно иногда заходить по SFTP и заливать/изменять данные. От root это делать также не удобно т/к перевыставляются права и скрипты не работают, картинки не грузятся. До этого у меня был сервер с настроенным chroot (каждый сайт имел своего юзера от которого и требовалось заходить - никаких проблем с безопасностью и изменением прав файлов). Теперь непонятно как быть - заходить по SFTP под юзером www-data как-то стремно, тем более что у него вся авторизация выключена по умолчанию, пробовал - не получилось, нужно конфиги менять (но если кто-то прописал юзеру все эти запреты, наверно не просто так?). Пермишшены на папки на сайте в основном 755, на файлы 644 и менять это не хочется. Хочется прозрачно, залил - работает, без дерганья консоли и исправления прав каждый раз.
Итак что делать? Разрешать доступ для юзера www-data или создавать другого юзера и как-то нахимичить ему те же права, что и у www-data?
Какие еще лучшие практики настройки SSH/SFTP лучше использовать в моем случае?
Я собираюсь настроить юзера для sudo/ходить им же по sftp/ssh, сделать только авторизацию по ключу, перенести порт ssh, закрыть все порты кроме 80, ssh, и порт для утилит EasyEngine (кстати как лучше закрыть порты, может есть особенности ну там ничего не отдавать в ответ или отдавать что-то специальное чтобы разрывать шаблон ботам?). Поделитесь секретами настройки.
Добавить пользователя в группу www-data и настроить в ssh для группы umask
vi /etc/ssh/sshd_config // добавляем в конец файла
Subsystem sftp internal-sftp
Match Group www-data
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp -l INFO -f USER -u 002
Ясно, спасибо. А не будет ли это более небезопасно, ведь права повышаются? Т/е что предпочесть: повышение прав на всё или заходить юзером www-data от которого работает вебсервер? Можно подробнее, какие риски в том и в другом случае? Хочется просто знать, чем жертвуешь выбирая один из вариантов.
В общем не заработала балалайка. Прописал я:
Subsystem sftp internal-sftp
Match Group www-data
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp -l INFO -f USER -u 002
после чего вообще перестал логиниться и под рутом и под юзером которого создал для группы www-data
Скорее всего у вас ошибка ssh. Выше в этом же файле найдите Subsystem и закомментируйте его. Эта директива должна быть объявлена только один раз в конце файла. И перезагрузить ssh не забудьте.
Если не сильно заморачиваться, то можно заливать данные от вашего пользователя, предварительно добавив его в группу www-data, а на нужные папки разрешить запись для членов группы.
-1 - + 1 это все ясно, про это я сам написал.
2. Что для этого есть? Через сервис что ли смс получать? Или приложение будет на мобильнике/лаптопе ключи генерить? Как это работает?
3) Оверхед. Защита первых трех уровней если сделана без изъяна уже дает +99%, а у меня не то чтобы такая важная информация, чтобы стоило ее так сильно стараться выколупать (конкуренты просто брутфорс закажут, а ботов остановят и первые 3 уровня). В конце концов проще найти баг в компонентах, чем ломиться в полностью забарикадированную нарисованную на стене дверь.
Scorry: ерунду говорите. далеко не все боты сканируют все порты в поисках ssh. Это больше для предотвращения паразитной нагрузки на ssh, чем в качестве реальной защиты. Если авторизация только по ключу - все равно сколько там ботов что там находят. +fail2ban и ваши волосы будут очень шелковистыми
Scorry: Смена порта не призвана "снижать нагрузку" на SSH или полностью решить вопрос безопасности. Это мера, минимизирующая попадание под более прицельные сканирования/брутфорсы после обнаружения существования сервера проходящими по всем IP-адресам сканерами. Для ускорения они это делают, прежде всего, по стандартным портам.
Разумеется этот приём не спасёт от прицельного сканирования, если человек знает, что именно и зачем он сканирует. Разумеется этот приём не спасёт от более продвинутых ботов, которым не жалко времени/ресурсов на поиск открытых SSH-портов на сторонних портах, но такие продвинутые сканеры, по личному опыту, встречаются редко.
По воводу SSH
1. запретить ssh login для root
2. изменить порт, на котором работает sshd c 22 на любой другой.
3. явно указать в конфиг файле, что будет использоваться ssh version 2.
4. ограничить доступ по SSH только для конкретных пользователей (директива AllowUsers).
5. использовать KeyBased Authentication с сильным ключом.
6. В iptables разрешить доступ по ssh/sftp только с определенных ip адресов.
7. Используй chroot jails для пользователей, которые будут логиниться по ssh/sftp.
Что касается прав доступа и вебсервера:
1. Создать учетную запись (sftp_uploader), которая будет использоваться для загрузки и обновления файлов на веб сервере.
2. Создать отдельную группу (site_operations), выдать группе права на папку с картинками /var/www/pictures
3. Добавить в группу пользователя site_operations и www-data.
4. Выставить права chmod -R 2770 /var/www/pictures. 2 означает SGID. Все файлы, которые будут изменяться/добавляться в папке /var/www/pictures будут иметь ID группы site_operations. Так как пользователи www-data и sftp_uploader состоят в этой группе, то оба аккаунта будут иметь доступ к файлам, также не потребуется переустанавливать права доступа.
5. Для предоставлния прав доступа вместо группы можно использовать ACL.
6. Для пользователя www-data изменить дефолтный shell на /sbin/nologin
Общесистемные:
1. Дроп ICMP пакетов (не отвечать на ping)
2. Обновить ядро, yum.
3. Держать как можно меньше софта на машине.
Это как? Заливаю я по SFTP специальным клиентом ( Transmit предположим) и как скрипт запустится? Я тут вижу только одно решение - по крону его раз в час пускать, но это капец костыль.
По крону - не вариант.
Автоматизировать заливку можно, например в составет putty есть консольный psftp или pscp, который то же поддерживает sftp, после заливки, следующей командой удаленный вызов скрипта с помощью plink из состава того же putty.
1) У меня нет putty - у меня терминал и им я не хожу файлы заливать. Для файлов есть файловый менеджер, для скриптов - консоль. Очень редко я работаю с этими сущностями параллельно.
Простой
