Debuggoljuk az iptables scriptemet!:)

Linux-security

Debuggoljuk az iptables scriptemet!:)

  • 6043 megtekintés

( rigidus | 2006. 02. 18., szo – 08:24 )

Sziasztok,

A problemam kicsit sokretu es nem biztos, hogy mindegyike kapcsolodik szorosan a topikhoz, de ezert nem akartam ujat inditani.

Eppen tuzfalat konfiguralok es az itteni peldak szerint osszeallitottam par scriptet ami a majd a gentoo-s szerveremen lesz.

Elsosorban Panther fenti scriptjet vettem alapjaul:
http://cfhay.inf.elte.hu/~panther/linux/scripts/fwon.new.txt

Ha jol vettem ki, akkor nem eleg, ha egyszer lefuttatom es elmentem, mivel ip cimeket le kell kerdeznie, nekem pedig dinamikus ip cimem van igy minden uj kapcsolat letrejotte utan meg kellene hivnom.

A gondok pedig itt kezdodnek, ugyanis a szolgaltatom hetkoznapokon reggel 8-10 es du 4-6 kozott rendszeresen ledobalja a vonalamat, valamint nem hivodik meg semmilyen script mikor ledobja, ill. akkor sem amikor ujra kapcsolodik. Ha ilyenkor megnezem az ifconfig ppp0 -val vagy a /etc/init.d/net.ppp0 status -szal, latszolag online vagyok, gyakorlatilag viszont nem.

Na most, "altalaban" magatol felepul a kapcsolat amikor helyrezokkennek a dolgok, de fogalmam sincs, hogy a scriptet hova tehetnem be. Van erre valakinek bevalt megoldasa?

A kovetkezo gondom a dns-sel van. A benti desktopnak egy dns van megadva: a natolo szerver, ahol forwardolom az ISP-m ket kulso dns-ere. Amikor online vagyok szepen megy a belso nevfeloldas is, amikor viszont megszakad a kapcsolat, valami eszmeletlen lassan oldja fel a belso cimeket. En ebbol arra kovetkeztettem, hogy eloszor a forward-okon megy vegig. Probaltam egy forwarded first; kapcsolot beallitani, de nem segitett sajnos. :(

Igy nez ki most a named.conf:
http://my-cat-is-a.dyn-o-saur.com/hosted/named.conf.txt

Mit rontottam el itt?

A kovetkezo kerdesem a Panther-fele scripttel kapcsolatos lenne. Van benne egy szakasz amit at kellene irnom, mivel a LAN-os IP tartomanyom beleesik egy "hamis_ip" csoportba. A belso halom a 10.0.0.0 es 255.255.255.0, de nem vagyok benne egeszen biztos, hogy milyen mas ip-ket kellene/lehetne kizarnom amiket biztosan nem hasznalok?

$IPT -A INPUT -s 192.168.0.0/16 -i $IFACE_EXT -j hamis_ip
$IPT -A INPUT -s 192.168.0.0/16 -i $IFACE_INT -j hamis_ip
$IPT -A INPUT -s 10.0.0.0/8 -i $IFACE_EXT -j hamis_ip
$IPT -A INPUT -s 10.0.0.0/8 -i $IFACE_MODEM -j hamis_ip
$IPT -A INPUT -s 172.16.0.0/12 -j hamis_ip

Vegezetul meg annyit, hogy jelenleg az /etc/init.d/iptables -szel kapcsolgatom ki-be a tuzfalat ami egy statikus elore elmentett beallitast hasznal.

Erdemes erre alapozni, vagy jobb a scriptes megoldas?

A segitseget elore is koszonom. :)

---------------------
Ригидус а бетегадьбол

Nálam a tűzfal automatikusan elindul, amikor az rp-pppoe elindul. (adsl-em van). Ehhez a /etc/ppp/ip-up scriptet piszkáltam, a végére beírtam egy sort, ami a tűzfal indítását jelenti (ezt: /root/bin/fwon).

Bár dinamikusan határozza meg az interfészek ip címeit, és a hálózati maszkot, stb, igazából mindig ugyanaz. Az $IFACE_INT az a 10.0.0.0/8-ba esik, az $IFACE_MODEM 192.168.0.0/16, tehát ami innen jön és nem ilyen tartományú, az dobható. Az $IFACE_EXT esetén is hasonló, csak ott a fenti 2 címen kívül még a 172.16.0.0/12 címeket is el kell dobni. Mivel a hálózatomban ilyen egyáltalán nem létezik, ezért most a scriptben nincs megadva interfész hozzá.

Nekem nem pppoe van hanem pppoa, ill ebbol kovetkezik, hogy nincsen "$IFACE_MODEM" sem. Ez azt jelenti, hogy azokat a sorokat siman kikommentelhetem?

Van itt egy resz, ez nem tudom, hogy pontosan mit csinal. Az eltero belso ip cimek miatt kell vele valamit kezdenem?

tcp_pfw[0]=10100:192.168.0.7:10100 #dc
udp_pfw[0]=10100:192.168.0.7:10100 #dc
tcp_pfw[2]=10101:192.168.0.7:10101 # amsn
udp_pfw[2]=10101:192.168.0.7:10101 # amsn
tcp_pfw[4]=6112:192.168.0.7:6112 # bnet war3
udp_pfw[4]=6112:192.168.0.7:6112 # bnet war3

tcp_pfw[5]=40:192.168.0.7:22 # ssh
tcp_pfw[6]=80:192.168.0.7:80 # http

Ill. ez sem pontosan tiszta:

# mi a franc ez???
$IPT -A FORWARD -i $IFACE_EXT -o $IFACE_EXT -j ACCEPT
$IPT -A FORWARD -i $IFACE_INT -o $IFACE_INT -j ACCEPT

$IPT -A FORWARD -i $IFACE_EXT -j forward_ext
$IPT -A FORWARD -i $IFACE_INT -j forward_int

Fentebb volt rola szo, de nem volt egyertelmu, hogy ez jo vagy nem jo ha van. Ezt benne hagyhatom?

Koszi elore is :)
---------------------
Ригидус а бетегадьбол

Az alsó 2 $IPT sort mindenképpen hagyjad benne, az első kettőt én sem vágom, SuSEfirewall2-ben volt (netről jövő csomagot netre dobni vissza - ez nagyon lol, de biztos megvan az oka - ez az első sor).

A tcp/udp pfw tömbök jelölik, hogy a külső interfész akárhanyas portjára érkező kapcsolat (kettőspontokkal határolva ez az első mezőt jelnti) melyik belső hálós gépre továbbítódjon, és ott milyen portra.

Nekem, mint mondtam, a belső háló 10.0.0.0/8-as (igazából a scriptben a portforwardból nem az látszik, mert átírtam). Szóval ha a routerem 10.0.0.1 (belső hálón) és az internet felől a 40-es portra érkező TCP kapcsolatot a 10.0.1.2-es belső gép 22-es portjára szeretném továbbítani, akkor elég annyit megadni,hogy
tcp_pfw[1]=40:10.0.0.2:22

Mivel ezek tömbök, fontos, hogy minden portforwardhoz külön tömbindex tartozzon, különben a legutolsó az érvényes.

Köszi.

Most így átnézve, egyet biztosan változtattam ill. változtatnék:
ez ronda, ráadásul az indexek miatt nehezen kezelhető: 


udp_pfw=()
tcp_pfw=()
...
tcp_pfw[2]=10101:192.168.0.7:10101 # amsn
udp_pfw[2]=10101:192.168.0.7:10101 # amsn

Így sokkal szebb: 


tcp_pfw=(
     10100:192.168.0.6:10100 # amsn
     10101:192.168.0.7:10101 # amsn
   )

( Panther v | 2005. 07. 26., k – 14:02 )

Nekem is van egy jó tűzfalszkriptem, a gondja csak az, hogy kicsit már gányolt, így nyekereg alatta a 166MHzes routerem. Egy rakat tiltás van benne, amit nem a scriptben kellene csinálnom, hanem egy abból a háttérben elindított scripttel. Csak azt nem tudom, kirakjam-e valahova.

( zither | 2005. 07. 29., p – 10:34 )

[quote:1bf5ca65e9="Panther"][quote:1bf5ca65e9="zither"][quote:1bf5ca65e9="Panther"](most > 10 sec).

Ez érdekes, mert szerintem nincs benne annyi minden. Az én szabálygyűjteményemnek kb. 2 sec, amíg betöltődik.

(A kirakott bash script fut minden alkalommal, nem használom az iptables-save és iptables-restore parancsokat)

Hát, mint itt a hupon párx írtam: a gép egy 166MHz-es pentium mmx 8GB vinyóval, 64MB memóval... Lassú.

Lehet, hogy számít, bár a mi tűzfalunk sem erőmű: 400Mhz Celeron, 128MB RAM, 4GB vinyó (hirtelen nem leltem kisebbet, amikor össze raktam).

( zither | 2005. 07. 26., k – 16:28 )

[quote:9d25fa989d="Panther"]Nekem is van egy jó tűzfalszkriptem, a gondja csak az, hogy kicsit már gányolt, így nyekereg alatta a 166MHzes routerem. Egy rakat tiltás van benne, amit nem a scriptben kellene csinálnom, hanem egy abból a háttérben elindított scripttel. Csak azt nem tudom, kirakjam-e valahova.

Ahogy gondolod...

Ha tényleg úgy érzed, hogy biztonságos, akkor nem jelenthet biztonsági problémát, főleg, ha nem adod ki a tényleges gépet amin fut (mármint a gép nevét, ip-jét, vagy más jellemző azonosítót, ami alapján meg lehet találni).
Ha viszont komolyabb logikai hibák is vannak a biztonsági beállításaidban (nem csak fw script, hanem a jogok, rendszerkomponensek, beállítások, stb...) akkor...

( zither | 2005. 07. 26., k – 16:40 )

A tűzfalat (főleg, ha kis teljesítményű gépeken nyekereg) gyorsítani lehet egy kis kapcsolat állapot követéssel.

Lényege, hogy definiálni kell egy olyan szabályt viszonylag a láncok elején, ami átengedi a már engedéjezett session-okhoz tartozó csomagokat (Vagyis kapcsolat kezdeményezésekor komolyabb ellenőrzés, aztán már a hozzá tartozó adatfolyamot csak egyszerűen átengedjük).
[code:1:47ac554b1a]
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
[/code:1:47ac554b1a]
A kapcsolatok elfogadásakor is érdemes ellenőrizni az állapotot, hogy valóban SYN csomaggal kapcsolódnak hozzánk és nem mondjuk egy FIN letapogatásról van szó
[code:1:47ac554b1a]
iptables -A OUTPUT -p udp --dport 53 -m state --state NEW,RELATED -j ACCEPT
[/code:1:47ac554b1a]
Illetve érdemes mindent eldobálni minden kapcsolat kezdeményt, ami nem SYN csomaggal indul (az RFC-k szerint ugyebár ezzel kéne a kapcsolat felvételt kezdeni)
[code:1:47ac554b1a]
iptables -A sinput -p tcp ! --syn -m state --state NEW -j DROP
[/code:1:47ac554b1a]

Nagyjából ennyi a kapcsolat állapot követő fw lényege. Megjegyzem, hogy (tudtommal) csak a 2.4.xx-es kernelektől kezdve létezik (a stabil ágon) és iptables kell hozzá.

( FoREE | 2005. 07. 26., k – 16:45 )

[quote:9c4a97a1f4="zither"]Megjegyzem, hogy (tudtommal) csak a 2.4.xx-es kernelektől kezdve létezik (a stabil ágon) és iptables kell hozzá.

ja, az iptables elodja az ipchains (2.0, 2.2 kernelek) meg nem tudott stateful modban mukodni

( Panther v | 2005. 07. 26., k – 16:51 )

No, felraktam: http://cfhay.inf.elte.hu/~panther/linux/scripts/firewall.txt

Egyszer nekiálltam átírni Mick Bauer-nek a Szerverek védelme Linux-szal c. könyve alapján, de utána vmiért nem ment a natolás (forward). Lényegében üres tűzfalszabályok mellett sem. Így ezt foltozom.

( Panther v | 2005. 07. 26., k – 17:27 )

[quote:7371403915="zither"] Mivel többen is kértétek, kiraktam webre az egyszerűség kedvéért.
Megtalálhatjátok a http://free.x3.hu/zither/hup/firewall.txt címen.
Ha esetleg találtok benne valami hibát (mint előző hozzászólásomban írtam, biztos, hogy van :) ), nyugodtam kössetek bele :wink: .

Belekötök: nem tudom elérni: connection timed out :? Viszont az ELTE-ről megy.

Más: a modprobe az elején felesleges, mert az iptables automatikusan betüülti a modulokat. Olyat meg nem csinálsz, hogy modprobe ... || {echo hiba; exit 1 }

( Panther v | 2005. 07. 26., k – 17:42 )

No, átfutottam:

[code:1:c960b30a29]iptables -A OUTPUT -s 127.0.0.0/255.255.255.0 -j ACCEPT[/code:1:c960b30a29]

Ezt nem tartom jó 5letnek: pl REDIRECT elvileg a lo interfészen megy, és ezt ezzel letiltod. Nálam van redirect :)

[code:1:c960b30a29]iptables -A sinput -j REJECT[/code:1:c960b30a29]

Ehelyt szerintem jobb:
[code:1:c960b30a29]iptables -A sinput -j reject_func

iptables -A reject_func -p tcp -j REJECT --reject-with tcp-reset
iptables -A reject_func -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A reject_func -j REJECT --reject-with icmp-proto-unreachable
[/code:1:c960b30a29]

Így minden protokoll a neki megfelelőt kapja...

[code:1:c960b30a29]iptables -A sinput -i $IFACE_INT -p tcp -s $NET_INT --dport 20 -m state --state NEW -j ACCEPT #ftp
iptables -A sinput -i $IFACE_INT -p tcp -s $NET_INT --dport 21 -m state --state NEW -j ACCEPT #ftp[/code:1:c960b30a29]

Ezt is egybe lehetne venni. Ha lassú a router (mint az enyém), akkor sajna számít ez a kis különbség is.

Az OUTPUT láncon először kiengeded a RELATED,ESTABLISHED kapcsolatokat, majd pedig egy csomó szabályban a RELATED megint szerepel - felesleges.

Azt látom, hogy szépen limitáltad az ssh-t: 1/óra - ez nálam 3/perc :)

( mikcsabee | 2005. 08. 11., cs – 00:51 )

Sziasztok!

Kissé gyakorlatlan vagyok az IPtablesben, szóval lenne egy -két kérdésem. Gyengébb idegzetű gyakorlott profik ne olvassák a lentebbi sorokat.

Tűzfalbeállítások előtt a Portscan Ezeket a portokat találta nyitva:
21
22
25
53
80
111
113
631
953
982
992
3306

No most a 111 - a 992-ig a nyitott portokra nem volt szükségem, ezért néhány minta alapján összeállítottam egy scriptet:

[code:1:c54187bf06]
#! /bin/bash

# tuzfal script

# volt beallitasok torlese
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD

#alapszabalyok
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state INVALID -j DROP

#szolgaltatasok:
#ftp
iptables -A INPUT -p tcp --dport 21 -j ACCEPT
#smtp
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
#ssh engedelyezes
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
#dns
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
#webszerver
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
#mysql - csak localhost-rol
iptables -A INPUT -s 127.0.0.1 -p tcp --dport 3306 -j ACCEPT

#icmp valaszok
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
iptables -A INPUT -p icmp -j ACCEPT

#ftp
iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT

#minden mas csomag eldobasa..
iptables -A INPUT -j DROP

echo "IP-Tables script Lefutott..."
[/code:1:c54187bf06]

A cód abban nagyon jó, hogy a portscan-t nem engedélyezi.
Mivelhogy nemvagyok még jártas az IPtables rejtelmeiben, ezért továbbra is kérdéses, hogy az adott portok (111,113,631,953,982,992) nyitva vannak-e? Mivel hogy elképzelni se tudom hogy mire jók ezek a prortok, így kipróbálni sem tudodm, hogy működnek-e, de nem szeretném, ha valaki besétálna rajta...
A localhost-ról a következők gyönyörűen működnek: 21,22,80. a töbit nem próbáltam.

Mielőtt javasolnátok ezt már olvastam: http://hup.hu/modules.php?name=Downloads&d_op=getit&lid=33

A segítséget előre is köszönöm.

( aty | 2005. 07. 12., k – 11:03 )

Még tavaly nyáron összeállítottam egy iptables scriptet, aminek az elsődleges feladata a dsl megosztása volt. Azóta szinte hozzá se nyúltam, de egyre több hiba bukkan fel mostanában, ha felrakom egy szerverre. Az egyik ilyen bug az MTU-hiba volt, de ezt javítottam. Most azonban egy olyannal találkoztam, hogy ha az alapszabály az INPUT láncon DROP, akkor a netet megosztó géppel nem lehet mit kezdeni, nem képes elvégezni a dns-feloldást, és emiatt sok program nagyon lassan indul el, ill. a netet se érem el róla. A kliensek természetesen működnek.
Szóval arra szeretnék kérni titeket, hogy nézzétek át a scriptet, és a probléma megoldásában és néhány jó ötlettel segítsetek! :roll: :D

[code:1:1a18cf14a2]#!/bin/sh
echo "Starting up the firewall..."
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -F
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD

#alapszabalyok
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -t nat -F PREROUTING
iptables -t nat -F POSTROUTING
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -s 127.0.0.1/32 -m state --state NEW -j ACCEPT
#netmegosztas
iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.0.0/16 -j MASQUERADE
#mtu problema fixelese
iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu

#hamis lokalis ipcimmel erkezo csomagok tiltasa
#iptables -A INPUT -i ppp0 -s 192.168.0.0/16 -j DROP
#itables -A INPUT -i ppp0 -s 127.0.0.0/8 -j DROP
#0.2 kliens teljes szabadsaga
iptables -A INPUT -s 192.168.0.2 -j ACCEPT
#szolgaltatasok engedelyezese
#ftp engedelyezese
iptables -A INPUT -p tcp --dport 21 -j ACCEPT
iptables -A INPUT -p tcp --dport 51000:51500 -j ACCEPT
#smtp
#iptables -A INPUT -p tcp --dport 25 -j ACCEPT
#ssh engedelyezes
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
#dns
#iptables -A INPUT -p tcp --dport 53 -s 192.168.0.0/16 -j ACCEPT
#iptables -A INPUT -p udp --dport 53 -s 192.168.0.0/16 -j ACCEPT
#webszerver
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
#rpc
#iptables -A INPUT -p tcp --dport 111 -s 192.168.0.0/16 -j ACCEPT
#identd engedelyezese
iptables -A INPUT -p tcp --dport 113 -j ACCEPT
#pop3
#iptables -A INPUT -p tcp --dport 110 -j ACCEPT
#samba
iptables -A INPUT -p tcp --dport 137:139 -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -p udp --dport 137:139 -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 445 -s 192.168.0.0/16 -j ACCEPT
#nfs
#iptables -A INPUT -p tcp --dport 1080 -j REJECT
#iptables -A INPUT -p tcp --dport 2049 -s 192.168.0.2 -j ACCEPT
#proxy
#iptables -A INPUT -p tcp --dport 3128 -s 192.168.0.0/16 -j ACCEPT
#iptables -A INPUT -p tcp --dport 3128 -s 195.228.157.253 -j REJECT
#iptables -A PREROUTING -t nat -s 192.168.0.0/16 -p tcp --dport 80 -j REDIRECT --to-port 3128
#vnc
iptables -A INPUT -p tcp --dport 5900:5920 -j ACCEPT
#torrent
#iptables -A INPUT -p tcp --dport 6881 -j ACCEPT
#irc szerver proxy ellenorzesenek gyorsitasa
iptables -A INPUT -p tcp --dport 6588 -j REJECT
iptables -A INPUT -p tcp --dport 8080 -j REJECT
iptables -A INPUT -p tcp --dport 3128 -j REJECT
iptables -A INPUT -p tcp --dport 1080 -j REJECT
#eggdrop
#iptables -A INPUT -p tcp --dport 9020 -j ACCEPT
#iptables -A INPUT -p tcp --dport 35005 -j ACCEPT
#psybnc
iptables -A INPUT -p tcp --dport 6789 -j ACCEPT

#icmp valaszok
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

#port forward(35000:35500 tartomany)
iptables -A FORWARD -j ACCEPT -p udp --dport 35000:35500
iptables -t nat -A PREROUTING -i ppp0 -p udp --dport 35000:35500 -j DNAT --to 192.168.0.2
iptables -A FORWARD -j ACCEPT -p tcp --dport 35000:35500
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 35000:35500 -j DNAT --to 192.168.0.2

#ftp
iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
echo "The firewall is up."
[/code:1:1a18cf14a2]

( nug | 2005. 07. 12., k – 11:25 )

ird at ezt accept-re es mukodni fog:
iptables -P INPUT DROP

( zither | 2005. 08. 11., cs – 08:54 )

Ami a legfontosabb: az iptables csupán egy szűrő, ami letiltja vagy engedélyezi a hálózati csomagok áramlását. Tehát, ha be van konfigurálva az iptables, akkor nem engedi a forgalmat a porthoz, viszont attól még az nyitva marad.
Ha komolyan tűzfalat akarsz építeni, akkor először azt kell elérned, hogy alapéretelmezetten minél kevesebb portod legyen nyitva, és csak azután érdemes a tűzfalat konfugrálni. A portokat legegyszerűbben az összes olyan szolgáltatás leállításával érheted el, amelyekre nincs szükséged. Kiemelten érdemes letiltani az NFS-t és a hozá tartozó Locatort-t, illetve az SMB-t. Még egy apróság: azt, hogy milyen hálózati szolgáltatások futnak, az /etc/services-ben meg tudod nézni a kapu portszáma alapján. Hasznos lehet arra nézve, hogy mit keress. (Pl.: nem tudom, hogy a MySQL-re tényleg szükséged van-e, vagy csak úgy fut.)
Más:
Ha azt akarod, hogy az ftp forgalom működjön, akkor nyisd ki a 20-as portot is, ugyan is 21-en az csupán a vezérlő üzenetek mennek, a tényleges fájlátvitel a 20-as porton megy. Továbbá szükséges lehet még hozzá a ip_conntrack_ftp kernel modul betöltése, amennyiben használsz állapotkövető szűrést (már pedig használsz).

( aty | 2005. 07. 12., k – 11:32 )

Igen... De azzal mire megyek? Épp az a kérdésem, hogy miért nem megy ha DROP az alapszabály INPUT láncon? Illetve milen kivétel kellene, hogy menjen?

( zither | 2005. 08. 11., cs – 08:58 )

Még egy apróság: az 53-as porton a DNS forgalom megy. Ammenyiben nem tartasz fennt dns kiszolgálót, ami más kiszolgálókkal szinkronizál (pl.: másodlagos dns kiszolgáló), akkor az 53tcp kaput nyugodtan bezárhatod, ugyanis a dns lekérdezések az 53udp kapun mennek. Ahhoz, hogy tudjál kapcsolódni a szolgáltatód feloldójához elég csupán azt (53udp) engedélyezni.

( mikcsabee | 2005. 08. 11., cs – 09:16 )

Köszönöm a segítséget, kicsit utánna járok adolgoknak...
Egyéb érdekesség, a Rendszer egy Debian 3.1 r0a - te írtad az install DVD-ket :D

( eddie303 | 2005. 07. 12., k – 11:33 )

[quote:7d6986c72c="nug"]ird at ezt accept-re es mukodni fog:
iptables -P INPUT DROP

Mondd, hogy csak a szmájlit felejtetted ki, és szíatni akarod :)

( FoREE | 2005. 07. 12., k – 11:45 )

output accept

input state ESTABLISHED,RELATED accept

ez alapjan kellene mukodnie a dns lekerdezesnek.

mivel az 53 -as portot kinyitod, gondolom sajat dns szervert hasznalsz. nem lehet hogy azzal van a gond?

probald mar ki igy:
[code:1:7f90865075]host -t a www.index.hu szolgaltato_dns_szervere
[/code:1:7f90865075]
aztan
[code:1:7f90865075]host -t a www.index.hu localhost
[/code:1:7f90865075]

van-e elteres?

( aty | 2005. 07. 12., k – 11:53 )

Nem használok saját dns szervert ezen a gépen, ahol gond van. Itthoni szerveren használtam csak anno sajátot, és benne maradt a scriptben, de itt ki is van kommentezve.

( Panther v | 2005. 08. 11., cs – 10:51 )

[quote:b7be932ada="zither"]Még egy apróság: az 53-as porton a DNS forgalom megy. Ammenyiben nem tartasz fennt dns kiszolgálót, ami más kiszolgálókkal szinkronizál (pl.: másodlagos dns kiszolgáló), akkor az 53tcp kaput nyugodtan bezárhatod, ugyanis a dns lekérdezések az 53udp kapun mennek. Ahhoz, hogy tudjál kapcsolódni a szolgáltatód feloldójához elég csupán azt (53udp) engedélyezni.

De az kevés, ha a szolgáltatóhoz lehet csatlakozni (lehet kifejezetten ezt a kapcsolatot is engedélyezni). Én ezt tettem, és menet közben kiderült, hogy pár program nem használja a /etc/resolv.conf-ot, így minden gép felé engedélyezni kell az 53-as portot udp-n.

A helyzet ennél rosszabb, ugyanis ha az adott lekérdezés nem fér bele egy (udp) csomagba, akkor tcp kapcsolatot nyit, tehát azt sem lehet tiltani. Amit lehet, az az 53-as portra bejövő kapcsolat, vagyis

[code:1:b7be932ada]iptables -A INPUT -p tcp --dport 53 -m state --state NEW -j DROP
iptables -A INPUT -p tcp --dport 53 --syn -j DROP[/code:1:b7be932ada]

Az hogy a sin flag be van billentve nem ekvivalens azzal, hogy a csomag egy új kapcsolat kezdetét jelzi, ezért kell mind2 szabály, vagy a rossz csomagokat már kezdetben el kell dobni.

( zither | 2005. 07. 14., cs – 09:43 )

Tegnap nem voltam, ezért kicsit késve tudom kielégíteni a felmerült igényeket. Mivel többen is kértétek, kiraktam webre az egyszerűség kedvéért.
Megtalálhatjátok a http://free.x3.hu/zither/hup/firewall.txt címen.
Ha esetleg találtok benne valami hibát (mint előző hozzászólásomban írtam, biztos, hogy van :) ), nyugodtam kössetek bele :wink: .

( zither | 2005. 07. 14., cs – 10:00 )

Egyébként tényleg érdekelne a véleményetek (ha már kiraktam :))...

( zither | 2005. 07. 12., k – 14:03 )

#icmp valaszok
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

Itt az első hiba... Ennek így semmi értelme. Minden icmp csagot elfogadsz az első sorban, aztán nekiálsz szűrögetni (amihez már nem jut el, hiszen előtte egy ACCEPT szabály már illet rá)

Ezt így kelett volna:
[code:1:847fc33996]
iptables -A INPUT -p icmp --icmp-type echo-request -m limit limit 1/s -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j LOG --log-prefix "PoD tamadas gyanu "
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
iptables -A INPUT -p icmp -j ACCEPT
[/code:1:847fc33996]
Vagyis először a limit szabály szerint fékezi a Pingeket. Azokat a pingeket, amiket nem engedett át naplózza, aztán eldob. Legvégül minden más (hiszen a pingeket már eldobáltuk) icmp csomagot átenged.

Egyébként ha több terminálból pingeled a gépet, kipróbálhatod a hatást. 3-4 folymatos ping process esetén a működő szabály miatt több esetben sem jön válasz a pingre.

( zither | 2005. 07. 12., k – 14:12 )

Más:

Ha igazán biztonságra vágysz, akkor nem csak az INPUT, ha OUTPUT és FORWARD láncokon is legyen a policy DROP, aztán ki kell felyteni, hogy mi az ami mégis mehet. Persze akkor a szabályok felállítása kicsit munkásabb, de megéri.

Még egy apróság: ha valóban tűzfalnak használod, akkor érdemes megnézned egy típushibát. Jellemző, hogy az alapértelmezett tűzfalszabályokat csak a net felépülése után változtatják meg, vagyis a bootolás alatt a gép sebezhető. Érdemes csinálni egy másik tűzfalszabály gyűjteményt, ami a hálózat feléplése előtt (inittabba kicsit bele kell nyúlni) betöltődik. Ez a szabály gyűjtemény minden hálózati forgalmat tiltson, kivéve azokat, amik feltételenül kellenek a boot-hoz (NFS kötetek gazdái, kábel modem, stb...). Aztán a boot folyamat legvégén eltakaritod a boot alatti szabályokat és feltöltöd a használathoz szükséges szabályokkal.

Ha érdekel oda adhatom az én tűzfalszabályaimat megtekintésre. Jóval nagyobb és bonyolultabb (és valszeg van benne hibás rész is :)), de esetleg tanulni lehet belőle...

( mikcsabee | 2005. 08. 11., cs – 13:46 )

Esetleg tudnátoki ajánlani valami jó könyvet amiben részletesen le vannak írva a beállítások?

( zither | 2005. 07. 27., sze – 08:52 )

[quote:6018b24462="Panther"]
Más: a modprobe az elején felesleges, mert az iptables automatikusan betölti a modulokat. Olyat meg nem csinálsz, hogy modprobe ... || {echo hiba; exit 1 }

Teljesen igazad van, hiszen a kernel modulok sikeres modprobe esetén automatikusan betöltődnek a továbbiakban minden rendszer indításkor. Igazából a modprobe-kal az volt a célom, hogy a szkript átvihető legyen konfigurálatlan "szűz" rendszerre, mert betöltögeti magának a szükséges kernel modulokat (a másik előny, hogy így azonnal látni lehet, hogy mi szükséges hozzá, aminek lehet jelenetősége, hiszen behúz ritkábban használt modulokat is).

( zither | 2005. 08. 11., cs – 14:13 )

[quote:9ac994cb76="Panther"]
De az kevés, ha a szolgáltatóhoz lehet csatlakozni (lehet kifejezetten ezt a kapcsolatot is engedélyezni). Én ezt tettem, és menet közben kiderült, hogy pár program nem használja a /etc/resolv.conf-ot, így minden gép felé engedélyezni kell az 53-as portot udp-n.

Olyannal még nem találkoztam, hogy egy program ne használná a resolv.conf-ot. Érdekes lehet :-(
Ami viszont tény, hogy valóban minden külső (inet-es) cím felé engedélyezni kell az udp-t, mert lehet, hogy a szolgáltató dns szervere nem tudja feloldani, és e miatt átirányít egy másik/magasabb rendű kiszolgálóhoz. Az viszont nem írtam, hogy csak a szolgáltató felé kell engedélyezni (ha mégsem volt egyértelű a fogalmazás, vagy félreérthető volt, akkor elnézést).

[quote:9ac994cb76="Panther"]
A helyzet ennél rosszabb, ugyanis ha az adott lekérdezés nem fér bele egy (udp) csomagba, akkor tcp kapcsolatot nyit, tehát azt sem lehet tiltani.
.

Én úgy tudtam, hogy a tcp kapu a zóna transzferekhez van fenntartva, de most javításodra reagálva utána néztem. Ha a dns szerver válasza (illetve - gondolom - ha a lekérdezés) hoszabb, mint 512 byte, akkor valóban tcp-n zajlik a forgalom, ezért ezt is engedélyezni lehet. Azt viszont nem tudom, hogy milyen dns név lehet az, ami nem fér bele 512 byte-ba. Nálam csak az udp van nyitva, és tökéletesen megy. Azt hiszem ezek ismeretében is megtartom ezt a beállítást, tudva azt, hogy tulajdonképpen ezzel elvi hibát követek el, ugyan is úgy gondolom, hogy gyakorlati jelentősége nincs a dolognak.
Ha esetleg ellen véleményed/tapasztalatod van, azért nyogudtan írjál, mert én se gondolhatok mindenre, és lehet hogy tévedek.

( zither | 2005. 07. 27., sze – 09:09 )

[quote:f9e1f0f2e2="Panther"]No, átfutottam:

[code:1:f9e1f0f2e2]iptables -A OUTPUT -s 127.0.0.0/255.255.255.0 -j ACCEPT[/code:1:f9e1f0f2e2]

Ezt nem tartom jó 5letnek: pl REDIRECT elvileg a lo interfészen megy, és ezt ezzel letiltod. Nálam van redirect :)

Érdekelne, hogy mi a te megoldásod erre a problémára, mert kimenőnek interface-t (lo) nem lehet engedélyezni (tudtommal)

Abban viszont nem vagyok biztos, hogy van-e értelme részletezni a reject-et, mivel az iptables-nek mindenféle protokollra van alapértelmezett visszautasító üzenete. Szerintem csak akkor van értelme definiálni, ha nem egy "szabványos" visszautasítást, hanem valamilyen speciális visszautasítási üzenetet akarsz küldeni.

[quote:f9e1f0f2e2="Panther"]Az OUTPUT láncon először kiengeded a RELATED,ESTABLISHED kapcsolatokat, majd pedig egy csomó szabályban a RELATED megint szerepel - felesleges.

Ez valójában egy elgépelési anomália lehet, ami a copy-paste műveleteknek köszönhetően tovább terjedt (az input láncon még nincs) :D

[quote:f9e1f0f2e2="Panther"]Azt látom, hogy szépen limitáltad az ssh-t: 1/óra - ez nálam 3/perc :)

Szerintem ez is bőven elég. Szívem szerint egyáltalán nem engedném az inet felöli beloggolást a rendszerbe, de sajnos elképzelhető olyan felállás, hogy távol vagyok a géptől, viszont szükségesé válik valkamilyen gyors beavatkozás. Ekkor lehet ezt használni. Viszont az 1 órás korlát talán annyira megnehezití a belépést, hogy feladják a próbálkozók. (Egyébként bónusznak csak RSA kulcs segítségével lehet bejelentkezni oda, ezzel is próbálván növelni a biztonságot).

( zither | 2005. 07. 27., sze – 09:12 )

[quote:e2fdbb240c="Panther"]No, felraktam: http://cfhay.inf.elte.hu/~panther/linux/scripts/firewall.txt

Egyszer nekiálltam átírni Mick Bauer-nek a Szerverek védelme Linux-szal c. könyve alapján, de utána vmiért nem ment a natolás (forward). Lényegében üres tűzfalszabályok mellett sem. Így ezt foltozom.

Elárulok egy titkot: ez a szabály gyűjtemény is az ott leírtak alapján készült (mármint a filozófiáját tekintve) megspékelve néhány további biztonsági riasztásokat generáló szabállyal. Sajnos ugyan az interneten terjengő nagy mennyiségű szemét miatt elég sok a téves riasztás...

(még finomítani kell rajta)

( zither | 2005. 07. 12., k – 15:26 )

Most azonban egy olyannal találkoztam, hogy ha az alapszabály az INPUT láncon DROP, akkor a netet megosztó géppel nem lehet mit kezdeni, nem képes elvégezni a dns-feloldást, és emiatt sok program nagyon lassan indul el, ill. a netet se érem el róla. A kliensek természetesen működnek.

A DNS feloldáshoz az 53-as UDP kapunak kell nyitva lennie minden irányba (Input, output, forward). A TCP 53 -at csak akkor kell kinyitnod, ha DNS szerverek szinkronizálkásában (elsődleges-másodlagos DNS szerverek adatainak egyeztetésében) is részt veszel. Minden más esetben ajánlott bezárni.
[code:1:5b911343b0]
#dns
#iptables -A INPUT -p tcp --dport 53 -s 192.168.0.0/16 -j ACCEPT
#iptables -A INPUT -p udp --dport 53 -s 192.168.0.0/16 -j ACCEPT
[/code:1:5b911343b0]

Az általad írt szkriptben (azon kívül, hogy megjegyzésbe került és nem halytódik végre) valószínűleg az lehet, hogy a DNS kérések kimennek, de a "-s 192.168.0.0/16" miatt a válaszokat csak akkor engedné be ha azok a belső hálódról jönnének, ami ugyebár... A tűzfal mögötti gépek azért szaladnak, mert a FORWARD láncodon nincs ilyen jellegű korlátozás. Ha a fentebb említett forrás direktívát eltávolítod a szabályokból, akkor szaladni fog. Egyébként a fentebb írtak alapján javaslom, hogy a TCP 53-at ne nyisd ki.

( zither | 2005. 08. 11., cs – 14:24 )

[quote:773f25b289="mikcsabee"]Esetleg tudnátoki ajánlani valami jó könyvet amiben részletesen le vannak írva a beállítások?

Itt van néhány könyv a Kiskapu kínálatából. Gyakorlatilag mindent leírnak a biztonságos szerver üzemeltetésről, így a netfilter (ipchains/iptables) alapú tűzfalakról is:

http://www.kiskapu.hu/index.php?BODY=BookInfo&OP=details&ID=54796%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20&VISIT=1
http://www.kiskapu.hu/index.php?BODY=BookInfo&OP=details&ID=52372%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20&VISIT=1
http://www.kiskapu.hu/index.php?BODY=BookInfo&OP=details&ID=43976%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20&VISIT=1

Ezekhez még hozzáolvasol internetes jegyzeteket, a felsorolt (és téged érintő) alkalmazások manuláljait, és már 100%-osan képben is leszel.

( Panther v | 2005. 07. 27., sze – 09:46 )

[quote:d72d38d4ff="zither"]Érdekelne, hogy mi a te megoldásod erre a problémára, mert kimenőnek interface-t (lo) nem lehet engedélyezni (tudtommal)

Első 2 szabályom:
[code:1:d72d38d4ff]$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT[/code:1:d72d38d4ff]

[quote:d72d38d4ff="zither"]
Abban viszont nem vagyok biztos, hogy van-e értelme részletezni a reject-et, mivel az iptables-nek mindenféle protokollra van alapértelmezett visszautasító üzenete. Szerintem csak akkor van értelme definiálni, ha nem egy "szabványos" visszautasítást, hanem valamilyen speciális visszautasítási üzenetet akarsz küldeni.

Sokkal lassabban ér vissza az alapértelmezett reject-tel (i--reject-with icmp-proto-unreachable) a válasz. Ha már reject, akkor legyen "rendes", ellenkező esetben jobb a DROP, még jobb a TARPIT :P De sajnos ez utóbbi csak a pom-ban van, nem az alap kernelben, így nem játszom vele.

[quote:d72d38d4ff="zither"]
[quote:d72d38d4ff="Panther"]Azt látom, hogy szépen limitáltad az ssh-t: 1/óra - ez nálam 3/perc :)

Szerintem ez is bőven elég. Szívem szerint egyáltalán nem engedném az inet felöli beloggolást a rendszerbe, de sajnos elképzelhető olyan felállás, hogy távol vagyok a géptől, viszont szükségesé válik valkamilyen gyors beavatkozás. Ekkor lehet ezt használni. Viszont az 1 órás korlát talán annyira megnehezití a belépést, hogy feladják a próbálkozók. (Egyébként bónusznak csak RSA kulcs segítségével lehet bejelentkezni oda, ezzel is próbálván növelni a biztonságot).

Az utóbbi jó gondolat, a gond viszont az 1/órával a következő. Nálam nagyon sokszor be kívánnak jönnni a 22es kapun, akár percenként többször is. Így elhasználják az 1/hour lehetőséget, és te szépen kint maradsz. Ezért használok 3/perc-es korlátot. Ráadásul az ELTE hálózatából alapból beengedem a kapcsolatokat, csak hogy bebiztosítsam magam. Ja, a jelszót magam sem ismerem, szóval akár ki is vehetném az passwd authot - hm, mindjárt megteszem.

[quote:d72d38d4ff="zither"]Elárulok egy titkot: ez a szabály gyűjtemény is az ott leírtak alapján készült

Részben ismermős volt "csúnya ip-k" szűrése az elején, de a többit máshogy oldottad meg. az XMAS, stb portscannelésnek meg nem olvastam utána (csak ősrégen :)), szóval lehet tanulni a scriptedből :)

( blanc | 2005. 07. 27., sze – 09:56 )

Csak egy elvi kérdésem lenne Pantherhez.
Van a scriptedben pár sor, konkrétan (a számozásokat én raktam bele a könnyebb hivatkozás miatt):
[code:1:c9f373916c]
#----- FORWARD CHAIN --

1. $IPT -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
2. $IPT -A FORWARD -i eth0 -o eth0 -j ACCEPT
3. $IPT -A FORWARD -i ppp0 -o ppp0 -j ACCEPT
4. $IPT -A FORWARD -i ppp0 -j forward_ext
5. $IPT -A FORWARD -i eth0 -j forward_int
6. $IPT -A FORWARD -j DROP
7. $IPT -A FORWARD -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
8. $IPT -A FORWARD -j LOG --log-prefix "SuSE-FW-FORWARD-ERROR " --log-tcp-options --log-ip-options
[/code:1:c9f373916c]
A kérdésem arra vonatkozik, miszerint ha engedélyezed a 2. sorban a bentről kifelé irányuló forgalmat, akkor mi értelme van a 4. sornak, illeve ha engedélyezed a 3. sorban a kívülről befelé jövőt, az 5. sor mit csinál?
Tudtommal ha egy szabály vége accept, akkor a csomag el van fogadva és a kernel nem foglalkozik vele többet. Ez viszont azt jelentené, hogy a 4. és 5. sorokban hiába küldöd további szűrésre a saját belső és külső forward láncaidra a csomagokat, azoknak az én ismereteim alapján nem kéne odaérkezniük. (Illetve a 6-8. sorokra sem lenne szabad egyetlen csomagnak sem érkeznie.)

Vagy ezek alapján rosszul értelmeztem a howto-t és mégis?

( Panther v | 2005. 07. 27., sze – 10:05 )

[quote:b97ec25eb0="blanc"]Csak egy elvi kérdésem lenne Pantherhez.
Van a scriptedben pár sor, konkrétan (a számozásokat én raktam bele a könnyebb hivatkozás miatt):
[code:1:b97ec25eb0]
#----- FORWARD CHAIN --

1. $IPT -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
2. $IPT -A FORWARD -i eth0 -o eth0 -j ACCEPT
3. $IPT -A FORWARD -i ppp0 -o ppp0 -j ACCEPT
4. $IPT -A FORWARD -i ppp0 -j forward_ext
5. $IPT -A FORWARD -i eth0 -j forward_int
6. $IPT -A FORWARD -j DROP
7. $IPT -A FORWARD -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
8. $IPT -A FORWARD -j LOG --log-prefix "SuSE-FW-FORWARD-ERROR " --log-tcp-options --log-ip-options
[/code:1:b97ec25eb0]
A kérdésem arra vonatkozik, miszerint ha engedélyezed a 2. sorban a bentről kifelé irányuló forgalmat, akkor mi értelme van a 4. sornak, illeve ha engedélyezed a 3. sorban a kívülről befelé jövőt, az 5. sor mit csinál?
Tudtommal ha egy szabály vége accept, akkor a csomag el van fogadva és a kernel nem foglalkozik vele többet. Ez viszont azt jelentené, hogy a 4. és 5. sorokban hiába küldöd további szűrésre a saját belső és külső forward láncaidra a csomagokat, azoknak az én ismereteim alapján nem kéne odaérkezniük.

Vagy ezek alapján rosszul értelmeztema howto-t és mégis?

Na most azt tudni kell, hogy az eredeti script egy SuSE 8.2-es SuSEfirewall2-ből készült, és csöppet nem láttam át, de a sajátomat már értem :)

2. sor: jön a csomag eth0-ról és visszamegy ugyanarra
3. sor ppp0-ra ugyanez
4-5. sor: ami az előző kettőre nem illeszkedett, az bekerül a két láncba

Az alábbi interface-ek vannak: eth0 - belső háló
eth1 - csak az adsl modem
ppp0 - internet
tehát eth0-eth0 2. sor
eth0-ppp0 és eth0-eth1 meg a forward_int ben folytatódik.

Mi értelme van az eth0-eth0 láncnak? Menet közben jöttem rá, hogy mi hiányzik, és még nincs benne a vége, de:
jön lan felől egy kérés a ppp0-as címre 80-as portra: nat PREROUTING -j DNAT --to-source belső ip cím (gépemé). Ekkor már a forward lánban úgy lesz, eth0-ról jön, eth0-ra megy. Ahhoz, hogy ez rendesen működjön, a végén egy nat tábabeli POSTROUTING -j SNAT --to-source a router belső ip címére. Ezt nem tettem meg, mert akkor nem tudom, hogy eredetileg kitől jön egy csomag. De ez eleve reménytelennek tőnik, mert hülyét kapott a gépem az ilyen félig natolt csomagoktól. Tehát ezt muszáj lenne beleírnom.

Eredetileg csak 7-8. sor volt, de inkább nem logoltam, így 6. sor bekerült (7-8 meg nem kommenteződott ki)

Íme a bizonyíték, mivel jár, amikor az ember csak foltoz valamit.

6. sorra simán juthat csomag, mert a láncok végén nem biztos, hogy mindegyik el van fogadva/dobva, stb. A láncok szerepe csak az egyazon logikai kategóriába tartozó szabályok összefogása (jobban átlásd és/vagy kevesebb szabály legyen).

( blanc | 2005. 07. 27., sze – 10:22 )

[quote:b0000f59ac="Panther"]
2. sor: jön a csomag eth0-ról és visszamegy ugyanarra
3. sor ppp0-ra ugyanez
4-5. sor: ami az előző kettőre nem illeszkedett, az bekerül a két láncba

Az alábbi interface-ek vannak: eth0 - belső háló
eth1 - csak az adsl modem
ppp0 - internet
tehát eth0-eth0 2. sor
eth0-ppp0 és eth0-eth1 meg a forward_int ben folytatódik.

Mi értelme van az eth0-eth0 láncnak? Menet közben jöttem rá, hogy mi hiányzik, és még nincs benne a vége, de:
jön lan felől egy kérés a ppp0-as címre 80-as portra: nat PREROUTING -j DNAT --to-source belső ip cím (gépemé). Ekkor már a forward lánban úgy lesz, eth0-ról jön, eth0-ra megy. Ahhoz, hogy ez rendesen működjön, a végén egy nat tábabeli POSTROUTING -j SNAT --to-source a router belső ip címére. Ezt nem tettem meg, mert akkor nem tudom, hogy eredetileg kitől jön egy csomag. De ez eleve reménytelennek tőnik, mert hülyét kapott a gépem az ilyen félig natolt csomagoktól. Tehát ezt muszáj lenne beleírnom.

Ha nem "csinálsz" a belső háló felől PREROUTING-ot, akkor elvileg a működése valami olyasmi lenne, hogy a belső gépről megy kifelé a cucc, eljut pl. az első DNS-ig, amelyik meg közli vele a kért IP-t (ami mellesleg ugyanaz a gép, amelyen elérte a DNS-t).
Csak egy elvi kérdés: miért nem hagytad meg ilyen működésűnek a rendszert? Miben jobb az (a csökkenő kifelé irányuló kapcsolatokon kívül), hogy elkapod a kimenő csomagokat, megnézed a célt és ha kívülről nézve az is te vagy, akkor nem engeded tovább? Ezek alapján akkor van egy belső DNS-ed, amely a "belsőszerver" név mellett még felold néhány külső címet is, mint pl. a "www.kulso.szerver.hu"-t?

( Panther v | 2005. 07. 27., sze – 10:29 )

[quote:ccc2363fce="blanc"]Ha nem "csinálsz" a belső háló felől PREROUTING-ot, akkor elvileg a működése valami olyasmi lenne, hogy a belső gépről megy kifelé a cucc, eljut pl. az első DNS-ig, amelyik meg közli vele a kért IP-t (ami mellesleg ugyanaz a gép, amelyen elérte a DNS-t).
Csak egy elvi kérdés: miért nem hagytad meg ilyen működésűnek a rendszert? Miben jobb az (a csökkenő kifelé irányuló kapcsolatokon kívül), hogy elkapod a kimenő csomagokat, megnézed a célt és ha kívülről nézve az is te vagy, akkor nem engeded tovább? Ezek alapján akkor van egy belső DNS-ed, amely a "belsőszerver" név mellett még felold néhány külső címet is, mint pl. a "www.kulso.szerver.hu"-t?

az elsőt majd megnézem (prerouting, stb). A routeren van egy bind9, egy dhcp, squid (régen volt ldap + kerberos is, de ma már értelmetlen, mert notebookhoz nem nyerő + linuxot váltottam: SuSE 8.2->gentoo).

Asszem felteszem az új változatot mindjárt ugyanoda, fwon.txt néven:
http://cfhay.inf.elte.hu/~panther/linux/scripts/fwon.txt

Közben rájöttem, hogy valamiért a végén a mangle táblában kár szűrnöm, mert dobom a csomagokat is (mark alapján). Egy access-point a saját MAC adress-ével küldi tovább a csomagokat? Valszeg ez lehet a baj, de azért nem értem, mert DHCP esetén látom a csatlakozó gépek ip-jét.

Miután most megfejtettem, hogy a mangle táblában csináltam hülyeségeket, már müxik a "Szerverek védelme linuxszal" c. könyv alapján készült scriptem is: http://cfhay.inf.elte.hu/~panther/linux/scripts/fwon.new.txt

( Panther v | 2005. 08. 11., cs – 14:56 )

[quote:3e5f3d82f0="zither"][quote:3e5f3d82f0="Panther"]
A helyzet ennél rosszabb, ugyanis ha az adott lekérdezés nem fér bele egy (udp) csomagba, akkor tcp kapcsolatot nyit, tehát azt sem lehet tiltani.
.

Én úgy tudtam, hogy a tcp kapu a zóna transzferekhez van fenntartva, de most javításodra reagálva utána néztem. Ha a dns szerver válasza (illetve - gondolom - ha a lekérdezés) hoszabb, mint 512 byte, akkor valóban tcp-n zajlik a forgalom, ezért ezt is engedélyezni lehet. Azt viszont nem tudom, hogy milyen dns név lehet az, ami nem fér bele 512 byte-ba. Nálam csak az udp van nyitva, és tökéletesen megy. Azt hiszem ezek ismeretében is megtartom ezt a beállítást, tudva azt, hogy tulajdonképpen ezzel elvi hibát követek el, ugyan is úgy gondolom, hogy gyakorlati jelentősége nincs a dolognak.
Ha esetleg ellen véleményed/tapasztalatod van, azért nyogudtan írjál, mert én se gondolhatok mindenre, és lehet hogy tévedek.

Hát egy lekérdezés tényleg nem gáz. De add ki:
[code:1:3e5f3d82f0]host panther.web.elte.hu[/code:1:3e5f3d82f0]

Eredmény:

[code:1:3e5f3d82f0]panther.web.elte.hu is an alias for web.caesar.elte.hu.
web.caesar.elte.hu has address 157.181.151.150
web.caesar.elte.hu has address 157.181.151.151
web.caesar.elte.hu has address 157.181.151.152
web.caesar.elte.hu has address 157.181.151.146
web.caesar.elte.hu has address 157.181.151.147
web.caesar.elte.hu has address 157.181.151.148
web.caesar.elte.hu has address 157.181.151.149
panther.web.elte.hu is an alias for web.caesar.elte.hu.
panther.web.elte.hu is an alias for web.caesar.elte.hu.
[/code:1:3e5f3d82f0]

Itt még az mx, stb rekordok nincsenek is benne, amik megléte egyes szervereknél előfordulhat, szóval a lekérdezés könnyen áttérhet tcp-re.

Ja, nálam a dig szerint: ";; MSG SIZE rcvd: 285"

( zither | 2005. 08. 11., cs – 15:25 )

Valóban ere nem gondoltam. Bár ez egy viszonylag speciális helyzet. Általában egy névhez csak egy ip és estleg egy alias (és annak az ip-je) jellemző. Azt hiszem az ilyen nagy lekérdezések (bár ez még bőven befért az udp-be) viszonylag ritkák lehetnek.
Az MX előtagok viszont ronthatnak a helyzeten. Ha csak a leggyakoribb MX-eket nézzük (mail, www, ftp) és ezt csapjuk hozzá a fentebb írtakhoz, a válaszban már 6 bejegyzést is kaphatunk.

Azt hiszem összegzésnek kimondhatjuk, hogy az udp 512 byte-ja akár még szűkös is lehet, viszont jellemzően elég az udp is a lekérdezésekhez. Innetől kezdve inkább már a tűzfalhoz tartozó hálózatokon lévő szokások döntenek arról, hogy az 53tcp engedélyezzük-e, vagy esetleg zároljuk. Egy biztos: semmiképpen sem helyes reflex szerűen zárni az 53tcp (ahogyan én is tettem), de esetenként azért gondos mérlegelés mellett tiltható.

Minden esetre örülök, hogy egy ilyen "tévhittel" sikerült leszámolnom, ami ráadásul nem csak bennem volt, hanem egy elég általános jelenség.

( DoDver | 2005. 07. 12., k – 17:27 )

[quote:61dd87ffa0="zither"]Más:

Ha érdekel oda adhatom az én tűzfalszabályaimat megtekintésre. Jóval nagyobb és bonyolultabb (és valszeg van benne hibás rész is :)), de esetleg tanulni lehet belőle...

Engem erdekelne.

( Panther v | 2005. 07. 28., cs – 17:48 )

Én is alkottam:
[code:1:7d9f237e19]NET_INT="`ifconfig $IFACE_INT | grep inet\ addr | sed -r 's#.*inet addr:([^ ]+).*Mask:([^ ]+).*#\1/\2#'`"[/code:1:7d9f237e19]

így már csak a belső hálóbeli IP címektől kellene valahogy megszabadulnom :D

Link: http://cfhay.inf.elte.hu/~panther/linux/scripts/fwon.new.txt

Bár azon gondolkodom, hogy egyszerűsítem a dolgot, és egy iptables-restore-nak átadható szabályokat tartalmazó fájlt generálok, és így az új szabályok betültése minimális idő lesz (most > 10 sec).

( zither | 2005. 07. 27., sze – 12:33 )

[quote:1efd29caa4="Panther"]
Az utóbbi jó gondolat, a gond viszont az 1/órával a következő. Nálam nagyon sokszor be kívánnak jönnni a 22es kapun, akár percenként többször is. Így elhasználják az 1/hour lehetőséget, és te szépen kint maradsz. Ezért használok 3/perc-es korlátot. Ráadásul az ELTE hálózatából alapból beengedem a kapcsolatokat, csak hogy bebiztosítsam magam. Ja, a jelszót magam sem ismerem, szóval akár ki is vehetném az passwd authot - hm, mindjárt megteszem.

Ezzel nem volt (eddig) gondom, de valószínűleg a következő trük eredménye lehet: Ha megfigyeled az ssh szabványos portjára (ahol egyébként tényleg figyel is az sshd) csak a belső hálózatról lehet bejelentkezni. Az oda vonatkozó szűrés csupán annyira szigorú ezen kívül, hogy védve legyen az elárasztás ellen.
Kívülről egy másik porton (nem szabványos, de a leíró miatt könnyen áthejezhető) a beérkező csomagokat szépen nat-tal átirányítom a belső oldalra. Ezen a ponton van az 1/órás szűrés.
Vagyis: Ha a szabály már aktíválódot, akkor még a belső hálóról (ez a jellemzőb) még mindig be tudok jönni. A szabványtalan port miatt pedig a scripterek nem is próbálkoznak, hiszen nem találják meg a szolgáltatást. Vagyis csupán azok tudják triggerelni a szabályt akiknek dolguk van ott, illetve azok a crackerek, akik tudják hogy mit keresnek, és képesek felismerni a sshd-t bármilyen porton. Náluk pedig jobb, ha minnél jobban blokkolom őket. Ráadásul a naplóba is bekerül az összes sshd-re átirányított forgalom, vagyis megmondhatóvá válik, hogy a tűzfal engedélyezte-e az ssh szolgáltatás igénybevételét vagy sem.
Szerintem ez így elég lehet a legtöbb esetre...
(Amire meg nem, arra ott az AIDE, majd az "visít")

( aty | 2005. 07. 12., k – 20:28 )

[quote:e59eada667="zither"]

#icmp valaszok
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

Itt az első hiba... Ennek így semmi értelme. Minden icmp csagot elfogadsz az első sorban, aztán nekiálsz szűrögetni (amihez már nem jut el, hiszen előtte egy ACCEPT szabály már illet rá)

Igen, ezt nem vettem észre. Köszönöm.
Az /etc/rc.boot mappában helyeztem el a scriptet, így a hálózat felállása előtt betölt. De akkor lehet ide egy mindent eldobó scriptet teszek, és majd valamelyik másik init szinthez rakom ezt.
Nem fut dns szerver, de az 53as source portról érkező dolgokat tényleg engedélyeznem kellene, ezt már mások is mondták. Kipróbálom mindjárt.

A scripted érdekelne, tanulásnak mindenképpen jó! :)

( Ajnasz v | 2005. 07. 12., k – 21:01 )

A scriptből, amit bemásoltál, nekem úgy tűnik, hogy kifele mindent engedsz, szóval nem oszt, nem szoroz, ha még engeded az 53-as portot.

( Panther v | 2005. 07. 27., sze – 13:19 )

[quote:b09b70d516="zither"]Ezzel nem volt (eddig) gondom, de valószínűleg a következő trük eredménye lehet: Ha megfigyeled az ssh szabványos portjára (ahol egyébként tényleg figyel is az sshd) csak a belső hálózatról lehet bejelentkezni.

Kissé nehezen láttam át elsőre, de ötletes. Nekem a 22es port nyitott, de van rajta egy 3/min limit. Viszont van egy nem std porton figyelő ssh is, ez pedig a gépemre továbbítja a kapcsolatot (nem raktam ki az oldalamra, mert a portforward szerkezete anélkül is látszik)

( aty | 2005. 07. 12., k – 22:18 )

Az INPUT láncon engedem be azt ami eddig tiltva volt (53as source portról érkező válasz). Ennek mi köze lenne ahhoz hogy az OUTPUT láncon ACCEPT az alapszabály?!

( Ajnasz v | 2005. 07. 12., k – 23:39 )

Semmi. Kevertem a szezont. :? :oops:

( Panther v | 2005. 07. 27., sze – 15:17 )

zither: 2 láncodat kicsit feljavítottam http://www.insecure.org és http://iptables-tutorial.frozentux.net/iptables-tutorial.html alapján. XMas és Null scan így néz ki, mint a szabályban. Ezeket: log&drop. A RETURN számomra szimpatikusabb volt :)

LOG esetén még ezt is szoktam használni: --log-tcp-options --log-ip-options

[code:1:d11cd0704b]#Portscan & PoD loggols
#echo 'pod & scan'
$IPT -A security -p tcp --tcp-flags ALL FIN,URG,PSH -j LOG --log-prefix "FW: Xmas-tree scan (!!) "
$IPT -A security -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
$IPT -A security -p tcp --tcp-flags ALL NONE -j LOG --log-prefix "FW: Null scan (!!) "
$IPT -A security -p tcp --tcp-flags ALL NONE -j DROP
# tul sok hamis tallatot eredm)nyez, gyakoraltilag minden data packet illeszkedik
# VEGEN kell lennie ezeknek a szabalyoknak
$IPT -A security -p icmp --icmp-type echo-request -m limit --limit 1/s -j RETURN
$IPT -A security -p icmp --icmp-type echo-request -j LOG --log-prefix "FW: PingofDeath attack (?) "
$IPT -A security -p icmp --icmp-type echo-request -j DROP

#DoS & agressziv Port scan kivedesere
$IPT -A dosattack -p tcp --syn -m limit --limit 8/s -j RETURN
$IPT -A dosattack -p tcp --syn -j LOG --log-prefix "FW: Syn-Flood attack (?) "
$IPT -A dosattack -p tcp --syn -j DROP
[/code:1:d11cd0704b]

( zither | 2005. 07. 29., p – 09:57 )

[quote:d5a9e13af5="Panther"](most > 10 sec).

Ez érdekes, mert szerintem nincs benne annyi minden. Az én szabálygyűjteményemnek kb. 2 sec, amíg betöltődik.

(A kirakott bash script fut minden alkalommal, nem használom az iptables-save és iptables-restore parancsokat)

( Panther v | 2005. 07. 29., p – 10:13 )

[quote:b18c24f67f="zither"][quote:b18c24f67f="Panther"](most > 10 sec).

Ez érdekes, mert szerintem nincs benne annyi minden. Az én szabálygyűjteményemnek kb. 2 sec, amíg betöltődik.

(A kirakott bash script fut minden alkalommal, nem használom az iptables-save és iptables-restore parancsokat)

Hát, mint itt a hupon párx írtam: a gép egy 166MHz-es pentium mmx 8GB vinyóval, 64MB memóval... Lassú.

( adarazs | 2005. 07. 26., k – 13:34 )

[quote:250994ae54="zither"]Egyébként tényleg érdekelne a véleményetek (ha már kiraktam :))...

Sok olyan van, amikor csak portokat nyitogatsz ki. Leegyszerűsítheted ezeket ezzel a módszerrel:
[code:1:250994ae54]OPENED_TCP="25 80 143"
# Opening TCP ports that we set in the top of this script
if test -n "$OPENED_TCP"; then
for i in $OPENED_TCP
do $IPTABLES -A INPUT -i $OIF -d 0/0 -p tcp --dport $i -j ACCEPT
done
fi
[/code:1:250994ae54]

Ez az én firewall scripemből való, csinosítgatom még a te scripted alapján is, köszi, hogy kiraktad. :)
Annyira nem néztem át, hogy véleményt merjek mondani arról, hogy mennyire biztonságos/hibátlan a scripted, de jó ötleteket ad annak aki most akar írni magának.

Üdv,
Zümi