Nelze se připojit na venkovní pptp vpn server po update na 3.11.20

Návod musí fungovat, ověřil bych zda-li je contrack_helper zapnutý:

sysctl -a 2>/dev/null | grep net.netfilter.nf_conntrack_helper

Hodnota se musí rovnat 1:

net.netfilter.nf_conntrack_helper = 1

A ověřil bych zda-li jsou moduly zavedené:

lsmod | grep nf_conntrack_

Musí obsahovat (a také obsahuje další):

nf_conntrack_pptp
nf_conntrack_proto_gre

Mimojiné doporučuji po dané úpravě restart.

1 Like

Dobrý den,

každou bezpečnostní chybu o které víme, případně je nám nahlášená bereme velmi vážně. Ve verzi Turris OS 3.11.20 jsme opravili bezpečnostní chybu známou jako NAT Slipstreaming, která má přiřazené CVE ID - CVE-2020-16009. V současné době existuje proof-of-concept zranitelného kódu prozatím pouze pro SIP, (VoIP) ale zranitelné jsou i jiné protokoly například PPTP, FTP a řada dalších.

Když se na to díváme zpětně dle issue (prozatím confidental), tak chyba nám byla bezpečností chyba nám byla nahlášena v úterý kolem 21. hodiny a do půlnoci jsme chybu analyzovali a našli možné řešení, které jsme pak začlenili následně začlenili do produkce. Předcházelo to k tomu, že o dva dny později tedy ve čtvrtek jsme vydali RC2 verzi Turris OS 3.11.20 a ve středu verze šla do produkce.

Během této doby od vydání RC2 do produkce jsme nezaznamenali žádné problémy s releasem. Bohužel, problémy se objevily až později v tomto vlákně.
Prozatím nevíme moc technických informací ku příkladu by nám pomohlo jaké VPN používáte a jakým způsobem to přestalo pracovat ideálně nějaký výstup z aplikace.

Co jsme změnili a upravili ve verzi Turris OS 3.11.20?

  • Ve výchozí instalaci jsme odinstalovali balíček kmod-nf-nathelper-extra, protože byl součástí userlistu. S ohledem na to, že tento balíček by měl být volitelný a ve výchozí instalaci není ve verzi Turris OS 5.x ani v OpenWrt a je nutné, aby si jej uživatel sám nainstaloval. Vzhledem k bezpečnosti všech routerů ve verzi Turris OS 3.x jsme se rozhodli, aby všechny routery byly bezpečné a balíček odinstalovali.

  • V souboru /etc/sysctl.conf jsme přidali proměnnou ve které je explicitně vypnutý nf_conntrack_helper.
    Pokud uživatel mít zranitelný router avšak funkční některé protokoly, tak je nutné v /etc/sysctl.conf povolit hodnotu pro conntrack_helper. Tuto záležitost jsme přidali do Errata pro verzi Turris OS 3.x v komunitní dokumentaci.

Vzhledem k opravě SAD DNS ve verzi Turris OS 3.11.21 nedoporučujeme v tuto chvíli rollback. Je možné provést ruční úpravu viz výše a od minulého týdne pracujeme na nové verzi Turris OS 3.11.22, kde balíček bude ve výchozím stavu nadále odinstalovat a v případě potřeby daného balíčku bude nutné jej pouze nainstalovat. Navíc také nedávno vyšla nová verze prohlížeče Google Chrome ve verzi 87, která opravuje zranitelnost Sad DNS a v této verzi dochází k odstranění podpory FTP protokolu pro většinu uživatelů Google Chrome.

1 Like

Chyba nebyla opravena, vypnutí zranitelné části není oprava, to je přinejlepším workaround.

Tady bych si troufal položit otázku, že když jste nám odinstaloval balíček a vypnuli zranitelnou část, tak jestli nikoho nanapadlo ověřit, které služby jsou na daném balíčku závislé?

Toto je dosti nesmyslná otázka. Nefunguje nic, co využívá, cokolik z těch modulů contrack. Pro nás zajímavé převážně, to co zprostředkovává kmod-nf-nathelper-extra a to si můžete přečíst v popisu balíčku:
https://openwrt.org/packages/pkgdata/kmod-nf-nathelper-extra
Jak se dotýká PPTP VPN si můžete přečíst zde:
https://openwrt.org/cs/doc/howto/vpn.nat.pptp

Podle mého názoru nefunguje žádná PPTP VPN, která jde z koncového zařízení skrz router. Z logu není vidět absolutně nic zajímavého, protože GRE přes router neprojde, Vaší podpoře jsem poslal screen z Windows, v Linux logu se jenom opakuje pokus o spojení. Ale prostě nefungují žádné PPTP VPN, ani žádné jiné VPN, které potřebují pro svůj běh GRE. A pravděpodobně spousta jiných věci, které využívají cokoli kmod-nf-nathelper-extra případně závisí na contrack.

Já si nejsem jistý, zda-li si uvědomujete, jak šíleně to zní, že jste nám na dálku odinstalovali z routeru balíček, který zprostředkovává zásadní funkcionalitu.

Tohle jsem potřeboval vědět minulý týden v úterý.

Ja si myslim, ze to bude souviset s tim, ze jste porad na verzi 3.x. Nerikam, ze to je spatne, porad ma podporu, nicmene testovacu RC verzi tam IMO bude mnohem min nez na verzi 5.x. Mozna by CZ.NIC mel nejake presnejsi statistiky, ale ja si to tak predstavuju. A kdyz je malo testovacu, tak se hur prichazi na vsechno mozne, co mohl update rozbit. Rekl bych, ze stable verze 5.x bude v tomhle smeru o neco lepsi.

Uz jsem nekolikrat poruznu zminoval, ze by se mi libilo, kdyby nekde byl exaktni seznam toho, co se testuje jeste pred tim, nez se neco preklopi z hbl do hbt. V CZ.NIC je urcite nejaka “testovaci farma” s par routery v ruznych konfiguracich, na kterych se zkousi, jak zmeny pusobi. Zatim jsem takovy seznam nevidel, ale obcas se objevi odpoved typu, ze dusledne testovani se dela pro veci, ktere se daji naklikat ve Forisu. Jakmile clovek nainstaluje neco mimo klasicke userlisty, musi pocitat s tim, ze podpora nebude 100% a obcas se neco muze pokazit.

Tohle je ale malicko jiny pripad, protoze GRE passthrough byl podle me by default funkcni bez jakekoli konfigurace (taky pptp vpn pouzivam a krom nastaveni firewallu a nainstalovani pptp kernel modulu si na 3.x nepamatuju, ze by bylo potreba instalovat jeste nathelper).

Rekl bych, ze odstraneni balicku byla vyjimecna situace, a pouceni pro CZ.NIC by z toho mohlo byt takove, ze pokud se bude nejaky balicek odstranovat, tak by bylo dobre do update notifikace vic rozepsat, proc se to stalo, a co vsechno to muze rozbit, a jak pripadne funkcnost balicku obnovit, pokud se nekdo rozhodne, ze poskytovana funkcionalita je pro nej dulezitejsi nez oprava zranitelnosti.

This might affect some services if you were using them like SIP, TFTP and GRE.

Tohle v notifikaci bylo, ale tipuju, ze neni moc uzivatelu, kteri s z toho odvodi, ze to rozbije PPtP VPN. Krom toho GRE neni service, ale protokol. I to muze byt matouci.

Za to může CZ.NIC:

Migration to Turris OS 5.x (HIGHLY EXPERIMENTAL)

This is experimental migration to the latest version of Turris OS. Make sure that you thoroughly read https://docs.turris.cz/geek/tos3_migration/ before enabling this!

Dokud neřeknou, že mi… budeme slušní, tak to dělat nebudu.

Já nevím, kde bych to mohl vidět, email žádný nepřišel, do routeru každý den nechodím a odinstalace a aktualizace proběhla automaticky.

1 Like

Aha, vam nechodi emaily s notifikacemi? http://192.168.1.1/foris/config/main/maintenance/

Sending of the testing message failed, your configuration is possibly wrong.

Nevíte, jestli se to dá někde debugovat?

mozna vam pomuze tento prispevek, ktery jsem napsal pred nekolika dny

root@dracena2:/tmp/log# create_notification -t -s error 'This is a testing notification'
Working on message: 1606251020-3820
Working on message: 1606251204-5664
cat: can't open '/tmp/user_notify/1606251204-5664/message_en': No such file or directory
cat: can't open '/tmp/user_notify/1606251204-5664/message_en': No such file or directory
Working on message: 1606251234-6070
cat: can't open '/tmp/user_notify/1606251234-6070/message_en': No such file or directory
cat: can't open '/tmp/user_notify/1606251234-6070/message_en': No such file or directory
Working on message: 1606251308-6956
cat: can't open '/tmp/user_notify/1606251308-6956/message_en': No such file or directory
cat: can't open '/tmp/user_notify/1606251308-6956/message_en': No such file or directory
Working on message: 1606251364-7593
cat: can't open '/tmp/user_notify/1606251364-7593/message_en': No such file or directory
cat: can't open '/tmp/user_notify/1606251364-7593/message_en': No such file or directory
Working on message: 1606251555-9480
cat: can't open '/tmp/user_notify/1606251555-9480/message_en': No such file or directory
cat: can't open '/tmp/user_notify/1606251555-9480/message_en': No such file or directory
Working on message: 1606253817-32658
cat: can't open '/tmp/user_notify/1606253817-32658/message_en': No such file or directory
cat: can't open '/tmp/user_notify/1606253817-32658/message_en': No such file or directory
Working on message: 1606253829-452
cat: can't open '/tmp/user_notify/1606253829-452/message_en': No such file or directory
cat: can't open '/tmp/user_notify/1606253829-452/message_en': No such file or directory
Working on message: 1606253845-755
cat: can't open '/tmp/user_notify/1606253845-755/message_en': No such file or directory
cat: can't open '/tmp/user_notify/1606253845-755/message_en': No such file or directory
msmtp: network read error: the operation timed out
msmtp: could not send mail (account default from /tmp/user_notify/.locked/msmtp.cfg.755)
notifier: msmtp has failed to send e-mail notification

:man_shrugging:

O tech

jsem psal v linkovanem prispevku, ze muzete ignorovat

Ten connection timeout je divný, objevuje se nějak náhodně, už mi nějaké zprávy přišly, kdyby někdo potřeboval ladit, tak doporučuji přesunout msmtp do msmtp.original a udělat si wrapper:

#!/bin/sh
cp $2 /var/log/msmtp.last
echo "$@" >> /var/log/msmtp.log
tee /var/log/msmtp.body | /usr/bin/msmtp.original "$@"