Просто хочу понять. Пожалуйста, исправляйте ошибки и пишите советы
Хакер может получить доступ к VPS:
1. Через (используя) консольный терминал, например, используя PuTTY.
Для доступа хакеру необходимо знать номер порта, имя пользователя и пароль.
Хакер по номеру порта может узнать, сканирует открытые порты и пытается войти в систему. Единственный способ войти, насколько я понимаю, нужно знать имя пользователя и пароль.
Чтобы заблокировать (усложнить) сканирование портов, необходимо использовать iptables configure / etc / sysconfig / iptables
. Я следил за этим https://www.digitalocean.com/community/articles/how-to-setup-a-basic-ip-tables-configuration-on-centos-6 руководством и получил
*nat
:PREROUTING ACCEPT [87:4524]
:POSTROUTING ACCEPT [77:4713]
:OUTPUT ACCEPT [77:4713]
COMMIT
*mangle
:PREROUTING ACCEPT [2358:200388]
:INPUT ACCEPT [2358:200388]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2638:477779]
:POSTROUTING ACCEPT [2638:477779]
COMMIT
*filter
:INPUT DROP [1:40]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [339:56132]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s 11.111.11.111/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -s 11.111.11.111/32 -p tcp -m tcp --dport 21 -j ACCEPT
COMMIT
По поводу портов, которые нужно открыть.
Если не используется ssl, то, похоже, необходимо оставить открытым 80 порт для веб-сайта.
Затем для ssh (по умолчанию 22) и для ftp (по умолчанию 21). И установить IP-адрес, с которого можно подключиться. Значит, если хакер использует другой IP-адрес, он не сможет получить доступ, даже зная имя пользователя и пароль?
Относительно электронной почты не уверен.
Если я отправляю электронную почту, используя Gmail (Отправить почту как: (Используйте Gmail для отправки с других адресов электронной почты)), порт 25 не нужен.
Для входящих писем на dynadot.com я использую пересылку электронной почты. Означает ли это, что электронные письма «не приходят на VPS» (до того, как они приходят на VPS, электронные письма пересылаются, например, в Gmail)? Если электронные письма не приходят на VPS, то порт 110 тоже не нужен.
Если используется только ssl, необходимо открыть порт 443 и закрыть порт 80.
Не понимаю, что касается порта 3306
В PuTTY с / bin / netstat -lnp
см.
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 992/mysqld
Как понимаю это для mysql. Но не помнит, что я открыл такой порт (может быть при установке mysql порт открывается автоматически?). Mysql установлен на том же сервере, где и все остальное содержимое.Необходимо понять, что касается порта 3306
2. Также хакер может получить доступ к консольному терминалу через Панель управления провайдера хостинга VPS (аварийный доступ к последовательной консоли).
Как известно, только с помощью консольного терминала (PuTTY и т. Д.) Можно вносить «глобальные» изменения (изменения, которые нельзя изменить с помощью ftp).
3. Хакер может получить доступ к моему VPS, используя некоторую дыру в моем php-коде и загружая, например, Trojan.
К сожалению, возникла ситуация, когда VPS был взломан. Насколько я понимаю, это потому, что я использовал ZPanel. На VPS (\ etc \ zpanel \ panel \ bin)) обнаружен один файл php, который некоторые антивирусные сканеры определили как троян (на сайте virustotal.com).
Экспериментировал с файлом на локальном компьютере (wamp).
И похоже, что хакер может видеть все содержимое VPS, переименовывать, удалять, загружать и т. Д. По моему мнению, если в PuTTY использовать команду типа chattr + i /etc/php.ini
, то хакер не сможет иметь возможность изменять php.ini.
Есть ли другой способ войти в VPS?
То, что вы описали, является уязвимостью ZPanel, если файл был помещен в его каталог и доступен через веб-сервер - я видел это миллион раз в установках Joomla / Wordpress. .
Что касается предоставленного снимка экрана - это похоже на оболочку PHP, которая сможет отображать файловую систему, потому что Apache имеет доступ к файловой системе. Какие файлы / каталоги скрипт может получить доступ / прочитать, зависит от разрешений, установленных для этих файлов.
Теперь, чтобы ответить на ваши вопросы:
Вы можете закрыть порт 3306 - MySQL, если вам нужно получить доступ к серверу MySQL из в удаленном месте вы всегда можете добавить правила iptables, которые разрешают доступ только удаленному IP-адресу к порту 3306.
Кроме того, вы можете использовать ключи SSH для входа в систему root и отключить вход по паролю для пользователя root (PermitRootLogin без пароля), поэтому только пользователи с ключом SSH, добавленным в ~ / .ssh / authorized_keys, могут получить доступ к учетной записи root. Другой способ - полностью отключить доступ root и использовать другую учетную запись, чтобы вы могли перейти в учетную запись root (su - root).
Но ваша безопасность так же сильна, как и ваше самое слабое звено - вы можете все заблокировать, но если веб-приложение уязвимо - они найдут способ проникнуть в него.
Если вы единственный, кто использует сервер, вы можете увидеть с помощью ZPanel добавление HTTP-аутентификации перед доступом к панели, или если вы находитесь за VPN-сервером, настроенным для обслуживания Zpanel, чтобы разрешить доступ только к вашему IP-адресу VPN.
Изменить:
Добавление chattr + i /etc/php.ini
отключит любые модификации файла php.ini, поскольку он установил неизменяемый атрибут, и ни вы (root), ни кто-либо другой не сможете изменить файл .
Что касается защиты php.ini, вы можете рассмотреть возможность изменения следующих параметров, если это рабочий сервер:
Также вы можете отключить количество ненужных функций PHP, которые могли бы сделать сценарии оболочки PHP непригодными для использования:
disable_functions = php_uname, getmyuid, getmypid, passthru, Leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, exec, system, highlight_file, source, showth_source, virtual, f , posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid,posix_getpgrp, posix_getpid, POSIX, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo
Если ваш сценарий не работает должным образом после отключения этих функций, проверьте, какая функция должна быть включена, удалите из списка и перезапустите HTTP-сервер.
Ну конечно! Все зависит от поверхности атаки.
Все, что идет снизу вверх, является потенциальной целью. Не зная больше о конкретном VPS, мы знаем, что они должны иметь как минимум:
В виртуализированной среде вид стека запускается заново, так что прикладной уровень на физическом сервере размещает физический уровень в виртуальной среде. Например, предположим, что вы размещаете VPS на одном физическом сервере с некоторым гипервизором. Любые проблемы с хранилищем, сетью или сервером могут повлиять на виртуальные машины, находящиеся на этом сервере.
С другой стороны, даже если в физическом мире все в порядке, в виртуальной среде размещается виртуализированное оборудование , так что вы должны начать все сначала.
Однако нет необходимости рассматривать эти две среды полностью отдельно. Хотя виртуальная среда находится поверх физической, она потенциально может достигать физических сетей. Именно здесь начинается совпадение виртуальных и физических угроз.
Например, у вашего интернет-провайдера может быть физический пограничный маршрутизатор, который проверяет и фильтрует трафик. Он может проверять строки запроса незашифрованных URL-адресов, чтобы убедиться, что что-то не так. Если бы фитлер был достаточно хорош, можно было предположить, что вам не нужно беспокоиться о внешнем трафике (благодаря мосту и NAT). Тем не менее, вы можете выполнить собственную проверку строк запроса, чтобы быть уверенным вдвойне. В этом случае трафик ушел:
Я понимаю, что это действительно окольный способ ответить на ваш вопрос, но я пытаюсь сказать, что вы должны думать о своей поверхности атаки - особенно о самом низком уровне - а не думать о контрольный список. Если вы разрешаете загрузку файлов, у вас должен быть надежный способ фильтрации плохих файлов. Если вы разрешите базовую HTTP-аутентификацию, вам нужно будет предотвратить перехват и атаки методом грубой силы. Если вы разрешаете SSH, вы можете захотеть тщательно проверять попытки входа в систему.
Поэтому вместо того, чтобы думать о безопасности категорически, вместо этого думайте о ней с точки зрения поверхности атаки, которая создается для работы ваших конкретных служб.