МikroТik advanced firewall
http://www.mikrotik.com/
Защитна стена – Уикипедия
МikroТik advanced firewall with multiple WAN ports without NAT
Този пост ще ви спести милото въведение което ще ви остави развълнувани, но незащитени в реалния свят, както и грубото разкриване на истината за сигурноста ви, което ще остави всички ви, с изключение на най коравите души, смутени, паранойчни и търсещи тежко оръжие!
Съжалявам да ви го кажа но вашата мрежа не е сигурна. Проблемът е позволяването на бързи и удобни комуникации, както и не винаги използването и за добри цели. Отдавна вече е ясно, че виновни и граница няма, защото ако всички знаят, че има свобода на словото, все някой в претъпканото кино ще извика “ПОЖАР!”
Интернет е пълен с ръководства как да конфигурираме Микротик рутер в домашна мрежа – респективно NAT. За мултиван има тук-таме някои проблясъци които като ги зглобя на парче и накрая светлината в тунела се оказва идващ насреща влак! Затова ще се опитам да споделя моя скромен опит и ако някой добър системен администратор открие грешка тук дано не си я крие за себе си и тайничко да си злорадства!
Линк към конфигурацията на рутера на която ще обърнем внимание по долу:
MikroTik Advanced Firewall txt file
Основната ни работа е веригата filter която включва:
INPUT – пакети идващи към интерфейсите на рутера (не важи за преминаващите). Тези пакети нямат нищо общо с мрежите зад рутера. На практика те са адресирани към него и търсят евентуално услугите му DNS, FTP, pptp, Proxy и др.
FORWARD – пакети преминаващи през интерфейсите на рутера. След като нямаме NAT е малко неестествено да кажем, че пакетите са адресирани за мрежи зад рутера, по скоро правилното е, че тази верига обслужва мрежите който рутера маршрутизира тоест, трафика между интерфейсите.
OUTPUT – пакети излизащи от интерфейсите на рутера
/ip firewall filter |
Веригата INPUT
Трябва да се уверим, че пакетите принадлежащи на съществуващите вече връзки са разрешени, както и, че пакетите идващи към рутера с неясен пройзход или с icmp грешки са забранени.
add action=accept chain=input comment=established-related-connections connection-state=established,related add action=drop chain=input comment=invalid-connections connection-state=invalid |
В 6-та версия на Микротик защитата от Сън флууд-а е включена опция по подразбиране. Не съм паранойк но незнам защо и нямам доверие затова си прилагам следните правила.
add action=add-src-to-address-list address-list=syn-flood address-list-timeout=30m chain=input comment=syn-flood connection-limit=30,32 \ protocol=tcp tcp-flags=syn add action=drop chain=input comment=syn-flood src-address-list=syn-flood |
Мразя да ме сканират! Тези правила след изпозлването на nmap към рутера блокирват сканиращия за един час. Разбира се става въпрос само за веригата INPUT което значи, че сканиращия не вижда рутера но вижда адресите зад него защото правилото не се изпълнява и на веригата FORWARD.
add action=add-src-to-address-list address-list=scanner-detect address-list-timeout=1h chain=input comment=scanner-detect protocol=tcp psd=\ 21,3s,3,1 add action=drop chain=input comment=scanner-detect src-address-list=scanner-detect |
Тъй като това е BGP рутер с три WAN интерфейса той има три BGP пиъра. Нямам никакво намерение да споделям това в Интернет, както и да описвам в поредица от правила кои рутери или пък интерфейси могат да виждат моя 179 порт на TCP за комуникация на протокола BGP. Правя това само с едно правило което забранява въпросния порт за всички а с опцията !bgp-accept създавам адресна листа за която не важи това правило. Правилото не важи защото пред името на листата има знак удивителен което значи без тези съвпадения. Тук има и една гяволия 🙂 заради опцията reject-with=tcp-reset при сканиране на порта той няма да е filtered (както при drop) за сканиращия а скенера ще го подмине което на практика няма да ме издаде, че ползвам BGP.
add action=reject chain=input comment=bgp dst-port=179 protocol=tcp reject-with=tcp-reset src-address-list=!bgp-accept |
Нещо подобно е и за сървъра с Cacti който чертае графиките за натоварване и трафик на рутера чрез протокола snmp, с удивителен но без адресна листа а с ип адрес. Опцията reject-with=tcp не важи за UDP протокола така, че тук няма как д я приложа.
add action=drop chain=input comment=snmp dst-port=161 protocol=udp src-address=!93.155.130.11 |
В един рутер ако имате повече от 20-30 правила в защитната стена с повече от 2-3 интефейса, значи имате нужда от whitelist и blacklist. С долното правило забранявам дадените портове който слушат на рутера за опредени услуги за всички в Интернет без това да важи за адрес листата whitelist (трика с удивителния). whitelist всъщност са адреси и мрежи на който се доверявам и важат за всички интерфейси защото аз не съм описал такива.
add action=drop chain=input comment=without-whitelist dst-port=53 protocol=udp src-address-list=!whitelist add action=reject chain=input comment=without-whitelist dst-port=53,2000,2222,8291 protocol=tcp reject-with=tcp-reset src-address-list=\ !whitelist |
Как добавям адреси или мрежи в адрес листата whitelist
ip firewall address-list add list=whitelist address=192.168.0.0/16 comment=My_Networks ip firewall address-list add list=whitelist address=172.16.100.100 comment=My_IPs |
Създаване на адрес листата blacklist
add action=drop chain=input comment=blacklist src-address-list=blacklist |
Как добавям адреси или мрежи в адрес листата blacklist
ip firewall address-list add list=blacklist address=111.111.111.111 comment=Hacker ip firewall address-list add list=blacklist address=222.222.222.222 comment=Flooder |
На въпросния рутер слуша и pptp server. Постоянно някакви дихатели се пробват да уцелят някаква паролка, затова също трябва да се вземат мерки които блокват ип адреса на атакуващия за 10 минути. В повечето случай това е някакъв скрипт който чувствително забавя действието си. В същото време не мога да увелича БАН-а на повече от 10 минути защото има вероятност клиент найстина да си е забравил паролата особено след нова инсталация на системата си.
add action=drop chain=input comment="pptp brute force drop 1/4 - complete comunication DROP" src-address-list=pptp_blacklist_DROP add action=add-dst-to-address-list address-list=pptp_blacklist_DROP address-list-timeout=10m chain=output comment="pptp brute force drop 2/4" \ content="bad username or password" dst-address-list=pptp_blacklist_stage_2 protocol=gre add action=add-dst-to-address-list address-list=pptp_blacklist_stage_2 address-list-timeout=1m chain=output comment=\ "pptp brute force drop 3/4" content="bad username or password" dst-address-list=pptp_blacklist_stage_1 protocol=gre add action=add-dst-to-address-list address-list=pptp_blacklist_stage_1 address-list-timeout=1m chain=output comment=\ "pptp brute force drop 4/4" content="bad username or password" protocol=gre |
По принцип достъпа до ssh и winbox е забранен от вън посредством адрес листата blacklist но въпреки всичко възможно е някой от вътрешната ни мрежа да се опита да налучка паролата на администратора на рутера. Паранойчно е, но е възможно, затова ще вземем мерки !
При три грешни опита или повече от три логвания в ssh ще се блокира ип адреса.
add action=add-src-to-address-list address-list=ssh_blacklist address-list-timeout=1d chain=input comment="ssh brute force" connection-state=new dst-port=2222 protocol=tcp src-address-list=ssh_stage add action=add-src-to-address-list address-list=ssh_stage address-list-timeout=1m chain=input comment="ssh brute force" connection-state=new dst-port=2222 protocol=tcp add action=drop chain=input comment="ssh brute force" dst-port=2222 protocol=tcp src-address-list=ssh_blacklist |
При три грешни опита или повече от три логвания в Winbox ще се блокира ип адреса.
add action=add-src-to-address-list address-list=winbox_blacklist address-list-timeout=1d chain=input comment="winbox brute force" connection-state=new dst-port=8291 protocol=tcp src-address-list=winbox_stage3 add action=add-src-to-address-list address-list=winbox_stage3 address-list-timeout=1m chain=input comment="winbox brute force" connection-state=new dst-port=8291 protocol=tcp src-address-list=winbox_stage2 add action=add-src-to-address-list address-list=winbox_stage2 address-list-timeout=1m chain=input comment="winbox brute force" connection-state=new dst-port=8291 protocol=tcp src-address-list=winbox_stage1 add action=add-src-to-address-list address-list=winbox_stage1 address-list-timeout=1m chain=input comment="winbox brute force" connection-state=new dst-port=8291 protocol=tcp add action=drop chain=input comment="winbox brute force" dst-port=8291 protocol=tcp src-address-list=winbox_blacklist |
Веригата FORWARD
Ако няма съвпадения пакетите се дропват и не преминават през рутера. Това е изумителна опция която често се подминава но истината е, че найстина достига по чист трафик до клиентите с нея.
add action=drop chain=forward comment="invalid packet flags" protocol=tcp tcp-flags=!fin,!syn,!rst,!ack add action=drop chain=forward comment="invalid packet flags" protocol=tcp tcp-flags=fin,syn add action=drop chain=forward comment="invalid packet flags" protocol=tcp tcp-flags=fin,rst add action=drop chain=forward comment="invalid packet flags" protocol=tcp tcp-flags=fin,!ack add action=drop chain=forward comment="invalid packet flags" protocol=tcp tcp-flags=fin,urg add action=drop chain=forward comment="invalid packet flags" protocol=tcp tcp-flags=syn,rst add action=drop chain=forward comment="invalid packet flags" protocol=tcp tcp-flags=rst,urg |
Пакети с източник и дестинация с номер 0 също се дропват. Странно е но веригата от време на време се пълни което значи, че от правилото има смисъл. Найстина не искам да задълбавам как става това но си представете, че някои устроиства в мрежата си генерират никому ненужен трафик е така да и е гадно на всички.
add action=drop chain=forward comment=drop_port_0 protocol=tcp src-port=0 add action=drop chain=forward comment=drop_port_0 dst-port=0 protocol=tcp add action=drop chain=forward comment=drop_port_0 protocol=udp src-port=0 add action=drop chain=forward comment=drop_port_0 dst-port=0 protocol=udp |
Отхвърляне на невалидни пакети в двете посоки през трите интерфейса и на трите доставчика.
add action=accept chain=forward comment=established-related-connections connection-state=established,related add action=drop chain=forward comment=invalid-connections connection-state=invalid in-interface=vlan149 add action=drop chain=forward comment=invalid-connections connection-state=invalid out-interface=vlan149 add action=drop chain=forward comment=invalid-connections connection-state=invalid in-interface=vlan1701 add action=drop chain=forward comment=invalid-connections connection-state=invalid out-interface=vlan1701 add action=drop chain=forward comment=invalid-connections connection-state=invalid in-interface=vlan1702 add action=drop chain=forward comment=invalid-connections connection-state=invalid out-interface=vlan1702 add action=drop chain=forward comment=invalid-connections connection-state=invalid in-interface=vlan2017 add action=drop chain=forward comment=invalid-connections connection-state=invalid out-interface=vlan2017 |
Протокола телнет, тотална забрана за всички. Има адрес листа !telnet-accept защото ползвам няколко стари суича Сиско на която не мога да пусна ssh
add action=drop chain=forward comment=telnet dst-port=23 protocol=tcp src-address-list=!telnet-accept |
На това правило трябва да му се обърне сериозно внимание. В един ред ползвам две адресни листи. Пакети отиващи към адрес листата ssh-drop се дробват но не важат за адрес листата !ssh-accept. В класическото описване на това правило без адрес листа и удивителен ще ми трябват няколко десетки реда с адресите и рутера би проверявал всяка верига за всеки пакет което си е сериозен ресурс за големи трафици. Но в случая с едно правило с две адрес листи рутера изпълнява няколко десетки правила но ползва ресурсите само като едно.
add action=drop chain=forward comment=ssh dst-address-list=ssh-drop dst-port=22 protocol=tcp src-address-list=!ssh-accept |
ip firewall address-list add list=ssh-drop address=192.168.0.0/16 comment=drop-ssh-to-network-for-all ip firewall address-list add list=ssh-accept address=172.16.200.200 comment=accept-ssh-to-192.168.0.0/16 |
Забранява се преминаването на пакети и в двете посоки между интерфейсите на рутера от адрес листата blacklist
add action=drop chain=forward comment=blacklist src-address-list=blacklist add action=drop chain=forward comment=blacklist dst-address-list=blacklist |
Типичните протоколи за windows лан споделяне на данни се забраняват задължително. Итриването на директорията със снимките от морето и споделянето на крипто вирусите трябва да става само в локалните мрежи на потребителите зад техните домашни рутери.
add action=drop chain=forward comment=samba dst-port=111,135,137-139,445 protocol=tcp add action=drop chain=forward comment=samba dst-port=111,135,137-139,445 protocol=udp |
С тази адрес листа автоматично блокирам порт 25 на определени ип адреси за три часа ако те превишат лимита от зададените пакети от мен в минута. Това разбира се не е генералното решение в борбата със спама но е първия безотказен филтър за упоритите флудери които в повечето случаи не знаят, че са такива и не подозират, че системата им е заразена. Тъй като аз имам два мейл сървъра те ще попаднат в тази адрес листа и няма да могат да изпращат електронни съобщения, затова ги изключвам от правилата с src-address-list=!mail-servers като така няма значение колко съобщения ще изпратят те.
add action=add-src-to-address-list address-list=spam address-list-timeout=3h chain=forward comment=spam connection-limit=30,32 dst-port=\ 25,587 limit=30/1m,0:packet protocol=tcp src-address-list=!mail-servers add action=drop chain=forward comment=spam dst-port=25,587 protocol=tcp src-address-list=spam |
И вече отдавна задължителния icmp тунинг
add action=accept chain=forward comment=echo-reply icmp-options=0:0 protocol=icmp add action=accept chain=forward comment=net-unreachable icmp-options=3:0 protocol=icmp add action=accept chain=forward comment=host-unreachable icmp-options=3:1 protocol=icmp add action=accept chain=forward comment=host-unreachable-fragmentation-required icmp-options=3:4 protocol=icmp add action=accept chain=forward comment=source-quench icmp-options=4:0 protocol=icmp add action=accept chain=forward comment=echo-request icmp-options=8:0 protocol=icmp add action=accept chain=forward comment=parameter-bad icmp-options=12:0 protocol=icmp add action=accept chain=forward comment=time-exceed icmp-options=11:0 protocol=icmp add action=drop chain=forward comment=other-types protocol=icmp |
Веригата OUTPUT
Не позволявам рутера да изпраща невалидни пакети към други устройства в мрежата
add action=accept chain=output comment=established-related-connections connection-state=established,related add action=drop chain=output comment=invalid-connections connection-state=invalid |
Автоматично обновяване на адрес листата blacklist с OpenBL.org, Spamhaus, dshield и malc0de
Надявам се да ви е ясно, че всъщност това до тук не е достъчно да защитим трафика на по сериозно количество клиенти с публични ип адреси. Разбира се трикчета има много и един от тях е използването на готови адрес листи със заразени мрежи, източници на спам и вируси. Има един добър човек който е написал един готин скрипт за Микротик като е автоматизирал обноваването на адрес листите на всеки три дни.
MikroTik Automatically Updated Address List
GEO Location Firewall
Има случаи в които трябва да се създаде филтър в защитната стена по геолокация. Тук вариантите също са няколко, но най удобен сякаш е да се използва ресурс точно за това. Сайтът http://www.mikrotikconfig.com/ е създаден с цел да генерира разни варианти на защитни стени. Аз определно не ползвам такива неща но гео филтъра тук генерира автоматично правилата в адрес листата на МикроТик което е много удобно защото не е нужно да се копират с copy – paste хиляди правила.
http://www.mikrotikconfig.com/
След като изтеглим файла с ип мрежите на Държавите които сме чекнали трябва да го качим в Микротик и да го импортнем с командата:
import IP-Firewall-Address-List.rsc |
След което можем да добавим следните правила. Пакети от избраните от нас държави в посока клиентите на рутера ще се отхвърлят на следните портове и протоколи. Разбира се комуникация от клиенти към тези държави проблем няма да има но в обратната посока услугите няма да работят.
add action=drop chain=forward comment=CountryIPBlocks protocol=icmp src-address-list=CountryIPBlocks add action=drop chain=forward comment=CountryIPBlocks dst-port=20,21,22,23,25,81,8000,8080,1000 protocol=tcp src-address-list=\ CountryIPBlocks add action=drop chain=forward comment=CountryIPBlocks dst-port=53,161 protocol=udp src-address-list=CountryIPBlocks |
Разбира се, че може би това не е правилния подход към всички клиенти, Вероятно ще има такива който не искат рестрикции дори и те да ги пазят в някаква степен. Затова аз подобни политики ги прилагам на бизнес клиенти за които сигурноста е по важна от свободата.
Добавяне на досери от Fail2ban в blacklist
На един от сървърите излвичам досерите от Fail2ban лога с:
#!/bin/bash echo "#########################" echo "INVALID FTP USER" echo "-------------------------" sudo cat /var/log/fail2ban.log | grep pureftpd | grep Ban | awk '{print $7}' | sort -n | uniq echo "-------------------------" echo "#########################" echo "INVALID POSTFIX LOGIN" sudo cat /var/log/fail2ban.log | grep postfix-sasl |grep Ban | awk '{print $7}' | sort -n | uniq echo "-------------------------" |
От скрипта получавам следния резултат:
samyil@hosting2:~$ sudo ./fail2ban_sort.sh ######################### INVALID FTP USER ------------------------- 2.133.245.98 5.136.126.196 5.164.176.130 5.18.176.130 31.180.218.207 37.113.107.159 37.232.160.132 37.29.7.45 37.45.124.52 37.78.188.20 46.0.237.72 46.150.71.219 46.211.197.180 46.229.188.185 77.222.116.137 83.234.49.217 85.64.44.204 89.21.95.226 89.90.74.138 92.112.167.179 92.153.49.242 92.37.142.107 93.177.249.150 95.32.80.175 109.194.27.202 109.222.184.221 109.252.36.244 130.180.210.250 178.121.107.110 178.185.51.250 178.219.88.0 178.64.82.203 188.186.193.232 188.234.107.74 213.135.157.109 213.184.234.86 ------------------------- ######################### INVALID POSTFIX LOGIN 192.254.70.140 ------------------------- |
Ако въпросните адреси ги копирам във файла gen_address-list.txt с долния скрипт мога да си генерирам правилата за адрес листата blacklist
#!/bin/bash ADDR=$(cat gen_address-list.txt) for IP in $ADDR; do echo ip firewall address-list add address=$IP comment=Fail2ban list=blacklist done; |
Резултата който ще получа е:
samyil@hosting2:~$ sudo ./gen_address-list.sh ip firewall address-list add address=2.133.245.98 comment=Fail2ban list=blacklist ip firewall address-list add address=5.136.126.196 comment=Fail2ban list=blacklist ip firewall address-list add address=5.164.176.130 comment=Fail2ban list=blacklist ip firewall address-list add address=5.18.176.130 comment=Fail2ban list=blacklist ip firewall address-list add address=31.180.218.207 comment=Fail2ban list=blacklist ip firewall address-list add address=37.113.107.159 comment=Fail2ban list=blacklist ip firewall address-list add address=37.232.160.132 comment=Fail2ban list=blacklist ip firewall address-list add address=37.29.7.45 comment=Fail2ban list=blacklist ip firewall address-list add address=37.45.124.52 comment=Fail2ban list=blacklist ip firewall address-list add address=37.78.188.20 comment=Fail2ban list=blacklist ip firewall address-list add address=46.0.237.72 comment=Fail2ban list=blacklist ip firewall address-list add address=46.150.71.219 comment=Fail2ban list=blacklist ip firewall address-list add address=46.211.197.180 comment=Fail2ban list=blacklist ip firewall address-list add address=77.222.116.137 comment=Fail2ban list=blacklist ip firewall address-list add address=83.234.49.217 comment=Fail2ban list=blacklist ip firewall address-list add address=85.64.44.204 comment=Fail2ban list=blacklist ip firewall address-list add address=89.21.95.226 comment=Fail2ban list=blacklist ip firewall address-list add address=89.90.74.138 comment=Fail2ban list=blacklist ip firewall address-list add address=92.112.167.179 comment=Fail2ban list=blacklist ip firewall address-list add address=92.153.49.242 comment=Fail2ban list=blacklist ip firewall address-list add address=92.37.142.107 comment=Fail2ban list=blacklist ip firewall address-list add address=93.177.249.150 comment=Fail2ban list=blacklist ip firewall address-list add address=95.32.80.175 comment=Fail2ban list=blacklist ip firewall address-list add address=109.194.27.202 comment=Fail2ban list=blacklist ip firewall address-list add address=109.222.184.221 comment=Fail2ban list=blacklist ip firewall address-list add address=178.121.107.110 comment=Fail2ban list=blacklist ip firewall address-list add address=178.185.51.250 comment=Fail2ban list=blacklist ip firewall address-list add address=178.219.88.0 comment=Fail2ban list=blacklist ip firewall address-list add address=178.64.82.203 comment=Fail2ban list=blacklist ip firewall address-list add address=178.89.37.138 comment=Fail2ban list=blacklist ip firewall address-list add address=188.234.107.74 comment=Fail2ban list=blacklist ip firewall address-list add address=213.135.157.109 comment=Fail2ban list=blacklist ip firewall address-list add address=213.184.234.86 comment=Fail2ban list=blacklist |
Директно мога да копирам правилата в Mikrotik терминала. Разбира тази задача също може да се авотматизира но това го правя рядко обикновенно в по особени случай когато някой прекали с атаките към сървъра.
Много колеги си мислят, че защитната стена изяжда голям ресурс от рутера. Аз бих казал, че ако е смислено описана рутера би трябвало да олекне от към натоварване а не обратното. Защо всъщност се случва така…?!? Не обичам да говоря в проценти защото е подвеждащо но по мои наблюдения между 10% и 20% пакетите идващи към рутер с публични адреси са невалидни, сканиращи, флудещи, вируси, ботнет, спам и др. Естествено, че тези проценти не са обема на трафика а брой пакети в секунда.
МikroТik advanced firewall with multiple WAN ports without NAT