Я понимаю, что вы можете реализовать брандмауэр, чтобы разрешить доступ к серверу только с определенных IP-адресов, но разве люди не могут подделать IP-адрес источника в пакете TCP? Как это на самом деле мешает недобросовестным людям получить доступ к вашему серверу?
4 ответа
Конечно, кто-то может подделать свой IP-адрес для ОТПРАВКИ пакетов TCP/IP, но он никогда не получит ОТВЕТА, потому что он перейдет на поддельный IP-адрес, который он использовал! Так что этот способ бесполезен для тех, кто хочет установить двустороннюю связь!
Чувак сказал, что это ответ, который вы ищете.
Я думаю, что вы думаете, это:
SERVER.......................CLIENT
............[FIREWALL].........|
..|............................|
..|_>___[CHECK FOR AUTHORITY]_<_|
Эта схема предполагает, что и сервер, и клиент имеют межсетевые экраны (обычно они есть).
Если Органу не удается, вызов к Серверу / Клиенту игнорируется.
Поэтому, если IP-адрес сервера равен xxx.xxx.xxx.1, а клиент - xxx.xxx.xxx.2, и клиент пытается получить доступ к серверу, отправив команду без авторизации. Журнал вашего сервера будет выглядеть так: xxx.xxx.xxx.2 [Авторизация не удалась - IGNORE]
Если xxx.xxx.xxx.2 замаскировал свой ip как xxx.xxx.xxx.3, который авторизован для доступа к серверу, то это произойдет .. xxx.xxx.xxx.3 -> отправить пакет команды на xxx.xxx.xxx.1 xxx.xxx.xxx.1 -> ответить на команду и отправить пакет на xxx.xxx.xxx.3
Таким образом, xxx.xxx.xxx.1 никогда не получит полученную команду.
Теперь, что вы, вероятно, думаете, как это безопасно?
Ну, большинство серверов на самом деле работают так
SERVER..............................CLIENT
..|______________[CONNECT]___________<_|
............|
...[TEST AUTHORIZATION]
...........|
......[PASSED]
..........|
...........[SEND CONNECTED RESPONSE]...|
Поэтому, если клиент авторизован и выполняет вызов на сервер, сервер ответит подключенным ответом, чтобы отправить его обратно клиенту, если клиент получит этот ответ, и сервер узнает, что это правильный клиент.
Было отмечено, что подделки отправителя недостаточно, вы также захотите получить ответ, чтобы сделать многое / что-нибудь полезное. Таким образом, вам нужно будет сделать полный человек в середине тогда.
Тем не менее, брандмауэры обычно не "разрешают" многое, просто основываясь на IP-адресе источника.
Межсетевые экраны в основном используются для блокировки, но не для авторизации.
Т.е. ненадежный IP-адрес даже не узнает, что есть VPN, и не сможет подключиться к службе VPN. Или напасть на это легко, в этом отношении Но главной особенностью безопасности является сама VPN.
Поскольку фильтрация на основе IP обходится дешево, она делает отличную первую линию защиты. Отклонение любого пакета на брандмауэре означает, что сервисам, стоящим за ним, придется иметь дело с гораздо меньшим количеством "атак" (и других помех). Запуск DDoS для брандмауэра сложнее, чем запуск DDoS для реального сервиса, потому что вам нужно заполнить интернет-соединение, а не процессор сервера, обрабатывающего запросы.
Действительно возможно нанести вред односторонним соединениям (например, с протоколами без сохранения состояния, такими как UDP), но тогда это сводится к тому, чтобы избежать (небезопасной) аутентификации на основе IP.
TCP
Как правило, на TCP это не влияет, поскольку для установления соединения требуется отправка пакета обратно на исходный хост. Вот как это происходит:
Алиса в списке авторизованных хостов.
- Алиса отправляет пакет SYN Бобу.
- Боб возвращает SYN-ACK Алисе, чтобы сообщить, что она может продолжить
- Алиса продолжает работу с ACK-пакетом и продолжает работу с предполагаемой полезной нагрузкой.
Чарли пытается подключиться к услуге.
- Чарли отправляет пакет SYN Бобу.
- Брандмауэр блокирует пакет, Боб ничего не получает (или предупреждение в журналах, что Чарли пытался подключиться к нему.
- Чарли может знать, а может и не знать, что его запрос был отклонен (в зависимости от конфигурации брандмауэра, либо время ожидания истекло, либо Боб явно отправил ICMP отклоненный / недоступный пакет)
Чарли почему-то знает, что Алиса может получить доступ к услуге.
- Чарли отправляет пакет SYN Бобу, делая вид, что он Алиса.
- Пакет проходит через Брандмауэр, Боб возвращает SYN-ACK Алисе.
- Алиса отвечает RST-ACK (подтверждение сброса) или ICMP Unreachable, так как она ничего не ожидала от Боба.
- Чарли никогда не узнает, прошел ли запрос.
А что если соединение уже установлено? Вот для чего нужны порядковые номера: они не могут (не должны) предсказываться другими, и обе стороны ожидают, что последовательности всегда будут увеличиваться на единицу.
- Когда соединение установлено, обе стороны выбирают предпочтительно случайный порядковый номер.
- В каждом отправляемом пакете порядковый номер должен увеличиваться на единицу. Это позволяет принимающей стороне отклонять пакеты с неправильными порядковыми номерами и переупорядочивать те, которые находятся в принятом окне.
Теперь у Чарли нет возможности "внедрить" пакеты в существующее соединение между Алисой и Бобом, так как он не может предсказать порядковый номер, и его пакеты будут отклонены Бобом вместе с, возможно, предупреждением или уведомлением в журналах.
UDP
Если протокол UDP, он сильно подвержен спуфингу, так как одноранговые узлы могут внедрять спуф-пакеты в Интернет, поэтому вместо транспорта необходимо добавить механизм аутентификации или шифрования на прикладном уровне.
смягчение
Интернет-провайдеры добавят меры для предотвращения подделки IP-адресов. Это может быть так же просто, как отклонение всех пакетов, которые не соответствуют их собственным сетевым блокам, от выхода из маршрутизатора, и пакетов, которые соответствуют их сетевым блокам, от входа в их сеть.
В локальной сети подделку часто очень легко сделать, так как не так много механизмов, чтобы кто-то не мог этого сделать.