Безопасность сокета для сервера клиентов

Question

Предполагая, что у нас есть сервер S и несколько клиентов (C), и всякий раз, когда клиент обновляет сервер, внутренняя база данных на сервере обновляется и реплицируется на других клиентов. Все это делается с использованием сокетов в среде интрасети. Я считаю, что злоумышленник может довольно легко обнюхать этот простой текстовый трафик. Мои коллеги считают, что я чересчур параноик, потому что мы за брандмауэром.

Неужели я слишком параноик? Вы знаете какой-либо эксплойт (ссылка, пожалуйста), в которой использовалась такая ситуация, как и что, и что делать по-другому. Клиенты были переписаны на Java, но сервер все еще использует C++. Любая вещь в коде может защитить от атаки?

Answer 1

Ваши коллеги - na ï ve.

Одна громкая атака произошла в Heartland Payment Systems, процессоре кредитных карт, который можно было бы ожидать очень осторожно в отношении безопасности. Предполагая, что внутренние коммуникации за их брандмауэром были в безопасности, им не удалось использовать что-то вроде SSL для обеспечения их конфиденциальности. Хакеры смогли подслушивать этот трафик и извлекать конфиденциальные данные из системы.

Вот another story с немного больше описания самого нападения:

Описанная Болдуин, как «довольно сложные атаки,» говорит он это был сложным, чтобы обнаружить точно , как это случилось. Судебно-медицинские бригады обнаружили, что хакеры «захватывали номеров с вредоносным программным обеспечением, так как он перешел на нашу платформу обработки», Болдуин говорит. «К сожалению, мы уверены, что имена держателей карт и номера были выставлены». Данные, в том числе карточных транзакций, пересылаемых через внутренней платформы глубинки в обработке , отправляются в незашифрованном виде, он объясняет, «Как сделки в настоящее время обработки, он должен быть в незашифрованном формы, чтобы получить запрос на авторизацию из».

Answer 2

Вы можете сделать много вещей, чтобы человек не находился в средней атаке. Для большинства внутренних данных в защищенной сети брандмауэра/IDS вам действительно не нужно ее защищать. Тем не менее, если вы хотите, чтобы защитить данные, которые вы можете сделать следующее:

1. Использование PGP шифрование для подписи и шифрования сообщений чувствительные
2. шифровать сообщения
3. Использование хэш-функции для проверки того, что сообщение отправлено не имеет был изменен.

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

Answer 3

Внутри брандмауэра вашей компании вы достаточно безопасны от прямых атак хакера со стороны. Тем не менее, статистические данные, которые я не буду беспокоиться о том, чтобы выкапывать, утверждают, что большая часть ущерба, нанесенного бизнес-данным, осуществляется со стороны INside. Большинство из них - простая случайность, но есть разные причины для того, чтобы сотрудники были недовольны и не были обнаружены; и если ваши данные чувствительны, они могут повредить вашу компанию таким образом.

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

Решение заключается в использовании SSL-соединений. Для этого вы хотите использовать предварительно упакованную библиотеку. Вы предоставляете частные/общедоступные ключи для обоих концов и сохраняете закрытые ключи хорошо скрытыми с обычными привилегиями доступа к файлу, и проблема обнюхивания в основном позаботится.

Answer 4

SSL обеспечивает шифрование и аутентификацию. Java имеет его built in и OpenSSL - широко используемая библиотека для C/C++.

Answer 5

Почти каждое «важное» приложение, которое я использовал, полагается на SSL или какую-либо другую методологию шифрования.

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

Answer 6

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

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

В принципе, для большинства предприятий VAST нет причин для шифрования внутреннего трафика. Есть почти всегда гораздо более простые способы получения информации, изнутри компании, даже не приближаясь к «обнюхиванию» сети. Большинство таких «атак» - это люди, которым просто разрешено видеть данные в первую очередь и уже имеют учетные данные.

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

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

Наконец-то вы делаете большое обожание о чем-то, что так же вероятно написано на липкой лапке на дне чьего-то монитора.

Answer 7

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

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

Answer 8

Есть ли у вас пароли в ваших базах данных? Я, конечно, надеюсь, что ответ на это да. Никто не поверит, что пароль, защищающий базу данных, слишком параноидальный. Почему бы вам не обладать, по крайней мере, одним и тем же уровнем безопасности * по тем же данным, что и в вашей сети. Так же, как незащищенная БД, незащищенный поток данных по сети уязвим не только для обнюхивания, но также изменен злоумышленником. Вот как я буду рассматривать обсуждение.

* На том же уровне безопасности я имею в виду использование SSL, как предложили некоторые, или просто зашифровать данные, используя одну из множества доступных библиотек шифрования, если вы должны использовать сырые сокеты.