Keresés

Részletes keresés

Filburt Creative Commons License 2003.07.10 0 0 27
Nem. A gaz az, hogy nem tudom, pontosan milyen tuzfal beallitast kell eszkozolnom, hogy az IP_C fele kuldott csomagok valojaban IP_B fele hagyjak el a kulso kartyamat. B-)

Ezt probaltam, de nem jo:
/sbin/iptables -A PREROUTING -t nat -p tcp -d IP_C -j DNAT --to IP_B

Filburt

Előzmény: Hülyesamu (26)
Hülyesamu Creative Commons License 2003.07.10 0 0 26
Az a gáz, hogy te ilyet nem tudsz csinálni, te egy cél IP címet adsz meg, és slussz, ez pedig a netről látszó gép kell, hogy legyen, az meg valszeg nem lehet az IP_C, csak IP_B. Innen a te tudományod megáll, ezt meg egy síma nat-os masquerade-val te el is intézted...

A többi egyértelműen a túloldal feladata, de az ottani tűzfal meg elvben tud arról, hogy jön be egy VPN kapcsolat, és irányítgat...

Előzmény: Filburt (25)
Filburt Creative Commons License 2003.07.10 0 0 25
Neked is koszi. B-)

Az a resze valszeg mukodik, mert masok hasznaljak, de en itthon egyelore nem tudom, hogyan kell beloni. Gondolom itthon is a nat tablat kell piszkalni.

Filburt

Előzmény: Hülyesamu (24)
Hülyesamu Creative Commons License 2003.07.10 0 0 24
Hát, ha a meg tudod adni a bejövő csomagok meghatározását, (pl fix IP cím, vagy fix port stb), akkor ezt meg lehet majd csinálni: te a gépedről az IP_B-t adod meg, és itt (magyarul a távoli gépen) kell egy csomag célcím fordítás IP_C-re, ez iptablessal megoldható. NB szerintem te a "sajat linux tuzfal"-on ezzel nem tudsz semmit csinálni, ez az IP_B gép dolga...

A nat táblába kell beírni a távoli gépen egy destination ip címfordítást...

Előzmény: Filburt (23)
Filburt Creative Commons License 2003.07.10 0 0 23
Koszi a valaszt.

Ez egy VPN-szeru behivas lenne egy ceghez, a tuloldal szamomra erinthetetlen. Nem lehet ezt a sajat oldalamon is 'siman' iptables-szel megoldani?

Kellene bele egy komplett cim forditas: megadom az IP_C-t, amirol tudnia kellene, hogy az IP_B-n at erheto el, stb. stb. Gondolom ilyesmit csak lehet...

Filburt

Előzmény: Wyfliff (22)
Wyfliff Creative Commons License 2003.07.10 0 0 22
Bar nem tudom mi a celod, de en feltennek egy rinetd nevu programot mindket tuzfalra (mar ha ezek (Linuxos) PCket jelentenek) ami altal a kovetkezo mukodest tartanam elkepzelhetonek
Az IP_A XXXXX portjat atiranyitod IP_B YYYYY portjata ami pedig at van iranyitva IP_C ZZZZZ portjara.
Előzmény: Filburt (21)
Filburt Creative Commons License 2003.07.10 0 0 21
Hali,

Nem sikerult rajonni a problema megoldasara, igy hozzatok fordulok. B;-)

Win2K gep - sajat linux tuzfal - internet - tavoli tuzfal - tavoli cel gep

Sajat linux tuzfal IP cime: IP_A
Tavoli tuzfal ip cime: IP_B
Tavoli cel gep cime: IP_C

Hogyan (masqueradinggal?) lehet megoldani, hogy ha a Win2K-s geprol meghivom az IP_C cimet, akkor az atjusson a sajat tuzfalon es eljusson az IP_B-s cimu gepig, ami mar bejuttat engem az IP_C cimu cel gephez?

Koszi,

Filburt

sewaqq Creative Commons License 2003.04.06 0 0 20
Udv mindenkinek!

Nincs veletlenul valakinek valami scriptje, mely eszlelve a portscannelest felhuzza a a tuzfalat. Vagy ha scannelest eszlel, akkor meghiv egy masik, "elore gyartot" scriptet, melyben en a tuzfalat aktivalom. Aztan egy ido utan levegye termeszetesen..:)

Hülyesamu Creative Commons License 2003.04.03 0 0 19
Szerintem a 8,4 Giga az inkább FAT körüli dolog, mert az asszem úgy jön ki, hogy max 4 partíció, és a VFAT max 2,1 GB. BIOS probléma a 30 Gigánál van, mert a régi BIOS-ok nem látják a 1024 cilinder feletti részt, kultúrált vincsiknél ez limitálható 1024-re (30 GB).
Előzmény: gir (15)
gir Creative Commons License 2003.03.24 0 0 18
Olvastam már (egyébként az eredeti angol jobb, 1-2 dolgot furcsán fordítottak le), és van egy jobb is de az angolul van csak azt hiszem.

Mivel itthonról istennek sem akar menni a google - se a sourceforge ÷( - így nem tudom nektek a linkeket bevágni. Nyittok 1 google-t, aztán:
'iptables howto' - erre jön a szabilinuxor angol verziója
'iptables guide' - erre meg egy hosszabb, részletesebb leírás, jó klafa

Na majd még bütykölök rajta ha eszembe jut valami okos.

Előzmény: dj (17)
dj Creative Commons License 2003.03.24 0 0 17
Előzmény: sampras_ (16)
sampras_ Creative Commons License 2003.03.24 0 0 16
Hello!

Iptables-el szeretnek csinalni egy tuzfalat, ugy kezdve hogy alapban minden tiltva van utana pedig engedelyezni sorban. Squid is mukodik a halozaton tehat ehhez kellene igazitani a tuzfalat. Ha valaki tudna kuldeni configot vagy valami jo otlete van ezzel kapcsolatban azt megkoszonnem.

gir Creative Commons License 2003.03.20 0 0 15
OFF

És ha én teszek bele egy idevezérlőt, akkor azzal látom a nagy vinyókat? Ha jól tudom ez BIOS kérdés, de nem lenne baj ha nagy vinyót is bele tudnék tenni valahogy. (> 8.4 GB - erről még tudom hogy belemegy)

ON

Egyébként még mindig nem az igazi a dolog, itt a script, mondom a problémát:

#!/bin/sh

###################
#--- Preconfig ---#
###################
iptables -P INPUT DROP
iptables -F
iptables -X

#--- Creating user chains ----
iptables -N userIP # client IP address list
iptables -N serverIP # smb server address list
iptables -N SMBmount # chain for enabling samba mounts
iptables -N SMBshare # chain for enabling samba sharing

########################
#--- Chain 'userIP' ---#
########################
iptables -A userIP -s 152.66.228.0/24 -j ACCEPT # wigner
iptables -A userIP -s 152.66.130.2 -j ACCEPT # ural2
iptables -A userIP -s 193.225.82.188 -j ACCEPT # egeer
iptables -A userIP -s 193.6.40.33 -j ACCEPT # petike
iptables -A userIP -s 193.170.121.99 -j ACCEPT # marec
iptables -A userIP -s 146.110.106.12 -j ACCEPT # vricsi

##########################
#--- Chain 'serverIP' ---#
##########################
iptables -A serverIP -s 152.66.228.5 -j ACCEPT # Multiplex
iptables -A serverIP -s 152.66.228.43 -j ACCEPT # Solid
#iptables -A serverIP -s 152.66.228.31 -j ACCEPT # giraff
iptables -A serverIP -s 152.66.228.111 -j ACCEPT # sandokan

##########################
#--- Chain 'SMBmount' ---#
##########################
iptables -A SMBmount -p udp --sport 137:138 --dport 137:138 -j serverIP
iptables -A SMBmount -p tcp --sport 139 --dport 139 -j serverIP
iptables -A SMBmount -p tcp --sport 445 --dport 445 -j serverIP

##########################
#--- Chain 'SMBshare' ---#
##########################
iptables -A SMBshare -p udp --sport 137:138 --dport 137:138 -j userIP
iptables -A SMBshare -p tcp --sport 139 --dport 139 -j userIP
iptables -A SMBshare -p tcp --sport 445 --dport 445 -j userIP

#######################
#--- Chain 'INPUT' ---#
#######################
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 152.66.228.1 -p udp --sport 68 --dport 68 -j ACCEPT # DHCP
iptables -A INPUT -p tcp --dport 25 -j ACCEPT # SMTP
iptables -A INPUT -p tcp --dport 80 -j ACCEPT # www
iptables -A INPUT -p tcp --dport 10000 -j ACCEPT # webmin
iptables -A INPUT -s 157.181.161.3 -j ACCEPT # apt (inf.elte.hu)
iptables -A INPUT -s 194.109.137.218 -j ACCEPT # apt (debian.org)

iptables -A INPUT -p icmp -j userIP # ICMP
iptables -A INPUT -p tcp --dport 22 -j userIP # ssh
iptables -A INPUT -p tcp --dport 20:21 -j userIP # ftp

iptables -A INPUT -j SMBmount # Samba mount
#iptables -A INPUT -j SMBshare # Samba share

A logika a következő:
1. Vannak alapservice-ek amik az INPUT elején vannak beállítva, pl DHCP, SMTP, web, stb.
2. Vannak user service-ek, amiket csak fix ipről lehet elérni, ezek vannak a userIPben felsorolva.
3. Vannak gépek amikről SMBmountolni akarok, ezek vannak a serverIPben felsorolva.

Ez utóbbiakat úgy érem el elvileg, hogy inputból meghívom az SMBmount láncot ami kinyitja a portokat, és elküldi a csomagot a serverIP-re IP-t ellenőrizni.

(Usereknek nem akarok egyelőre samba elérést adni, ezért az INPUTban a hasonló elven működő SMBshare lánc ki van kommentezve.)

Namost az a gond hogy minden további nélkül be tudok mountolni olyan smb megosztást ami nincs a serverIPben felsorolva. Hol a luk?

gir

Előzmény: lip (14)
lip Creative Commons License 2003.03.20 0 0 14
Azon a 20 modulon mar nem mulik semmi....
Nálam is hasonló vas megy, csak 48 mega RAMmal, és van benne egy RAID kártya, és 6 vincsi, valahol 200 GB körül :-)
És elfértek az iptables modulok.
Előzmény: gir (12)
gir Creative Commons License 2003.03.20 0 0 13
MEEEEEEEEEEEEEEEEEEEEEEEGY!!!!!

Leszopom magam! ÷D

Előzmény: gir (12)
gir Creative Commons License 2003.03.20 0 0 12
Azért nem forgattam be, mert minden cafat hely és memória kincs! ÷)

Konfig:
P133 (mezei, mégcsak MMX sincs ÷)
32 MB RAM
1 db WD 420 MB vinyó /
1 db WD 250 MB vinyó, ebből 70 swap 180 /home

Itt olyan dolgok vannak ám hogy a /homeból forgatom a kernelt mert ott fér el a forrás, ottis ippencsak, majdnem elfoglalja az egész partíciót ÷D

Vashoz képest fut pár service rajta, apache, ftp, ssh, samba, mailman, webmin, exim, hogy csak a legfontosabbakat említsük. Majd valamikor lecserélem a vasat aztán lesz 1 baba szerverem, ezen most csak tanulok, meg mellesleg smbmount-tal tükrözök pár 100 giga filmet.... ÷)

Előzmény: hekker barbie (11)
hekker barbie Creative Commons License 2003.03.20 0 0 11
mazohista :)))) miert nem forgattad be rogton az osszes ipv4 iptables cuccot modulba? az iptables scripted elejen meg kiadhattad volna az insmod-okat is...
Előzmény: gir (10)
gir Creative Commons License 2003.03.19 0 0 10
Minnyáminnyá, először pörgetünk, aztán próbálkozunk! ÷))

gir

Előzmény: hekker barbie (8)
gir Creative Commons License 2003.03.19 0 0 9
Naja, kell a kernelbe olyan is hogy 'Connection state match support'.
Meg ha jól láttam akkor a 'Helper match support' sem árt.

Na lassan csak összeáll minden, akkor pörgessünk mégegyet....

Előzmény: gir (7)
hekker barbie Creative Commons License 2003.03.19 0 0 8
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j userIP

en a -j moge ACCEPT-et irnek, mert a kapcsolatot mar ellenoriztem a felepulesekor, igy hadd szoljon. valahogy igy:

iptables -A xxx -p TCP --syn -j ACCEPT
iptables -A xxx -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A xxx -p TCP -j DROP

ezt az xxx-et hozzadnam -N kapcsoloval az INPUT chain-hez, meg a userIP chained elott.

proba?

Előzmény: gir (7)
gir Creative Commons License 2003.03.19 0 0 7
Kösz, azóta énis bogozódtam, meg olvasgattam, meg írtam egy scriptet amit végül át is látok faszán. ÷)

Szal az a lényeg hogy külön rule-ok vannak a szerverekre (DHCP, Samba, stb, mindegyikre csak az a port nyitva ami kell), valamint a userek IP-i továbbra is külön chain-ben vannak, mert mindenki ugyanazokat a service-eket kapja, és egyszerűbb új júzernél csak az IP-jét beverni mint egy félméteres rule-t.

Az FTP-vel az a helyzet, hogy lipnek van igaza, a 21-es porton dumálják le hogy milyen porton akanak beszélni (X), majd attól függően hogy passzív vagy aktív ftp kapcsolat, így néz ki a dolog:

aktív: [szerver]:20 -------- X:[kliens]
passzív: [szerver]:X -------- 20:[kliens]

Ergo vagy csak aktív FTP-vel legyen hajlandó dolgozni az ember, vagy pedig a megoldás a connection tracking.

Pördítettem új kernelt hogy legyen benne conntrack is, és bevertem a megfelelő parancsot:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j userIP

Azaz fogadjunk el minden forgalmat ami már kétoldalról létrejött kapcsolathoz tartozik, és olyan IPről származik ami fel van sorolva a userIP chainben.

Mostmár csak az a gondom hogy a shell a "No chain/target/match by that name" hibaüzenettel tér vissza, márpedig a parancs eléggé hibátlannak tűnik nekem. ÷)

Szal megvan a gyógyír csak nem veszi be a gép valamiért. Ötlet?

gir

Előzmény: hekker barbie (6)
hekker barbie Creative Commons License 2003.03.19 0 0 6
probalom az iptables -n -L outputod visszaforditani iptables parancsokra, de nagyon taknyos vagyok, igy igen nehezen veszi be a szoke fejem. inkabb kerdezek.

aminek a

userIP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22

az eredmenye, az

iptables -A INPUT -p TCP --dport 22 -j userIP

volt? ha igen, akkor en biztosan nem igy csinalnam. a userIP chainben minden egyes altalad valasztott IP-re csinalnak --dport szabalyt az osszes portra kulon-kulon. azaz mind a hat IP-re lenne kulon-kulon szabaly --dport 22, ill. --dport 20:21.

aztan folyamataban:

iptables -N userIP
iptables -A userIP -P TCP ... [sokszor a kul. portokra]
iptables -A input -p UDP -i eth0 -s 0/0 --source-port 53 -j ACCEPT
iptables -A INPUT -p TCP -i eth0 -j userIP

a szabalyokat az iptables a sorrend alapjan ertekeli ki. ez magyarazatot adhat arra, amit az (5)-ben irsz.

ha forditottal ipt_LOG modult, akkor minden egyes -j ACCEPT/DROP szabaly __ele__ (ennek a -j DROP eseten van jelenbtosege) irjal egy ugyanilyen tartalmu szabalyt -j LOG --log-level info --log-prefix "valami szabalyra utalo szoveg" formaban, akkor legalabb kiderul, hogy melyik szabaly dobja el a csomagot.

lehet kavarni a connection tracking-gel is. akkor a mar felepitett kapcsolatokat siman atengeded, es ezek szuresevel nem foglalkozol. ekkor eloszor eldobod azt, amit mindekkepn dobnal (pl. a bad packetek, atengeded a related (ez jatszik az ftp data packeteknel is) es established kapcsolatokat meg a synchronize packeteket, es szurod a maradekot.

btw, amire lip is celzott: ha kell a bejovo ssh kapcsolat, akkor nincs a masik oldalon scp (secure cp, resze az ssh csomagnak) is? mert akkor talan nem kell az ftp-vel is kuzdened, a 22-es port megoldja ezt a problemat is.

en a bootp-t udp sp:68 dpt:67-el engedelyeznem. es valszeg nem is kell mind a hat ip-edhez amit a userIP-ben felsoroltal. (ezt csak velelmezem, mert nem ismerem sem a te, sem az involvalt domainek viszonyait, de hogy a linux boxodrol bootp-vel szedne fel az ip cimet az ural2 a muegyetemen, egy bke-s es egy veszpremi gep is, sot meg ausztriabol is, az erosen meglepne...)

ha mar emlitetted: igy elsore azt sem ertem hol van engedelyezve a named (udp spt:53), ezert mutattam ra neked az elejen egy INPUT szabalyt.

tovabba az egesz nagyon szepen bonyolodhat, ha linux boxod egy firewall is egyuttal es nat-ot is kell adnod egy belso halonak, valamint dinamikus ip cimed van, amit dhcp-vel veszel fel. lehet, hogy en bonyolitom tul, sot paranoid is vagyok (ez egeszen biztos), de keveslem a szabalyaid. az viszont biztos, hogy felettebb csekelyertelmu es tudatlan vagyok: en speciel az iptables-t felepito script nelkul, csak ebbol az outputbol nehezen tudnam megjavitani a problemat.

remelem nem irtam tul nagy hulyesegeket es valamit tudtam segiteni.

Előzmény: gir (4)
gir Creative Commons License 2003.03.19 0 0 5
Ha tisztán IP alapján szűrök (azaz az INPUT lánc elején elküldök mindent a userIP láncra) akkor minden megy. Szétolvastam a fejema logokban, már mindenhol portokat látok meg protokollokat, de olyat nem láttam hogy 20:21 porton kívül is akarna valamit használni. Szal 5letem sincs.
Előzmény: gir (4)
gir Creative Commons License 2003.03.19 0 0 4
Mégsincsmeg.

Naszal itt az egész szaromány:

Chain INPUT (policy DROP)
target prot opt source destination
userIP icmp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:68 dpt:68
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
userIP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
userIP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpts:20:21
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:25

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain userIP (3 references)
target prot opt source destination
ACCEPT all -- 152.66.228.0/24 0.0.0.0/0
ACCEPT all -- 152.66.130.2 0.0.0.0/0
ACCEPT all -- 193.225.82.188 0.0.0.0/0
ACCEPT all -- 193.6.40.33 0.0.0.0/0
ACCEPT all -- 193.170.121.99 0.0.0.0/0
ACCEPT all -- 146.110.106.12 0.0.0.0/0

Aki makulát talál benn mondja már el miaz.

gir

Előzmény: gir (3)
gir Creative Commons License 2003.03.19 0 0 3
Nem, megvan a gond.

A kommunikáció csak a 20:21-en zajlik TCP-n, a name resolutionnal volt a gond. Tiszta IP-t megadva működik a dolog. Elfelejtettem kinyitni a name service portokat.

gir

Előzmény: p1mp0 (2)
p1mp0 Creative Commons License 2003.03.19 0 0 2
Ha jól emlékszem az FTP 20:21-en keresztül egyeztet egy nem privilégizált portot a klienssel (1024-) és azon zajlik a kommunikáció.
Előzmény: gir (-)
lip Creative Commons License 2003.03.19 0 0 1
Nekem szerencsere nincs szuksegem ftp-re (scp ruley), de van a kernelben olyan a netfilter confignal, hogy "FTP protocol support", valamint allits be egy iptables ... -j LOG szabalyt minden lanc vegere, es akkor latod, hol akad el a cucc.
Előzmény: gir (-)
gir Creative Commons License 2003.03.19 0 0 0
iptables -A INPUT -s -j ACCEPT

Na a -s után kimaradt az IPcím mert kacsacsőrbe tettem oszt asziszi a marhája hogy HTML-t kódolok. ÷)

Előzmény: gir (-)
gir Creative Commons License 2003.03.19 0 0 topiknyitó
Üdv!

Valaki mondja már meg nekem miért nem megy iptables mellett az ftp.

Rendszer: debian woody, wu-ftpd, default portok (20,21 tcp)

iptables konfig:
OUTPUT policy: ACCEPT
FORWARD policy: ACCEPT
INPUT policy: DROP

ide vonatkozó INPUT rule:
iptables -A INPUT -p tcp --dport 20:21 -j ACCEPT

Tények:
1. ftp open parancs visszatér az 'Established connection with ' üzenettel, aztán elhallgat, user autentikációra már nem kerül sor.

2. 20-as port udp nyitása semmit nem változtat.

3. Fragmentek engedélyezése nem változtat.

4. Ha nem portra engedélyezek hanem IP-re (pl: iptables -A INPUT -s -j ACCEPT) akkor minden fasza.

A wu-ftpd biztos hogy a 20:21 portokon megy, le is ellenőriztem. Mi a rákot kell akkor még kinyitni a 20:21 portok mellett hogy menjen ez a car?

Kösz a válaszokat előre is.
gir

Ha kedveled azért, ha nem azért nyomj egy lájkot a Fórumért!