Трябва ли филтрирането на IP адреса на източника да бъде внедрено в самия слой на приложението или делегирано от приложението на защитната стена

Да приемем, че моето приложение има слушащ UDP сокет и знае от какви IP адреси може да получава UDP дейтаграми. Всичко, идващо от други IP адреси, ще се счита за злонамерена дейтаграма и трябва да бъде изхвърлено възможно най-рано, за да се предотвратят DoS атаки. Трудната част е, че наборът от тези легитимни IP адреси може динамично да се променя през живота на приложението (т.е. чрез динамичното им получаване по контролен канал).

Как бихте приложили филтриране въз основа на IP адреса на източника в горния случай?

Виждам две решения къде да поставя тази изходна логика за филтриране на IP:

  1. Внедрете го в самото приложение след извикване на recvfrom().
  2. Инсталирайте политиката за изхвърляне по подразбиране в защитната стена и след това оставете приложението да инсталира правила за защитна стена, които динамично ще добавят в белия списък законните IP адреси.

Има плюсове и минуси за всяко решение. Някои, които ми идват наум:

  1. iptables може да завърши с O(n) сложност на филтриране (против за iptables)
  2. iptables изпуска пакети, преди дори да стигнат до буфера на сокета (про за iptables)
  3. iptables може да не е много преносим (против за iptables)
  4. iptables от моето приложение може да попречи на други приложения, които потенциално биха инсталирали правила за iptables (против за iptables)
  5. ако моето приложение инсталира правила за iptables, тогава то може потенциално да стане вектор за атака (против за iptables)

Къде бихте приложили IP филтриране на източника и защо?

Можете ли да посочите приложения, които следват конвенция №2 (администраторът ръчно инсталира статични правила на защитната стена не се брои)?


linux firewall sockets network-programming denial-of-service
person user389238    schedule 28.10.2015    source източник
comment
iptables е ниво на ядрото, приложението е потребителско пространство. Там има съществена разлика. Бих очаквал внедряване като tcpwrapper, ако правите неща в потребителското пространство.. но като цяло цялата причина да го имате е споделена инфраструктура като правила за разрешаване/отказ на Apache.   -  person Mike Guelfi    schedule 28.10.2015

Отговори (2)


arrow_upward
1
arrow_downward

Моята препоръка (без абсолютно никакви правомощия зад това) е да използвате iptables за ограничаване на скоростта, за да смекчите всякакви DoS атаки и да извършите действителното филтриране във вашето приложение. Това ще ви даде най-малко лошото от двата свята, позволявайки ви да използвате производителността на iptables, за да ограничите пропускателната способност на DoS, както и възможността да промените кои адреси са разрешени, без да въвеждате потенциална дупка в сигурността.

Ако все пак решите да го направите само с iptables, бих създал нова верига, която да извърши специфичното за приложението филтриране, така че потенциалът за намеса да бъде намален.

Надявам се това да помогне.

person Joel C    schedule 29.10.2015

arrow_upward
-3
arrow_downward

Надявам се тази връзка да ви помогне Защитните стени на мрежовия слой или филтрите за пакети работят в стека на TCP/IP протокола, като не позволяват на пакетите да преминават през защитната стена, освен ако не съответстват на установения набор от правила, дефиниран от администратора или приложен по подразбиране. Съвременните защитни стени могат да филтрират трафик въз основа на много атрибути на пакети, като например IP адрес на източник, порт на източник, IP адрес или порт на местоназначение или услуга на местоназначение като WWW или FTP. Те могат да филтрират въз основа на протоколи, TTL стойности, мрежов блок на инициатора, на източника и много други атрибути. Защитните стени на приложния слой работят на ниво приложение на TCP/IP стека, като прихващат всички пакети, пътуващи към или от приложение, отхвърляйки нежелания външен трафик от достигане до защитените машини, без потвърждение към подателя. Допълнителните критерии за проверка могат да добавят допълнителна латентност към препращането на пакети до тяхната дестинация. Задължителният контрол на достъпа (MAC) филтриране или пясъчна среда защитава уязвимите услуги, като разрешава или отказва достъп въз основа на MAC адреса на конкретни устройства, на които е разрешено да се свързват към конкретна мрежа. Прокси сървърите или услугите могат да работят на специални хардуерни устройства или като софтуер на машина с общо предназначение, като отговарят на входни пакети, като например заявки за връзка, като същевременно блокират други пакети. Злоупотребата с вътрешна система не би причинила непременно пробив в сигурността, въпреки че методи като IP spoofing могат да предават пакети към целева мрежа. Функцията за преобразуване на мрежови адреси (NAT) позволява скриване на IP адресите на защитените устройства, като ги номерира с адреси в „диапазон от частни адреси“, както е дефинирано в RFC 1918. Тази функционалност предлага защита срещу мрежово разузнаване

person user5496545    schedule 28.10.2015