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

Привязка служб к localhost и использование туннелей SSH - можно ли подделывать запросы?

Учитывая типичный веб-сервер с Apache2, обычными сценариями PHP и DNS-сервером, будет ли достаточно с точки зрения безопасности привязать интерфейсы администрирования, такие как phpmyadmin, к localhost и получить к нему доступ через туннели SSH?

Или мог бы кто-нибудь, кто знал, например. что phpmyadmin (или любой другой общедоступный скрипт) прослушивает определенный порт на локальном хосте, легко подделывает запросы, которые были бы выполнены, если бы не было другой аутентификации?

  1. Другими словами: может ли кто-нибудь откуда-то из Интернета легко подделать запрос, чтобы веб-сервер принял его, думая, что он исходит из 127.0.0.1, если сервер прослушивает только 127.0.0.1?
  2. Если бы был риск, можно ли как-то справиться с ним на более низком уровне, чем приложение, например. используя iptables? Идея в том, что если кто-то обнаружит уязвимость в php-скрипте или apache, сеть все равно заблокирует этот запрос, потому что он не поступил через SSH-туннель?

Если вы изменили адрес привязки процесса на 127.0.0.1, этого должно быть достаточно, чтобы предотвратить удаленный доступ с любой другой машины. Если вы попытаетесь подключиться, вы получите В соединении отказано. Это будет выглядеть (с точки зрения удаленных машин) точно так же, как процесс остановлен, а порт закрыт.

Для дополнительной безопасности вы можете добавить правила iptables, чтобы блокировать эти порты с удаленных адресов. Это предотвратит случайное включение удаленного доступа путем изменения конфигурации (по ошибке или после обновления).

... может ли кто-нибудь откуда-то из Интернета легко подделать запрос, чтобы веб-сервер принял его, думая, что он исходит из 127.0.0.1, если сервер прослушивает только 127.0.0.1?

Возможно, но чрезвычайно вряд ли. Подумайте об этом так: когда процесс прослушивает порт, привязанный к 127.0.0.1, входящий IP-пакет достигнет процесса, только если адрес назначения пакета - 127.0.0.1. Если ваш злоумышленник не разрушил каждый маршрутизатор между собой и вашим сервером, такой пакет никогда не будет перенаправлен на ваш сервер, поскольку 127.0.0.1 обычно не является маршрутизируемым адресом.

Но предположим, что происходит немыслимое, и на ваш сервер приходит поддельный пакет на 127.0.0.1. В этом случае пакет должен был прийти через сетевой интерфейс, который не является интерфейсом обратной связи (lo). Поскольку по соглашению все легитимные пакеты, предназначенные для 127.0.0.0/8, должны прибыть через lo интерфейс, легко идентифицировать и блокировать поддельные пакеты до 127.0.0.0/8 с помощью простого iptables правило:

-A INPUT -d 127.0.0.0/8 ! -i lo -j DROP