Tűzfal és DHCP

[quote:57c7629e14="habib"]Szerintetek a két hálókártya hardveres konfigurációja ebben ki is merül, vagy még kell valamit állítanom? Másik kérdésem, hogy ha a kártyákkal minden rendben, akkor hogyan kezdjek neki az iptables beállításának?
Előre is köszönöm a segítséget!

Milyen halokartyakrol van szo, es hanyas kernelrol?

append = "ether=0,0,eth0 ether=0,0,eth1" <- az ilyen bejegyzesek mar reg foloslegesek...

[quote:ac183456c4="habib"]Tegnap a segítségeddel elkezdtem egy tűzfal felkonfigurálását. Végül sikerült 2.4-es kernelre váltani. A hálókártyák 100-as Intel szerverkártyák (eepro100).
Az appendet egy netes cikkből lestem...

Append nem kell. A modern kernelek mar lekezelik a ket egyforma halokartyat.

nezzuk a /etc/network/interfaces -t:

Pelda:

auto eth0 eth1 <- mit huzzon fel automatikusan a bootkor

iface eth0 inet static
address 195.xx.253.xxx
netmask 255.255.255.248
gateway 195.xx.253.xxx

iface eth0:0 inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255

iface eth1 inet static
address 10.0.0.3
netmask 255.255.255.0
network 10.0.0.0
broadcast 10.0.0.255
gateway 10.0.0.1

Itt aztan mindenre latsz peldat. Pl: egy ip aliasra is. ebben a peldaban az egyik halozati kartyanak (eth0) ket ip cime is van. Termeszetesen ez egy nem mukodo konfig, csak illusztracio.

man interfaces

[quote:7c8b42c43b="habib"]Ha ez működik, akkor még mit kell átnézni, mielőtt elkezdem konfigurálni az iptablest?

mindegyik interfacen menjen a ping, mukodjon a halozat. ennyi.

a resolver be legyen allitva:

/etc/resolv.conf

alapvetoen mukodjon a halozat.

[quote:1ddb41cc46="habib"]Érdemes alaplapi driverekkel felismertetni a még ismeretlen eszközöket?

Pl.:
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
Unknown bridge resource 2: assuming transparent
.
.
.
PCI_IDE: unknown IDE controller

kicsit elkalandozunk a topictol. az ilyen kerdeseket mashova kene...

erdemes, ha lehet. nem minden esetben lehet, pl. akkor nem ha nincs hozza a kernelben meg tamogatas. Egyebkent nekem az az elso a Debian telepitese utan, hogy sajat kernelt forditok. megiscsak az az igazi :-)

Sziasztok!
A problémám erősen hasonlít: net megosztás és csomagszűrés. Ez a topic jól kivesézi a témát :lol: És érthetővé tette a szabályok megadását is.
De vmi miatt ennél a szabálymegadásnál elakadok:

>#a gép által kezdeményezett kommunikációt engedélyezi
>iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

ezt valahogy sehogysem akarja megenni, ezt mondja rá:
>iptables: No chain/target/match by that name

Ha jól sejtem e nélkül nem fogja a belső gép megkapni a külső csomagokat... :?

Van vmi 5letetek?

Előre is köszi:
Tag

[quote:976c6941da="Tag"]a gép által kezdeményezett kommunikációt engedélyezi

>iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

ezt valahogy sehogysem akarja megenni, ezt mondja rá:

>iptables: No chain/target/match by that name

Van vmi 5letetek?

<*> Connection state match support

ez a baratod. be kell tolteni a kernel modult.

[quote:b21879c9cb="habib"]A két hálózati kártya között a NAt-ot (azt hiszem Linux alatt is így hívják) hogyan tudom életre kelteni?
Vagy ez már az iptables-re tartozik?

Laci!i!i! ;D

NAT-ot is megérti mindenki, de Linuxosok inkább IP masqueradingnak (röviden ipmasq) hívják. Találsz róla leírást itt.

[quote:01c207599b="habib"]Hunger fiam :)
Az említett leírásban ipchains segítségével lehet a maszkolást elkövetni. Ha az említett parancssorokat iptablesre átfordítom, az működik?
Mennyire kompatibilisek egymással?

Ha hülyeséget írok, kérlek ne itt röhögj ki :)

ITT mar egyszer leirtam hogy mit hogyan. Megtalasz ott mindent.

[quote:1872effa62="hunger"]NAT-ot is megérti mindenki, de Linuxosok inkább IP masqueradingnak (röviden ipmasq) hívják. Találsz róla leírást itt.

Mint ahogy már Trey is megirta a hupwiki-n a MASQ az egy spec. SNAT

MASQ:
/sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

SNAT:
/sbin/iptables -t nat -A POSTROUTING -s 10.0.0.2 -j SNAT --to-source 1.2.3.4

Gus

Mint ahogy már Trey is megirta a hupwiki-n a MASQ az egy spec. SNAT

Nem rosszúl emlékeztem, nem a HupWiki-n olvastam és nem Trey keze nyomán, hanem Oskar Andreasson kezéből, http://iptables-tutorial.frozentux.net/iptables-tutorial.html , ezen a helyen!

Bocsi!

Gus

[quote:b9c2e9f1fc="habib"]Próbálkozatm, de csak nem akar sikerülni:

Az
#iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j ACCEPT

sort felváltottam az

#iptables -A INPUT -i eth0 -p tcp --destination-port 80 -j ACCEPT (http)
#iptables -A INPUT -i eth0 -p tcp --destination-port 443 -j ACCEPT (https)
#iptables -A INPUT -i eth0 -p tcp --destination-port 53 -j ACCEPT (DNS hozzáférés)
#iptables -A INPUT -i eth0 -p udp --destination-port 53 -j ACCEPT (DNS hozzáférés)
#iptables -A INPUT -i eth0 -p udp --destination-port 67 -j ACCEPT (DHCP szerver - IP kérés)
sorokkal.

A kliensgépen a korlátozások ellenére a böngészés mellett tudok ftp-zni és tudom használni a dc++ -t is.
Miért?

Ui.: tudom, hogy proxival érdemes kizárólagos http szolgáltatást engedni. most csak általánosságban próbálom a szolgáltatások korlátozásának módjait.

A FORWARD táblának mi a tartalma meg a default rule-ja? Mert szerintem a MASQ-olt gépek által keltett forgalom azon a táblán megy keresztül nem az INPUT táblán.

Gus

[quote:86f6026f64="habib"]Sziasztok!

Több dologban is fennakadtam!

Nézem a különböző szabályokat, de kommentek nélkül az esetek többségében nem vágom, hogy mi célt szolgálnak.

Ezzel még csak-csak megbirkóznék, de általános irányelvekre nagyon nagy szükségem lenne.
- Ha először alapból letiltok minden forgalmat, utána milyen portokat kell engedélyezni a DNS (53) és a DHCP (67)-n kivül , hogy a hálózat, a NAT lábraálljon?
- Találtam maszkolásra példát, de nem értem a legutolsó sorát
iptables -t nat -A postrouting -s 192.168.1.0/24 -j SNAT --to 64.81.39.24

Valaki segítsen.....

#iptables -P INPUT DROP

(minden befele jovo forgalmat letiltunk)

#iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT

(a lokalis dolgokat engedelyezzuk)

#iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

(minden olyan dologra johet valasz, amit mi kezdemenyeztunk. Azaz egy HTTP keresre jovo valaszt visszaengedjuk)

#iptables -A INPUT -s {annak az ipje akit be akarsz engedni} -j ACCEPT

(ezzel beengeded a {annak az ipje akit be akarsz engedni} hostrol az osszes befele jovo dolgot, porttol, protokolltol fuggetlenul

PL: ha a 10.0.0.0/24 -re akarsz MASQ-olni akkor engedelyezni kell az onnan jovo forgalmat:

#iptables -A INPUT -s 10.0.0.0/24 -j ACCEPT

#iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

(legegyszerubb az interface-re megadni a MASQ-ot. ez azt jelenti hogy a ppp0-on van az internet kapcsolat. ha az neked halozati csatolon van, akkor irj a ppp0 helyett eth0-t vagy irhatsz eth+ ot is, ami barmilyen csatolot jelol)

echo "1" > /proc/sys/net/ipv4/ip_forward

(bekapcsolod az ip_forward-ot, mert enelkul nem megy a masq)

Azta ezt lehet cifrazni, de elobb ertsd meg ezt.

Ha irsz konkret peldat akkor leirom azzal.

[quote:a59a101e50="habib"]#iptables -D INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

...ezt nem -A val kellene?

De. Latod, megy ez :-)

(mondhatnam az is, hogy tesztnek tettem bele, de nem annak. egyszeruen elgepeltem :-)

trey :lol:

[quote:a72e6611dd="habib"].... de az azelőtti kérdésem még él, miszerint:
a befelé jövő forgalom tiltása alapértelmezetten az eth0-ra (külső >kártya) vonatkozik?

Az eth1 (belső kártya) irányából jövő kérésekre (Pl. DHCP, DNS) milyen szabályok vonatkoznak, hogyan tudom azokat konfigurálni, ha abból az irányból is korlátoznom kell?

az

#iptables -P INPUT DROP

azt jelenti, hogy az _osszes_ befele jovo forgalmat tiltja. Ezert kellett engedelyezni a peldaban a 10.0.0.0/24 felol jovo kereseket.

Hogy erthetobb legyen:

adott egy gep eth0 es eth1 interface-szel. Az eth0 a "internet' laba, mondjuk legyen 195.xx.253.xxx az ip-je. A belso halozat legyen a 10.0.0.0/24 (10.0.0.1-10.0.0.255-ig) a router meg legyen a 10.0.0.1-es.

Ha kiadom az

#iptables -P INPUT DROP

parancsot, akkor sem az internet felol, sem a lokalis 10.0.0.0/24-rol nem fog befele (a befele alatt a routert, magat a gepet ertjuk mindig) jonni adat.

Tehat ha azt akarjuk, hogy a 10.0.0.0/24-en levo tetszoleges gep ki tudjon menni a netre a routeren (nevezzuk igy a MASQ-olo tuzfalat, ami ugye meg nem tuzfal csak csomagszuro) keresztul, akkor a kereseket onnan engedni kell a router fele. Ezert van a

#iptables -A INPUT -s 10.0.0.0/24 -j ACCEPT

(a -s a forras megadasa) tehat a 10.0.0.0/24 felol (akiben azert megbizunk) minden forgalmat engedunk a 10.0.0.1-re (router).

Innetol kezdve ha beallitottad a MASQ sort, es a ip-forward -ot is negedelyeztes a /proc-ban, mar nem kell mast csinalni, mint a 10.0.0.0/24-es halozaton levo gepeken beallitod, hogy a default gw (alapertelmezett atjaro) a 10.0.0.1 legyen. A belso gepeken megadsz egy valos DNS kiszogalot (ami akar lehet a 10.0.0.1 is) es mar megy is net.

Ha a 10.0.0.0/24 halon valaki rosszalkodik (mondjuk a 10.0.0.25-os gep gazdaja), akkor egyszeruen:

#iptables -A INPUT -s 10.0.0.25 -j DROP

es ezzel az onnan jovo csomagoka eldobja a gep, a pali nem fog netezni.

Az internet felol nem fog jonni semmi, mert mindent eldob a gep (koszonhetoen a iptables -P INPUT DROP -nak az elejen (mindig ezzel kezdjuk!)), csak arra johet valasz amit mi kezdemenyeztunk (iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT).

HUrra!!

[quote:6c9a897710="trey"]HUrra!!

HUPrra!

[quote:2c8928d754="habib"]iptables -P INPUT DROP
iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT

a fenti két sor nem váltható fel ezzel?

iptables -P INPUT -i eth0 DROP
iptables -P INPUT -i eth1 ACCES

(és hunger! mielőtt lebuktatnál, hogy számtech tanárszakos is vagyok, gondolkozz el, hogy mennyi plusz tudást tudtál pécsett felhalmozni :wink: )

Nem, mert a -P kapcsolóval a tábla default rule-ját adod meg.

Ez a számtech tanárszaokos probléma ismerős. Nálunk melóhelyen vindózer server van és egy ELTE infó/matek tanárszakos valaki az admin, akit még linux használatra is oktatnak, de mikor mondtam neki, hogy kellene NAT akkor azt sem tudta miről van szó. :(

Gus

[quote:dc2468080b="habib"]iptables -P INPUT DROP
iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT

a fenti két sor nem váltható fel ezzel?

iptables -P INPUT -i eth0 DROP
iptables -P INPUT -i eth1 ACCES

Viszont

iptables -A INPUT -i eth0 -j DROP
iptables -A INPUT -i eth1 -j ACCEPT

ezek jók lehetnek, de nem elég biztonságos, inkább

iptables -P INPUT DROP
iptables -A INPUT -i eth1 -s 192.168.0.0/24 -j ACCEPT

ez még legalább spoof ellen is véd.

Gus

Végre működik a maszkolás :D
Ez a topic sokat segített.
thx
Tag

[quote:3d333e7de2="habib"]Abszolút nem akarom a problémát megkerülni (jelen pillanatban is az iptables sorokat probálgatom), csak lenne egy kérdésem.

Amennyiben csak és kizárólag http-https és ftp-ftps protokollokat engedem át a tűzfalon a következő metódus mennyire biztonságos?

1. az összes futó daemont letiltani
2. echo "1" > icmp_echo_ignore_all (a pingre nem figyel, a mama a helyén marad)
3. bind-et felrakni
4. squid-ot felrakni

A koncepció az, hogy egy port alapállapotban zárva van, ha nincsenek feleslegesen futó folyamatok, akkor azok zárva is maradnak.
A tűzfal csak a proxyn keresztül kommunikálna, ráadásul a szolgáltasok (http, ftp...) portjait sem lehet csibészségekre használni.

Mit szóltok?

( Itt jegyezném meg, hogy természetesen nem az én kis agyamból pattant ki ez az okosság. Carlos volt, akit ma egy órán keresztül zaklattam a hülyeségeimmel. )

Elvileg ez jonak tunik. Viszont. Ha bekapsz mondjuk egy rootkit-et (backdoor) akkor a csomagszuros pelda megved az ellen, hogy az portot nyisson a tudtod nelkul es azon ki-be jarjanak. Ez a dolog, hogy csak a futo servicek figyelnek es a tobbi azert szokott gaz lenni, mert neha akarva-akaratlanul figyelhet cucc a gepen. Nem beszelve arrol, hogy felso portot (1024 felett) nyitni egy gepen userkent is lehet. Viszont csomagszuro eseten _ha az jol be van allitva_ nem tud senki ilyet tenni.

[quote:ee9f345514="habib"]

Az

#iptables -t nat -A POSTROUTING -o eth+ -j MASQUERADE

valamiért kevésnek bizonyult

Pedig elegnek kellett volna lennie...

ha kombinálom a proxy biztonságát az előző oldalon leírt iptables mintákkal, akkor ha jól látom, már nem lesz szükség bind-re.

A BIND-nek mi koze ehhez? A BIND egy DNS szerver. Nem sok koze van sem a HTTP/HTTPS/FTP/.. proxykhoz, sem a csomagszurohoz.

[quote:d0f30e28a4="habib"]Ezt átgondolhattam volna, igaz...

A Carlos féle verzióval kapcsolatban jegyeztem meg:
a kizárólag proxy-n keresztül folyó kommunikációnál, mivel ott nem volt maszkolás, gondoltam kell DNS szerver.

De mivel most már lesz NAT, felesleges volt megkérdeznem, bocs.

Vagy a proxy már eleve feleslegessé teszi a DNS szervert?

1.) MASQ mogott hasznalhatsz kulso DNS szervert, pl. az ISP-d (pl. ns.axelero.hu IP-je, ns.datanet.hu IP-je, stb.) DNS szerveret. MASQ mogott meg kell adnod minden gepen a DNS szervert, mert ott honnan tudnak a gepek, hogy honnan kell feloldani a leveleket?

2.) Ha pl. HTTP proxy-t hasznalsz (mondjuk SQUID), akkor nem kell DNS szervert kulon telepitened, mert a proxy elintezi (/etc/squid.conf a reszletekert) a kliensek szamara a nevfeloldast, igy nem kell BIND-et telepitened.

Azaz osszefoglalva: nem szukseges egyik esetben sem a BIND telepitese, mert meg lehet oldani a nevfeloldast a szolgaltato DNS szerverivel.

Az egy masik kerdes, hogy egy un. cacheing only DNS szervert erdemes telepitened akkor, ha a tuzfal mogott bizonyos szamu kilensek vannak. Hogy mennyi utan, arra megszolanak a velemenyek, de szerintem ha mar 10 kliens van a tuzfal (en a tuzfal alatt mindig valami csomagszuro (iptables) + valamilyen proxy (squid, zorp) kombinaciojat ertek. magaban az iptables, vagy a squid) nem nevezheto szoros ertelemben vett tuzfalnak) mogott, akkor erdemes lehet egy helyi DNS cache-t felallitani.

[quote:647c050a68="habib"]

A most beírt iptables sorokat hogyan automatizáljam?

Úgy értem:

- melyik futási szintre érdemes betenni
- fontos e az elnevezés, vagy csak az hogy @S* legyen az elején

A szkriptet már megírtam, futtathatóvá is tettem.
Köszönöm

[code:1:647c050a68]#!/bin/bash

iptables='/sbin/iptables'

case "$1" in

start)

echo -n "Starting up firewall : iptables"

echo "1" > /proc/sys/net/ipv4/ip_forward

$iptables -P INPUT DROP
$iptables -P FORWARD ACCEPT
$iptables -P OUTPUT ACCEPT

$iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
$iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

echo "."
;;

stop)

echo -n "Shutting down firewall : iptables"

echo "0" > /proc/sys/net/ipv4/ip_forward

$iptables -P INPUT ACCEPT
$iptables -P FORWARD ACCEPT
$iptables -P OUTPUT ACCEPT

$iptables -D INPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
$iptables -D INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

echo "."

;;

flush)

echo -n "Flushing firewall settings : "

$iptables -F
$iptables -F -t nat
$iptables -P INPUT ACCEPT
$iptables -P FORWARD ACCEPT
$iptables -P OUTPUT ACCEPT

echo "done."

;;

*)
echo "Usage: ./firewall { start | stop | flush }"
exit 1
;;

esac

exit 0
[/code:1:647c050a68]

Imho igy szebben nez ki. Ezt lemented mondjuk fw neven, chmod 755 fw, beteszed a /etc/init.d konyvtarba. Elotte egeszitsd ki a te MASQ beallitasaiddal.

Ha debian: akkor az update-rc.d -vel letrehozod a megfelelo runlevel-ekre a symlinkeket.

A lenyeg: a tuzfal script _mindig_ legeloszor induljon, es legutolsokent alljon le. A magyarazat egyszeru: ha eloszor indul, akkor nem tud elotte semmi kaput nyitni. Ha utolsokent zarodik a leallitaskor, akkor nem tud senki okoskodni.

De hasznalhatod a iptables-save/iptables-restore megoldast is...

[quote:7f53764cf1="habib"]Nagyon kulturált :)

A szkriptel kapcsolatban:
Van olyan szituáció, amikor a -stop- állapotba kell hozni a fw szkriptet?

Ha valamit elallitottal :-) Meg leallitaskor leallitja az egeszet.

Úgy értem, mikor van szükség arra, hogy a NAT működjön, de a tűzfal átengedjen minden jöttmentet?

Nemtom, teszteles idejere?

A futási szintekkel kapcsolatban:
Jelen pillanatban a 2. szinten van a tűzfal, elegendő csak ezen a szinten indítani, vagy már az 1.-n indítsam el?
Mikor kikapcsol a gép, a 6.-ra lép át, ezek szerint ott kapcsoljon ki?

az egyes szint (init 1) single user, halozat nelkul. azaz nincs ertelme nagyon ott inditani :-) de fo az ovatossag :lol:

[quote:b0f53d204d="habib"]
Egy előző kérdésemre visszatérve: a backdoor ellen hogyan védekezzek?
Mert, ha a belső tartományból az egyik gépre felgyaknak egyet, akkor onnan bármilyen portot megnyithat a tűzfalon.

A belso halonlevo barmelyik gepre telepitett backdoot hogyan nyithatna barmilyen portot is a tuzfalon? Sehogy. Hogy megertsd:

A NAT (halozati cimforditas lenyege):

a belso halon levo. mondjuk 10.0.0.10-es IP cimmel rendelkezo gep ha mondjuk egy HTTP kerest kuld kifele, akkort az nem kozvetlenul teszi. Mivel neki nincs publikus cime, nem lat ki az internetre. Ha le akarja kerni mondjuk a HUP index.php-jet, ahhoz kapcsolatba kene lepnie a HUP 80-as portjaval. De nem tud, mert nem talalja. Mit csinal? Szetnez a halon, felkialt, hogy van alapertelmezett atjaro. Elindul arra, annak elkuldi a kerest, az ezt a belso 10.0.0.10-es IP cimet atforditja a sajat, mondjuk 195.xxx.253.xxx cimre, elkuldi a kerest, majd vissza is kapja ra a valaszt. Majd a cuccot visszafordita ugy, hogy el tudja kuldeni 10.0.0.10-es gepnek.

Nezzuk kintrol nezve mi tortenik. Mondjuk a 10.0.0.10-es gep 3337-es portjat ul egy backdoor. A cracker kintrol csatlakozni akar hozza. Hogy eri el a 10.0.0.10-es gepet? Sehogy. Max. akkor ha a kulso gep a 3337-es portja beforwadolja a 10.0.0.10-es gep 3337-es portjara.

Es el is erkeztunk ahhoz a reszhez, hogy hogyna uzemeltessunk web, vagy ftp vagy mail szervert masq mogott :-)

ezt nevezik port forward-nak.

Tehat a belso halon levo gep nem tud lukat utni a tuzfalon. Ahhoz magat a tuzfalat kell kilyukasztani. Ezert egy jo tuzfalon nincs soha lokalis felhasznalo :-), nem futtatunk rajta eggdropot, bnc-t, stb. nem teszunk ra megbizhatatlan usereket, akiknek elso dolguk, hogy egy jo kis lokal root exploittal felnyomjak a gepunket, majd arra rootkiteket tegyenek :-)

[quote:e36610b046="habib"]Sziasztok!

Szeretnék egy tűzfalat, de már elegem van az MS termékekből.
Mielőtt valaki ajánlaná az egylemezes automatikusan felkonfigurálódó disztribeket, kérem, ne tegye. Tanulni akarok!

Sz'al letöltöttem az alap Debiant, van sok leírásom iptablesről meg dhcp-ről, de nem tudom, hogyan kezdjek neki.
Pl. milyen csomagok kellenek, hogyan kezdhetek neki telepítés után az iptables konfigurálásának, be kell e fordítanom a kernelbe, meg ilyenek.....

Nagyon köszönöm, Laci voltam

Nem latom a tuzfal es a DHCP szerver kozti osszefuggest. Szerintem targyaljuk kulon.

Tuzfal:
--------

A tuzfal alatt mit ertesz? Csomagszurot? Ha igen, akkor Linux alatt egyertelmuen iptables. Mi kell hozza? Feltelepited a Debian alaprendszert. A Debian Woody kernele ``gyarilag'' tamogatja az iptables-szel valo csomagszurest, tehat sok dolgod nincs vele. Feltelepited (ha meg nem lenne fenn) az iptables userspace kezeloprogramjat, amelynek a neve stilszeruen iptables

Telepitese (a megfelelo telepitoforras kivalasztasa utan):

apt-get install iptables

ha ez megvan leteszteljuk hogy mukodik-e:

(root-kent)

alderaan:/home/trey# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

valami ilyesmit kell latnod. Ha azt irja, hogy a kerneled inkompatibilis, akkor:

#modprobe iptables

majd megismetled a tesztet.

Innen folytatjuk. Ha eddig eljutottal szolj!

[quote:1f9fb12ca8="habib"]Telepítek...... ....egy kérdés: a conventional unix server vajon mí? Köszönöm

hagyományos unix szerver

[quote:426b1ca8c9="habib"]:).....miben hagyományos?
Remélem nem kellett feltennem, mert már készen van a telepítés, szerintem nem rontottam benne sokat....

Az iptables legújabb verziója is fent figyel.

Ezt írtad:

>"ha ez megvan leteszteljuk hogy mukodik-e:
>
>(root-kent)
>
>alderaan:/home/trey# iptables -L
>Chain INPUT (policy ACCEPT)
>target prot opt source destination
>
>Chain FORWARD (policy ACCEPT)
>target prot opt source destination
>
>Chain OUTPUT (policy ACCEPT)
>target prot opt source destination
>
>valami ilyesmit kell latnod. Ha azt irja, hogy a kerneled inkompatibilis, >akkor:
>
>#modprobe iptables "

Szégyenlem magam, de nem találtam egyik "dokumentumomban" sem a magyarázatot az utasításodra. Beírtam egy #iptables -L parancsot, de ezt írta ki: modprobe: Can't locate module ip_tables.
A #modprobe iptables-re természetesen ugyanezt kaptam.

Elakadtam, hogyan tovább

az cel az iptables modul betoltese. erre ket lehetoseg van, az egyszerubb a ``modconf'' nevu program futtatasa:

#modconf

ott megkeresed az iptables-t es betoltod.

vagy

a //lib/modules/{kernelverzioszam}/kernel/net/ipv4/netfilter/ konyvtarban megkeresed az iptables.o (2.6 eseten az iptables.ko) modult es betoltod (insmod vagy modprobe), az eleresi ut megadasaval.

[quote:2ad190aa49="habib"]ha sem a modconf-ban, sem a /lib/modules/ könyvtárban sem találom az iptablest, akkor mit tegyek?
az apt-get install iptables parancsra azt írja, hogy már fent van a legfrissebb verzió, szóval nem tudom.
leszedjem és tegyem fel újra?

Hanyas Debian ez? Kizart dolog, hogy nincsen benne iptables.

Feltenni nem kell semmit, ert fenn van ami kell. A kernel oldalon kell meg allitani. Ha nincs a kernelbe forditva iptables tamogatas, es kernel modul sincs akkor uj kernel kell (de kizart szerintem h nincs benne ilyen tamogatas).

Ha beiros, hogy

#ipchains -L

arra mit ir?

meg valami...
hanyas kernel fut?

#uname -a

ird ide mit ir ki..

lehet, hogy 2.2-es kernelt telepitettel?

[quote:41e2715aac="habib"]Igaza van Uram!
Ez 2.2.20-as kernel, gyorsan letöltök egy újabb verziójú Debiant.
Honnan érdemes? Mert ezt a debian.org ról húztam le, nem eléggé körültekintően.
Vagy elég lesz egy kernelfrissítés is?

ftp://ftp.fsn.hu/pub/CDROM-Images/debian/3.0_r2/i386/

( ftp://ftp.fsn.hu/pub/CDROM-Images/debian/3.0_r2/i386/debian-30r2-i386-binary-1_NONUS.iso )

eleg az elso lemez.

A kernel frissites ugy magaban nem eleg, mert frissiteni kell a modutils csomagot is, es ha azt frissited akkor vele jon egy rakas masik is. Lehet dist-upgrade-t csinalni, ha van tapasztalatod, turelmed, es savszelesseged. Ha valamelyik nincs, akkor inkabb tolsd le az ISO-t, es huzd fel ujra a rendszert ezuttal 2.4-es kernellel. Lehetoleg a bf24-gyel (telepiteskor F1 elolvas korultekintoen a szoveg, majd kivalaszt a bf24-es kernel).

[quote:6c2005e8ff="habib"]ha sem a modconf-ban, sem a /lib/modules/ könyvtárban sem találom az iptablest, akkor mit tegyek?
az apt-get install iptables parancsra azt írja, hogy már fent van a legfrissebb verzió, szóval nem tudom.
leszedjem és tegyem fel újra?

Elotte gyozodj meg arrol, hogy 2.4-es kernelt hasznalsz-e, mert az a gyanum, hogy nem. uname -r parancs megmondja a hasznalt kernelverziot. Ha nem 2.4...., akkor apt-get install kernel-image-2.4.18-bf2.4, es utana probald ki ugyanezeket.

Eloszor is koszi mindenkinek ezt a hasznos topicot, mert ennek eredmenyekepp van egy mukodo csomagszurom.

Itt egy kis adalek meg a fenti osszefoglalashoz:

[code:1:1192be5004]# pingeles engedelyezese
$iptables -t filter -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/minute -j ACCEPT

# eldobott csomagok logolasa
$iptables -t filter -A INPUT -m limit --limit 1/second --limit-burst 5 -j LOG --log-prefix "iptables dropped packet: "[/code:1:1192be5004]

Ugyanakkor maradt meg kerdesm a csomagszuressel kapcsolatban. Megneztem nehany grafiks csomagszuro beallito program altal generalt szkriptet. Pl a kmyfirewall a kovetkezo erdekessegekkel szolgalt:

[code:1:1192be5004]# Disable IP Forwarding
echo 0 > /proc/sys/net/ipv4/ip_forward

# Enable Reverse Path Filtering
for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do
echo 2 > $i
done

# Enable log_martians (logging)
for i in /proc/sys/net/ipv4/conf/*/log_martians ; do
echo 1 > $i
done

# Enable Syn Cookies
echo 1 > /proc/sys/net/ipv4/tcp_syncookies[/code:1:1192be5004]

Ha errol esetleg tudna vki mondani vmit bovebben. Az ip_forward-rol van vmi fogalmam, a tcp_syncookies-rol olvastam (syn flood), de egy rovid osszefoglalas a temaban jo lenne. Megprobltam pl. a tcp_syncookies-t 1-re allitani, de ez a bejegyzes nalam nem talalhato meg.

Amiota el a csomagszuro folyamatosan gyulnek a logban az eldobott csomagok, mint pl.:

[code:1:1192be5004]Mar 4 21:04:28 localhost kernel: iptables dropped packet: IN=ppp0 OUT= MAC= SRC=217.239.91.224 DST=217.239.89.238 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=43229 DF PROTO=TCP SPT=4707 DPT=445 WINDOW=8760 RES=0x00 SYN URGP=0
Mar 4 21:04:31 localhost kernel: iptables dropped packet: IN=ppp0 OUT= MAC= SRC=217.239.91.224 DST=217.239.89.238 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=43279 DF PROTO=TCP SPT=4707 DPT=445 WINDOW=8760 RES=0x00 SYN URGP=0
Mar 4 21:04:37 localhost kernel: iptables dropped packet: IN=ppp0 OUT= MAC= SRC=217.239.91.224 DST=217.239.89.238 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=43377 DF PROTO=TCP SPT=4707 DPT=445 WINDOW=8760 RES=0x00 SYN URGP=0
Mar 4 21:15:40 localhost kernel: iptables dropped packet: IN=ppp0 OUT= MAC= SRC=80.121.86.69 DST=217.239.89.238 LEN=48 TOS=0x00 PREC=0x00 TTL=121 ID=7830 DF PROTO=TCP SPT=62581 DPT=135 WINDOW=64240 RES=0x00 SYN URGP=0
Mar 4 21:17:34 localhost kernel: iptables dropped packet: IN=ppp0 OUT= MAC= SRC=217.239.90.36 DST=217.239.89.238 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=6760 DF PROTO=TCP SPT=1986 DPT=135 WINDOW=65136 RES=0x00 SYN URGP=0
Mar 4 21:28:04 localhost kernel: iptables dropped packet: IN=ppp0 OUT= MAC= SRC=68.148.20.62 DST=217.239.89.238 LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=38179 DF PROTO=TCP SPT=1179 DPT=3127 WINDOW=16384 RES=0x00 SYN URGP=0
Mar 4 21:28:07 localhost kernel: iptables dropped packet: IN=ppp0 OUT= MAC= SRC=68.148.20.62 DST=217.239.89.238 LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=38500 DF PROTO=TCP SPT=1179 DPT=3127 WINDOW=16384 RES=0x00 SYN URGP=0
Mar 4 21:28:13 localhost kernel: iptables dropped packet: IN=ppp0 OUT= MAC= SRC=68.148.20.62 DST=217.239.89.238 LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=39212 DF PROTO=TCP SPT=1179 DPT=3127 WINDOW=16384 RES=0x00 SYN URGP=0
Mar 4 21:33:04 localhost kernel: iptables dropped packet: IN=ppp0 OUT= MAC= SRC=217.42.202.68 DST=217.239.89.238 LEN=78 TOS=0x00 PREC=0x00 TTL=122 ID=378 PROTO=UDP SPT=1039 DPT=137 LEN=58
Mar 4 21:36:44 localhost kernel: iptables dropped packet: IN=ppp0 OUT= MAC= SRC=217.234.226.10 DST=217.239.89.238 LEN=52 TOS=0x00 PREC=0x00 TTL=126 ID=16 DF PROTO=TCP SPT=1098 DPT=135 WINDOW=32767 RES=0x00 SYN URGP=0
[/code:1:1192be5004]

Elegge erdekelne, hogy milyen csomagok ezek. Van olyan sejtesem, hogy ezek lennenek a syn cookiek, de nem akarok nagy baromsagot mondani.

Ezen kivul a topic egyik resze elsikkadt, megpedig a proxy tipusu tuzfalak. Olvastam errol a HUP Wikiben meg egyeb helyeken az interneten, Trey is emlitette itt a topicban, hogy egy teljeserteku tuzfalhoz a csomagszuron kivul egy proxy is tartozna.

Ugyan nalam joideje fut a squid, de most az eddigieken felbuzdulva megprobalom a hozzafereseke rendesen bekonfiguralni. (Eddig ugyanis meglehetosen intuitiv konfiguracioval ment.) Akinek esetleg van egy jol hasznalhato konfig mintaja, ne tartsa vissza magat.

[quote:a239c57591="habib"]Az a furcsa, hogy az ISO fálj szerint a 3.0 r2 -t használtam. Rosszul gondolom, amikor azt hiszem, hogy van összefüggés egy adott disztrib verziója és az általa használt kernel verziója között?

rosszul. 3.0-as kernel meg nincs, es egyhamar nem is lesz. a jelenlegi stabil kernelsorozat a 2.4-es, a szinten stabil legujabb kernelsorozat a 2.6-os

a 2.2-es is stabil de mar regicske. iptables-hez a 2.4, 2.6 kernelek a jok

[quote:7f9f00eeae="habib"]A másik hálózati kártyát hogyan konfiguráljam fel intranet kiszolgálására?
Úgy értem, hogy tudom neki beadni az ip címét...

Keresd az /etc/network/interfaces allomanyt. 8O

Info a kernel forras /Documentation/filesystems/proc.txt filebol:

"rp_filter
---------

Integer value determines if a source validation should be made. 1 means yes, 0 means no. Disabled by default, but local/broadcast address spoofing is always on.

If you set this to 1 on a router that is the only connection for a network to
the net, it will prevent spoofing attacks against your internal networks
(external addresses can still be spoofed), without the need for additional firewall rules.

log_martians
------------

Log packets with source addresses with no known route to kernel log."

A logbol jelen esetben a SRC= DST= SPT= es a DPT= ertekek az erdekesek, peldaul ebbol:
"Mar 4 21:36:44 localhost kernel: iptables dropped packet: IN=ppp0 OUT= MAC= SRC=217.234.226.10 DST=217.239.89.238 LEN=52 TOS=0x00 PREC=0x00 TTL=126 ID=16 DF PROTO=TCP SPT=1098 DPT=135 WINDOW=32767 RES=0x00 SYN URGP=0"
kiderul, hogy a 217.234.226.10-es gep 1098-as portjarol TCP kapcsolodasi kiserlet tortent a 217.239.89.238-as gep 135-os portjara.

Udv,
S.

Nagyon koszi a valaszodat.

[quote:2967467837="Sallus"]Info a kernel forras /Documentation/filesystems/proc.txt filebol:

"rp_filter
---------

Integer value determines if a source validation should be made. 1 means yes, 0 means no. Disabled by default, but local/broadcast address spoofing is always on.

If you set this to 1 on a router that is the only connection for a network to
the net, it will prevent spoofing attacks against your internal networks
(external addresses can still be spoofed), without the need for additional firewall rules.

log_martians
------------

Log packets with source addresses with no known route to kernel log."

Kb. ertem, hogy mirol van szo, de azert egy kicsit ugy vagyok vele, mint Aron bacsi az antennaval.

A logbol jelen esetben a SRC= DST= SPT= es a DPT= ertekek az erdekesek, peldaul ebbol:
"Mar 4 21:36:44 localhost kernel: iptables dropped packet: IN=ppp0 OUT= MAC= SRC=217.234.226.10 DST=217.239.89.238 LEN=52 TOS=0x00 PREC=0x00 TTL=126 ID=16 DF PROTO=TCP SPT=1098 DPT=135 WINDOW=32767 RES=0x00 SYN URGP=0"
kiderul, hogy a 217.234.226.10-es gep 1098-as portjarol TCP kapcsolodasi kiserlet tortent a 217.239.89.238-as gep 135-os portjara.

Ez nagyon sokat segitett. Vegigneztem a logokat, es kigyujtottem a "megtamadott" portokat. Majd osszevetettem eezzel: http://isc.sans.org/. Mit ad Isten, hat nem ugyanazok?

subscribe

---
https://www.dropbox.com/referrals/NTM3MTUzNzQ5