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.