Re: [Lug-bg] firewall project

[Momchil Ivanov <idiotbg@xxxxxxxxx>]

На 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
> трябва да поема огромна натоварване. Това е засега което се сещам.
> Ако имате време и някакви по-добри идеиотнасно как мога да проектирам
> системата, моля пишете на адрес derleader@xxxxxx. Не пест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

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Lug-bg mailing list
Lug-bg@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg