Přímý přenos z konference OpenAlt 2024, jež probíhá tento víkend v prostorách FIT VUT v Brně. Na programu je spousta zajímavých přednášek. Pokud jste v Brně, stavte se. Vstup zdarma.
V Coloradu unikla hesla k volebním počítačům. Více než 2 měsíce byla tabulka se stovkami hesel do BIOSu volně na webových stránkách. Dle úřadu je potřeba ještě druhé heslo, takže se o žádnou bezprostřední bezpečnostní hrozbu pro volby nejedná [Ars Technica].
Apple kupuje Pixelmator Team stojící za grafickými editory Pixelmator, Pixelmator Pro a Photomator.
Apple představil nový MacBook Pro s čipy M4, M4 Pro a M4 Max.
Na GOG.com běží Halloween Sale 2024. Při té příležitosti lze získat zdarma počítačovou hru Return of the Phantom.
Společnost OpenAI spustila internetový vyhledávač ChatGPT search.
Konference OpenAlt 2024 proběhne již tento víkend 2. a 3. listopadu v prostorách FIT VUT v Brně. Začíná ale už v pátek na warm-up party ve Studentském klubu u Kachničky v 17:00. Pokud jste ještě areál FITu nenavštívili, k dispozici jsou pokyny k orientaci. Na programu je 54 přednášek a workshopů. Témata jsou od silně technických témat jako je třeba GCC nebo PostgreSQL po méně technické témata jako eGovernment, nebo třeba detailní analýzu … více »
Byla vydána nová verze 6.9 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 14.0.1. Tor client na verzi 0.4.8.13. Thunderbird na verzi 115.16.0.
Vývojáři free a open source synchronizačního nástroje (a p2p náhrady Dropboxu) Syncthing oznámili, že z důvodu odporu ze strany Google Play ukončují podporu OS Android. Bohužel v rámci toho zmizí i vydání Syncthing na F-Droid, který má slabší uživatelskou základnu. Syncthing je na Androidu implementován formou wrapper aplikace, která spustí Syncthing démon, vyžádá potřebná oprávnění a zpřístupní webové rozhraní démona. Ve srovnání se
… více »V červnu 2022 bylo oznámeno, že z K-9 Mailu se stane Thunderbird pro Android. Trvalo to poněkud déle, než vývojáři předpokládali, ale včera byl první stabilní Thunderbird pro Android 8.0 vydán.
Zdravím,
mám server, který funguje jako GW. Připojen k internetu je pomocí VDSL modemu (v režimu bridge, s veřejnou IP) (eth1 resp. ppp0).
Dále je tam síť eth0 na vnitřní síť a routování.
eth0 má IP 192.168.0.11, síť je tedy 192.168.0.0/24
Na serveru běží tyto služby, které by měly být přístupné zvenčí:
- VPN PPTP, FTP
Po připojení k VPN dostávám IP adresu 192.168.0.230-235
Pokoušel jsem se nastavovat IPTABLES tak, aby to fungovalo, ale nějak mi to nejde. Zkoušel jsem různé návody, ale pořád mi něco nefungovalo.
Mohl by mi prosím někdo pomoci s tím, jak iptables nastavit, aby to fungovalo?
Zkoušel jsem toto:
iptables -A INPUT -i eth1 -p tcp --dport 1723 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth1 -p tcp --sport 1723 -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth1 -j DROP
iptables -A OUTPUT -o eth1 -j DROP
iptables -A INPUT -i eth0 -p tcp -s 192.168.0.0/24 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -j DROPiptables -A OUTPUT -o eth0 -j DROP
ale nějak to nejelo.
Díky moc
Pokud mám INPUT a OUTPUT ACCEPT, tak to jede bez problému.
Zkouším různé návody, ale pokaždé mi něco nefunguje.
Mohl by mě nekdo nakoupnout a poradit, abych měl vše z venku zakázané krom PPTP VPN a FTP, z vnitřní sítě, aby mi vše fungovalo?
iptables -P INPUT DROP iptables -P OUTPUT ACCEPT iptables -P FORWARD DROP iptables -A INPUT -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i eth1 -p TCP --dport 21 -j ACCEPT iptables -A INPUT -i eth1 -p TCP --dport 47 -j ACCEPT iptables -A INPUT -i eth1 -p TCP --dport 1723 -j ACCEPT iptables -A INPUT -i eth1 -p ICMP --icmp-type echo-request -j ACCEP iptables -A INPUT -i eth0 -j ACCEPT iptables -A INPUT -i lo -j ACCEPTNeřeším forward a nat.
iptables -A FORWARD -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i eth0 -j ACCEPT iptables -A FORWARD -o eth1 -j ACCEPT iptables -A FORWARD -o eth0 -j ACCEPT
Inspirací jsem již prošel a něco pořád nefungovalo. Nyní, pokud to zadám, tak jak píšeš, tak mi jde vnitřní síť OK, ale z venku se nepřipojím ani na VPN, ani na FTP.
Zkusil jsem namísto eth1 zadat ppp0 a situace je taková, že jde se připojit na VPN, ale nefunguje (to znamená, že se nedostanu na vnitřní síť a vše nějak trvá déle) a FTP se snaží sice připojit, ale nenačte se. Vše dlouho trvá.
Výpis iptables -L -n:
maniakum@server:~$ sudo iptables -L -n Chain INPUT (policy DROP)target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:47 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy DROP)target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT)target prot opt source destination
Při řešení eth1 se z venku tvářili porty zavřeny, Při ppp0 otevřený.
jde se připojit na VPN, ale nefunguje (to znamená, že se nedostanu na vnitřní síť a vše nějak trvá déle)
ip link show
??? ip route show
???openvpn
, zda je povolená volba client-to-client
cat /proc/sys/net/ipv4/ip_forward
zřejmě vrací hodnotu 1
FTP se snaží sice připojit, ale nenačte se
U chainů input
i forward
sice máte výchozí politiku DROP
, ale de facto tam projde úplně všechno díky posledním dvěma pravidlům v INPUT
a díky posledním třem pravidlům ve FORWARD
(mimochodem tyhle duplicity bych odstranil). Takže explicitně povolit port 20 nedává moc smysl, tak bych asi zkontroloval, zda FTP server naslouchá na vnějším rozhraní, zkontroloval logy týkající se FTP, eventuálně bych zkusil tcpdumpem odsledovat požadavek na data z vnějšího rozhraní.
# Modul pro FTP prenosy /sbin/modprobe ip_conntrack_ftp /sbin/modprobe ip_nat_ftp # Zapneme routovani paketu echo "1" > /proc/sys/net/ipv4/ip_forward echo "1" > /proc/sys/net/ipv4/tcp_syncookies iptables -P INPUT DROP iptables -P OUTPUT ACCEPT iptables -P FORWARD DROP iptables -A INPUT -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i ppp0 -p TCP --dport 21 -j ACCEPT iptables -A INPUT -i ppp0 -p TCP --dport 1723 -j ACCEPT iptables -A INPUT -p 47 -j ACCEPT iptables -A INPUT -i ppp0 -p ICMP --icmp-type echo-request -j ACCEP iptables -A INPUT -i eth0 -j ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A FORWARD -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i eth0 -j ACCEPT iptables -A FORWARD -o ppp0 -j ACCEPT iptables -A FORWARD -o eth0 -j ACCEPTJinak předpokládám že ftp běží na tom serveru. Samozřejmě pokud používáš IPv6 musíš nastavit pravidla i pro IPv6
Stále stejné. VPN se připojí (znatelně pomaleji, než bez firewallu nebo dříve přes router). Server nevidí na klienta a ani klient nevidí na server.
FTP se připojí, ale nenačte se strom adresářů a celý proces trvá dlouho. V čem mám hledat potíž?
V čem mám hledat potíž?
Třeba v tom, že některé rady ignorujete. Pan Šobáň ve vás zřejmě vzbudil naději, že to za vás kompletně naklape, a vám bude stačit jen copy&paste. Evidentně to nefunguje a i když se pan Šobáň opravdu snažil, tak to fungovat ani nebude, protože neposkytujete všechny informace, co jsou potřeba.
Takže - seznam rozhraní, jejich síťových adres a jejich rout (ne to, co vy si myslíte, že tam máte, ale jak to máte skutečně nastavené) - to už jsem se vám snažil naznačit výše. Neobtěžoval jste se sdělit, jestli máte na vpn serveru direktivu client-to-client
, pokud se opravdu chcete dostat na vnitřní síť, jak tu tvrdíte. Pokud se chcete opravdu dostat na vnitřní síť, tak asi proto, že chcete používat nějaké služby vnitřní sítě, což jste ale zatím nijak nespecifikoval. Dál je potřeba seznam služeb a to, na jakých rozhraních a portech naslouchají. A nakonec (tedy doufám, že jsem na nic nezapoměl) by nebylo od věci si po každém zásahu do iptables
nechat vypsat seznam všech pravidel a pastnout ho sem.
Taky jste se nepochlubil, co se děje na portu 20, když se pokusíte připojit k FTP, jak jsem vám doporučoval.
Pokud tady nebudete dodávat dostatek informací ke svému problému, ztrácí s vámi ostatní zbytečně čas. A vy ho ztrácíte zbytečně taky.
Omlouvám se, že jsem popsal nedostatečně a z části i chybně stávající řešení. Tak abych to napravil.
Níže jsem zaslal výpisy, které jste chtěl.
V podstatě na serveru jede rozhraní eth0 -vnitřní síť, eth1 resp. ppp0 - připojení pomocí modemu a protokolu PPPOE k internetu, ppp1 - připojení k VPN, které se vytvoří jen při spojení.
Na vnitřní síti bšží v tuto chvíli několik služdeb, ale řekněme, že asi nejdůležitješí je FTP, HTTP, SAMBA, DLNA. Tyto služby jsou k dispozici ve vnitřní síti. FTP chci mít k dispozici z internetu, také připojení k VPN. Pokud se připojím k VPN, chci mít dosažitelné i vnitřní služby. V tuto chvíli, jak jsem poslal zprávu níže, VPN a komunikace na vnitní síti jede. Nejsem si však jistý, zda-li to je nastaveno v pořádku.
U FTP byl můj problém, že jsem neměl natažený ip_conntrack a ip_conntrack_ftp, ikdyž jsem myslel, že ano.
V tuto chvíli, jak jsem poslal zprávu níže, VPN a komunikace na vnitní síti jede.
Tak důležité je, že už máte funkční konfiguraci, pokud budete cokoli ořezávat, a přestane to jet, tak aspoň se máte k čemu vrátit.
U FTP byl můj problém, že jsem neměl natažený ip_conntrack a ip_conntrack_ftp, ikdyž jsem myslel, že ano.
No jo, stane se. To je jedna z nejblbějších chyb, protože člověk si myslí, že už to má opraveno, a přitom tam ta chyba pořád straší.
Nejsem si však jistý, zda-li to je nastaveno v pořádku.
Možná trochu zbytečně nadužíváte direktivu state
, zpomaluje to filtrovací proceduru (i když to při vašem malém počtu pravidel nejspíš vůbec nepocítíte), ale state NEW
je IMHO ve většině případů zbytečná.
Čtvrté pravidlo v chainu INPUT (zkuste příště dávat výpis iptables
s volbou --line-numbers
) tam vypadá nadbytečně, pravidlo se ani jednou neaktivovalo, takže bych ho zkusil vyhodit, navíc si nejsem úplně jistý, jestli zrovna tenhle protokol povolený paušálně (tj. bez restrikce na konkrétní port/y) na vnějším rozhraní nemůže znamenat nějaké bezpečnostní riziko. Poslední pravidlo v chainu INPUT je duplicitní.
Jinak FTP a PPTP nejsou samy o sobě příliš nebezpečné služby, takže momentálně bych viděl největší bezpečnostní riziko spíš právě v nich než ve špatně nastaveném firewallu.
Errata:
Jinak FTP a PPTP nejsou samy o sobě příliš nebezpečné služby
(Pravda, u FTP záleží na tom, k čemu přesně ho používáte).
FTP jede jen na zálohování, nic důležitého tam není.
Asi záleží na tom, co zálohujete. Pokud obrazy linuxových instalaček, tak asi ok (pokud si kontrolujete checksumy). Pokud jsou to data více či méně privátního charakteru, tak bych to za ok nepovažoval (ale jsme lidé různí a máme různým způsobem nastavenou citlivost k úniku osobních dat, že). U FTP taky hrozí, že někdo odposlechne v komunikaci přihlašovací heslo, a pak to úložiště vymaže, takže pokud je to jediná zálohovací technika, pak to není úplně optimální.
PPTP má AFAIK slabý autentizační mechanismus, ne sice tak moc, jako to FTP, a prolomit ho už vyžaduje určitou námahu a/nebo čas a/nebo peníze, takže to nejspíš nebude nikomu stát moc za to, ale do optima to má IMHO daleko. IPSec asi není špatná volba, ale vlastními zkušenostmi neposloužím, já používám openvpn (lépe řečeno "jsem používal", teď mi trochu hnije, protože mi stačí ssh), které by snad taky nemělo trpět nějakým zásadním neduhem.
FTP samozřejmě použít můžete (i když bych osobně upřednostnil nfs nebo sambu v závislosti na klientských OS), ale když už tam máte tu VPN (ať už jakoukoli), co vám brání tu službu zavěsit na loopback serveru místo aby visela na vnějším rozhraní, a přistupovat k té službě přes tu VPN? Od toho ta VPN je - aby se skrz ni protáhly služby, u nichž nemá bezpečnost tak vysokou prioritu.
Pokud mu povolím ještě tohle:
-A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 137 -j ACCEPT -A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 138 -j ACCEPT -A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 139 -j ACCEPT -A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 445 -j ACCEPT
Tak mi to sdílení jede, ale pořád mám pocit, že to jede trochu pomaleji... Každopádně, tohle by přeci nemělo být nutné, když tam je pravidlo FORWARD ne?
Ano, na serveru běží i SAMBA. A FTP také běží, pro komunikaci z vnějšku.
NAT jsem vůbec neřešil, přiznávám se.
za odkazy děkuji, prostuduji.
Jinak nic GUI instalovat nemůžu, nemám na serveru nahozený žádný window manager. Jak jsem psal níže, tak jsem NAT nastavil a stejně mi to nejde. Je mi jasný, že mi něco chybí nebo dělám špatně, jen nemůžu přijít na to co..
Tak jsem tam nabouchal toto:
http://www.revsys.com/writings/quicktips/nat.html
Ale stejně nepomohlo
Jak docílit toho, aby všechny porty, všechna komunikace ve vnitřní síti byla povolena (samozřejmě, aby byla povolena komunikace i z venčí, pokud byla otevřena zevnitř) a z vnějšku aby běželo FTP a VPN PPPTP (kde dostává stejnou síť jako uvnitř) ??
1. ip link show:
maniakum@server:~$ ip link show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 44:8a:5b:24:15:d4 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:e0:7d:9c:75:a9 brd ff:ff:ff:ff:ff:ff 5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3 link/ppp 37: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1396 qdisc pfifo_fast state UNKNOWN qlen 3 link/ppp
1. ip route show
maniakum@server:~$ ip route show default dev ppp0 scope link 10.0.0.2 dev ppp1 proto kernel scope link src 10.0.0.1 88.103.xx.xx dev ppp0 proto kernel scope link src xxx.xxx.xxx.xxx 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.11
2. nepoužívám openvpn, ale pptpd. Každopádně, žádnou takovou volbu jsem tam nezadával
Nyní mi chodí VPN, ale přiznám se, že si nejsem jistý, zda je to tak dobře. V tuto chvíli výpis iptables -L -nv vypadá takto (eth0 vnitřní síť, ppp0 internet pomocí VDSL modemu, ppp0 PPTP VPN). Je tam nějaká chyba, která by mi to mohla nabourat, resp. není ta mnějaká věc zbytečně?:
Chain INPUT (policy DROP 215 packets, 36627 bytes) pkts bytes target prot opt in out source destination 3920 661K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 12020 4639K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 4 176 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723 state NEW 0 0 ACCEPT 47 -- * * 0.0.0.0/0 0.0.0.0/0 state NEW 3 132 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 state NEW 960 281K ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0 state NEW 400 106K ACCEPT all -- ppp1 * 0.0.0.0/0 0.0.0.0/0 state NEW 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 state NEW Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 3869 1036K ACCEPT all -- eth0 ppp0 0.0.0.0/0 0.0.0.0/0 6297 5406K ACCEPT all -- ppp0 eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- ppp1 eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 3891 407K ACCEPT all -- ppp1 ppp0 0.0.0.0/0 0.0.0.0/0 3209 2986K ACCEPT all -- ppp0 ppp1 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 4890 packets, 3340K bytes) pkts bytes target prot opt in out source destination
3. ano je tam 1
Zkusil jsem namísto eth1 zadat ppp0Forward je opravdu potřeba mít mezi eth0 a ppp0 a služby povolit pro ppp0. Protože ppp0 je to rozhraní které má veřejnou IP adresu. Po eth1 leze jen jen ppp tunel (myslím, že eth1 nemusí mít přidělenou ani žádnou IP adresu, aby to fungovalo) k poskytovateli (jestli tedy kabel z eth1 vede do modemu a k modemu, už není připojené nic jiného).
Pokud mu povolím ještě tohle: -A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 137 -j ACCEPT -A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 138 -j ACCEPT -A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 139 -j ACCEPT -A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 445 -j ACCEPTJooo, nejlepsi je pustit deravou sambu do sveta ...lol
Jedná se sice o provozní stroj, ale o domácí server, kde v podstatě nic není.
Chci se to naučit sám, ať vím jak to tam je nastavený a proč. Nemyslím, že by to mělo být pár stovek hodin, ale něco tomu věnovat budu.
Ano zkoušel jsem m to povolit, abych věděl kde hledat chybu.
iptables -vL
a pochopit, jak co funguje.
iptables -A INPUT -p 47 -j ACCEPT
Nikde jsem nenašel zmínku o tom, že bych měl povolovat i tyto porty. Když jsem měl připojení přes modem router, tak jsem přeposílal jen port 1723 a šlo to.
Tiskni Sdílej: