anonimowy blog

Dziś postanowiłem napisać coś więcej o ukończonym niedawno proxy ruchu www.

Oczywiście daleko temu rozwiązaniu do komercyjnych produktów. A dlaczego? Brak panelu do zarządzania przez wirtynę www czy tez standalone aplikację Java, użycie ClamAV jako skanera antywirusowego, wykorzystanie nierozwijanego już SquidGuard. Pozwolę sobie nieco dokładniej opisać ułomności tego systemu.

1. ClamAV. Jest bardzo dobrym antywirusem i dość dobrze radzi sobie, ale nie oszukujmy się, że w szybkości publikacji szczepionek jest w stanie konkurować z potentatami branży (Symantec, McAfee, Nod32). Zawsze będzie nieco “do tyłu” i nie można oczekiwać i żadać suportu. Ma jednak niezaprzeczalna zaletę … jest bezpłatny i szybki. Uważam że wykorzystanie ClamAV na bramkach smtp / pop3 / www jest bardzo dobrym rozwiązaniem jeśli “poniżej” lub też na stacjach roboczych działają komercyjne skanery antywirusowe.
2. SquidGuard. Od bardzo dawna nie pojawiła się żadna ważna zmiana w źródłach projektu, ale nie ma nad czym rozpaczać. Specyfikacja Squida nie zmieniła się znacząco, obsługa wyjątków i regół została bardzo dobrze dobracowana. Brak obsługi SQL jest do zaakceptowania, zważywszy na ilość odwołań i wydajność wykorzystywanych BerkelyDB.
3. Squid. Jego wydajność zależy tylko od konfiguracji i sprzętu. Doskonale dopracowany i ciągle rozwijany (prace nad wielowatkowością)

Oczywiście Linuks nie byłby systemem jaki kochamy, gdyby wszystko poszło od razu i działało poprawnie tylko po instalacji.

Pierwszy problem to “uzbieranie” kompletu wymaganych bibliotek i pilków binarnych (szczególnie cURL okazał się złośliwy, gdy chciałem wykorzystać cały potencjał squidGuard). Tu muszę nadmienic, że jak zawsze wykorzystałem PLD więc z *.rpm nie było problemów. Squid z branch’a ac-main posiada bardzo dużo patchy i stanowił stabilny “rdzeń” w3cache. Na początku zrezygnowałem ze squidGuard, zainstalowałem tylko squid, bannerfilter i squidclamav. O ile BannerFilter także jest dostępny w głównym drzewie dystrybucji to squidclamav już tylko do samodzielnej kompilacji z repozytorium SPEC. Po kompilacji i instalacji kolejnym krokiem była optymalizacją clamvd. Kilka godzin testów i przeskanowane kilkaset gigabajtów dało pogląd na możliwości daemona. I tutaj natrafilem na kilka płotków i jeden wielki mur

Pierwsze “murki” to zagadnienia jak wykorzystać kilka redirectów, gdy squid wykonuje tylko pierwszy, oraz dlaczego squidclamav nie działa. Aby wykorzystać wiele filtrów w jednym “cyklu” squida należy po prostu odpowiednio “skolejować” filtry a następnie wykonywać je jeden po drugim (1 filtr na koncu swojej akcji wywowuje 2 i przekazuje mu treść, … n-1 dokonuje analizy i przekazuje do n-tego redirectora). W sieci dostępna jest wersja 3.0 squidclamav i w przeciwieństwie do starej z “peeldowego” spec’a, działa. Jestem bardzo leniwą osobą i w3cache robiłem w godzinach pracy więc squidclamav.spec nie poprawiłem a skompilowałem program ze źródeł. I już prawie wszystko działało … ale nie do końca. Squidclamav nie potrafi (lub bardzo mocno broni się przed takim działaniem) zwrócic wyniku bezposrednio do procesu squida. Po doinstalowaniu squidGuard i zdefiniowaniu dość restrycyjnych list, całość zadziałała.

Po dość intensywnym testowaniu pozwolę sobie podzielić się przemyśleniami

• nie należy przesadzać ze szczegółowością skanowania clamavd (rekurencja i rozmiar plików)
• squidclamav + clamavd najlepiej i najszybciej komunikują się za pomocą socketów unixowych
• squidclamav oraz Force 1 to średni pomyśł, lepiej wpisać wiecej wzorców za pomocą wyrażeń regularnych
• dobrze działający squid to więcej niż połowa sukcesu w bitwie o wydajność
• squid (razem z dodatkami) nie lubi chroot <szczególnie w PLD>

To raczej wszystko z cyklu “Wujek Dobra Rada”.