Wiele linux'owych klientów torrent'a umożliwia ładowanie zewnętrznej listy z zakresami adresów IP i ta lista ma służyć jako swego rodzaju filtr połączeń chroniący nas przed różnego rodzaju organizacjami, które mogą zbierać i przetwarzać informacje na temat naszego IP i tego, co on porabia w sieci p2p. Oczywiście, kwestia czy korzystać z takiego typu rozwiązania jest bardzo dyskusyjna i wiele osób jest zdania, że to tak naprawdę w niczym nie pomoże, a wręcz nawet przyczynia się do samounicestwienia sieci p2p. Także taki filtr może czasem przynieść więcej szkody niż pożytku, zwłaszcza gdy się go używa lekkomyślnie, czyli na zasadzie, że ten który blokuje więcej adresów IP musi być lepszy. Poniżej zostanie opisane rozwiązanie zakładające wykorzystanie rozszerzenia ipset , które w połączeniu z iptables da nam w pełni działający filtr połączeń p2p (coś na wzór popularnego oprogramowania PeerGuardian), dzięki któremu będziemy w stanie wyciąć dowolny ruch i to nie tylko przy korzystaniu z różnych klientów torrent, np. qbittorrent, ale także i przy zwykłym przeglądaniu stron www.

Prędzej czy później, każdy z nas będzie musiał zabezpieczyć dostęp do swojego komputera w sieci. Do tego zadania na stacjach z linux'em jest oddelegowane narzędzie iptables wraz z szeregiem dodatków, jak np. ipset . By zbudować solidny firewall nie potrzeba zbytnio się wysilać. Niemniej jednak, temat zapory linux'owej jest bardzo rozległy i nie będziemy tutaj opisywać wszystkich możliwych scenariuszy jej zastosowania. Zamiast tego skupimy się jedynie na bazowym skrypcie, który można rozbudować bez przeszkód i dostosować go zarówno pod maszyny klienckie jak i te serwerowe.

Do protokołów SSL/TLS w serwisach www chyba wszyscy już przywykli. Obecnie praktycznie na każdej stronie, gdzie jest okienko logowania, mamy do czynienia z szyfrowaniem danych przesyłanych w różnego rodzaju formularzach. Co prawda, klucze nie są zbyt długie (512-2048 bitów) ale zawsze to lepsze niż nic. O ile dane służące do logowania czy też wszelkie operacje dokonywane w panelach administracyjnych da radę ukryć bez większego problemu, o tyle zapytania DNS są przesyłane otwartym tekstem i każdy może je sobie podejrzeć. Pytanie tylko, po co szyfrować ruch DNS? Czy są tam przesyłane jakieś ważne informacje? Jeśli przyjrzymy się jak działa system DNS, możemy dojść do wniosku, że szyfrowanie zapytań jest pozbawione sensu, bo z reguły nazwa domeny oznacza konkretny adres IP. Znając adres IP, możemy ustalić kto na jakie strony wchodzi. Nie do końca jest to prawdą, poza tym istnieją jeszcze inne czynniki, które sprawiają, że ukrycie zapytań DNS ma jak najbardziej sens. W tym wpisie zaimplementujemy sobie na naszych linux'ach szyfrowanie zapytań DNS przy wykorzystaniu narzędzia dnscrypt-proxy.

ZRAM to moduł kernela, który tworzy wirtualne urządzenia w pamięci operacyjnej komputera, a te z kolei można wykorzystać pod system plików lub też i pod przestrzeń wymiany SWAP. Dane w takim urządzeniu są kompresowane, dzięki czemu mamy do dyspozycji więcej miejsca w pamięci. Jeśli mamy niepierwszej jakości dysk twardy, lub też wykorzystujemy szyfrowanie i nie mamy przy tym procka ze wsparciem dla AES, to operacje zapisu/odczytu mogą zająć wieki. Możemy w dość znacznym stopniu odciążyć dysk przenosząc pliki do pamięci RAM, który jest o wiele szybszy, no i dane w nim nie podlegają szyfrowaniu. Jeśli mamy dużo pamięci operacyjnej, to ZRAM raczej będzie zbędny i tylko podniesie nam rachunek za prąd. Natomiast jeśli nasz komputer nie szasta zbytnio pamięcią, możemy rozszerzyć ją 2-3 krotnie.