Риск эксплойтов "назад" в исходящие соединения TCP

Question

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

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

Протокол, используемый в соединении, не сложно определить, но он основан на периодическом сердцебиении (интервал 30 секунд). Если два последовательных импульса пропущены, инициатор (мы) прервет соединение и переподключится.

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

Answer 1

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

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

Если вы можете доверять клиенту, но не сети, то добавление некоторого шифрования к вашему сетевому протоколу поможет.

Answer 2

Ваш сценарий довольно распространен, очень редко сеть полностью изолирована от Интернета. Тем не менее, рассмотрим следующие факторы:

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

Answer 3

Они ничего не могут сделать для вас, кроме как сообщить вам ваш протокол. Риск как раз и заключается в том, что все, что можно сделать, от их конца до вашего конца, используя ваш протокол, будет сделано.

N.B. Я не имею в виду, что они должны сообщить вам правильную версию вашего протокола. Если ваша система читает входящие сообщения в статический буфер с помощью fgets (), то «переполнение буфера» является частью того, что вы можете сделать с помощью вашего протокола.

Answer 4

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