MikroTik RouterOS 2.9.41

Pojawiła się nowa wersja MikroTik RouterOS a w niej następujące zmiany:

* routing-test - fixed bugs introduced in 2.9.40: bgp routes were not removed; was possible to enter busy-loop;
* fixed RADIUS rate attribute processing in wireless;
* fixed RSTP protocol version number;
* certificates - sometimes when importing CA certificate, certificate cache was reset. Fixed;
* graphing - incorrect scale legend bugfix for large data amounts;
* improved support for realtek 8169 chip (routerboard 44G
* user manager - added PayPal payment system;
* user manager - voucher customization bugfix;
* user manager - user signup bugfix;

Przystojny jestem ;)

Nasz Antek w końcu pokazał nam swoje zadowolone oblicze. Jeszcze dwa miesiące i koniec wakacji pod serduszkiem mamusi.

tips & tricks: overall-tx-ccq / current-ack-timeout / current-distance

Jak się okazuje, ilość informacji wyświetlanych za pomocą

interface wireless monitor wlan1

zależy od ustawionego na danym interfejscie mac-address'u.
Dla przykładu gdy na karcie z Atheros AR5413 "zasymulujemy" kartę Planet przez zmianę mac-address'u na naprzykład 00:30:4F:31:F5:E9 w raporcie wyświetlonym przez powyższą komendę będzie brakować parametrów overall-tx-ccq, current-ack-timeout, current-distance:

               status: running-ap
                 band: 2.4ghz-b
            frequency: 2472MHz
          noise-floor: -96dBm
   registered-clients: 2
authenticated-clients: 2
              nstreme: no
    current-tx-powers: 1Mbps:19,2Mbps:19,5.5Mbps:19,11Mbps:19
  notify-external-fdb: no

gdy tylko przywrócimy stary mac-address otrzymamy:

               status: running-ap
                 band: 2.4ghz-b
            frequency: 2472MHz
          noise-floor: -96dBm
       overall-tx-ccq: 92%
   registered-clients: 3
authenticated-clients: 3
  current-ack-timeout: 39
     current-distance: 39
              nstreme: no
    current-tx-powers: 1Mbps:19,2Mbps:19,5.5Mbps:19,11Mbps:19
  notify-external-fdb: no

Więcej Picasa Web Albums i nie tylko

Z radością informuje iż miejsce przeznaczone pod zdjęcia w serwisie Picasa Web Albums zwiększyło się z 250MB do ... 1GB (and counting)!! Dodano również możliwość przeszukiwania udostępnionych przez innych użytkowników zdjęć za pomocą nowej opcji - Search Community Photos. Również od teraz wszystkie nowe jak i stare zdjęcia uploadowane do Blogger'a zostaną umieszczone w Picasa Web Albums.

RB532 <150m> RB532

Skuszony informacją z broszury RB44 na temat maxymalnej obsługiwanej długości przewodu Ethernetowego równej 150 metrów, postanowiłem sprawdzić jak to wygląda w przypadku RB532, do której dokumentacja nie zawiera informacji na temat obsługi dłuższych, niż to przewiduje standard, segmentów.

Do testów użyłem dwóch płyt RB532A z najnowszym systemem RouterOS 2.9.40. Przepustowość mierzyłem za pomocą wbudowanej w system funkcjonalności bandwidth-server/-test. Ponieważ test jest zasobożerny (cpu load serwera w czasie testów utrzymywał się cały czas na poziomie 100%) obie płyty okroiłem tylko do działającej paczki system. Podejrzewam, że gdyby test wykonać na dwóch dodatkowych maszynach zapiętych za testowanymi płytami, osiągnięte przepustowości były by większe.

Testowany kabel kategori 5e o długości 152m zapiąłem na porty ether3 w obu płytach (test powiódł się na wszystkich portach).

bandwidth-test: 266MHz, 64MB, RouterBOOT 2.5
bandwidth-server: 264MHz, 64MB, RouterBOOT 1.12, authenticate=no

Poniżej tabela z wynikami:

RouterBOARD 532r5

MikroTik rozpoczął sprzedaż nowych wersji płyt RB532 oznaczonych jako r5. Poniżej lista zmian dokonanych w stosunku do poprzedniej wersji:

CPU Factory tested at 400MHz
higher speed memory to support 400MHz DDR
3.3V power supply improved to handle more high-power radios (20W available at 3.3V)
over-voltage protection
power polarity protection
Speaker added
less jumpers

RouterBOARD 133/133C

W końcu, po okresie testowym, na stronie producenta pojawiła się oficjalna specyfikacja nowych tanich płyt RouterBOARD 133 oraz 133C. Idealnie sprawdzą się one jako APC współpracujące z bazą, na przykład opartą na RB532. Cena płyt to odpowiednio 89 i 59$.

Specs: RB 133/133C
OS: RouterOS Level 4
CPU: MIPS32 4Kc, 175MHz embedded
Data storage: 128MB/64MB onboard NAND
Memory: 32/16MB SDRAM
Ethernet ports: three/one Mbit ethernet ports supporting Auto MDI/X
MiniPCI slot: three/one miniPCI Type IIIA/IIIB slots
Speaker: on board
Console: DB9 Serial port
Power options: PoE 16..28V DC (except power over datalines); Power jack 9..28V DC; Overvoltage protection
Dimensions: 117mm x 105mm

tips & tricks: port knocking

Podczas "co sobotnich" porządków wpadł mi do głowy pomysł jak za pomocą address-list zaimplementować w MikroTik RouterOS metodę zabezpieczającą uruchomione na nim usługi zwaną port knocking'iem.

"Port-knocking" jest metodą pozwalającą na nawiązanie zdalnego połączenia z usługami działającymi na komputerze, do którego dostęp został ograniczony np. za pomocą filtra pakietów, umożliwiającą odróżniania prób połączeń, które powinny i nie powinny być zrealizowane.

Można uznać, że z punktu widzenia chcącego się połączyć klienta, na komputerze tym nie ma otwartych portów. System, z którego ma nastąpić połączenie, wysyła serię pakietów na zamknięte porty maszyny docelowej. Pakiety te są oczywiście ignorowane, ale odpowiednie oprogramowanie śledzi przychodzące pakiety i jeśli pakiety z danego adresu IP układają się w zdefiniowaną dla pewnej usługi sekwencję, wówczas system zezwala na połączenia z nią z tego adresu IP.

źródło: pl.wikipedia.org

Wyobraźmy sobie scenariusz w którym powinniśmy uzyskać dostęp do SSH działającego na danej maszynie pod warunkiem wysłania do niej wcześniej określonej sekwencji pakietów, na przykład: 100/tcp, 50/udp, 72/udp.

ip firewall filter [ent]
add chain=input protocol=tcp dst-port=100 action=add-src-to-address-list address-list=stage-1 address-list-timeout=5 [ent]
add chain=input protocol=udp dst-port=50 src-address-list=stage-1 action=add-src-to-address-list address-list=stage-2 address-list-timeout=5 [ent]
add chain=input protocol=udp dst-port=72 src-address-list=stage-2 action=add-src-to-address-list address-list=stage-3 address-list-timeout=5 [ent]
add chain=input protocol=tcp dst-port=22 src-address-list=stage-3 action=accept [ent]

Powyższa konfiguracja zakłada że kolejne pakiety z sekwencji będą pojawiać się nie później niż w 5 sekundowych odstępach.

tips & tricks: dst-port 25

W tym post'cie przedstawię jak skutecznie walczyć z wirusami z własnym silnikiem umożliwiającym im rozsyłanie się za pomocą poczty elektronicznej. Skutecznie .. to znaczy pozbywając się ruchu przez nie generowanego i przy okazji informując klienta o fakcie zainfekowania jego maszyny.

W iptables z modułem recent wystarczy 4 reguły a nawet 2 (bez jump'a do osobnego łańcucha):

iptables -N tcp_dport25 [ent]
iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j tcp_dport25 [ent]
iptables -A tcp_dport25 -m recent --update --seconds 10 --name smtp -j DROP [ent]
iptables -A tcp_dport25 -m recent --set --name smtp -j ACCEPT [ent]

Co robią powyższe regułki? Pierwsza tworzy nowy łańcuch o nazwie tcp_dport25. Kolejna wysyła do niego ruch wędrujący przez łańcuch FORWARD z portem docelowym 25/tcp oraz stanem połączenia NEW. Następna sprawdza w tabeli smtp czy z danego źródłowego adresu IP, w ciągu ostatnich 10 sekund, była już próba nawiązania połączenia z docelowym portem 25. Jeśli tak, to uaktualnia czas żywotności wpisu informującego o tym fakcie na 10 sekund, oraz DROP'uje próbę nawiązania połączenia. Ostatnia reguła dokonuje wpisu w tabeli smtp świadczącego o tym że z danego IP zanotowano próbę połączenia z zdalnym portem 25, oraz ACCEPT'uje to połączenie.
W tym momencie klient jest w stanie wysłać jednego maila co 10 sekund pod warunkiem że w ciągu tych 10 sekund nie próbował ponownie łączyć się do portu 25. W tym momencie wirusowi, który średnio rozsyła się z częstotliwością kilku prób na sekundę, uda się tylko jedna próba wyjścia na świat z portem docelowym 25. Wszystkie kolejne będą skutecznie blokowane.

A jak powyższy scenariusz zaimplementować w MikroTik'u?

ip firewall filter [ent]
add chain=forward protocol=tcp dst-port=25 connection-state=new action=tcp_dport25 [ent]
add chain=tcp_dport25 src-address-list=smtp address-list=smtp address-list-timeout=10s action=add-src-to-address-list [ent]
add chain=tcp_dport25 src-address-list=smtp action=drop [ent]
add chain=tcp_dport25 action=add-src-to-address-list address-list=smtp address-list-timeout=10s [ent]
add chain=tcp_dport25 action=accept [ent]

Najpierw przechodzimy do konfiguracji tabeli filter firewall'a. Następnie do automatycznie tworzonego łańcucha tcp_dport25 przekierowujemy pakiety rozpoczynające (NEW) połączenie z docelowym portem 25. W kolejnej regule sprawdzamy czy z danego IP były już próby nawiązania połączenia na port 25. Jeśli tak to uaktualniamy wpis. Następnie jeśli nadający host znajduje się już na liście DROP'ujemy połączenie. Jeśli natomiast się na niej nie znajduje dodajemy go do listy na 10 sekund. Ostatnia reguła zezwala na połączenie.

Dodając jeszcze jedną regułę można doprowadzić do tego, że z danego IP można będzie przeglądać strony www pod warunkiem czystego komputera.

ip firewall nat [ent]
add chain=dstnat src-address-list=smtp action=dst-nat to-address=[IP serwera www z stroną informacyjną] to-ports=[port na którym nasłuchuje serwer] [ent]