Sziasztok.
Adott egy szerver, ami wlan0-n szolgáltatja a hálózati adatforgalmat, meg egy kliens, ami csatlakozik rá.
A tűzfalszabályokat szeretném módosítani úgy, hogy a 2947-es és a 10010-es nyitva legyen mindkettőn.
Elég sokat olvastam (régebben szintén) ahhoz, hogy felmérjem, teljesen analfabéta vagyok a területen.
Ott akadtam el, hogy nmap-pel a portletapogatás mindkettőn nyitva találta a 2947-es portot, de a másik gép ip címét nézve már semit nem adott:
Íme a kliensoldali próbálkozás:
-------------------------------
root@fekete:/# nmap -p 2947 localhost
Starting Nmap 6.47 ( http://nmap.org ) at 2017-01-25 14:03 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00011s latency).
PORT STATE SERVICE
2947/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 0.29 seconds
Új levél a következőben: /var/mail/root
root@fekete:/# nmap -p 2947 192.168.12.1
Starting Nmap 6.47 ( http://nmap.org ) at 2017-01-25 14:03 CET
Nmap scan report for domain1.com (192.168.12.1)
Host is up (0.0071s latency).
PORT STATE SERVICE
2947/tcp closed unknown
MAC Address: 10:7B:EF:CD:0A:D1 (ZyXEL Communications)
Nmap done: 1 IP address (1 host up) scanned in 0.54 seconds
root@fekete:/#
A szerveroldali meg ez:
-----------------------
# nmap -p 2947 192.168.12.118
Starting Nmap 7.01 ( https://nmap.org ) at 2017-01-25 14:06 CET
Nmap scan report for 192.168.12.118
Host is up (0.052s latency).
PORT STATE SERVICE
2947/tcp closed unknown
MAC Address: B0:48:7A:8D:DB:E5 (Tp-link Technologies)
Nmap done: 1 IP address (1 host up) scanned in 13.89 seconds
# nmap -p 2947 localhost
Starting Nmap 7.01 ( https://nmap.org ) at 2017-01-25 14:06 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (-1500s latency).
Other addresses for localhost (not scanned): 192.168.0.2 ::1
rDNS record for 127.0.0.1: localhost.localdomain
PORT STATE SERVICE
2947/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 0.56 seconds
Tűzfalam a szerveren ez:
#!/bin/sh
IPT="/sbin/iptables"
IF_ETH="eth0"
IF_WLAN="wlan0"
TCP_IN_PORTS="60000"
UDP_IN_PORTS="0"
FTP_PORTS="20,21,113"
NMEA_PORTS="2947" #itt a kritikus port
URAL="10.64.40.173"
###############################################################################
#==============================================================================
######################################################
ipt_start() {
# lancok uritese, szamlalok nullazasa
$IPT -F INPUT;
$IPT -F FORWARD;
$IPT -F OUTPUT;
$IPT -Z INPUT;
$IPT -Z FORWARD;
$IPT -Z OUTPUT;
###############################################################################
# INPUT
###############################################################################
$IPT -P INPUT DROP;
# Connection tracking
$IPT -A INPUT -p tcp --tcp-flags ALL ALL -j DROP;
$IPT -A INPUT -p tcp --tcp-flags ALL NONE -j DROP;
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT;
$IPT -A INPUT -m state --state INVALID -j LOG --log-level info --log-prefix SPOOF: ;
$IPT -A INPUT -m state --state INVALID -j DROP;
$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP;
# Synflood ellen
$IPT -N SYNFLOOD;
$IPT -A INPUT -p tcp --syn -j SYNFLOOD;
$IPT -A SYNFLOOD -m limit --limit 10/s --limit-burst 20 -j RETURN;
$IPT -A SYNFLOOD -j LOG --log-level info --log-prefix SYNFLOOD: ;
$IPT -A SYNFLOOD -j DROP;
# Floodping ellen
$IPT -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s --limit-burst 10 -j ACCEPT;
$IPT -A INPUT -p icmp --icmp-type echo-reply -m limit --limit 1/s --limit-burst 10 -j ACCEPT;
$IPT -A INPUT -p icmp -j DROP;
# Loopback / tunnel IF-ek
$IPT -A INPUT -i lo -s 127.0.0.1 -j ACCEPT;
$IPT -A INPUT -i tap+ -j ACCEPT;
# Bejovo forgalom, IF-enkent es protokollonkent
$IPT -A INPUT -i $IF_ETH -p tcp -m multiport --dports $TCP_IN_PORTS -m state --state NEW -j ACCEPT;
$IPT -A INPUT -i $IF_ETH -p udp -m multiport --dports $UDP_IN_PORTS -m state --state NEW -j ACCEPT;
$IPT -A INPUT -i $IF_WLAN -p tcp -m multiport --dports $TCP_IN_PORTS -m state --state NEW -j ACCEPT;
$IPT -A INPUT -i $IF_WLAN -p udp -m multiport --dports $UDP_IN_PORTS -m state --state NEW -j ACCEPT;
# Ha az ftp-t be akarod engedni a vezetekesen
#
# $IPT -A INPUT -i $IF_ETH -p tcp -m multiport --dports $FTP_PORTS -m state --state NEW -j ACCEPT;
# $IPT -A INPUT -i $IF_ETH -p udp -m multiport --dports $FTP_PORTS -m state --state NEW -j ACCEPT;
# GPS NMEA bridge wlan-on (sajat modositas, nem megy...)
$IPT -A INPUT -i $IF_WLAN -p udp -m multiport --dports $NMEA_PORTS -m state --state NEW -j ACCEPT;
# Ha csak bizonyos IP-rol (portonkent, IP-nkent :S)
#
# $IPT -A INPUT -i $IF_ETH -p tcp -s $URAL --dport 20 -m state --state NEW -j ACCEPT;
# $IPT -A INPUT -i $IF_ETH -p tcp -s $URAL --dport 21 -m state --state NEW -j ACCEPT;
# $IPT -A INPUT -i $IF_ETH -p tcp -s $URAL --dport 113 -m state --state NEW -j ACCEPT;
#
# $IPT -A INPUT -i $IF_ETH -p udp -s $URAL --dport 20 -m state --state NEW -j ACCEPT;
# $IPT -A INPUT -i $IF_ETH -p udp -s $URAL --dport 21 -m state --state NEW -j ACCEPT;
# $IPT -A INPUT -i $IF_ETH -p udp -s $URAL --dport 113 -m state --state NEW -j ACCEPT;
# $IPT -A INPUT -i $IF_ETH -p udp -s $URAL --dport 2947 -m state --state NEW -j ACCEPT;
# oralekerdezesre hasznalt ICMP csomagok fogadasanak letiltasa,
# hadd gyanitsa a tamado vietkong, hogy idotol is fuggo titkositast hasznalunk
# $IPT --append INPUT --protocol icmp \
# --icmp-type timestamp-request \
# --jump DROP
#bzs
# echo tiltasa halozaton kivuli gep fele
# $IPT --append OUTPUT --protocol icmp \
# --icmp-type echo-reply \
# --out-interface lo \
# --jump DROP
#--jump ACCEPT
#bzs
# A tobbi loggolva a lecsoba
$IPT -A INPUT -j LOG --log-level info --log-prefix REJECT: ;
}
###############################################################################
#==============================================================================
#==============================================================================
###############################################################################
ipt_stop() {
$IPT -F SYNFLOOD;
$IPT -F OUTPUT;
$IPT -F INPUT;
$IPT -Z SYNFLOOD;
$IPT -Z OUTPUT;
$IPT -Z INPUT;
$IPT -X SYNFLOOD;
$IPT -P OUTPUT ACCEPT;
$IPT -P INPUT ACCEPT;
}
case "$1" in
'start')
ipt_start
echo ----------------------------------------------------------- ;
$IPT --list
;;
'stop')
ipt_stop
echo ----------------------------------------------------------- ;
$IPT --list
;;
'restart')
ipt_stop;
sleep 0.5;
ipt_start;
echo ----------------------------------------------------------- ;
$IPT --list
;;
*)
echo "usage $0 start|stop|restart"
esac
(sok éve ebben segített valaki, kisebb módosításokat magam hajtottam végre, de a 2947-es port valamiért tényleg nem nyitott.)
Hozzászólások
Mit is látunk az nmap kimenetében?
"2947/tcp open unknown"
És mit látunk a tűzfalszabályodban?
"$IPT -A INPUT -i $IF_WLAN -p udp -m multiport --dports $NMEA_PORTS -m state --state NEW -j ACCEPT;"
Csináltam egy új sort tcp-vel, már más a helyzet.
server:
# nmap -p 2947 localhost
Starting Nmap 7.01 ( https://nmap.org ) at 2017-01-25 15:21 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (-1100s latency).
Other addresses for localhost (not scanned): 192.168.0.2 ::1
rDNS record for 127.0.0.1: localhost.localdomain
PORT STATE SERVICE
2947/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 0.62 seconds
kliens:
# nmap -p 2947 192.168.12.1 ###(ez a szerver IP címe)
Starting Nmap 6.47 ( http://nmap.org ) at 2017-01-25 15:25 CET
Nmap scan report for domain1.com (192.168.12.1)
Host is up (0.0087s latency).
PORT STATE SERVICE
2947/tcp closed unknown
MAC Address: 10:7B:EF:CD:0A:D1 (ZyXEL Communications)
Nmap done: 1 IP address (1 host up) scanned in 0.53 seconds
Új levél a következőben: /var/mail/root
---
--- A gond akkor van, ha látszólag minden működik. ---
---
A Zyxel eszköz a szerver, vagy a Zyxel egy router, és mögötte van az, amit el akarsz érni?
Azon a tűzfalon, amiről az imént szó volt, elvileg átjut minden, ami kifelé kezdeményezett kapcsolat. Az indításban nincs módosítva az amúgy alapértelmezésként ACCEPT default policy az OUTPUT láncon. A leállításkor ACCEPT-re van állítva. Az INPUT pedig visszaengedi a RELATED-et.
A Zyxelen nézd meg a tűzfalat (vagy NAT-ot).
Zyxel a wifi stick neve, gyártója, ami egy raspberrybe van dugva. Az RPI-n pedig a szerver van, amin fut egy gpsd, mely elméletileg minden localhoston a 2947-es porton elérhető adatfolyamot küld. A kplex-szel pedig a hálózat többi gépére küldeném a jelsorozatot, jelenleg a 10110-es porton keresztül, amit azt hiszem már használok. a bajom most az, hogy kliensoldalon az opencpn nem veszi az "adást", wiresharkon viszont észlelhetp az ip cím (192.168.12.1) és a 10110-as port is. Csak a jel kusza. Még nem tudom, miért..
Szóval még oknyomozok, hogy egyáltalán meg tudjak fogalmazni egy kérdést.
---
--- A gond akkor van, ha látszólag minden működik. ---
---
Valamit megcsinálhattam, mert már ez az nmap kimenete:
# nmap -p 2947,10001 192.168.12.1
Starting Nmap 6.47 ( http://nmap.org ) at 2017-01-26 15:37 CET
Nmap scan report for domain1.com (192.168.12.1)
Host is up (0.077s latency).
PORT STATE SERVICE
2947/tcp filtered unknown
10001/tcp filtered scp-config
MAC Address: 10:7B:EF:CD:0A:D1 (ZyXEL Communications)
Nmap done: 1 IP address (1 host up) scanned in 2.34 seconds
Új levél a következőben: /var/mail/root
...szóval most már nem closed, hanem filtered van, ami azt hiszem a tűzfalazottat jelenti, nem a zártat. Csak még mindig nem értem, hogyan kell a portot megnyitni.
---
--- A gond akkor van, ha látszólag minden működik. ---
---
Ez az nmap a kliensről lett indítva a szerver felé. Tehát azt kérdezed, hogy a 192.168.12.1-en a TCP/2947 és TCP/10001 miért nem látszik nyitva.
Két lehetőség van:
a) A kliensről nem jut ki a forgalom, mert a kliens tűzfala(OUTPUT) ezt megakadályozza.
b) A szerverre nem jut be a csomag, mert a szerver tűzfala (INPUT) ezt megakadályozza.
Azt kellene tudni, hogy amit a nyitó hozzászólásban írtál, az most éppen mire van módosítva, illetve hogy az a script csak a szerveren, csak a kliensen, vagy mindkettőn ugyanaz-e.
Következő kérdések:
Én nem találom "10001" karaktersorozatot a scriptedben. Hol engedted be?
"jelenleg a 10110-es porton keresztül"
"az ip cím (192.168.12.1) és a 10110-as port is"
Most akkor 10001 vagy 10110? A "10110" sem szerepel a scriptben.
Légy szíves, mindkét eszközről adj egy
kimenetet. Továbbá egy
is mindkettőről.
Nem tudom, az OUTPUT-ot hogyan kell beállítani iptables-láncon.
A szerverre soros porton bejut az adat 2947-rd porton, ugyanez a kliensen is meg van oldva, ha ott is van egy gps a /dev/ttyUSB0-n.
Szerintem a szerverről nem jut ki semmi 2947-es porton.
A másik két portot is beállítottam a fentiek szerint az iptables tűzfalscriptben, mert azon mennének át más adatok is (AIS sentences)
De egyik portról sem érkeznek kliensoldalon adatok.
Éjszaka valami méfis sikerült, mert átmenetileg mind a három portról érkeztek NMEA-mondatok. Csak éppen nem tudom, hogy akkor éppen mivel kísérleteztem. Szóval van remény.. :)
---
--- A gond akkor van, ha látszólag minden működik. ---
---
Feltettem néhány kérdést, de nem válaszoltál rájuk.
"Azt kellene tudni, hogy amit a nyitó hozzászólásban írtál, az most éppen mire van módosítva, illetve hogy az a script csak a szerveren, csak a kliensen, vagy mindkettőn ugyanaz-e."
"Én nem találom "10001" karaktersorozatot a scriptedben. Hol engedted be?"
"Most akkor 10001 vagy 10110? A "10110" sem szerepel a scriptben."
"Légy szíves, mindkét eszközről adj egy iptables -nvL kimenetet. Továbbá egy netstat -nlA inet is mindkettőről."
Végrehajtottam mindkét oldalon a fentieket, már scriptet is írtam erre, hogy megtanuljam:
# cat iptables_test.sh
#!/bin/bash
iptables -nvL >1
netstat -nlA inet >2
exit 0
Szerveroldal (192.168.12.1):
-------------
Szerveroldal:
Látsz-e a netstatban olyan sort, amely szerint nem a loopback címén hallgat a TCP/2947, illetve hallgat a TCP/10001 vagy TCP/10110?
Én csak olyan sort látok, ahol a TCP/2947 a 127.0.0.1-en hallgat, illetve van egy TCP/10000.
Kliensoldal:
Látsz-e olyan sort, amely szerint a TCP/2947 nem a loopbacken hallgat? UDP/2947 van, de TCP-t nem látok. Hasonlóképpen UDP/10110 van, TCP-n nincs. TCP-n és UDP-n van 10000, 100001 csak UDP-n.
A tűzfalszabályaid között viszont csak ilyeneket látok:
Ennek ismeretében jön a következő kérdés:
Pontosan milyen protokollon milyen cél IP-nek melyik célportjait szeretnéd elérni?
Ha erre megvan a válasz, akkor már magától adódik a következő:
Miért nincsenek ezek a tűzfalszabályaidban felsorolva?
A szerver OUTPUT láncában lévő szabállyal (ICMP Type 0 ) mit szerettél volna elérni?
Fontos: először értsd meg, hogy miért és mit akarsz csinálni, ennek eléréséhez mik szükségesek, és utána írd meg a tűzfalat.
Ez nekem nem fog menni.
Melyik részére gondolsz, amiről azt sejted, hogy nem fog menni?
Pedig viszonylag egyszerű a dolog. Van egy rendszered, amit te állítasz össze, a rajta futó programokat is te konfigurálod a saját megvalósítandó célodnak megfelelően. Abból kellene kiindulni, hogy melyik program milyen módon akar kommunikálni, milyen szerepkört tölt be (hálózati szempontból szerver vagy kliens), ha kliens, akkor milyen protokollon milyen szervercímre és portra akar kapcolatot nyitni, ha szerver, akkor milyen helyi porton, protokollon hallgat, és mely kliensek felől akar kapcsolatot fogadni. Persze - az adott programtól függően - a program lehet egyidőben kliens és szerver is.
Ezeket az adatokat a manual, a dokumentáció, illetve a konfigok (lehet, hogy nem explicite, hanem implicite) a legtöbbször tartalmazzák.
Szóval csak ezek az adatok kellenek, és utána már pikk-pakk megvan a tűzfalszabályrendszer, az iptables szintaktikája nem bonyolult, de ha nem megy, segítünk. Viszont ha tűzfal kell, és valóban védeni akarod a rendszert, akkor dokumentált, illetve egyértelmű esetekben nem találgatunk, hanem azokat, és csak azokat engedjük, amire szükség van. Ezért kértem, hogy elsőként tegyünk rendet a TCP vagy UDP protokollok, illetve 2947/10000/10001/10110 poprtok körül, hogy melyik milyen célt szolgál, szükség van-e rá stb.
Nem értek az iptableshez, mindig csak példákon keresztül tudok tanulni. Hiába mennék be a Műszaki Könyvtárba (ott oldottam meg eddig a legtöbb dolgot), az iptableshez túl öreg vagyok már szerintem, és idegesít, hogy amit 4-5 éve tanultam róla, mind kihullott a fejemből.
Azon kívül állandóan külföldön vagyok, net szakadozik, lassú, könyvtár sehol. Már alternatív módszereket kerestem, egyik a firewalld lett volna, csakhogy Arch-on nekem nem telepedik rendesen. Egy másik valami shorewall lenne, egy ismerősöm erre esküszik, mert az ő haja is égnek áll az iptablestől.
De leírom még egyszer, mi a gondom.
2947 engedi át az NMEA mondatokat amolyan adatfolyamként. Ez TCP ill. UDP portokat is használhat.
10001 a muplex.sh
100110 pedig a kplex, e két utóbbi szolgálna arra, hogy a hálózat összes gépén olvasható lenne a szerverre kötött GPS-ről érkező NMEA mondat.
A klienseken opencpn, foxtrotgps, gpscat, gpsprune fut, valamint egy tableten néhány androidos program.
---
--- A gond akkor van, ha látszólag minden működik. ---
---
Ne az iptables-t akard megtanulni, hanem azt az alapelvet érteni (az egymással kommunikáló programok közül melyik melyikkel milyen viszonyban van: kliens ill. szerver, kapcsolatfelépítés iránya, forrás- ill. célport, stb.), ami alapján elkészül egy tűzfal. Az, hogy az iptables szintaktikája milyen, másodlagos kérdés.
Megpróbáltalak kérdésekkel vezetni, de eddig nem sok sikerrel. :)
Az sem biztos, hogy tűzfalproblémád van. Ha kikapcsolod a tűzfalakat, akkor működik minden rendben?
"2947 engedi át az NMEA mondatokat amolyan adatfolyamként. Ez TCP ill. UDP portokat is használhat."
Itt azt akarod mondani, hogy a gpsd mint szerver működik a TCP/2947 vagy UDP/2947 portokon. Küldtél egy netstat kimenetet. Abban az látszik, hogy UDP-n rendben van, viszont TCP-n csak a localhoston (127.0.0.1:2947) hallgatózik, máshol nem. Ha pedig a kliensről nem érhetőe el az az IP amin hallgatózik, illetve amelyik IP-n elérné a gépet, azon meg nem hallgatózol a gpsd-vel, akkor egyértelműen nem fog menni. Állítsd be a gpsd-t úgy, hogy a 192.168.12.1-en is hallgasson TCP-n, ha azt tervezed használni. Ki fog erre kapcsolódni? Helyben az emlegetett kplex/muplex, vagy távolról a kliens?
"Ez TCP ill. UDP portokat is használhat."
Jó, használhat. De kell neki mindkettő? Vagy választható, hogy melyik? Ha választható, akkor te melyiket választod ki?
"100110 pedig a kplex"
A TCP és UDP portok 0 és 65535 között értelmezettek. A 100110 nem lehet ilyen port.
"e két utóbbi szolgálna arra, hogy a hálózat összes gépén olvasható lenne a szerverre kötött GPS-ről érkező NMEA mondat."
Tehát a kliensről nem a TCP/UDP/2947-et akarod elérni, hanem a TCP/10001-et? Vagy a másik portot? Vagy mindkettőt?
Hiába, olyan vagyok, mint az Argo2-ben a kopasz, aki még a kérdést sem tudja feltenni az informatikus felé.
Bekezdésenként válaszolok, az idézőjelek közé tett mondatokat a/b/c/d-ként értelmezve.
a/
Szerveren a gpsd fut TCP/2947 porton, szerver ip címe 192.168.12.1.
Amikor ssh-n rácsatlakozom, a netstatot *localhost-ként indítottam, erre vonatkozott a kimenet.
Jól értem, hogy a szerverre csatlakoztatott gépen is futtatni kell egy gpsd-t, ami úgy van beállítva, hogy a szerverről olvasson a 2947-es portról? Nem is tudtam, hogy ilyet is lehet.
A muplex vagy kplex programokat, melyek tulajdonképpen scriptek, szerveren kell futtatni a leírások szerint, bár ha mindent meg lehet oldani rendes tűzfalszabályokkal és mezei használatú gpsd-vel, akkor nincs rájuk szükség.
b/
nem kell mindkettő, a TCP javasolt.
c/
10110 a port valódi száma. Vak vagyok, írni sem tudok. Forrás: http://www.stripydog.com/kplex/examples/piap.html
d/
csak azt, amit működésre tudok bírni. Eddig egyiket sem sikerült. Annak örülnék, ha a kplexre és a muplex.sh-ra nem is lenne szükségem.
---
--- A gond akkor van, ha látszólag minden működik. ---
---
Feliratkozás
+1
-----------------------------------------
Linux parancsok, kezdőknek
sub
Azt hiszem fejezetváltás következik ide:
http://hup.hu/node/151832
---
--- A gond akkor van, ha látszólag minden működik. ---
---
Ez a topic arról szól, hogy - elvileg - van egy működő rendszered, ami tűzfal nélkül rendben üzemel, viszont szeretnéd védeni tűzfallal, amin át szeretnéd engedni a rendszered által igényelt IP-s forgalmat. Ezért adtad a topicnak a "iptables:..." címet. A linkelt másik topic netcat használata hogyan fogja a tűzfalkérdést megoldani?
Vagy eleve nem tűzfalprobléma volt? (Lásd az előző hozzászólásomban az "Az sem biztos, hogy tűzfalproblémád van. Ha kikapcsolod a tűzfalakat, akkor működik minden rendben?" kérdést, amire nem érkezett válasz.)
Igen, arról szól.
Ha kikapcsolom a tűzfalat, minden port zárva lesz.
Nem értek a tűzfalakhoz, sosem volt szükségem rá, mert vagy készen érkezett a distribekkel, vagy volt valaki, aki beállította (1 ilyen alkalom volt az életemben)
Találtam egy kiskaput, amivel már nem kell foglalkoznom a kérdéssel, mivel időm igen kevés. Így legalább nem kell megfogalmaznom olyan félresikerült kérdéseket felétek, mely kiveri a biztosítékot tanultabb embereknél. Mert már nekem kínos, hogy a válaszokat sem értem.
---
--- A gond akkor van, ha látszólag minden működik. ---
---
"Ha kikapcsolom a tűzfalat, minden port zárva lesz."
Téves. Alapesetben minden nyitva van, azaz a filter táblában az INPUT, OUTPU és FORWARD lánc default policy is ACCEPT.
Az INPUT-ban te állítottad át DROP-ra - ami a megfelelően megírt ACCEPT sorok mellett jó is lehetne.
De ezt már előzőleg is leírtam: "Az indításban nincs módosítva az amúgy alapértelmezésként ACCEPT default policy az OUTPUT láncon. A leállításkor ACCEPT-re van állítva." Tehát ha nem indítod el a jelenlegi tűzfaladat, akkor minden át tud menni rajta, oda-vissza, a gépnek helyben szóló és a rajta keresztül továbbított forgalom is.
Így néz ki az az állapot, amikor nem konfigutálod a tűzfalat: