> И в чем же я неправ, мой костноязычный друг?
> CVE-2005-3110:
> A race condition in the ebtables netfilter module (ebtables.c), when running on an SMP system that is operating under a heavy load, might allow remote attackers to cause a denial of service (crash).
> Это, дружок, DoS в чистом виде, D - это от слова dead, когда ядру полный писец.
Нет, мой юный друк, не нужно путать теплое с мягким.
Протри свои запотевшие лапки и узнай, что ebtables настолько малоиспользуемая фича, что сравнивать ее дырой в ipfw можно только перекушав с утра портвейна.
Для чистоты эксперимента необходимо найти такую уязвимость в iptables, при которой система падает на специально созданном трафике, а не на специально созданных правилах.
> Для чистоты эксперимента необходимо найти такую уязвимость в iptables, при которой система падает на специально созданном трафике, а не на специально созданных правилах.
Такой эксперимент не будет чистым, потому что найденная уязвимость в ipfw не может свалить систему на _любых_ правилах, а только на специально созданных. :)
>> Для чистоты эксперимента необходимо найти такую уязвимость в iptables, при которой система падает на специально созданном трафике, а не на специально созданных правилах.
> Такой эксперимент не будет чистым, потому что найденная уязвимость в ipfw не может свалить систему на _любых_ правилах, а только на специально созданных.:-)
Хорошо, на любых reset, reject or unreach правилах :)
CVE-2005-3275:
The NAT code in Linux kernel incorrectly declares a variable to be static, which allows remote attackers to cause a denial of service (memory corruption).
> CVE-2005-3275:
> The NAT code in Linux kernel incorrectly declares a variable to be static, which allows remote attackers to cause a denial of service (memory corruption).
Это только NAT, а не вообще любое accept/reject правило.
Не нужно выдавать желаемое за действительное...
> Хорошо, на любых reset, reject or unreach правилах :)
Да, тогда ты докажешь, что iptables более безопасен, чем ipfw до патча на reset, reject or unreach правилах. В то же время ipfw более безопасен, чем iptables до патча при использовании nat. Что из этого всего следует? Ничего особенного. К чему тогда этот спор? :)
Около года назад окончательно и бесповоротно мигрировал на pf(4), чего и вам всем желаю.
p.s.: ей-богу, смешно наблюдать вашу перепалку из серии "какая бага более бажная". Могу сказать одно - у ipfw есть альтернативы, и не все, кто использует пакетные фильтры на FreeBSD, делают ЭТО с помощью ipfw. Если бы подобная уязвимость была в iptables, пользователям Linux, наверное, было бы хуже, т.к. у них альтернатив нет.
>> Хорошо, на любых reset, reject or unreach правилах:-)
> Да, тогда ты докажешь, что iptables более безопасен, чем ipfw до патча на reset, reject or unreach правилах. В то же время ipfw более безопасен, чем iptables до патча при использовании nat. Что из этого всего следует? Ничего особенного. К чему тогда этот спор?:-)
Скажем так, машин с простыми reset, reject or unreach несравнимо больше, чем машин с NAT и bridge вместе взятых.
А спор абсолютно ни о чем, хотя можно и покричать, что FreeBSD отстой и т.п.
> пользователям Linux, наверное, было бы хуже, т.к. альтернатив нет
как не странно - они есть.
и потом - большинство проблем с iptables - в экзотичных модулях.
но что ipfw - suxx по функционалу - это точно, также как и фрюхин встроенный nat .:)
pf навчерное таки значительно получше и сравним с iptables.
The SIP conntrack/NAT modules support the connection tracking/NATing of
the data streams requested on the dynamic RTP/RTCP ports, as well as mangling of SIP requests/responses.