Назад | Перейти на главную страницу

Вопросы безопасности VPS при доступе только с одного IP-адреса

Я использую VPS, на котором я развернул несколько проектов. Поскольку я единственный человек, который обращается к серверу, и, кроме того, у меня есть фиксированный IP-адрес, я решил настроить iptables так, чтобы доступ к серверу был возможен только с моего фиксированного IP-адреса.

Поскольку меня очень беспокоят проблемы с безопасностью, я не совсем уверен, нужно ли мне что-то делать для защиты моего сервера, когда доступ есть только у моего фиксированного IP-адреса.

Есть ли дополнительные улучшения безопасности, которые я должен учитывать?

Есть много вещей, которые следует учитывать, однако это зависит от того, какой тип настройки у вас есть, что вы хотите защитить.

Вот несколько вещей, которые следует учитывать:

  • нет пароля для доступа по ssh (используйте закрытый ключ)
  • нет корневого доступа для ssh
  • использование sudo для пользователей, чтобы команды регистрировались
  • регистрировать попытки несанкционированного входа в систему (и учитывать программное обеспечение для блокировки / блокировки пользователей, которые пытаются получить доступ к вашему серверу слишком много раз)
  • ssh на нестандартный порт
  • убедитесь, что такие вещи, как ipv6, заблокированы, если они не используются
  • поддерживать программное обеспечение в актуальном состоянии (ОС, веб-сервер, язык сценариев, CMS)
  • удалите все программное обеспечение, которое вам не нужно
  • убедитесь, что права доступа к файлам заблокированы (особенно для таких вещей, как загрузка пользователями)
  • ограничить людей, у которых есть доступ к серверу
  • защитить паролем админку для CMS на уровне веб-сервера
  • использовать SSL для админки и других конфиденциальных данных

Для целей разработки ограничения по IP-адресу достаточно, чтобы предотвратить большинство злоумышленников. Тем не менее, вы все равно должны беспокоиться о том, что информация в открытом виде отправляется туда и обратно. По возможности всегда используйте зашифрованные каналы для взаимодействия с вашим сервером: SSH для администрирования и передачи файлов, HTTPS и т. Д.

Подробнее об этом читайте в ответах на: Советы по защите LAMP-сервера.

Я использую ту же меру и лучше сплю!

СОВЕТ 1. У вас должен быть провайдер с реальными рабочими возможностями восстановления. У меня есть один, и однажды я им пользовался. Я продолжаю слышать слухи о провайдерах, у которых есть только номинальные возможности восстановления.

Вас могут взломать независимо от ваших мер, это может произойти через взломанный ноутбук вашей серверной компании, через серверное программное обеспечение, какую-то уязвимость Linux и т. Д. Вы никогда не узнаете как. Решение для взломанной или внедренной учетной записи vps - только одно полное восстановление из резервной копии предполагаемой даты очистки.

СОВЕТ 2: Что касается программных паролей, будьте внимательны к утомительным дням и паролям типа «Я изменю через несколько минут», а также к старым неиспользуемым неважным оставленным в стороне сайтам cms, которые никто не проверяет и не обновляет.

По моему небольшому опыту, атака, если таковая будет, будет исходить от программного обеспечения веб-сайта. Или, по крайней мере, именно в этом вас обвинит ваша веб-хостинговая компания.

Защита root с помощью правила ip не позволяет злоумышленнику получить root-доступ с помощью SSH. Но в наши дни, когда vps взломан, полезная нагрузка - это сами веб-сайты, электронные письма в базах данных, php-файлы, которые хакер заражает. Кого волнует рут-доступ, вроде. Но вы правы, одно дело - взломать, другое - рутировать.

Остерегайтесь этого: когда у вас много проектов и по прошествии многих лет, в утомительный день, работая над тестовым проектом, вы просто не можете беспокоиться о поиске длинного пароля или не беспокоиться о том, чтобы иметь другой логин администратора, кроме ' admin '. Думаю, потом поменяют. И этой одной ошибки обычно достаточно.

Вы не должны иметь никаких политик исключений для всех ваших паролей cms, никогда не используйте admin в качестве имени пользователя admin и обновляйте свое программное обеспечение в максимально возможной степени.

СОВЕТ 3: правила брандмауэра Iptables, возможно, они не защищают вход в область графического интерфейса VPS от разных IP-адресов.

Например, можно использовать файл etc / hosts.allow для IP-фильтрации логинов ssh И логинов в админпанели. Вам следует обратиться в службу поддержки, а затем самостоятельно проверить этот файл.

СОВЕТ 4. Более сильное разделение учетных записей между веб-сайтами.

Cpanel или любой другой, разделение между учетными записями по умолчанию является слабым по состоянию на 2013 год. Одна учетная запись, взломанная в> человек-скрипт, достигает всех учетных записей за несколько минут> достигает всех баз данных> сервер так же хорош, как и рутированный. Посмотри пожалуйста http://forums.cpanel.net/f185/solutions-handling-symlink-attacks-202242.html за 24 страницы страха. Решение: попросите ваш веб-хостинг установить защиту от атак символьных ссылок И также, если возможно, chmod 600 для config.php и любых других файлов информации базы данных ( http://whmscripts.net/misc/2013/apache-symlink-security-issue-fixpatch/ ).

//some symlink protection between user accounts, if you know what you are doing
//list files: web root >
find -type f -regex ".*config.php" -exec ls -lh {} \;
//change permissions
find -type f -regex ".*config.php" -exec chmod 600 {} \;