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

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

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

enter image description here

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

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

5
задан 28 October 2013 в 10:54
2 ответа

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

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

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

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

  • display_errors - Off
  • expose_php - Off

Также вы можете отключить количество ненужных функций 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-сервер.

5
ответ дан 3 December 2019 в 01:13

Ну конечно! Все зависит от поверхности атаки.

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

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

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

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

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

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

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

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

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

4
ответ дан 3 December 2019 в 01:13

Теги

Похожие вопросы