« Отговор #15 -: Jan 10, 2009, 12:37 »
Идеята не е точно да се раздават адреси, идеята е за всеки пристигнал пакет да се проверява дали адресът му съответства на A записа на хоста.
Ако набиеш хостнейм вместо адрес в някое правило на iptables, хостнеймът ще се резолв-не и адресът ще се използва там в правилото. Може след един ден например този хостнейм да се резолв-ва вече на друг адрес, но това въобще не касае iptables, защото веднъж набито това правило, то match-ва ИП адреса там и няма нищо общо с хостнеймове.
Та явно идеята му е била дали няма начин динамично, при всеки пристигнал пакет, match-ващ там някакво правило, да се прави една справка дали някакъв хост се резолв-ва на този адрес.
На теория е възможно такова нещо да се напише, но идеята е бая безумна. За всеки получен пакет, рутерът трябва да изпрати едно A запитване към DNS сървър, да чака отговора и ако му хареса, да пропусне пакета. Не знам някой замисля ли се:
1) Колко би скочило latency-то в следствие на това?
2) Колко лесно би могло да се DoS-не рутера? Примерно почваш да flood-ваш някой хост навън с малки пакети:
* За всеки пакет се създава един клиентски сокет на рутера. Този сокет хаби памет. Когато се отворят голям брой сокети, се хаби съответно доста памет.
* На теория едновременно не можеш да имаш повече от 65535 такива клиентски сокети защото толкова му е множеството от source ports на мрежовия стек. Така че този flood успешно може да "отреже" други потребители на вътрешната мрежа.
* Създават се добри предпоставки за traffic amplification DoS. Примерно твоите "малки" ICMP пакети с които flood-ваш са с големина 28 байта. За всеки 28 байта караш сървъра да ти изпрати и изчака отговор на заявка, тези две заявки са UDP пакети, и двете поне 2 пъти по-големи от твоят ICMP пакет. Значи поне 4х traffic amplification, което не е чак лошо постижение.
Отделно, DNS заявките трябва да се реализират в kernelspace, това означава внасяне на допълнителна нестабилност и допълнителни секюрити рискове.
Сега остава другия вариант, на определено време един cronjob да ходи, да маха правила и да слага правила с набити хостнеймове. Което значи че поне в прозорците от време между две изпълнения на cronjob-a има рискове хостнейма да спре да се резолв-ва на този адрес, но пакети да бъдат пропускани. Или пък в момента между премахването на правилото и слагането на ново правило, вероятно ще преминават повече пакети, отколкото трябва, добре че този момент е кратък.
Ама наистина няма смисъл, няма абсолютно никаква файда от това, единствено проблемите се увеличават.