Saturday, December 2, 2017

Ile naprawdę jest dystrybucji systemu Linux

W ostatnim wpisie pisząc ogólnie o systemie Linux doszłem między innymi do wniosku, że na końcowy kształt systemu największy wpływ mają deweloperzy dystrybucji. W tym wpisie chciałbym poruszyć właśnie ten temat, czyli dystrybucji. Gdy patrzę na ilość dostępnych dystrybucji systemu Linux to widzę wielki nadmuchany balok, w który zaraz wbiję szpilę. Wcześniej jednak chciałbym napisać jak wygląda mniej więcej ogólnie proces powstawania dystrybucji GNU/Linux.

Wszystko zaczyna się od pewnej grupy ludzi, których łączy wspólna wizja jakiegoś kształtu dla systemu Linux. Ustalają sobie wewnętrzne zasady działania społeczności i zasady techniczne w jaki sposób będą rozwijać system, chodzi tu o cykl wydawniczy przede wszystkim. Technicznie proces ten wygląda mniej więcej tak:
  1. Pobierane są źródła poszczególnych komponentów systemu z tzw. upstream
  2. Budowane są pakiety w jakimś formacie, mogą to być np. tylko skrypty
  3. Dodawane są własne rozwiązania dotyczące organizacji systemu (instalator, sposób konfiguracji, sposób rozruchu systemu itd.)
  4. Przygotowuje się dystrybucji do wydania (obrazy .iso, witryna, społeczność, repozytoria, testowanie wersji próbnych)
  5. Udzielanie wsparcia dla wydanej dystrybucji (łatki bezpieczeństwa, usuwanie błędów, nowe wersje pakietów itp.)
Często dystrybucje różnią się tym z czego zostaną złożone, dobrym przykładem są różne odmiany programu init. Jednak większość powodów, dla których ktoś kocha albo nienawidzi daną dystrybucję pochodzi z punktu trzeciego, czyli własne rozwiązania (np. w Ubuntu i OpenSUSE własna nakładka graficzna na GNOME).

Teraz zobaczmy jak wygląda oferta dostępnych dystrybucji społeczności GNU/Linux. Jako punkt odniesienia proponuje drzewo rozwoju dystrybucji dostępne w artykule Linux distribution na Wikipedii. Dlaczego uważam, że jest to dobry punkt odniesienia? Jeżeli interesujesz się systemem Linux, to zapewne spotkałeś się już z stwierdzenie wyglądającym mniej więcej tak: "według distrowatch.com najpopularniejszą dystrybucją jest ...". Niestety distrowatch.com jest bardzo częstym źródłem informacji o najpopularniejszych dystrybucjach systemu Linux. Ja tak nie uważam, i to jest jeden z powodów, dla których powstał ten wpis. Jeżeli ktoś siedzi długo w tej tematyce i zobaczy tą listę najpopularniejszych dystrybucji na wspomnianej stronie to od razu zauważy, że cos tu się nie zgadza. Po pierwsze to należy sobie zadać pytanie jak oni to liczą, choć sami przyznają, iż nie jest to dokładny szacunek. Czy można ustalić to na podstawie ilości pobrań danej dystrybucji? Nie, często ludzie pobierają jakąś dystrybucję aby ją zainstalować, nie spodoba się i ją usuwają. Czy ilość pobranych aktualizacji jest wiarygodnym wskaźnikiem? To już lepsze rozwiązanie, ale również ma wady. Jeżeli ktoś instaluje wielokrotnie system od nowa to pobiera wielokrotnie te same aktualizacji. Z kolei duże organizacje, które mają setki instalacji często pobierają raz obraz, a następnie redystrybucją go wewnątrz swojej wewnętrznej sieci z własnych serwerów. Spotkałem się z wypowiedzią twórcy systemu MINIX, który na pytanie o popularność systemu odpowiedział, że monitoruje ilość pobrań ale nie wie, kto go pobiera i co z nim robi.

Kolejną kwestią w "bańce dystrybucyjnej" jest ilość dostępnych dystrybucji, wg. distrowatch.com jest ich ponad 300! Ręce opadają. Postaram się odnieść do tej liczby i w tym bardzo przydatne okaże się wspomniane drzewo rozwoju dystrybucji. Jeżeli na nie popatrzymy to większość dystrybucji jest formaki kilku głównych. Postanowiłem przejrzeć czym są te liczne forki. Duża rzesza to dystrybucje rozwijane przez firmy w celu dostosowania dystrybucji do potrzeb ich produktu. Jest też wiele dystrybucji nie będącymi forkami, głównym ich przeznaczeniem są systemy wbudowane. Są też takie, których głównym celem jest predefiniowana konfiguracja lub stworzenie prześlicznego środowiska graficznego. Niektóre powstały tylko z nienawiści do jakiegoś komponentu dystrybucji macierzystej (np systemd). Znalazłem również takie, których główną stroną jest blog na blogger i wyglądają raczej na hobby twórcy, niż zaspokojenie do tej pory niezaspokojonych potrzeb. Warto zwrócić uwagę, że duża ilość odszczepów umarła śmiercią naturalną. Są też takie które są zaznaczone jako ciągle rozwijane, ale ich strony www już nie działają. Wiele z nich to tylko LiveCD, bądź dystrybucje z preinstalowanym tematycznym oprogramowaniem. Jednym zdaniem podsumowując większość forków to dystrybucje  spreparowane pod czyjeś potrzeby bądź upodobania. Nie są to systemy uniwersalne jak ich macierzyste wersji.

Teraz wymienie moim zdaniem dystrybucje, które rzeczywiście mogą pretendować do miana odmiany systemu Linux, reszta to zazwyczaj przeróbki. Oczywiście mam tu na myśli dystrybucje, które są budowane w celu ogólnego przeznaczenia, a nie tylko do konkretnych upodobań. Wymienie je w kolejność wg. popularności moim zdaniem:
  1. Debian (119)
  2. Ubuntu (52) - potomek Debiana
  3. CentOS (6) - potomek RedHata
  4. RedHat (41)
  5. Gentoo (12)
  6. Slackware (37)
  7. Arch (13)
  8. ...
Wyszukiwarka Google zdobyła wielką popularność ponieważ okazała się przydatna dla wielu ludzi. Jej algorytm opiera się na liczbie linków do danej strony. Skoro tam taki algorytm się sprawdził to czemu nie zastosować go w przypadku dystrybucji. W tym celu przy ich nazwach w nawiasach podałem ilość forków wywodzących się z danej dystrybucji. Uważam, że jeżeli ktoś opiera swoją dystrybucję na jakiejś innej to znaczy, że uznał ją za dobrą podstawę. Jak widać Debian pod tym względem wygrywa, duża w tym zasługa systemu Ubuntu. CentOS nie ma wiele forków, ale wynika to z faktu, że z założenia jest kopia RedHata, która wśród serwerów jest bardzo popularna. Jeżeli chodzi o Arch i Slackware to szczerze mówiąc nie orientuje się który bardziej jest popularny, pierwszy to bardziej desktop, drugi z kolei to serwer.
We wspomnianej liście pominąłem kilka niezależnych dystrybucji, ale są to zazwyczaj dystrybucje narzędziowe bądź laboratoryjne. Dobrym przykładem jest Kali przeznaczony do testów penetracyjnych, jego zaletą jest wyposażenie w narzędzia i skrypty do tego służące. Innym przykładem jest płytka SystemRescueCd bazująca na Knoppix, z której sam wiele lat korzystałem jako zestawu narzędzi do diagnozowania i naprawiania komputerów. Z kolei przykładem pewnego rodzaju eksperymentu bądź laboratorium jest Qubes OS, którego celem demonstracja najbardziej bezpiecznego złożenia systemu. Sam niedawno instalowałem dystrybucję, która wyposażona jest w narzędzia do inspekcji sieciowych pakietów. Także jak widać wiele forków jest stworzona w celu konfiguracji systemu pod konkretne zadania.

Oczywiście przedstawiona przeze mnie lista nie jest idealna, ponieważ można by zrobić oddzielną dla desktopów i serwerów. Poza tym część z nich jest komercyjna, jednej z nich np. SUSE nawet nie wymieniłem. Nie wymieniłem również Fedory, która jest poligonem doświadczalnym RedHata. Z kolei surowa liczba obecnie żyjących forków też nie jest idealnym wskaźnikiem. Możnaby wybrać tylko te, które mają już co najmniej np. 7 lat. Ale myślę, że rozdrabnianie się na te szczegóły nie ma już dalej sensu, bo i tak każdy wybierze według upodobania lub potrzeb. Nie mniej łatwiej wybrać z ok. 10 niż 300. Należy, również nadmienić, że wybierając dystrybucję bazową pod nową dystrybucję deweloperzy chyba najbardziej kierują się stabilnością rozwoju takiej dystrybucji. Tak więc takie stabilne, ale przestarzałe dystrybucje są dobrą podstawą dla nowej dystrybucji z aktualniejszymi pakietami.

Nie ma co się przejmować ilością istniejących dystrybucji, bo to co będzie potrzebne przetrwa, reszta nie. Taka jest natura wolności open source. Myślę, że dobrze tą sytuację oddaje to co kiedyś Winston Churchill powiedział, że demokracja, to zarazem najlepszy i najgorszy system jaki do tej pory wymyślono.

Thursday, November 23, 2017

Linux nie jest idealny, ale jest!

Z okazji zbliżającego się 10-lecia mojego przejścia na system Linux postanowiłem co nieco napisać na jego temat. Z drugiej strony nie chciałbym powtarzać rzeczy napisanych gdzie indziej, więc wyszło na to, że trzeba by napisać to w sposób mało spotykany. No i fajnie, napiszemy o tym o czym zazwyczaj wyznawcy systemu Linux nigdy by Ci nie powiedzieli. Hy czyli wyjdzie takie nietypowe 10-lecie - bez słodzenia.

Na wstępie należałoby napisać dla kogo GNU/Linux będzie dobrym systemem. Pominę zachwalanie, o osiągnięciach systemu Linux o tych wszystkich superkomputerach i super możliwościach. Najkrócej rzecz ujmując Linux jest systemem przemysłowym, którego możesz również używać legalnie w swoim domu. Tym mniej więcej Linux różni się od UNIX-a, którego nie mogłeś używać w domu. A czemu przemysłowym? Cóż, bo rozwijany jest głównie przez przemysł informatyczny i głównie w nim jest używany. Czy to znaczy, że Linux nie nadaje się do małych firm jako darmowa platforma do pewnych usług sieciowych. Ależ nadaj i to wyśmienicie. No dobrze, a co z używaniem Linuksa w domu na tzw. desktopie? - liczyłem na to, że o to zapytasz :) Cóż, powiem tak. Jeżeli nie interesuje Cię informatyka w szerokim tego słowa znaczeniu to nie polecałbym go, chyba, że zależy Ci na tym aby mieć legalny i darmowy system w domu. Oczywiście kosztem jakiś problemów czy to z obsługa sprzętu albo koniecznością grzebania w systemie. Z kolei jeżeli jesteś zapaleńcem informatyki, jest Ci ona ważniejsza od grania w gierki (czyli mniej więcej wtedy jak wydoroślejesz ;)  i jeszcze wcześniej kupisz sprzęt z myślą o tym aby Linux go obsłuży to pannie..., aż strach mówić co się stanie. Od 10 lat na komputerze domowym, obecnie laptopie używam dystrybucji Debian w wersji stabilnej i powiem, że nie wiele to się różni od Mac OS X.

Więc jakie to wspaniałe rzeczy można robić na systemie Linux? Uczyć się! Tak, bo przecież fascynuje Cię informatyka, prawda? Możesz uczyć się na programistę, administratora systemów i sieci, specjalistę od bezpieczeństwa, pentestera i pewnie jeszcze kilka specjalizacji o których zapomniałem. A co jeżeli Ciebie po prostu interesuje jak działa system i cały komputer? Cóż, przykro mi, ale pewnie zostaniesz informatykiem - tak było ze mną i wieloma innymi fascynatami systemu Linux. Dla osoby interesującej się informatyką system open source jest bardzo atrakcyjny.

Z Linuksem to ciekawa historia wyszła. Po pierwsze to nikt tego do końca tak nie planował, co tylko świadczy o tym, że widocznie istniało zapotrzebowanie na ogólnie dostępny system operacyjny. Początki powstawania Linuksa sięgają lat 80-tych gdy powstał projekt wolnego systemu zwany GNU. Wtedy tak naprawdę powstała większość narzędzi używana dziś w systemie Linux. Później w latach 90-tych projekt GNU doczekał się jądra systemu i to właśnie od niego wywodzi się nazwa systemu. Popularności dla jądra Linux na pewno dodawał fakt, iż od początku było pisane z myślą o architekturze x86. A co to daje? Architektura Intel x86 to nic innego jak upowszechnienie komputerów domowych. Dorzucił się do tego również IBM swoim otwartym standardem PC. Tak więc komputery stawały się powszechne, ale na te powszechne komputery w tamtych czasach nie było systemu Unix. Zarówno narzędzia GNU jaki i jądro Linux były wzorowane na systemach Unix. Często można spotkać się ze stwierdzeniem, iż GNU/Linux to nie UNIX. Ależ to jest UNIX, tylko napisany od nowa i na powszechną architekturę x86. Całe to wydzielanie systemów na UNIX i Unix-like odnosi się tylko do tego, czy dany system wywodzi się z rodziny pierwszych systemów UNIX, czy też nie. Poza tym nazwa UNIX była zarejestrowana itd., więc co z tego, że Linux nie wywodzi się ze żadnego systemu UNIX skoro jest jego klonem. Wiele osób zarzuca dla systemu Linux, że nie jest zgodny ze standardami UNIX i nie zasługuje na to aby go tak nazywać. Cóż, wydaje mi się, że oczekiwanie od nowoczesnych systemów 100% zgodności ze wzorcami stworzonymi ponad 40 lat temu trochę mija się z celem. Po prostu Linux jest nowoczesną odmianą systemu typu Unix i to do tego bardzo dojrzałą. Dla przykładu, pierwsza firma żyjąca z rozwoju i wsparcia systemu Linux, czyli RedHat ma już 24 lata. Mało która komercyjna odmiana system UNIX rozwijana jest tak długo. Dla porównania system Solaris rozwijany jest przez prawie taki sam okres czasu, z tym, że już zdążył zmienić właściciela i teraz to już jest Oracle Solaris. Tak więc jak na całą epokę systemów UNIX system GNU/Linux przetrwał bardzo długo i co najciekawsze, obecnie jest w kulminacyjnym okresie swojego rozwoju.

Skoro już było o historii to czas też na przyszłość systemu Linux. Więc obecne trendy w tym systemi to chmury i systemy wbudowane. Nikt nie wie jaka do końca czeka przyszłość system z pod znaku pingwina ale wiadomo jest, iż obecny otwarty model rozwoju systemu po prostu się sprawdza. Może wydawać się to dziwne, ale dla Linuksa udało się połączyć rozwój systemu do użytku prywatnego i komercyjnego. Każda ze stron rozwija go na swoje potrzeby, a że duży może więcej to rozwiązania desktopowe rozwijają się jakieś cztery razy wolniej niż serwerowe. Wydaje mi się że klejem, który to  wszystko jeszcze trzyma jest to, że system ten jest tak konfigurowalny, iż każda ze stron różnych interesów składa go na swój sposób. Tak więc powstał w pewnym sensie uniwersalny system Unix. Jeszcze nigdy w historii IT z jednego systemu nie żyło tyle firm co dziś z Linuksa. Kiedyś każda z firm miała swoją odmianę i rozwój systemu Unix był bardzo rozproszony. Dziś jest scentralizowany i dzięki temu jest najszybciej rozwijającym się systemem. Czy jest to powód tylko do dumy? Nie zawsze, ale jaki już pisałem, na razie ten model się sprawdza.

Nadszedł czas aby powiedzieć sobie co złego jest w systemie Linux. A no chyba to co jest w nim najlepsze, czyli rozproszony rozwój. Zauważ, że rozwijanie nowych funkcjonalność w tym systemie odbywa się głównie na poziomie poszczególnych komponentów. Intel chce lepszego wsparcia sprzętu - rozwija jądro. Komuś innemu zależy na obsłudze protokołu SMB - rozwija projekt Samba. W każdym z tych projektów poziom rozwoju jest bardzo wysoki, ale w końcu przychodzi czas na złożenie kompletnego systemu i tu wkraczają do akcji deweloperzy wszelkich dystrybucji. Im jest ich więcej w danej grupie tym system udaje się lepiej, ale z tym bywa różnie. Właśnie tym problemem zajmuje się większośc firm żyjąca z Linuksa: RedHat, Oracle, Novell, Canonical. Istnieje również cała masa niekomercyjnych organizacji zajmujących się składaniem systemu z kawałków GNU. Bez wątpienia najlepiej udaje się to dla społeczność systemu Debian, co mogę osobiście potwierdzić.

Budowa systemu, zwłaszcza tak zaawansowanego jest bardzo czasochłonnym i kosztownym zajęciem, więc wydaje się że coraz więcej firm zaczyna to akceptować i dorzuca swój cenny czas w rozwój wspólnego systemu. Stało się to już trendem, więc doszło już do czegoś takiego, że jak firma chce być konkurencyjna to czasami musi sięgnąć po gotowy system, nawet jeżeli nie chce. Dziwna sytuacja, firmy stały się zakładnikami własnych praw ekonomii - czyli 'tnijta koszty'. Geniusz Stallman, czy czysty przypadek? Ale z drugiej strony, skoro USA z Rosją razem rozwijają Międzynarodową Stację Kosmiczną, to czego tu się czepiać. Widocznie taka jest natura rozwoju wielkich projektów, należy to zaakceptować i póki co korzystać.

Koniec końców, wydaje mi się, że największe podziękowania za wkład w rozwój systemu GNU/Linux należą się jego najmniejszym twórcom a nie dużym firmom, bo te wcale by się nim nie zainteresowały gdyby nie wkład fascynatów. Wychodzi na to, że najpopularniejszy system przemysłowy narodził się w... domu. Co za ironia losu.

Sunday, May 15, 2016

Home Lab - Cisco & MikroTik

I would like to share with you my experience of building a network home lab. If you think about to build your own network home lab some of this tips can be useful for you. At the beginning i want to discuss about why to do it and what is the goal of my lab. Even if you have other goal some basic concepts will stay the same.

The first assumption is to do it cheaply. If you live in country where GDP is not the biggest you want to build lab but don't spend all money for it ;)
The second assumption is to have switching, routing and WiFi in lab. Switching give you Cisco devices, routing you have in MikroTik (or Cisco) and WiFi in MikroTik. From my perspective it is the best combination and I will explain why.

When I had chosen Cisco switch I didn't want pass the exam certificate for CCNA or another. I'm just need a professional management switch. That is the reason why I buy End-of-life devices. My choice is Cisco Catalyst 2950 and Cisco Catalyst 3550. The first is switching only device (L2 only), the second switch is combination switching and routing (L2+L3).

Cisco 2950 is great switch, it have all what probably you will need. It have not large size like on switch, low power consumption and it is be quiet. And of course it's cheap today (2016). Another switch Cisco 3550 made a bad first impression for me, is big, noisy and it costs two times more than 2950. But, when I tested it I change the mind. Now it is my favorite switch, but in beginning I have big problem with it. When I enable routing it's working less then one minute and stop working. Upgrade system for highest available version resolved this problem.
So first things which you should do is upgrade all Cisco switch, but here is the next problem. Usually this switch from auctions is send without any cable. So you to have need own power cable and console cable. About console cable, it have two connector, RJ-45 to switch and DB9 to computer (serial port). If you don't have serial port in your computer you need also to have serial port to USB adapter. And finally you can use and upgrade your Cisco switch ;)

Another bad things about this switch is that it's very old and yet not support auto-negotiation (Auto-MDI/MDIX). The result is that, if you want connect two switch together via Ethernet cable you need crossover cable. Yes, and this moment I finish the bad news about Cisco switch 2950 and 3550, it's time for good news :)

I have three Cisco switch in my lab (two 3550 and one 2950), I think it's enough to test of switching (e.g. STP). Now I little describe the 3550 switch. As I had said earlier 3550 offers routing. 2950 can have only one IP address mainly to management, but 3550 can have many IP address. Each port can by used of two mode, routable (L3) and not routable (L2). But you can set L2 port with and without IP address, in result you get three combinations: port L3 (routing), L2+L3 (VLAN + IP) and L2 (VLAN without IP). If you use last combination you can simulate many switches in one 3550 switch. In fact one 3550 switch allows you to use one switch as one router and many switches. That its great.
And I will be forgot, 3550 is selling with two version SMI and EMI. The SMI version don't have all dynamic routing protocol, EMI version have got, but cost double than SMI version of devices. The next great good news is that in the SMI version you can upload EMI image without any technical problem.

Time to describe second type of device which is MikroTik. First of, why MikroTik? Two reasons. The first it's big configuring possibility and CLI interface. The second it's new model named MikroTik hAP lite. It is designed to home use and it's cost is low. In my country in 2016 year one new device of this model cost the same as one Cisco 2950 switch. MikroTik hAP lite has the same version operating system as MikroTik RouterBoard, it has only less powerful equipment (CPU, RAM, etc.). I've three this devices and I'm very happy with them. This MikroTik router with Cisco switch 3550 you can use at the same time as WAN router and as LAN AP, is sufficient that you divide ether-* ports in MikroTik. Generally I think Cisco switch and MikroTik router is a great combination.

The below presents schematic of network in my home lab. With this equipments and computers with Linux system I can simulate any type of Linux service in network (WAN, LAN, WLAN).


And how its looks.





Wednesday, May 11, 2016

GNU/Linux - maxload in fight with overload

Your server is too busy?
You have problem with overload?
You want use CPU resource more effective?

If your answer is YES, maybe you are interested maxload. maxload allow you to run a very intensive task which can be paused and protects your server from overload.

Suppose your Linux server consumes 40% of CPU resource. So you have reserve of 60%. You want use from it but you worry about overload because you don't have control over how much your task will use of CPU resource. maxload resolves this problem and give you possibility to use your CPU say in 99%.

Example
You have very large folder and you must create a backup for this files. This is a very intensive task for CPU and disk. So you create a script like below.

cat backup.sh
#!/bin/bash
tar -cjpf /root/backup/site_file.tar.bz2 /var/www/html/example.com/public_html

Next what you do is run it via maxload and set correct border value for maxload. Suppose your server has 4 CPU cores visible in operating system. So if you want use ~90% of CPU you must set max border on 3.6.

maxload 3.6 /root/backup/backup.sh

More about maxload you can read in GitHub.


Friday, April 15, 2016

MikroTik + remote syslog server

In this post I show how to configure Linux server syslog with MicroTik. The goal is register networks connectivity "like" the ISP must do. Why external syslog? Because it is the best way, first MikroTik don't has too much storage capacity, second external syslog service is the most flexible solution. Once configured logsys server can be used in future to gather logs from other devices e.g. switch.

So in our scenario we have two devices, MikroTik router and Linux server. First we configure the syslog service. I use Debian 8 (jessie) Linux distribution where default server logs is rsyslogd. In the config file /etc/rsyslog.conf we must uncomment the lines below.

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

Next we restart syslog service.

systemctl restart rsyslog.service

Of course you must check is your firewall not block traffic on the port UDP 514 in your server. If you use SELinux (like CentOS) you must also enable this port in SELinux.
This is all what you must do in your Linux server. Now we start configure our MikroTik router. First we set remote syslog server.

[admin@R2] /system logging action> print 
Flags: * - default 
 0 * name="memory" target=memory memory-lines=1000 memory-stop-on-full=no 

 1 * name="disk" target=disk disk-file-name="log" disk-lines-per-file=1000 disk-file-count=2 disk-stop-on-full=no 


 2 * name="echo" target=echo remember=yes 


 3 * name="remote" target=remote remote=0.0.0.0 remote-port=514 src-address=0.0.0.0 bsd-syslog=no syslog-time-format=bsd-syslog 

     syslog-facility=daemon syslog-severity=auto 
[admin@R2] /system logging action> set 3 remote=172.16.16.101

Next the logs marked as info (topics) redirects to remote target (action).

[admin@R2] > /system logging print 
Flags: X - disabled, I - invalid, * - default 
 #    TOPICS                                                       ACTION                                                      PREFIX    
 0  * info                                                         memory                                                                
 1  * error                                                        memory                                                                
 2  * warning                                                      memory                                                                
 3  * critical                                                     echo                        
[admin@R2] > /system logging set 0 action=remote 
[admin@R2] > /system logging print               
Flags: X - disabled, I - invalid, * - default 
 #    TOPICS                                                       ACTION                                                      PREFIX    
 0  * info                                                         remote                                                                
 1  * error                                                        memory                                                                
 2  * warning                                                      memory                                                                
 3  * critical                                                     echo                           

Now we do most important things. We create firewall rule in MikroTik from which it will depends range and intensity of data logs. In this example we will be log only TCP 80 and 443 traffic (http, https). To make this rule work we must put it top on the forward chain.

[admin@R2] /ip firewall filter> add chain=forward protocol=tcp dst-port=80,443 action=log disabled=no log-prefix=R2
[admin@R2] /ip firewall filter> print 
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=output action=accept log=no log-prefix="" 

 1    chain=input action=accept in-interface=ether1-gateway log=no log-prefix="" 

 2    chain=input action=accept log=no log-prefix="" 

 3    chain=forward action=accept log=no log-prefix="" 

 4    chain=input action=accept connection-state=new log=no log-prefix="" 

 5    ;;; default configuration
      chain=input action=accept protocol=icmp log=no log-prefix="" 

 6    ;;; default configuration
      chain=input action=accept connection-state=established,related log=no log-prefix="" 

 7 X  ;;; default configuration
      chain=input action=drop in-interface=ether1-gateway log=no log-prefix="" 

 8 X  ;;; default configuration
      chain=forward action=fasttrack-connection connection-state=established,related,new log=no log-prefix="" 

 9    ;;; default configuration
      chain=forward action=accept connection-state=established,related,new log=no log-prefix="" 

10    chain=forward action=accept in-interface=all-ethernet out-interface=all-ethernet log=no log-prefix="" 

11    chain=forward action=accept in-interface=ether1-gateway out-interface=ether2-master-local log=no log-prefix="" 

12    chain=forward action=accept in-interface=ether2-master-local out-interface=ether1-gateway log=no log-prefix="" 

13    ;;; default configuration
      chain=forward action=drop connection-state=invalid log=no log-prefix="" 

14 X  ;;; default configuration
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface=ether1-gateway log=no log-prefix="" 

15    chain=forward action=log protocol=tcp dst-port=80,443 log=no log-prefix="R2" 
[admin@R2] /ip firewall filter> move 15 destination=2

But this rule has one defect, it logs everything, and we get a lot of data. So we must add special option which tells our rule to log only start new connection (state NEW).

[admin@R2] /ip firewall filter> set 2 connection-state=new       
[admin@R2] /ip firewall filter> print 
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=output action=accept log=no log-prefix="" 

 1    chain=input action=accept in-interface=ether1-gateway log=no log-prefix="" 

 2    chain=forward action=log connection-state=new protocol=tcp dst-port=80,443 log=no log-prefix="R2" 

...

We still can improve our rule using options limit, which work like in Linux iptables. The point is, when we have 100 connections from the same host per minute we can limit this data to e.g. only first 5 of them.
Ok, time to test our solution. Now I connect to the Internet from my tablet through MikroTik and I get this log:

root@probook:~# tail /var/log/user.log 
Apr  2 19:37:45 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:33976->216.58.209.46:443, len 60
Apr  2 19:37:46 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:37422->216.58.209.42:443, len 60
Apr  2 19:37:54 probook gnome-session[1456]: (gnome-settings-daemon:1519): GLib-CRITICAL **: Source ID 2018 was not found when attempting to remove it
Apr  2 19:46:07 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43287->212.77.100.114:443, len 60
Apr  2 19:49:07 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43288->212.77.100.114:443, len 60
Apr  2 19:52:07 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43289->212.77.100.114:443, len 60
Apr  2 19:56:07 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43290->212.77.100.114:443, len 60
Apr  2 19:59:29 probook google-chrome.desktop[2048]: [2048:2079:0402/195929:ERROR:socket_stream.cc(210)] Closing stream with result -7
Apr  2 20:00:07 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43291->212.77.100.114:443, len 60
Apr  2 20:04:25 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43292->212.77.100.114:443, len 60

The logs we can identified by prefix R2, which I add to the firewall rule or by source IP address. You can change destination where is the logs saved [1]. The R2 is the name of my MikroTik in my home lab, and I had connected via VLAN20, what you can see in logs.

[1] http://www.rsyslog.com/storing-messages-from-a-remote-system-into-a-specific-file/

Saturday, April 2, 2016

Mikrotik + zewnętrzny serwer logów syslog

W tym wpisie pokażę prosty przepis jak skonfigurować serwer logów z MikroTik'iem. Z założenia chodziło o to, aby zapisywać logi ruchu sieciowego, tak jak to niby ISP ma obowiązek ;). Dlaczego na serwerze zewnętrznym? Bo to najlepszy sposób, po pierwsze MikroTik nie ma zbyt zasobnej pamięci, a po drugie to najbardziej elastyczna metoda. Raz skonfigurowany serwer logów może być później wykorzystany wielokrotnie, np. do zbierania logów również ze switcha.

Więc mamy dwa urządzenia, router MikroTik (MT) i serwer Linux. Najpierw na serwerze ustawiamy demona logów. Jak to robię na Debianie 8 (jessie) gdzie jest rsyslog. W pliku /etc/rsyslog.conf usuwamy komentarze z poniższych linii:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

Następnie resetujemy usługę:

systemctl restart rsyslog.service

Oczywiście trzeba się upewnić, czy port UDP 514 na naszym serwerze jest otwarty w zaporze, w przypadku systemu CentOS trzeba jeszcze włączyć ten port w SELinux.
I to by było wszystko co musimy właściwie zrobić na Linuksie, teraz przechodzimy do MT i ustawiamy zdalny serwer logów:

[admin@R2] /system logging action> print 
Flags: * - default 
 0 * name="memory" target=memory memory-lines=1000 memory-stop-on-full=no 

 1 * name="disk" target=disk disk-file-name="log" disk-lines-per-file=1000 disk-file-count=2 disk-stop-on-full=no 


 2 * name="echo" target=echo remember=yes 


 3 * name="remote" target=remote remote=0.0.0.0 remote-port=514 src-address=0.0.0.0 bsd-syslog=no syslog-time-format=bsd-syslog 

     syslog-facility=daemon syslog-severity=auto 
[admin@R2] /system logging action> set 3 remote=172.16.16.101

Następnie logi typu info przekierujemy do celu remote:

[admin@R2] > /system logging print 
Flags: X - disabled, I - invalid, * - default 
 #    TOPICS                                                       ACTION                                                      PREFIX    
 0  * info                                                         memory                                                                
 1  * error                                                        memory                                                                
 2  * warning                                                      memory                                                                
 3  * critical                                                     echo                        
[admin@R2] > /system logging set 0 action=remote 
[admin@R2] > /system logging print               
Flags: X - disabled, I - invalid, * - default 
 #    TOPICS                                                       ACTION                                                      PREFIX    
 0  * info                                                         remote                                                                
 1  * error                                                        memory                                                                
 2  * warning                                                      memory                                                                
 3  * critical                                                     echo                           

Teraz najważniejsze, ustawiamy regułę w zaporze MT, to od niej zależy stopień i intensywność logowania. Ja założyłem, iż przechwytujemy tylko ruch po protokole TCP i portach 80 i 443 (czyli http i https). Musimy również umieścić naszą regułę na początku łańcucha forward:


[admin@R2] /ip firewall filter> add chain=forward protocol=tcp dst-port=80,443 action=log disabled=no log-prefix=R2
[admin@R2] /ip firewall filter> print 
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=output action=accept log=no log-prefix="" 

 1    chain=input action=accept in-interface=ether1-gateway log=no log-prefix="" 

 2    chain=input action=accept log=no log-prefix="" 

 3    chain=forward action=accept log=no log-prefix="" 

 4    chain=input action=accept connection-state=new log=no log-prefix="" 

 5    ;;; default configuration
      chain=input action=accept protocol=icmp log=no log-prefix="" 

 6    ;;; default configuration
      chain=input action=accept connection-state=established,related log=no log-prefix="" 

 7 X  ;;; default configuration
      chain=input action=drop in-interface=ether1-gateway log=no log-prefix="" 

 8 X  ;;; default configuration
      chain=forward action=fasttrack-connection connection-state=established,related,new log=no log-prefix="" 

 9    ;;; default configuration
      chain=forward action=accept connection-state=established,related,new log=no log-prefix="" 

10    chain=forward action=accept in-interface=all-ethernet out-interface=all-ethernet log=no log-prefix="" 

11    chain=forward action=accept in-interface=ether1-gateway out-interface=ether2-master-local log=no log-prefix="" 

12    chain=forward action=accept in-interface=ether2-master-local out-interface=ether1-gateway log=no log-prefix="" 

13    ;;; default configuration
      chain=forward action=drop connection-state=invalid log=no log-prefix="" 

14 X  ;;; default configuration
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface=ether1-gateway log=no log-prefix="" 

15    chain=forward action=log protocol=tcp dst-port=80,443 log=no log-prefix="R2" 
[admin@R2] /ip firewall filter> move 15 destination=2

Tak wygląda reguła w najprostszej postaci, ale ma ona pewien defekt, loguje wszystko! Więc dodajemy odpowiednią opcję aby logował tylko początek połączenia (stan NEW):

[admin@R2] /ip firewall filter> set 2 connection-state=new       
[admin@R2] /ip firewall filter> print 
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=output action=accept log=no log-prefix="" 

 1    chain=input action=accept in-interface=ether1-gateway log=no log-prefix="" 

 2    chain=forward action=log connection-state=new protocol=tcp dst-port=80,443 log=no log-prefix="R2" 

...

Można jeszcze ją ulepszyć poprzez dodanie opcji limit, działa ona tak jak w iptables. Chodzi o to, że gdy mamy np. 100 połączeń na minutę do tego samego hosta to wystarczy nam tylko np. 5 z nich w logach.
Ok, czas na test, łączę się z tabletu z internetem przez MT i w systemie mam logi:

root@probook:~# tail /var/log/user.log 
Apr  2 19:37:45 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:33976->216.58.209.46:443, len 60
Apr  2 19:37:46 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:37422->216.58.209.42:443, len 60
Apr  2 19:37:54 probook gnome-session[1456]: (gnome-settings-daemon:1519): GLib-CRITICAL **: Source ID 2018 was not found when attempting to remove it
Apr  2 19:46:07 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43287->212.77.100.114:443, len 60
Apr  2 19:49:07 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43288->212.77.100.114:443, len 60
Apr  2 19:52:07 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43289->212.77.100.114:443, len 60
Apr  2 19:56:07 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43290->212.77.100.114:443, len 60
Apr  2 19:59:29 probook google-chrome.desktop[2048]: [2048:2079:0402/195929:ERROR:socket_stream.cc(210)] Closing stream with result -7
Apr  2 20:00:07 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43291->212.77.100.114:443, len 60
Apr  2 20:04:25 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43292->212.77.100.114:443, len 60

Logi możemy identyfikować poprzez prefix R2 jaki dodałem w regule zapory lub przez adres IP źródła. Jeżeli chcesz aby logi zapisywały są we wskazanej lokalizacji, to oczywiście możesz to zmienić[1]. R2 to oznaczenie mojego MT w moim labie a ja łączyłem się przez VLAN20, co jest zresztą w logach.

Tuesday, January 12, 2016

Arduino do nauki elektroniki

W sieci jest wiele tekstów i opinii na temat, czy Arduino jest dobre dla kogoś, kto chce nauczyć się elektroniki od podstaw. Oczywiście ja przedstawię tu swoją pozytywną opinię ale muszę przyznać, że w tych negatywnych też jest trochę prawdy. Wynika to z tego, iż co innego gdy ktoś bierze się za programowanie mikrokontrolera nie mając pojęcia ani o elektronice ani o programowaniu. Gdy zna się na programowaniu to jest o połowę prościej - tak mi się wydaje. Wtedy można skupić się tylko na elektronice i sprzęcie, bo "rozmawia" się przecież w ojczystym języku :) Dlatego uważam, że Arduino jest bardzo dobrym rozwiązaniem dla informatyka, ale i nie tylko.

Nagrałem nawet dwa projekty, które gdzieś tam w wolnym czasie sklepiłem na szybko. Pierwszy to nic innego jak pewnego rodzaju analogia do wyświetlacza w sprzęcie muzycznym, który wskazuje natężenie dźwięku - niestety nie miałem jak puścić tego dźwięku jednocześnie aby było go słychać.
Drugi to zdalna kontrola diodą RGB za pomocą pilota. Chciałem zrobić sterowanie TV z Arduino poprzez przechwycenie kodu mojego pilota (co mi się udało) i wysłanie go z diody IR, którą mam, ale nie znalazłem biblioteki do niej, a nie miałem czasu zagłębiać się w temat.



Teraz trochę opowiem o tym sprzęcie i jego jakiś głównych cechach. Otóż Arduino Uno Rev 3 ma mikrokontroler ATmega328p firmy Atmel, najlepiej w obudowie DIP, gdyż z takiej sam mikrokontroler można wyjąć lub wymienić go. Można również wybrać taki mikrokontroler w obudowie SMD, ale wtedy to już lepiej Arduino Leonardo. ATmega328p jest to mikrokontroler typu AVR w architekturze RISC, czyli tak jak ARM (RISC), które często mamy w telefonach i tabletach. Jeżeli mówimy o nauce elektroniki od podstaw to chyba warto wspomnieć czym właściwie różni się mikrokontroler od procesora. Najprościej wytłumaczyć to w ten sposób - jeżeli wiesz, że komputer składa się z wielu podzespołów złożonych razem takich jak CPU, RAM, HDD, Mainboard, to mikrokontroler jest tym wszystkim w jednym kawałku krzemu. Oczywiście wtedy jego komponenty mają inny charakter, jak np. dysk twardy, wtedy to jest pewna odmiana pamięci flash i dlatego taki mikrokontroler różni się sposobem połączenia tych wszystkich elementów, co zwie się architekturą. Taki mikrokontroler ma w sobie zintegrowany CPU ale nie ma on takich wydajności jak typowe procesory choćby w laptopach. Dokładnie to we wspomnianym modelu jest to 20 MHz.

Warto również poruszyć temat programatora, bo Arduino samo w sobie, tak naprawdę jest "płytką prototypową" jak to jego producenci określają. A co należy rozumieć przez płytkę prototypową? A no, to nic innego jak płytka z zintegrowanym mikrokontrolerem (tym zajmuje się drugi mikrokontroler do USB na płytce w obudowie SDM) i niezbędnym obwodem do pracy głównego mikrokontrolera. Gdyby nie to, to potrzebowałbyś oddzielnego mikrokontrolera i oddzielnego obwodu z głównym mikrokontrolerem, co wyglądałoby jak kupa kabli i nie byłoby tak wygodne jak gotowa elegancka płytka. W sieci znajdziecie wiele poradników jak złożyć samemu taką płytkę na płytce stykowej jeżeli kogoś to interesuje tak jak mnie interesowało :).

Na rynku dostępnych jest wiele podobnych rozwiązań, zwłaszcza osoby interesujące się systemem GNU/Linux powinny kojarzyć projekt Raspberry Pi. Więc czym różni się Arduino od Raspberry Pi? Podstawowa różnica to możliwości mikrokontrolera, o ile można go tak nazwać. Z założenia nim jest, ale nie wszystko ma zintegrowane w środku, potrafi korzystać z zewnętrznych kości pamięci ale ogólnie jest zintegrowany. Za możliwościami idzie oprogramowanie, w Arduino jest relatywnie prosty procesor, więc i do nauki jest w sam raz. Z kolei w Raspberry Pi procesor umożliwia już uruchamianie zaawansowanych systemów wielozadaniowych (tak tak to GNU/Linux) i jednocześnie oferuje jeszcze piny I/O ale nie są one już dostępne bezpośrednio jak w Arduino. W Raspberry Pi pinami I/O sterujemy za pomocą odpowiedniej biblioteki, najczęściej w Pythonie. jeżeli nie wyraziłem się dość jasno to polecam obejrzeć to wideo. Więc dla mnie jako weterana z GNU/Linux generowanie sygnałów 5V z systemu Linux za pomocą skryptów Pythona to mało pouczające, zwłaszcza dla takiej osoby. Ponadto gdy weźmie się cenę Raspberry Pi to tym bardziej się nie opłaca.

Powiem słów parę jeszcze o modułach do Arduino, które są sprzedawane wraz z nim lub osobno. Cóż większość z nich jest drugiej jakości, dla przykładu taki czujnik dźwięku, który testowałem jest tak czuły, iż odróżnia chyba tylko dwa stany natężenia dźwięku: wybuch bomby z 1 i 10 metrów :) Chociaż do zrobienia czegoś takiego może i by się nadał :) No ale skoro ma być tanio to i tak nie taki zły kompromis, ponieważ nauczysz się jak działają takie urządzenia, a czujnik zawsze można kupić lepszy jeżeli będzie potrzebny. Oczywiście nie wszystkie moduły są takie lipne, są też i dobre.

Ostatnią rzeczą jaką chcę nadmienić, jest to, że Arduino ma przeważnie gotowe biblioteki do wielu modułów. Nie zawsze ale i tak to jest lepsze niż to, z czym ja miałem do czynienia na studiach, czyli płytką Texas Instruments, z którą aby cokolwiek zrobić trzeba było ustawić dziesięć flag. Oczywiście, gdyby zabrać z Arduino biblioteki to tu również będzie taka sytuacja, ale nie jest.

Wypada jeszcze dodać, że w pewnym sensie Arduino i temu podobne są przygrywką do tzw. IoT, czyli Interentu rzeczy. Zapewne słyszałeś już o inteligentnych domach, który zapala światło gdy przychodzisz, spuszcza wodę gdy wychodzisz ;) To wszystko jest realizowane na bazie małych minikomputerów do których podłączona jest masa czujników i przełączników. Oczywiście inteligentne domy to tylko przykład, ja podam swój, który mnie bardziej interesuje. Chodzi o moduł Arduino Ethernet Shield, który również sobie zakupiłem i możliwość monitorowania parametrów np.... Na przykład w szafce sieciowej, gdzie w lato może być naprawdę gorąco możemy wsadzić Arduino, które będzie za pomocą czujnika temperatury sprawdzać czy nie jest za gorąco i odpowiednio włączać jakieś urządzenie chłodzące poprzez przełącznik 230V. Bardzo prosty projekt do wykonania i bardzo przydatny. Można go również zlutować na stałe gdy konstrukcja się sprawdzi i urządzenie gotowe.

Na koniec jako inspirację podsunę projekt, który również można wykonać z Arduino, a jest nim LED Cube.