На Monday 29 June 2009 22:07:10 derleader derleader написа: > здравейте, > > > обмислям в момента един хоби проект за управление на достъпа на големи > мрежи, и също така firewall който да предпазва от DoS DDoS и други атаки. > Ще се състои от Squid transparent proxy и openldap и от софтуер писан на > PHP на отделен сървър който да подава тези IPта на firewall който могат да > преминат а тези който не могат автоматично да ги дропи. > > Когато клиента не трябва да достъп до мрежага php програмата маха ip-то от > списъка на firewalls с ip-та които могат да преминават. firewall изписва на > потребителите че достъпа е заключен. Също > може да се зададе firewall да филтрира имената на web sites които нямат > право да минат. > > > > Не съм проверил но мисля че може да се направи squid да чете списък от > ip-та които могат да се свързват на порт 22 - SSH. Ако ip-то не е в списъка > squid ще дропи клиентите които искат да се свържат през порт 22. > > > > Цялата система дори ще е по- лесна за администрация. Не съм проверил но > можеби има вариан да направя пощенски сървър който да ченте от главната php > програма дали даден e-mail адрес на потребител може да се ползва. Тоест > мога да заключа освен достъпа до сървъра и е-mail акаунта в пощенския > съвър. Друга опция която бих искал да използвам е delay pools - тоест да > лимитирам скоростта на всяко ip. Също така да се лимитира и общия брой > конекции който ip може да прави. > Като за начало мисля само да направя като функционалност да се проверява > дали до дадено IP може да има достъп и да се брои трафита на всяко IP. > Другите екстри ще се обсъждат по нататък. Виж picture 1 > Проблема е че тези защитни стени трябва да издържат огромен брой конекции и > огромен трафик. Иска ми се да мога да ги пригодя за реализация в големи > datacenters със стотици съвъри и гигабити трафик. > > В случая firewall смятам да проектирам по следния начин. Виж picture 2 > На съвъра има качен squid, OpenLDAP в който се съхраняват IPтата които имат > достъп, скриптове за защита против DoS DDoS и може и да включа APF и CSF > като тяхното използване e под въпрос тъйкато сървъра можеби ще се > претоварва. Малко е спорно това дали да има OpenLDAP на сървъра тъйкато ще > се натоварва, но ако няма достъп до главния сървър firewall ще си работи > без пробелем. > Squid ще се конфигурира да използва този скрипт > http://www.stress-free.co.nz/transparent_squid_authentication_to_edirectory > за да провери дали пакета на клиентите магат да преминат. В squid се > настройва и така наченото ttl в случая представлява колко време достъпа на > ip-то на важи. Като изтече ttl squid пак проверява в openldap дали има > достъп. Все пак ако скоростта по спомени межди CPU и RAM е по смътни > спомени е 6 GB/sec ако направя squid всеки път да проверява в главния > сървър ще има голямо чакане от страна на клиента и мрежата може да се > претовари. Главния сървър (php+mysql) периодично ще обновява списъка с > ip-та на openLDAP. Дори обмислям дали да не напрява т.н RAMDISK - да > инсталирам програма която да инсталира в рам паметта виртуален твърд диск и > всичко да инсталирам там. Разбирасе в случая трябва рам паметта да е > по-голяма. И трябва да се бриджнат двете мрежи, за да бъде невидима > firewall (без ip адрес) > > > > Засега проблема който не съм решил е как да записвам трафика на всяко ip в > списъка на openldap и дали проекта ще бъде ефикасен, каква производителност > да очаквам на съвъра с двете програми на гъба си + скриптовете. Замислям се > дали да не кача всичко на Sun Spark машина с opensolaris защото > производителността ще е по-голяма. > > > > > > > > Естествено налага се да направя модофикации на OS - задаване на висок > приоритет на изпълнение на squid, увеличаване на буфера на мрежовата карта. > Разтоварване на ненужните модули на ядрота и сигурно ще се наложи да орежа > ядрото. Да спра ненужните демони. Ще направя обединение на мрежови портове > - bonding, на няколко мрежови карти за да вдигна на 2 гигабита възможния > трафик който може да премине. Има security appliance на juniper > и cisco струващи 20к+$ способни да обработват 10Gbit трафик, за съжаление > не мога да разгледам как са устроени. > Има тестови проведени с squid - двупроцесорна машина с 8 гигабайта рам може > да издържи 3000 заявки с кешираща функция а на мен кеширане в случая не ми > трябва. > > И още един проблем - с увечаването на хоповете ще се увеличи забавянето на > отваряне на страници, негативен ефект който няма как да реша. > Другото което мога да направя е да използавам по-ново прокси > http://varnish.projects.linpro.no/ незнам каква е точно производиелността > на предполагам че ще е по-добра > > Моля пишеште ми как мога да си пеша пролема с производителността. firewalla > трябва да поема огромна натоварване. Това е засега което се сещам. > Ако имате време и някакви по-добри идеиотнасно как мога да проектирам > системата, моля пишете на адрес derlea...@abv.bg. Не пестeте критики! > > сто схеми http://img341.imageshack.us/i/picture1gpm.png/ > http://img40.imageshack.us/i/picture2vxu.png/
Не мисля, че изборът на инструментите ти е добър за голямо количество трафик. В повечето случаи защитна стена се реализира в ядрото, иначе се получават фалове при голям брой пакети (типиче пример ipfw + natd под freebsd). Тук на помощ под linux идва iptables, под freebsd pf, ipfw и netgraph, за opensolaris не знам :) Като цяло няма значение къде си държиш информацията за firewall-а (mysql, ldap, ........), важното е да я преобразуваш в съответните правила за системата, която решиш да ползваш. За ограничаване на скоростите под linux имаш tc (trafiic control), под freebsd вече споменатите. Четенето на трафика от съответните правила е нищо особено. Приятно четене! Момчил -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
