Как хакер может получить доступ к контенту VPS CentOS 6?

Просто хочу понять. Пожалуйста, исправляйте ошибки и пишите советы

Хакер может получить доступ к 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-коде и загружая, например, трояна.

К сожалению, возникла ситуация, когда VPS был взломан. Насколько я понимаю, это потому, что я использовал ZPanel. На VPS (\ etc \ zpanel \ panel \ bin)) обнаружен один php-файл, который некоторые антивирусные сканеры определили как троян (на сайте virustotal.com).

Экспериментировал с файлом на локальном компьютере (wamp).

И похоже, что хакер может видеть все содержимое VPS, переименовывать, удалять, загружать и т. Д. На мой взгляд, если в PuTTY используйте команду вроде chattr +i /etc/php.ini тогда хакер не сможет изменить php.ini.

Есть ли другой способ попасть на VPS?

security vps

Вы описали уязвимость ZPanel, если файл был помещен в его каталог и доступен через веб-сервер - я видел это миллион раз в установках Joomla / Wordpress.

Что касается предоставленного снимка экрана - это похоже на оболочку PHP, которая сможет отображать файловую систему, потому что Apache имеет доступ к файловой системе. Какие файлы / каталоги скрипт может получить доступ / прочитать, зависит от разрешений, установленных для этих файлов.

Теперь отвечу на ваши вопросы:

Я бы посоветовал использовать CSF для защиты вашего сервера, который обеспечивает защиту от стука портов и сканирует ваш журнал SSH, чтобы увидеть, есть ли какие-либо атаки грубой силы и заблокировать IP-адрес злоумышленника. Что касается оставления открытых портов - спросите себя, что будет делать сервер, а затем откройте нужные порты:
- 21 для FTP
- 22 для SSH
- 25 для SMTP-сервера
- 80 для HTTP
- 443 для HTTPS, если вы используете это
- 110/995 для POP3 / POP3 через SSL - если вы хотите использовать почтовый сервер на своем VPS
- 143/993 для IMAP4 / IMAP4 через SSL - то же, что и для соединения POP3

Вы можете закрыть порт 3306 - MySQL, если вам нужно получить доступ к серверу MySQL из удаленного места, вы всегда можете добавить правила iptables, которые разрешают доступ к порту 3306 только удаленному IP-адресу.

Кроме того, вы можете использовать ключи 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, вы можете изменить следующие параметры, если это рабочий сервер:

display_errors - Выкл.
expose_php - Выкл.

Также вы можете отключить ряд ненужных функций 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, show_source, fpaththru, virtual, 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, мы знаем, что они должны иметь как минимум:

Уязвимости физического уровня (перехват провода, кража физического сервера)
Уязвимости уровня 2 (перехват трафика из другой VLAN, эксплойты ARP)
Сетевые уязвимости (отказ в обслуживании)
Уязвимости сеанса / транспорта / и т. Д. (Слой оболочки) (манипулирование клиентом, чтобы он считал, что сертификаты действительны, другие проблемы с SSL, захват и т. Д.)
Уязвимости уровня представления / приложения (здесь начинается ваше путешествие)

В виртуализированной среде стек запускается заново, так что на уровне приложений физического сервера размещается физический уровень в виртуальной среде. Например, предположим, что вы размещаете VPS на одном физическом сервере с некоторым гипервизором. Любые проблемы с хранилищем, сетью или сервером могут повлиять на виртуальные машины, живущие на этом сервере.

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

Однако нет необходимости рассматривать эти две среды полностью отдельно. Хотя виртуальная среда находится поверх физической, она потенциально может достигать физических сетей. Здесь начинается совпадение виртуальных и физических угроз.

Например, у вашего интернет-провайдера может быть физический граничный маршрутизатор, который проверяет и фильтрует трафик. Он может проверять строки запроса незашифрованных URL-адресов, чтобы убедиться, что что-то не так. Если бы фитлер был достаточно хорош, можно было предположить, что вам не нужно беспокоиться о внешнем трафике (благодаря мосту и NAT). Тем не менее, вы можете выполнить собственную проверку строк запроса, чтобы быть уверенным вдвойне. В этом случае трафик ушел:

От клиента к пограничному фильтру ISP (физический)
Либо: от пограничного фильтра ISP к клиенту через физический мост к виртуальному ИЛИ от пограничного фильтра ISP к клиентскому шлюзу к клиенту
От клиентского фильтра к клиентскому приложению

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

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