Re: Iptables-kérdés

[BORBELY Zoltan]

Sziasztok!

On Fri, Jan 22, 2016 at 09:46:14AM +0100, Lajber Zoltan wrote:
> Ez azt jelenti, hogy ha mar lat kimeno kapcsolatot, akkor engedje be a
> valaszt (RELATED).

A RELATED lényege, hogy olyan új kapcsolatokat engedélyezzen, ami valami
módon kapcsolódik a jelenlegiekhez. Ilyen pl. az FTP protokoll adatcsatornája,
de ide sorolják az ICMP hibaüzeneteket is.

> udp-n nincs ertelmezve az ESTABLISHED.

Értelmezett, a kimenő UDP csomagra visszaengedi a választ.

A man iptables-extensions leírja ezeket.

Üdv
Bozo
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: Iptables-kérdés

[Zs]

Hi!




Asus router gyári firmware (Linux fut rajta) kiexportáltam a tűzfalat
és valamit nem értek:
Ez a sor:
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Ez azt jelenti, hogy ha mar lat kimeno kapcsolatot, akkor engedje be a 
valaszt (RELATED). udp-n nincs ertelmezve az ESTABLISHED.

A lényegen nem változtat, csak kis pontosítás: én úgy emlékszem, hogy a
válasz beengedéséért az ESTABLISHED felel és a RELATED, ami nincs
értelmezve UDP esetén.
A lényeg: egy kapcsolat felépítésekor az első csomag NEW opcióval jön,
ha az nincs beengedve (és ez a szabály nem engedi be), akkor új kapcsolat
nem fog tudni létre jönni, de a már létezőket (valahol valamely másik
szabály beengedte, vagy a kapcsolat a másik irányból (OUTPUT) épült
fel,) nem bántja.

megoldaná az alábbit is és feleslegesen van engedélyezve, vagy 
rosszul gondolom?

-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT

Ez a bejovo dhcp -t engedelyezi.
Ha nincs ez a sor, akkor dhcp klienskent fog mukodni, de nem tud dhcp 
szerver lenni.
Ez a konkrét magyarázat. Egyébként meg azt nézd meg, hogy itt mind a 
forrás-,
mind a cél port is meg van adva. Tehát nem elég, hogy UDP-n eltalálod a 
68-as
portot, de a csomagnak tőled a 67-es portról kell indulnia! Ez azért 
bőven nagyobbat

szűr, mint az előző szabály, ahol nincs semmilyen port korlátozás.


Mivel már kezdeményezett kapcsolatokra utal és nekem sima Linux alatt
soha nem volt bajom tűzfallal, ha csak ezt az egyetlen sort
tartalmazta és csak a related és established csomagokat engedtem, UDP
üzenetek is mentek, DNS lekérdezés stb.
Nem jelent kockázatot külön az UDP engedélyezése?
Nem. A portok szűkítése miatt minimális forgalmat engedélyezel, azt meg 
engedned
kell ahhoz, hogy a masina DHCP szerver legyen. Illetve ha ezt nem 
akarod, akkor

ezt a szabályt kiveheted.


Üdv
Zsolt

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: Iptables-kérdés

[Lajber Zoltan]

On Fri, 22 Jan 2016, Géza Kovacs Géza wrote:


Sziasztok!

Asus router gyári firmware (Linux fut rajta) kiexportáltam a tűzfalat
és valamit nem értek:
Ez a sor:
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


Ez azt jelenti, hogy ha mar lat kimeno kapcsolatot, akkor engedje be a 
valaszt (RELATED). udp-n nincs ertelmezve az ESTABLISHED.



megoldaná az alábbit is és feleslegesen van engedélyezve, vagy rosszul gondolom?
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT


Ez a bejovo dhcp -t engedelyezi.
Ha nincs ez a sor, akkor dhcp klienskent fog mukodni, de nem tud dhcp 
szerver lenni.



Mivel már kezdeményezett kapcsolatokra utal és nekem sima Linux alatt
soha nem volt bajom tűzfallal, ha csak ezt az egyetlen sort
tartalmazta és csak a related és established csomagokat engedtem, UDP
üzenetek is mentek, DNS lekérdezés stb.
Nem jelent kockázatot külön az UDP engedélyezése?

Üdv, G
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux


-=Lajbi=-
 LAJBER Zoltan
 engineer: a mechanism for converting caffeine into designs.

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: Iptables-kérdés

[Ferenc Wagner]

Lajber Zoltan  writes:

> On Fri, 22 Jan 2016, Géza Kovacs Géza wrote:
>
>> Asus router gyári firmware (Linux fut rajta) kiexportáltam a tűzfalat
>> és valamit nem értek:
>> Ez a sor:
>> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>
> Ez azt jelenti, hogy ha mar lat kimeno kapcsolatot, akkor engedje be a
> valaszt (RELATED).

Nem, az UDP válasz az ESTABLISHED révén jöhet be
/proc/sys/net/netfilter/nf_conntrack_udp_timeout másodpercig.  A RELATED
megüzent portszámok választásakor lép be, pl. TFTP esetén, ha betöltöd a
megfelelő helper modult.
--
Feri.
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: Iptables-kérdés

[Géza Kovacs Géza]

Sziasztok!

Nagyon köszönöm mindenkinek a válaszokat.

Azt kérdezném még, hogy a "NAT áthaladás" menüpont alatt minden
alapértelmezetten be volt kapcsolva és pár portot NAT-olt befelé, ez
nagyon régóta így volt, most vettem észre.
El lehetett kapni valamilyen kártevőt pl. a Windows-os gépeknek? Sok
olyan kártevő program van, ami portszkenneléssel próbálkozik bejutni
vagy sebezhetőséget keresni és ha olyan porton próbálkozott, ami
NAT-olva volt befelé akkor akár be is juthatott valami?
Következő opciók voltak engedélyezve valamint alábbit írja erről a
web-es felület:

WAN - NAT áthaladás
A NAT áthaladás engedélyezése lehetővé teszi egy Virtuális
magánhálózati (VPN) kapcsolat számára az áthaladást a routeren a
hálózati kliensekhez.

PPTP áthaladás
L2TP áthaladás
IPSec áthaladás
IPTV áthaladás
H.323 áthaladás
SIP áthaladás
PPPoE közvetítés engedélyezése

Ezek mind engedélyezve voltak.

Nincs IPTV, VPN-hez sem szoktam csatlakozni.

Üdv, G
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Iptables-kérdés

[Géza Kovacs Géza]

Sziasztok!

Asus router gyári firmware (Linux fut rajta) kiexportáltam a tűzfalat
és valamit nem értek:
Ez a sor:
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
megoldaná az alábbit is és feleslegesen van engedélyezve, vagy rosszul gondolom?
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
Mivel már kezdeményezett kapcsolatokra utal és nekem sima Linux alatt
soha nem volt bajom tűzfallal, ha csak ezt az egyetlen sort
tartalmazta és csak a related és established csomagokat engedtem, UDP
üzenetek is mentek, DNS lekérdezés stb.
Nem jelent kockázatot külön az UDP engedélyezése?

Üdv, G
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: iptables NAT kill

[Salamon Attila]

Hello!

2011-10-11 16:37 keltezéssel, Szima Gábor írta:
 Hogyan lehet iptables segitsegevel egy mar felepult NAT-olt kapcsolatot 
 megszuntetni/lezarni?

Szerintem
aptitude install conntrack
conntrack -F # töröl minden megfigyelt kapcsolatot.
-D -vel lehet valahogy egyenként is bejegyzéseket törölni.

-- 
Üdv:
Salamon Attila

PMielőtt kinyomtatná eztaz e-mailt, gondoljon a KÖRNYEZETVÉDELEMRE /
Before printing this mail, think about ENVIRONMENTAL responsibility
 
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

iptables NAT kill

[Szima Gábor]

Sziasztok!

Hogyan lehet iptables segitsegevel egy mar felepult NAT-olt kapcsolatot 
megszuntetni/lezarni?

Van 2 tuzfal scriptem, amelyek bizonyos feltetelek eseten indulnak el 
felvaltva (vagy az egyik, vagy a masik az aktiv).

Az egyik enged egy bizonyos cimre/portra valo NAT-ot, a masik nem.
Ez mindaddig szepen mukodik, amig nincs egy mar elo kapcsolat. Ugyanis 
hiaba van tiltva a masik script altal, a meg aktiv kapcsolatok tovabbra is 
mukodnek, ami nekem nem jo, el kellene dobni oket.

Pelda:

firewall_on.sh:
...
iptables -t nat -A PREROUTING -p tcp --dport 1234 -j DNAT --to-destination 
3.4.5.6:1234
...



firewall_off.sh:

iptables -F
iptables -F -t nat


OFF utan nem epul fel uj kapcsolat, viszont a mar meglevok maradnak.


-Sygma


_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables NAT kill

[Bartos-Elekes Zsolt]

Sziasztok!

Szima Gábor wrote:

 Hogyan lehet iptables segitsegevel egy mar felepult NAT-olt kapcsolatot 
 megszuntetni/lezarni?

Nemreg csinaltam egy gyereknevelo routert, amivel egy kollegam otthoni 
gepeit lehet akar egyenkent letiltani az internetrol. Az volt a 
megoldas, hogy az engedelyezest/tiltast az

-m state --state ESTABLISHED,RELATED -j ACCEPT

sor ele kellett betenni (ami nalam a legelso szokott lenni), igy azonnal 
megszakad minden kapcsolat.

-- 
Sziasztok: Zsolt

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables dnat localhost-rol

[Hegedüs Ervin]

hello,

On Wed, Sep 08, 2010 at 06:27:36PM +0200, Gabor HALASZ wrote:
 2010.09.08. 15:54 keltezéssel, Hegedüs Ervin írta:
 
  Nem nagyon ertelek
  konkrétan mit?
 
 
 Az egeszet kavarast, pl minek kell ip cima http-ben, nem lehetne oda is 
 dns name-t irni, stb...

ez volt a javaslatom az üzemeltetők/fejlesztők felé...

 Az az 1.2.3.4 altalaban virtualis interface cime szokott lenni, akkro 
 tevedtem.

példa volt, bocs.
 
  de miert is nem hasznalsz valami proxyt
  befele? A squid is tud accelerator lenni, apache/lighttpd/nginx mind tud
  ilyet.
 
  ez mit változtatna a felálláson?
 
 
 Manipulalhatja a http forgalmat, ha mashogy nem, faragni kell egy 
 redirektort, ami atirja a cimet, par perc alatt megoldhato.

de nem a kintről jövő forgalomban kell manipulálni, hanem akik
bentről mennek proxyn keresztül. És itt ez a lényeg, h a belső
kliensek mennek proxyn keresztül egy külső címre, amit ua a hoszt
redirectel a saját hálójuk felé (bár ez utóbbi irreleváns,
lehetne másik IF is, akkor is ue lenne a szitu)
 
  Attól még a Squid a kliens által kért 1.2.3.4-re akarna
  kapcsolódni, konkrétan én ezt látom problémának (tehát h az
  alkalmazás a saját hoszt egyik interface-re akar kapcsolódni, ami
  egyébként DNAT szabály szerint egy másik IP-re megy - vagyis hogy
  lehet lo interfacen egyébként nem lo IP címmel rendelkező
  csomagoknak megmondani, hogy a POSTROUTING-ban levő szabályt
  légyszi' vegyék figyelembe)
 
 Ez mar tobbszor emlegettem a listan, de nem lehet elegszer ismetelni: az 
 netfilterben csak a prerouting chainekben lehet olyan szabalyt irni, ami 
 a destination interface-en valtoztat, a routeing (ami nem ip routeing, 
 tobbek kozott az is itt dol el, hogy melyik lesz az output interface) 
 utan mar nem.

igen, tisztában vagyok ezzel, de megpróbálom harmadik módon
megfogalmazni a kérdést: egy csomagot hogy lehet routingra
kényszeríteni, ha egyébként nem lenne routing (egy adott IP:célport
alapján)?

iproute[2] vagy vmi egyéb mágikus tool jó lenne erre? tapasztalat
érdekelne, vagy bármi, ami felett esetleg elsiklottam.

  Én azt javasoltam, h a vegyünk fel egy új rekordot az adott
  zónába, a weblapon írják át az IP hivatkozást DNS névre, és a
  Squid-nek megmondom h az az új A rekord az 5.6.7.8-ra mutat.
 
 
 Nagyjabol, a korrekt megoldas termeszetesen a split-dns, ahol az 
 internal dns lefedi az external dnst is, csak a privat ip cimekket ad 
 vissza, es termeszetesen http linkben nem hasznaltok ip cimet.
 
  (de ehhez jelenleg 300 felett jár a felhívott egyének száma, és
  perpill senki nem érzi magát illetékesnek)
 
 Jo kis helyen dolgozol :)

nem itt dolgozom (szerencsére), ez csak amolyan úri passzió
esténként lefekvés előtt.

persze h a split DNS lenne a tisztább, szárazabb megoldás, de ez
egy állami hivatal, a döntés (szerintem) kb így megy (a lista
következő eleme az előzőt minden pontjában felülbírálja):

- mi a logikus
- melyik a jobb ajánlat
- a Béla a múltkor tejelt
- most akkor is a Géza lesz

Így asztán az a 300 telefon bár alkotói túlzás, de a 10 körüli
szám sajnos nagyon is valós :(


a.
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables dnat localhost-rol

[Gabor HALASZ]

On 2010.09.09. 8:37, Hegedüs Ervin wrote:


 de nem a kintről jövő forgalomban kell manipulálni, hanem akik
 bentről mennek proxyn keresztül. És itt ez a lényeg, h a belső
 kliensek mennek proxyn keresztül egy külső címre, amit ua a hoszt
 redirectel a saját hálójuk felé (bár ez utóbbi irreleváns,
 lehetne másik IF is, akkor is ue lenne a szitu)


Oh, akkor valahol elkavarodtam. Akkor a mukodo squid-ban kelle egy kis 
rewrite.

 igen, tisztában vagyok ezzel, de megpróbálom harmadik módon
 megfogalmazni a kérdést: egy csomagot hogy lehet routingra
 kényszeríteni, ha egyébként nem lenne routing (egy adott IP:célport
 alapján)?

 iproute[2] vagy vmi egyéb mágikus tool jó lenne erre? tapasztalat
 érdekelne, vagy bármi, ami felett esetleg elsiklottam.

Lehet egy-egy host-ra is routeingot irni, de ha nem akarsz probalkozni, 
at kellene gondolni, mit hogyan csinal a kernel. Anno egy kinai siteon 
megtalaltam ezt http://oreilly.com/catalog/9780596002558 bescannelva, 
ebben van egy jokora (es jol ertheto) folyamatabra arrol, hogyan 
jon-megy a csomag a kernelben, ami alapjan konnyu meghatarozni, hogy a 
kulonbozo toolok hol avatkoznak be a folyamatba, es ez milyen hatassal 
van; igy el tudodm donteni, egyaltalan van-e lehetoseg ilyesmire.


 persze h a split DNS lenne a tisztább, szárazabb megoldás, de ez
 egy állami hivatal, a döntés (szerintem) kb így megy (a lista

Nem akartam talalgatni, de ebben biztos voltam :)

-- 
Gabor HALASZ halas...@freemail.hu
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables dnat localhost-rol

[Hegedüs Ervin]

hello,

On Wed, Sep 08, 2010 at 06:55:44AM +0200, Zs wrote:
 Hi!
 
 
  A cég weboldalán az egyik oldalon van egy iframe, amiben a
  hivatkozás a gép publikus IP-je (tehát nem DNS név, hanem IP) és
  egy port, mondjuk 1.2.3.4:82. Ez van DNAT-tal továbbítva az
  5.6.7.8:80-ra.
  
  Akkor van gond, ha a proxy mögött ülő kliensek megpróbálják
  megnézni ezt az oldalt, ui a Squid az őt futtató gép egyik
  interface-ére próbál csatlakozni, vagyis ilyesmi:
 
 A problémát az okozza, hogy ebben az esetben mindkét gép a
 belső hálón van, így a szerver a válasz csomagot nem a tűzfal
 felé küldi el, hanem direktben oda tolja a kliensnek.

nem.
A klienseken explicit be van állítva a proxy, néhány kivétel van
- ezek között nincs ott az 1.2.3.4. Van olyan gép ami kimehet
proxy nélkül, azok ha kikapcsolják a proxyt akkor náluk működik.

Tehát proxy esetében _ezek_ a kérések _is_ a squid-hez mennek, és a
squid próbál konnektálni a saját publikus IP címére.

Erre írtam h lehetne kivételeket hozzáadni, de elég macerás.

 A megoldás az lehet, hogy a nat tábla POSTROUTING láncába is
 felveszel egy szabályt, ami azt mondja, hogy minden csomag,
 amely a belső hálóból jön és a kérdéses szerver felé halad,
[...]

innentől szerintem ez már nem releváns.



a.

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables dnat localhost-rol

[Gabor HALASZ]

On 2010.09.08. 14:48, Hegedüs Ervin wrote:

 innentől szerintem ez már nem releváns.


Nem nagyon ertelek (plane, hogy a kernel nem szeparalja rendesen az 
alias interfacek forgalmat), de miert is nem hasznalsz valami proxyt 
befele? A squid is tud accelerator lenni, apache/lighttpd/nginx mind tud 
ilyet.

-- 
Gabor HALASZ halas...@freemail.hu
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables dnat localhost-rol

[Hegedüs Ervin]

hello,

On Wed, Sep 08, 2010 at 03:17:54PM +0200, Gabor HALASZ wrote:
 On 2010.09.08. 14:48, Hegedüs Ervin wrote:
 
  innentől szerintem ez már nem releváns.
 
 
 Nem nagyon ertelek
konkrétan mit?

 (plane, hogy a kernel nem szeparalja rendesen az 
 alias interfacek forgalmat),
a lo interface-t érted alias if alatt? ha nem, hogy jön ide az
alias if?

 de miert is nem hasznalsz valami proxyt 
 befele? A squid is tud accelerator lenni, apache/lighttpd/nginx mind tud 
 ilyet.

ez mit változtatna a felálláson?

Attól még a Squid a kliens által kért 1.2.3.4-re akarna
kapcsolódni, konkrétan én ezt látom problémának (tehát h az
alkalmazás a saját hoszt egyik interface-re akar kapcsolódni, ami
egyébként DNAT szabály szerint egy másik IP-re megy - vagyis hogy
lehet lo interfacen egyébként nem lo IP címmel rendelkező
csomagoknak megmondani, hogy a POSTROUTING-ban levő szabályt
légyszi' vegyék figyelembe)


Én azt javasoltam, h a vegyünk fel egy új rekordot az adott
zónába, a weblapon írják át az IP hivatkozást DNS névre, és a
Squid-nek megmondom h az az új A rekord az 5.6.7.8-ra mutat.

(de ehhez jelenleg 300 felett jár a felhívott egyének száma, és
perpill senki nem érzi magát illetékesnek)


a. 
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

[gn] Re: iptables dnat localhost-rol

[Hegedüs Ervin]

On Wed, Sep 08, 2010 at 03:54:05PM +0200, Hegedüs Ervin wrote:
 Attól még a Squid a kliens által kért 1.2.3.4-re akarna
 kapcsolódni, 

ja, akarna.

én kérek elnézést.


a.
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables dnat localhost-rol

[Gabor HALASZ]

2010.09.08. 15:54 keltezéssel, Hegedüs Ervin írta:

 Nem nagyon ertelek
 konkrétan mit?


Az egeszet kavarast, pl minek kell ip cima http-ben, nem lehetne oda is 
dns name-t irni, stb...

 (plane, hogy a kernel nem szeparalja rendesen az
 alias interfacek forgalmat),
 a lo interface-t érted alias if alatt? ha nem, hogy jön ide az
 alias if?


Az az 1.2.3.4 altalaban virtualis interface cime szokott lenni, akkro 
tevedtem.

 de miert is nem hasznalsz valami proxyt
 befele? A squid is tud accelerator lenni, apache/lighttpd/nginx mind tud
 ilyet.

 ez mit változtatna a felálláson?


Manipulalhatja a http forgalmat, ha mashogy nem, faragni kell egy 
redirektort, ami atirja a cimet, par perc alatt megoldhato.

 Attól még a Squid a kliens által kért 1.2.3.4-re akarna
 kapcsolódni, konkrétan én ezt látom problémának (tehát h az
 alkalmazás a saját hoszt egyik interface-re akar kapcsolódni, ami
 egyébként DNAT szabály szerint egy másik IP-re megy - vagyis hogy
 lehet lo interfacen egyébként nem lo IP címmel rendelkező
 csomagoknak megmondani, hogy a POSTROUTING-ban levő szabályt
 légyszi' vegyék figyelembe)

Ez mar tobbszor emlegettem a listan, de nem lehet elegszer ismetelni: az 
netfilterben csak a prerouting chainekben lehet olyan szabalyt irni, ami 
a destination interface-en valtoztat, a routeing (ami nem ip routeing, 
tobbek kozott az is itt dol el, hogy melyik lesz az output interface) 
utan mar nem.



 Én azt javasoltam, h a vegyünk fel egy új rekordot az adott
 zónába, a weblapon írják át az IP hivatkozást DNS névre, és a
 Squid-nek megmondom h az az új A rekord az 5.6.7.8-ra mutat.


Nagyjabol, a korrekt megoldas termeszetesen a split-dns, ahol az 
internal dns lefedi az external dnst is, csak a privat ip cimekket ad 
vissza, es termeszetesen http linkben nem hasznaltok ip cimet.

 (de ehhez jelenleg 300 felett jár a felhívott egyének száma, és
 perpill senki nem érzi magát illetékesnek)

Jo kis helyen dolgozol :)
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

iptables dnat localhost-rol

[Hegedüs Ervin]

hello,

van egy irodai tűzfal, HTTP-nek Squid a kliensek felé, ill van
egy iptables, ami többek között néhány portot DNAT-tal továbbít
belső hosztokra.

A cég weboldalán az egyik oldalon van egy iframe, amiben a
hivatkozás a gép publikus IP-je (tehát nem DNS név, hanem IP) és
egy port, mondjuk 1.2.3.4:82. Ez van DNAT-tal továbbítva az
5.6.7.8:80-ra.

Akkor van gond, ha a proxy mögött ülő kliensek megpróbálják
megnézni ezt az oldalt, ui a Squid az őt futtató gép egyik
interface-ére próbál csatlakozni, vagyis ilyesmi:

$ telnet 1.2.3.4 82
Trying 1.2.3.4...
telnet: Unable to connect to remote host: Connection refused

Ilyen esetben ugye a csomag nem kerül be a nat táblába, tehát
nincs dnat.

Van valami mód ennek feloldására? (lehet olyat h a klienseken ezt
az IP-t felvesszük a kivételek közé, de ez nem játszik, tekintve
elég sok usernek kellene beállítani, és se AD, se egyéb kontroll
nincs ezt szabályozandó)


Köszi:


a.
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables dnat localhost-rol

[Zs]

Hi!


 A cég weboldalán az egyik oldalon van egy iframe, amiben a
 hivatkozás a gép publikus IP-je (tehát nem DNS név, hanem IP) és
 egy port, mondjuk 1.2.3.4:82. Ez van DNAT-tal továbbítva az
 5.6.7.8:80-ra.
 
 Akkor van gond, ha a proxy mögött ülő kliensek megpróbálják
 megnézni ezt az oldalt, ui a Squid az őt futtató gép egyik
 interface-ére próbál csatlakozni, vagyis ilyesmi:

A problémát az okozza, hogy ebben az esetben mindkét gép a
belső hálón van, így a szerver a válasz csomagot nem a tűzfal
felé küldi el, hanem direktben oda tolja a kliensnek. A bibi
ott van, hogy a tűzfal manipulálta az eredeti csomagot, a
válasz viszont nem ment át rajta, így a válasz csomag vissza-
alakítása nem történhet meg.

A megoldás az lehet, hogy a nat tábla POSTROUTING láncába is
felveszel egy szabályt, ami azt mondja, hogy minden csomag,
amely a belső hálóból jön és a kérdéses szerver felé halad,
az MASQUERADE. Ekkor a belső hálós csomagok úgy kerülnek a
szerverhez, mintha a tűzfal küldte volna, így a válasz csomag
is a tűzfalnak megy - ergo lehetőség van a válaszcsomag
visszaalakítására és így működni fog a kapcsolat.
Amiért ennek a megoldásnak a szépsége vitatható, az az, hogy
a szerver innen kezdve az összes belső hálózatból származó
forgalmat az eredeti valós gép helyett a tűzfalról származó
csomagnak fogja naplózni - viszont a kommunikáció működni fog.


Zsolt
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

iptables által eldobott csomagok

[Kis János Tamás]

Van egy, az alábbiak szerint beállított iptables:

iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Valamennyi helyi forgalom engedélyezése:
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Kizárólag az általunk kezdeményezett forgalom engedélyezett:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#
# OUTPUT lanc
#

iptables -A OUTPUT -p udp --dport 53 -j ACCEPT  # DNS

iptables -A OUTPUT -p tcp --dport 80   -m state --state NEW -j ACCEPT   # HTTP
iptables -A OUTPUT -p tcp --dport 443  -m state --state NEW -j ACCEPT   # HTTPS
iptables -A OUTPUT -p tcp --dport 1863 -m state --state NEW -j
ACCEPT  # IRC kapcsolatok engedélyezése
iptables -A OUTPUT -p tcp --dport 6667 -m state --state NEW -j ACCEPT   # MSN

iptables -A OUTPUT -p tcp --dport 25  -m state --state NEW -j ACCEPT#
Levelezés (SMTP)
iptables -A OUTPUT -p tcp --dport 465 -m state --state NEW -j ACCEPT#
Levelezés (SMTPS)
iptables -A OUTPUT -p tcp --dport 143 -m state --state NEW -j ACCEPT#
Levelezés (IMAP)
iptables -A OUTPUT -p tcp --dport 993 -m state --state NEW -j ACCEPT#
Levelezés (IMAPS)
iptables -A OUTPUT -p tcp --dport 110 -m state --state NEW -j ACCEPT#
Levelezés (POP3)
iptables -A OUTPUT -p tcp --dport 995 -m state --state NEW -j ACCEPT#
Levelezés (POP3S)

iptables -A OUTPUT -p tcp --dport 20 -m state --state NEW -j ACCEPT
 # FTP-ADAT
iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT # FTP

# A feleslegesen naplózandó kapcsolatokat eldobjuk:
iptables -A INPUT -p tcp -m multiport --dport
135,137,139,445,1026,1027,5900,6881 -j DROP
iptables -A INPUT -p udp -m multiport --dport
135,137,139,445,1026,1027,5900 -j DROP

# Ami a fentiekre nem illeszkedett, azt naplózzuk és eldobjuk:
iptables -A OUTPUT -j LOG --log-prefix OUTPUT_DROP: 
iptables -A OUTPUT -j DROP

#
# INPUT lanc
#

iptables -A INPUT -j LOG --log-prefix INPUT_DROP: 
iptables -A INPUT -j DROP


Ezzel kapcsolatban 2 kérdésem lenne:
1. Van-e benne valami olyan, ami a nálamnál hozzáértőbbeknek szúrja a szemét...?
2. a syslogban tömegével vannak ilyen sorok:
debian kernel: [ 3103.055139]  INPUT_DROP: IN=eth0 OUT=
MAC=00:0d:61:4b:ad:77:00:17:10:01:67:35:08:00 SRC=120.92.243.7
DST=85.66.119.134 LEN=126 TOS=0x00 PREC=0x00 TTL=106 ID=26547
PROTO=UDP SPT=16881 DPT=29777 LEN=106
Meg tudná valaki mondani, hogy melyik program használja ezt a portot...?

A segítséget/észrevételeket előre is köszönöm!

Üdv,
kjt
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables álta l eldobott csomagok

[Hegedüs Ervin]

hello,

 2. a syslogban tömegével vannak ilyen sorok:
 debian kernel: [ 3103.055139]  INPUT_DROP: IN=eth0 OUT=
 MAC=00:0d:61:4b:ad:77:00:17:10:01:67:35:08:00 SRC=120.92.243.7
 DST=85.66.119.134 LEN=126 TOS=0x00 PREC=0x00 TTL=106 ID=26547
 PROTO=UDP SPT=16881 DPT=29777 LEN=106
 Meg tudná valaki mondani, hogy melyik program használja ezt a portot...?

nem biztos h használja valami a portot, mivel ha az iptables
eldobja a csomagot, akkor logolódik.

Ez az input láncon van, tehát valaki ismeretlenül próbál erre
konnektálni.


(egyébként meg netstat -anup | grep 29777)


a.


-- 
Minden baj forrása az 1/x függvény.
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables által eldobott csomagok

[Kis János Tamás]

Hegedüs Ervin airw...@freemail.hu írta, 2010.01.17.:
 hello,

 2. a syslogban tömegével vannak ilyen sorok:
 debian kernel: [ 3103.055139]  INPUT_DROP: IN=eth0 OUT=
 MAC=00:0d:61:4b:ad:77:00:17:10:01:67:35:08:00 SRC=120.92.243.7
 DST=85.66.119.134 LEN=126 TOS=0x00 PREC=0x00 TTL=106 ID=26547
 PROTO=UDP SPT=16881 DPT=29777 LEN=106
 Meg tudná valaki mondani, hogy melyik program használja ezt a portot...?

 nem biztos h használja valami a portot, mivel ha az iptables
 eldobja a csomagot, akkor logolódik.

 Ez az input láncon van, tehát valaki ismeretlenül próbál erre
 konnektálni.


 (egyébként meg netstat -anup | grep 29777)


Ez semmit sem ad vissza, nyilván mert semmi sem használja...
De melyik progtam szokta ezt használni?
Azt tudom, hogy ez nem dedikált port, de másnak nyilván nagyobb
tapasztalata van..
Egyébként én valamelyik játékprogramra gyanakodtam, mert a gyerekeim
miatt majdnem mind fent van, ami része a Lenny-nek.

Mindenesetre asszem' LOG nélkül DROP-olom ezeket.

Köszönettel,
kjt
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables gyorssegely

[Kiss Gabor]

In article 20090819160112.gd27...@linux.gyakg.u-szeged.hu,
=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?= pasz...@linux.gyakg.u-szeged.hu 
writes:
 Mi=E9rt akarod, hogy broadcast storm legyen a h=E1l=F3don?
 
 Wins-t tess=E9k be=E1ll=EDtani, =E9s el=F5re eld=F6nteni ki a master browse=
 r.

Hidd el nem poénnak szánom a kérdést: mi az a wins? :-)
(Csak költõinek. Nehogy ajánlj valami olvasnivalót!)
Nem foglalkozom a vindózok lelkivilágával. Ebbe az ügybe is
véletlenül keveredtem bele. De már kimásztam belõle. :-)

g
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables gyorssegely

[Kosa Attila]

On Mon, Aug 24, 2009 at 06:46:45AM +, Kiss Gabor wrote:
 
 Hidd el nem poénnak szánom a kérdést: mi az a wins? :-)

Microsoft WINS Servers

The WINS system for name resolution can be viewed as a set of
tightly integrated components:

 * WINS server. A computer that provides the WINS service and
replicates the WINS database with other WINS servers so that
complete name-to-address resolution information is available
regardless of which WINS server a WINS client uses.
 * WINS client. Any WINS-enabled computer that uses the WINS
service to register or refresh its NetBIOS name and IP address.
 * WINS proxy. A WINS-enabled computer that helps resolve name
queries in routed TCP/IP intranets for computers that are not
WINS-enabled.
 * WINS database. Dynamically updated list of NetBIOS names
and their associated IP addresses, including IP addresses
assigned by DHCP. In networks with multiple WINS servers, the
servers exchange database updates through replication.
 * WINS Management Console. A plug-in to the Microsoft
Management Console that provides a range of management tools.

 (Csak költőinek. Nehogy ajánlj valami olvasnivalót!)

Azert a fenti meg talan belefer :)

-- 
Udvozlettel
Zsiga
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables gyorssegely

[PÁSZTOR György]

Hi!

Kiss Gabor ki...@ssg.ki.iif.hu írta 2009-08-13 07:16-kor:
 Ez mindenfele szolgaltatasokat nyujt a regi szomszedainak.
 Illetve csak nyujtana. Van ami nem megy, mert a kliensei most
 hiaba kuldik a broadcastokat a 137-es UDP portra (netbios-ns),
 baratunk nem kapja meg oket.
Ez ugyan nem a kérdésedre a válasz, csak egy észrevétel:
Miért akarod, hogy broadcast storm legyen a hálódon?

Wins-t tessék beállítani, és előre eldönteni ki a master browser.

Lajbi élményszámbamenően tudja elmondani, milyen az, amikor broadcast
segítségével van browser election! ;-)

Ha meg dhcp is van a környéken, akkor dhcp-ből el is tudod mondani a
klienseknek, hogy csak a kijelölt wins szervert használják, és az ki
legyen.

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

iptables gyorssegely

[Kiss Gabor]

Volna itt egy linuxbol gyartott tuzfal, amihez tegnap hozzaadtam egy
uj interfeszt, es egy picike networkot, ahova athelyeztem egy
nem megbizhato vindozos gepet egy masik szegmensrol.

Ez mindenfele szolgaltatasokat nyujt a regi szomszedainak.
Illetve csak nyujtana. Van ami nem megy, mert a kliensei most
hiaba kuldik a broadcastokat a 137-es UDP portra (netbios-ns),
baratunk nem kapja meg oket.

Hogy lehetne az iptables-be olyan funkcionalitast konfiguralni,
mint a Cisco routerekben az ip helper?

kissg

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables gyorssegely

[Kiss Gabor]

In article h60ekd$nn...@turmix.ikk.sztaki.hu,
ki...@ssg.ki.iif.hu (Kiss Gabor) writes:
 Hogy lehetne az iptables-be olyan funkcionalitast konfiguralni,
 mint a Cisco routerekben az ip helper?

Targytalan! Bocs!

g
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables+time

[Kiss Gabor]

In article h0r56g$pr...@turmix.ikk.sztaki.hu,
ki...@ssg.ki.iif.hu (Kiss Gabor) writes:
 Ezt a sort generálja a ferm:

 -A RESTRICTED --jump ACCEPT --protocol tcp --source XX.XX.XX.XX --destination 
 YY.YY.YY.YY --dport  --match time --datestop 2009-06-12T12:00

 Szoval a kerdes meg mindig az: mitol mulik el az UNKNOWN match `time'?

Egy masik gepen viszont mukodik...

0 0 ACCEPT tcp  --  anyany XX.XX.XX.XX  YY.YY.YY.YY
TIME until date 2009-06-12 12:00:00 

Ott 2.6.26-13lenny2 verzioju linux-image-2.6.26-1-686 van.

Mindeketton szepen emelkedik a use count az xt_time modul neve mellett,
ahogy uj - idotol fuggo - szabalyokat adok a chainhez. 
Szoval ez kell hozza, de valamiert megsem tetszik neki. :-(

g

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables+time

[Kiss Gabor]

In article 87ocstbvaq@tac.ki.iif.hu,
Ferenc Wagner wf...@niif.hu linux@mlf.linux.rulez.org writes:

  Egy masik gepen viszont mukodik...
 
  0 0 ACCEPT tcp  --  anyany XX.XX.XX.XX  YY.YY.YY.YY 
 TIME until date 2009-06-12 12:00:00 
 
  Ott 2.6.26-13lenny2 verzioju linux-image-2.6.26-1-686 van.
 
  Mindeketton szepen emelkedik a use count az xt_time modul neve mellett,
  ahogy uj - idotol fuggo - szabalyokat adok a chainhez. 
  Szoval ez kell hozza, de valamiert megsem tetszik neki. :-(
 
 Nézd meg, hogy a /lib/xtables tartalmával minden rendben van-e.
 Strace, iptables reinstall...

Bingo!
Volt egy régi iptables a /usr/local/sbin/ alatt es en tudtomon
kivul azt futtattam. :-(

Danke schoen! - mondtak a partizanok. :-)

kissg
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables+time

[Erdei-Gulyás Ferenc]

SziYa!

Próbáld meg így:
Pl: iptables -I FORWARD -i eth0 -s xx.xx.xx.xx -m time --datestart 
2009-06-13T18:00 -j ACCEPT

Kiss Gabor írta:

 --match time --datestart 2009:06:13T18:00 opciojaval,
   
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables+time

[Erdei-Gulyás Ferenc]

Sőt: ha órához akarod kötni és nem adott naphoz
--timestart hh:mm[:ss]
--timestop hh:mm[:ss]

iptables -I FORWARD -i eth0 -s xx.xx.xx.xx -m time --timestart 06:30:00 
-j ACCEPT
iptables -I FORWARD -i eth0 -s xx.xx.xx.xx -m time --timestop 06:30:00 
-j ACCEPT

Bár én még nm próbáltam hogy működik de hiba nélkül elfogadja a 
beállításokat! ;)
 --match time --datestart 2009:06:13T18:00 opciojaval,
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables+time

[Kiss Gabor]

In article 4a310e55.3020...@comp-net.hu,
Erdei-Gulyás Ferenc erdeigfer...@comp-net.hu writes:
 Próbáld meg így:
 Pl: iptables -I FORWARD -i eth0 -s xx.xx.xx.xx -m time --datestart 
 2009-06-13T18:00 -j ACCEPT
 Kiss Gabor írta:
 --match time --datestart 2009:06:13T18:00 opciojaval,

Nyugalom! :-)
Az elso ket kettospont csak elgepeles a segelykero levelemben.
Persze, hogy kotojelekkel adom ki a parancsot, maskepp szintaktikai hibaval
szallna el.
Ezt a sort generálja a ferm:

-A RESTRICTED --jump ACCEPT --protocol tcp --source XX.XX.XX.XX --destination 
YY.YY.YY.YY --dport  --match time --datestop 2009-06-12T12:00

Szoval a kerdes meg mindig az: mitol mulik el az UNKNOWN match `time'?

g
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

iptables - adsl - modem lekérdező sm50b - hogyan?

[gaborlinux]

Hi!

Adott egy adsl modem lekérdezésére alkalmas program:
http://www.webtemp.org/index.php?page=sm50b
A progi úgy működik, hogy a notebook ot drivektbe kell kötni a
modemmel, majd amikor nem kap tőle ip-t és a notesz ip-je feláll
(mivel nincs dhcp) a 169.254.127.88/255.255.0.0-ra.

Ezek után az sm50b program már képes a modemmel kommunikálni,
leolvasni belőle az adatokat.

Elképzelhető az is, hogy a 169.254... ip csak a kommunikáció elején
szükséges, és utána elegendő a modem saját ip-je.

Jelenleg egy gw nevű gép végzi az internetre betárcsázást, és a
natolást is.


Szeretném elérni, hogy az adsl modem (sm50b) a belső hálózatról is
elérje az adsl-el modemet. De jelenleg minden ip a pppoe -n át megy,
és ez így nem megfelelő, mert ezt kikerülve direktbe kell az eth-ra
kiszólni a modemnek.

Hogyan lehet az eth-ra felvenni ugy egy ip-t, ugy hogy a
modemet direktbe el tudjam érni, (közben a pppoe tudja használni)?
A gond az, hogy a pppoe nem ad az eth-nak ip-t, ezert az eth0:0
felvétele nem biztos, hogy a legjobb járható megoldás.

A második kérdés, hogy mit irjak az iptables-nek, hogy az adott
címekre irányuló csomagokat direktbe a modemnek küldje, a pppoe-n
kívűl?

A weboldalon van egy összetett megoldás, de ez csak openwrt-vel
működik:
http://www.webtemp.org/index.php?page=sm50b
valamit, nem kötném össze a belső gépeimet fizikailag a
netszolgáltató modemével loop kábellel.

Ötlet?
Működő megoldás???

Köszönettel:
Gábor

-- 
Best regards,
 gaborlinux  mailto:gaborli...@gsmfree.hu

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables - adsl - modem lekérdező sm50b - hogyan?

[Vastagh Norbert]

2009. január 26. dátummal gaborlinux ezt írta:
 Szeretném elérni, hogy az adsl modem (sm50b) a belső hálózatról is
 elérje az adsl-el modemet. De jelenleg minden ip a pppoe -n át

Jó ronda megoldás: a (lan) switc-be dugod a modemet, meg a router wan 
portját is ;-)))

(nálam volt így kötve régen, hogy az ügyfelek gépein ki tudjam 
próbálni az adsl kapcsolatot, hogy működik-e: és nem volt eddig 
kedvem pppoe szerverrel szórakozni ;-)))

Üdv:

-- 
Vastagh Norbert
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

iptables ROUTE patch

[Erdei-Gulyás Ferenc (compnet)]

Üdv mindenki.

Hivatalos iptables leírás szerint létezik egy ROUTE kapcsolo, paraméter, 
... ,csak éppen patch kell hozzá.
Googleztam kicsit és rátaláltam a patch-o-matic -ra. Yo csak a legutolsó 
nem tartalmazza a ROUTE patch -et.
A régiek meg nem mennek fel az új kernelre + nem ismerik az új iptables 
verziókat.
Tud evvel kapcsolatban valaki valamit hogy miért vették ki vagy hogy 
hogy lehet bevarázsolni.

U.i.:
Igen tudom használjam az iproute2 -őt.
De nekem szimpatikusabb lenne az iptables ROUTE megoldása.
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables ROUTE patch

[Ferenc Wagner]

Erdei-Gulyás Ferenc (compnet) [EMAIL PROTECTED] writes:

 Hivatalos iptables leírás szerint létezik egy ROUTE kapcsolo,
 paraméter, ... ,csak éppen patch kell hozzá.

Már nem létezik.

 Igen tudom használjam az iproute2 -őt.

Igen.
-- 
Feri.
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

iptables, connection tracking

[BEREGNYEI Balazs]

Hali,

Egy 2.6.22-es gepen make oldconfig-gal csinaltam egy ujabb, 2.6.25-os 
kernelt. Fura modon az uj kernelben mintha elromlott volna a netfilter 
connection tracking support, mert erre az iptables szabalyra 
ujabban egyetlen csomag sem passzol:

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

Tehat nem tudok ratelnetelni egy masik gep 80-as portjara, mert a 
visszafele irany nem mukodik. Csak akkor mukodik, ha direktben beengedem:

iptables -I INPUT -s tavoli_gep_ip -p tcp --sport 80 -j ACCEPT

Termeszetesen az uj kernel konfigjaban benne van a conn. track.
Vajon miert nem mukodik?

Koszi,
BB

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables, connection tracking

[Budacsik Attila]

BEREGNYEI Balazs wrote:
 Hali,
 
 Egy 2.6.22-es gepen make oldconfig-gal csinaltam egy ujabb, 2.6.25-os 
 kernelt. Fura modon az uj kernelben mintha elromlott volna a netfilter 
 connection tracking support, mert erre az iptables szabalyra 
 ujabban egyetlen csomag sem passzol:
 
 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
 Tehat nem tudok ratelnetelni egy masik gep 80-as portjara, mert a 
 visszafele irany nem mukodik. Csak akkor mukodik, ha direktben beengedem:
 
 iptables -I INPUT -s tavoli_gep_ip -p tcp --sport 80 -j ACCEPT
 
 Termeszetesen az uj kernel konfigjaban benne van a conn. track.
 Vajon miert nem mukodik?
 

nf_conntrack modul be van töltve?
/proc/net/nf_conntrack-ban kellene lennie a kapcsolatoknak.

/proc/sys/net/netfilter/nf_conntrack_max
ebben van, hogy max mennyi kacsolatkövetést figyel

/proc/sys/net/netfilter/nf_conntrack_count
ebben, hogy éppen most mennyi kapcsolatot figyel

Remélem jól írtam

-- 
Üdv / Attila

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables, connection tracking

[Balazs Beregnyei]

Szia,

Budacsik Attila wrote:

 nf_conntrack modul be van töltve?
 /proc/net/nf_conntrack-ban kellene lennie a kapcsolatoknak.
 
 /proc/sys/net/netfilter/nf_conntrack_max
 ebben van, hogy max mennyi kacsolatkövetést figyel

Modul betoltve, a kapcsolatok maximuma 4096,

 /proc/sys/net/netfilter/nf_conntrack_count
 ebben, hogy éppen most mennyi kapcsolatot figyel

... epp 12 kapcsolatot figyel, es mindegyik olyan tipusu, hogy SYN_SENT,
 [UNREPLIED], azaz mintha tenyleg elromlott volna a conntrack :(


BB
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Apache squid iptables

[Erdei-Gulyás Ferenc (compnet)]

SziYa mindenki.


Következő kérdésem lenn:
 - hogy tudom megoldani a leg egyszerűbben azt hogy adott tartományba lévő
   gépek ha internetezni akarnak csak egy adott oldal jöjjön be bármit 
írnak a böngészőbe?

Adott egy linux -os router + tűzfal + apache (ezt kéne látnia 
mindenkinek az adott tartományban).

iptables -ben nézegettem már egy pár dolgot de akadnak problémáim.
Teljesen jogosan hiába írányítom át a kéréseket ha a kérés más névhez,ip 
-hez szól akkor a local apache nem válasszol.

Megoldásnak a squid -ra gondoltam. De nem találok leírást ami legalább 
hasonló dologról szolna.

Vagy csak nem vettem észre.

Van valakinek evvel kapcsolatban ötlete tapasztalata?

Segítséget előre is köszönöm:

Erdei-Gulyás Ferenc
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: Átirányítás iptables-el

[PÁSZTOR György]

Hi!

Szabo Istvan [EMAIL PROTECTED] írta 2008-06-13 13:41-kor:
 Van -e valakinek egyéb ötlete, javaslata?
Kezdésnek rajzold le mégegyszer ezt az ábrát, amit egyszer már megtettél.
Valahogy nekem a mellékelt szöveg mentén sem sikerült a redundanciát
megtalálnom a két telephely vagy akármi kapcsolatában.
Meg ha egyszer írsz olyat, hogy telephely, akkor az a rajzról is legyen
egyértelműen beazonosítható, hogy mire is gondolsz.
Így aki segíteni próbálna is a sötétben tapogatózik.
Lásd még ESR smart questions-ét! ;-)

Üdv:Gyur!
-- ---[ Free Software ISOs - http://www.fsn.hu/?f=download ]--- --
PÁSZTOR György e-mail: [EMAIL PROTECTED]
Free Software Network (FSN.HU)  cell.: +3620 512 3335
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: Átirányítás iptables-el

[Szabo Istvan]

On Wed, 18 Jun 2008, PÁSZTOR György wrote:

 Kezdésnek rajzold le mégegyszer ezt az ábrát, amit egyszer már megtettél.

Akkor picit átrajzolom:

 Telephely
 |
   |- Internet --|
   | |
  Iroda(ADSL) ...WLAN... Üzem (SDLS)

1. Tisztában vagyok vele, hogy a gyenge láncszem a telephely, mert 1
kapcsolata van.

2. A telephely az Üzemet az SDSL-en éri el, az ott lévő tűzfal a megadott
portokra érkező kéréseket (http, és ODBC) az üzemi szerverre továbbítja.

A kérdés az, hogy a Telephely linuxos kijáróján lehet -e valamilyen
iptable-s szabály szerkeszteni, ami minden SDSL felé irányuló kapcsolatot
eltérít az Iroda felé.

 Valahogy nekem a mellékelt szöveg mentén sem sikerült a redundanciát
 megtalálnom a két telephely vagy akármi kapcsolatában.

A redundanciát az üzemi szerver elérésére értettem. Feltételezve egy SDSL
hibát a telephely cliens gépein ne kelljen címeket átállítani, elég legyen
egy helyen. Erre voltak az alap ötletek:
1. Proxy rewrite modullal
2. Local DNS

Ezek helyett szerettem volna inkább iptables-es megoldást, ha lehetséges
egyáltalán. (Mivel nincs tapasztalatom terhelésmegosztásban, így
laikusként arra hasonlítanám. Persze ott az egyik kérés az egyik, míg a
másik kérés a másik gépre megy, de jelen esetben mindig _csak_ egy felé
kellene mennie.)

-- 
  (O__--
  //\   /  Varosi Csokonai Konyvtar
 //  ) |   Tel.: 59/503-152
 V__/_[EMAIL PROTECTED]   \  [EMAIL PROTECTED]


_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: Átirányítás iptables-el

[Kosa Attila]

On Wed, Jun 18, 2008 at 02:07:54PM +0200, Szabo Istvan wrote:
 On Wed, 18 Jun 2008, PÁSZTOR György wrote:
 
  Kezdésnek rajzold le mégegyszer ezt az ábrát, amit egyszer már megtettél.
 
 Akkor picit átrajzolom:
 
  Telephely
  |
|- Internet --|
| |
   Iroda(ADSL) ...WLAN... Üzem (SDLS)
 
 1. Tisztában vagyok vele, hogy a gyenge láncszem a telephely, mert 1
 kapcsolata van.
 
 2. A telephely az Üzemet az SDSL-en éri el, az ott lévő tűzfal a megadott
 portokra érkező kéréseket (http, és ODBC) az üzemi szerverre továbbítja.
 
 A kérdés az, hogy a Telephely linuxos kijáróján lehet -e valamilyen
 iptable-s szabály szerkeszteni, ami minden SDSL felé irányuló kapcsolatot
 eltérít az Iroda felé.

Most van valamilyen szabaly? Mert akkor annyi, hogy figyeled az
sdls fele a kapcsolatot, es ha nem megy, akkor atirod a szabalyt,
ha megy, akkor meg visszairod.

-- 
Udvozlettel
Zsiga
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: Átirányítás iptables-el

[Salamon Attila]

2008. június 18. dátummal Szabo Istvan ezt írta:
 2. A telephely az Üzemet az SDSL-en éri el, az ott lévő tűzfal a
 megadott portokra érkező kéréseket (http, és ODBC) az üzemi
 szerverre továbbítja.

 A kérdés az, hogy a Telephely linuxos kijáróján lehet -e valamilyen
 iptable-s szabály szerkeszteni, ami minden SDSL felé irányuló
 kapcsolatot eltérít az Iroda felé.

Igen, DNAT-al lehet. Pl. a http forgalomra:
iptables -t nat -A PREROUTING --dst $SDSL_IP -p tcp --dport 80 \
-j DNAT --to-destination $IRODA_ADSL_IP

A --dport 80 nélkül a teljes tcp forgalmat arra tereli.

Ezután meg kell még oldani, hogy az irodai ADSL adott portjaira 
irányuló forgalom is eljusson az üzem szerverére.

Végül, hogy a csomagok a helyes útvonalon jussanak vissza, az üzem 
szerverén a telephely ipje felé irányuló csomagokat az irodai adsl 
belső lába felé kell routolni.

-- 
Sala
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: Átirányítás iptables-el

[Szabo Istvan]

On Wed, 18 Jun 2008, Kosa Attila wrote:

 Most van valamilyen szabaly? Mert akkor annyi, hogy figyeled az

Nincs. A clienseken a böngészőbe https://IP:Port-ot írnak be
(kezdőoldal ez), az ODBC-nek is beégetve IP van beállítva, ami az
SDSL-re mutat.


 sdls fele a kapcsolatot, es ha nem megy, akkor atirod a szabalyt,
 ha megy, akkor meg visszairod.

Pont ez a kérdés, hogy ez van most minden cliensen alapnak beállítva
és azt szeretném, hogy szakadás esetén tudjak egy iptables szabályt
berakni a telephely kijárójára, ami eltéríti az SDSL felé irányuló
kérést az Iroda felé.

-- 
  (O__--
  //\   /  Varosi Csokonai Konyvtar
 //  ) |   Tel.: 59/503-152
 V__/_[EMAIL PROTECTED]   \  [EMAIL PROTECTED]


_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Átirányítás iptables-el

[Szabo Istvan]

Hi!

A felállás a következő:

  Internet(ADSL)--- Iroda ==WIFI== Üzem --- Internet(SDSL)

Van egy telephely, ami az SDLS-ee oldalon kapcsolódik az Üzem szerveréhez
(portforward-al van https és ODBC beengedve).

Szeretném azt megoldani, hogy amennyiben az SDSL megszakad, akkor a
telephelyen egy gépen kelljen csak a címet átírni és a többi cliens ennek
megfelelően ne az SDSL felöl, hanem az Irodai ADSL+WIFI-n keresztül érje
el az üzem szerverét (mondhatni ez lenne a tartalékvonal). Két megoldás
jutott eszembe:
1. A telephelyen lokálisan egy DNS és cím alapján lehetne kapcsolódni. A
probléma ezzel csak az, hogy a windows/böngésző cacheli a címet és
emiatt reboot-ra lesz szükség.

2. Transparent proxy + rewrite. Továbbra is IP:port megadással megy, de
ezt egyből átirom IP:másik port-ra annak függvényébe, hogy melyik oldalról
kell elérni az üzem szerverét.
Ennél a megoldásnál a rewrite nem igazán tetszik (mindamellett, hogy
cachelni _nagyon nem kellene_), sajnos voltak rossz tapasztalataim
(squid+jesred)

Van -e valakinek egyéb ötlete, javaslata?

Iptables-t preferálnám, ha azzal meg lehetne oldani, de ahhoz néhány
kulcsszót kérnék, ami mentén el tudnék indulni.

Segítségeteket előre is köszönöm!

-- 
  (O__--
  //\   /  Varosi Csokonai Konyvtar
 //  ) |   Tel.: 59/503-152
 V__/_[EMAIL PROTECTED]   \  [EMAIL PROTECTED]

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: Átirányítás iptables-el

[Kosa Attila]

On Fri, Jun 13, 2008 at 01:41:41PM +0200, Szabo Istvan wrote:
 
 1. A telephelyen lokálisan egy DNS és cím alapján lehetne kapcsolódni. A
 probléma ezzel csak az, hogy a windows/böngésző cacheli a címet és
 emiatt reboot-ra lesz szükség.

Ez ugyan tisztan windowsos kerdes, de miert kellene?
ipconfig/flushdns

-- 
Udvozlettel
Zsiga
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: Átirányítás iptables-el

[Szabo Istvan]

On Fri, 13 Jun 2008, Kosa Attila wrote:

 Ez ugyan tisztan windowsos kerdes, de miert kellene?
 ipconfig/flushdns

Ezt nem ismertem, köszönöm a tippet.
Ettől még a clienseken dolgozó emberkéket nem szeretném ezzel
macerálni, jobb, ha Ők erről mit sem tudnak

-- 
  (O__--
  //\   /  Varosi Csokonai Konyvtar
 //  ) |   Tel.: 59/503-152
 V__/_[EMAIL PROTECTED]   \  [EMAIL PROTECTED]

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

redirect - iptables ?

[Pávlicz György]

Sziasztok!

A következőt szeretném megoldani:
Ha egy gép (Ubuntu LTS 6.06) a névfeloldás után az a.b.c.0/22 hálózatba 
küldene kérést a 80-as vagy a 443-as portra, azt az a.b.c.d:8080-ra küldje!

Egy ideje már bénázok vele.

Előre is köszönöm a segítséget, észrevételeket!

Üdv,
Qvik
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: redirect - iptables ?

[Medovárszky Zoltán]

Pávlicz György írta:
 A következőt szeretném megoldani:
 Ha egy gép (Ubuntu LTS 6.06) a névfeloldás után az a.b.c.0/22 hálózatba 
 küldene kérést a 80-as vagy a 443-as portra, azt az a.b.c.d:8080-ra küldje!
iptables -t nat -A PREROUTING -i ethX -d a.b.c.0/22 -p tcp --dport 80 -j 
REDIRECT --to a.b.c.d:8080
iptables -t nat -A PREROUTING -i ethX -d a.b.c.0/22 -p tcp --dport 443 
-j REDIRECT --to a.b.c.d:8080

Üdv,
Igor
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables ismerkedés

[Gádori Zsolt]

előző levél:
---
Thu, 14 Feb 2008 22:08:56 +0100 Gábor Lénárt
Re: iptables ismerkedés
---
 On Thu, Feb 14, 2008 at 09:53:57PM +0100, Gádori Zsolt wrote:
  No ezt az utolsó félmondatodat ha kicsit kifejtenéd. Úgy GY.K.
  szinten. :-))
 
 Most nem kotekedeskeppen, de ilyeneket megtalahatsz valami
 halozatosdival foglalkozo konyvben/site-on stb, ez azert annyira nem
 rovid tema, hogy jol el lehessen magyarazni, foleg nem ezen a listan.

Semmi gáz nem lesz, ha csak annyit mondasz: erről itt találsz
leírást. Eddig is sokat segítettél. Kösz az eddigieket.
Zs.



_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables ismerkedés

[Gábor Lénárt]

On Thu, Feb 14, 2008 at 09:53:57PM +0100, Gádori Zsolt wrote:
 No ezt az utolsó félmondatodat ha kicsit kifejtenéd. Úgy GY.K.
 szinten. :-))

Most nem kotekedeskeppen, de ilyeneket megtalahatsz valami halozatosdival
foglalkozo konyvben/site-on stb, ez azert annyira nem rovid tema, hogy jol
el lehessen magyarazni, foleg nem ezen a listan. Egy rovid pelda, a
klasszikus traceroute hasznalata: itt arrol van szo, hogy a cel fele kuldunk
egy csomagot, ahol a ttl mezoben 1 van, igy az elso hop utan lejar es
visszajon az elso hop-tol egy time exceeded uzenet. Ezutan kuldunk egy
csomagot ttl=2-vel, igy az pont a masodiknal jar le (ui szokas csokkenteni
eggyel a ttl erteket minden routeren/stb, ha nullara er akkor baj van, ezt
hasznalja ki tulajdonkeppen a traceroute ahhoz, hogy a fenti modszerrel
felterkepezze az utvonalat). No mint lathato, kuldok egy csomagot a cel
fele ami lehet akar egy UDP csomag is pl, de mondjuk a ttl nullat valo
elerese miatt visszajon egy icmp uzenet formajaban az, hogy na ez nem
nyert. Ilyenforman ez is RELATED, mivel kapcsolatban van a kerdeses UDP
csomaggal (annak sorsarol hoz informaciot), a netfilter pl igy is tekinti.
Ha nem tekintene, akkor pl nem lenne hasznalhato a traceroute igazan egy
netfilterezett geprol :) Sorry a bena forgalmazasert es masoknak a
savszelessegert ... Ha erdekelnek ilyesmik, szerintem szerezz egy jo konyvet
v leirast a tcp/ip mukodeserol es hasonlok.

Amugy ha megnezed pl az iptables man oldalat ott is emlitenek par dolgot:

RELATED meaning that the packet is starting a new connection, but is
associated with an existing connection, such as an FTP data transfer, or an
ICMP error.

-- 
- Gábor
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables ismerkedés

[Gádori Zsolt]

előző levél:
---
Wed, 13 Feb 2008 21:48:00 +0100 Gábor Lénárt
Re: iptables ismerkedés
---
  Jól gondolom?
 
 Elvileg jol, sot icmp-re is, mert ugye annak sincs allapota de pl
 hasonloan az udp-hez ha pl nyomsz egy icmp echo request-et egy cim
 fele (nepies neven ping) akkor a valasz is vissza lesz engedve
 automatice. Csak most arra vigyazzunk, nehogy osszekeverdjen az info:
 persze icmp nem feltetlen csak pingelesre jo, pl RELATED
 statusban elofordul bizonyos pl tcp kapcsolat eseten is, ami fontos
 uzentet hordoz, es nem illik kizarni ...
 

No ezt az utolsó félmondatodat ha kicsit kifejtenéd. Úgy GY.K.
szinten. :-))
Zs.

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables ismerkedés

[SZABO Zsolt]

On Tue, 12 Feb 2008, Gábor Lénárt wrote:

 On Tue, Feb 12, 2008 at 06:11:24PM +0100, Gádori Zsolt wrote:
 Igen, már mondták a kollégák is, hogy ez egy rossz megoldás. Ennek
 következtében én arra gondoltam, hogy a szolgáltató IPcíméről engedem
 csak be ezeket a csomagokat. Ez milyen ötlet? Mi a state matching?

 Az amit csinalsz Te is (-m state --state ...) csak epp az udp protokolra.

Lehet, hogy lemaradtam valmirol, de nem arrol volt szo, hogy az udp 
stateless protokoll?

--
sZs
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables ismerkedés

[Gábor Lénárt]

Re,

On Wed, Feb 13, 2008 at 06:31:20PM +0100, Gádori Zsolt wrote:
 $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
 Mer' ugye itt most csak a státust adtam meg a protokollt nem. Akkor
 most jól gondolom, hogy a fenti sor mindkét (pontosabban az összes)
 protokollra és az össze portra megoldja a feladatot?
 Vagyis egmagában egyenértékű az alábbi két sorral:
 
 #tcp
 $IPTABLES -A INPUT -p tcp --dport 0:65535 -m state --state
 ESTABLISHED,RELATED -j ACCEPT
 
 #udp
 $IPTABLES -A INPUT -p udp --dport 0:65535 -m state --state
 ESTABLISHED,RELATED  -j ACCEPT
 
 Jól gondolom?

Elvileg jol, sot icmp-re is, mert ugye annak sincs allapota de pl hasonloan az
udp-hez ha pl nyomsz egy icmp echo request-et egy cim fele (nepies neven
ping) akkor a valasz is vissza lesz engedve automatice. Csak most arra
vigyazzunk, nehogy osszekeverdjen az info: persze icmp nem feltetlen csak
pingelesre jo, pl RELATED statusban elofordul bizonyos pl tcp kapcsolat
eseten is, ami fontos uzentet hordoz, es nem illik kizarni ...

-- 
- Gábor
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables ismerkedés

[Gádori Zsolt]

előző levél:
---
Mon, 11 Feb 2008 18:57:19 +0100 BORBELY Zoltan
Re: iptables ismerkedés
---
   Sziasztok!
 
 On Mon, Feb 11, 2008 at 06:36:01PM +0100, Gádori Zsolt wrote:
  $IPTABLES -A INPUT -p udp --sport 53 -j ACCEPT
 
 En ilyet nem irnek, ilyenkor ugyanis a tamado az 53-as portrol
 a gepeden futo barmilyen udp szolgaltatast elerhet. A DNS valaszt
 teljesen jol lekezelheted a state matching-val.
 
Szia!
Igen, már mondták a kollégák is, hogy ez egy rossz megoldás. Ennek
következtében én arra gondoltam, hogy a szolgáltató IPcíméről engedem
csak be ezeket a csomagokat. Ez milyen ötlet? Mi a state matching?
Köszi:
Zs.
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables ismerkedés

[Gádori Zsolt]

előző levél:
---
Mon, 11 Feb 2008 19:02:36 +0100 Gábor Lénárt
Re: iptables ismerkedés
---
 
 Ok, de ez amit megadtal ez azt mondja, hogy elfogadsz BARMILYEN udp
 csomagot ha a forrasport 53-as. Tehat en akar (udp) portscannelhetlek
 is teged, ha forrasportkent 53-at mondok, de nem fogod megallitani. A
 lenyeg pont az lenne, amit mar irtam, hogy annak ellenere, hogy az
 udp nem kapcsolatorientalt protokoll nemileg nagyobb biztonsagot ad,
 ha kihasznalod azt a tenyt, hogy a netfilter kvazi udp-re is kezel
 NEW/ESTABLISHED allapotot bar nem kozvetlen olyan lepesek alapjan
 mint a TCP kapcsolatfelvetel stb, persze.
 
 Mert ugye kerdes az mi az elsodleges celod, eltuntetni a zavaro
 uzeneteket, vagy lehetoleg jol (vagyishat jobban) megcsinalni :)
 

Természetesen az a célom, hogy normális tűzfalat faragjak magamnak, 
meg hogy megtanuljam hogy is műXik mindez.
Te két szabályt küldtél ami logol. Nem vágom, az miért segít a
hibakeresésen túl, ha tudom, hogy mit dobok el.

Zs. 


_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables ismerkedés

[Gábor Lénárt]

Re,

On Mon, Feb 11, 2008 at 06:36:01PM +0100, Gádori Zsolt wrote:
 $IPTABLES -A INPUT -p udp --sport 53 -j ACCEPT
 $IPTABLES -A OUTPUT -p udp --dport 53 -j ACCEPT
 
 parancsok, egyből megszűnt a log áradat. Legalábbis a portokból erre
 következtetek, remélem nem lesz meglepetés.

Ok, de ez amit megadtal ez azt mondja, hogy elfogadsz BARMILYEN udp csomagot
ha a forrasport 53-as. Tehat en akar (udp) portscannelhetlek is teged, ha
forrasportkent 53-at mondok, de nem fogod megallitani. A lenyeg pont az
lenne, amit mar irtam, hogy annak ellenere, hogy az udp nem
kapcsolatorientalt protokoll nemileg nagyobb biztonsagot ad, ha kihasznalod
azt a tenyt, hogy a netfilter kvazi udp-re is kezel NEW/ESTABLISHED
allapotot bar nem kozvetlen olyan lepesek alapjan mint a TCP
kapcsolatfelvetel stb, persze.

Mert ugye kerdes az mi az elsodleges celod, eltuntetni a zavaro
uzeneteket, vagy lehetoleg jol (vagyishat jobban) megcsinalni :)


-- 
- Gábor
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables ismerkedés

[BORBELY Zoltan]

Sziasztok!

On Mon, Feb 11, 2008 at 06:36:01PM +0100, Gádori Zsolt wrote:
 $IPTABLES -A INPUT -p udp --sport 53 -j ACCEPT

En ilyet nem irnek, ilyenkor ugyanis a tamado az 53-as portrol
a gepeden futo barmilyen udp szolgaltatast elerhet. A DNS valaszt
teljesen jol lekezelheted a state matching-val.

Udv
Bozo
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables ismerkedés

[Gádori Zsolt]

Szia!

Megfejtettem, hogy mi volt az a rengeteg üzenet. A DNS szerver próbált
kommunikálni valami külső szerverrel. Amint elhangzottak a

$IPTABLES -A INPUT -p udp --sport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --dport 53 -j ACCEPT

parancsok, egyből megszűnt a log áradat. Legalábbis a portokból erre
következtetek, remélem nem lesz meglepetés.

Köszi:
Zs.

előző levél:
---
Sun, 10 Feb 2008 15:42:20 +0100 Gábor Lénárt
Re: iptables ismerkedés
---
 Hi,
 
 On Sat, Feb 09, 2008 at 12:22:05PM +0100, Gádori Zsolt wrote:
  Megfaragtam (?) életem első tűzfalát. Most az volna a kérésem, hogy
  akinek van kedve olvassa át a kódot. A végén lenne egy kérdésem, meg
  persze kíváncsi volnék minden szakmai tanácsra is. Próbáltam
  kommentezni hogy mi volt a szándékom egy adott paranccsal.
 [...] 
  A kérdés pedig a következő:
  Mi okozza a logban az alábbi bejegyzést?
  
  Feb  9 12:01:46 server kernel: tiltott protokoll be IN=ppp0 OUT=
  MAC= SRC=IPcím DST=IPcím LEN=142 TOS=0x00 PREC=0x00 TTL=123
  ID=50676 PROTO=UDP SPT=18168 DPT=39872 LEN=122
 
 Esetleg az, hogy az UDP ugyan nem kapcsolatorientalt, ennek ellenere a
 netfilter nemi conntrack infot probal felepiteni a rendelkezesre allo
 adatokbol (pl; cel/forras IP cel/forras port), itt meg ez esetleg egy
 conntrack szempontjabol NEW allapotunak van minositve. A RELATED es
 ESTABLISHED dolgokat beengeded, de a NEW-t nem, gondolom azert.
 Esetleg a fenti szabaly ele:
 
 $IPTABLES -A INPUT -m state --state NEW -j LOG \
   --log-prefix Uj allapotu kapcsolat 
 $IPTABLES -A INPUT -m state --state INVALID -j LOG \
   --log-prefix Invalidall apotu kapcsolat 
 
 (az INVALID is jol johet esetleg)
 
 Ugye, NEW allapotra nezel dolgot az eleje fele, csakhogy az mind
 TCP-vel kapcsolatos dolog, de az UDP az meg nem TCP (sot az ICMP sem
 pl ...).
 


_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

iptables ismerkedés

[Gádori Zsolt]

Tisztelt listatagok!

Megfaragtam (?) életem első tűzfalát. Most az volna a kérésem, hogy
akinek van kedve olvassa át a kódot. A végén lenne egy kérdésem, meg
persze kíváncsi volnék minden szakmai tanácsra is. Próbáltam
kommentezni hogy mi volt a szándékom egy adott paranccsal.

a kód:
***
#!/bin/sh

CSATOLO=eth0
IPTABLES=/sbin/iptables

#minden eddigi szabály kukába
$IPTABLES --flush

#ha semmire sem illeszkedik akkor kuka
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP

#a loopback interafcen mindent lehet
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

# == BEMENET =
echo
echo tiltott címek

#kintről nem jöhetnek belső hálózati címek
$IPTABLES -A INPUT -i $CSATOLO -s 0.0.0.0/8 -j DROP
$IPTABLES -A INPUT -i $CSATOLO -s 10.0.0.0/8 -j DROP
$IPTABLES -A INPUT -i $CSATOLO -s 127.0.0.0/8 -j DROP
$IPTABLES -A INPUT -i $CSATOLO -s 172.16.0.0/12 -j DROP
$IPTABLES -A INPUT -i $CSATOLO -s 192.168.0.0/16 -j DROP
$IPTABLES -A INPUT -i $CSATOLO -s 208.13.201.2 -j DROP
$IPTABLES -A INPUT -i $CSATOLO -s 255.0.0.0/8 -j DROP

echo nem szabályos kapcsolat

#nem szabályos kapcsolatkezdeményezés
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG
--log-prefix letapogatási kísérlet? $IPTABLES -A INPUT -p tcp ! --syn
-m state --state NEW -j DROP

echo szabályos kapcsolat be

#korábban engedélyezett kapcsolatokból származó bejövő kapcsolatok
#elfogadása
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#tcp
$IPTABLES -A INPUT -p tcp --dport 0:65535 -m state --state
ESTABLISHED,RELATED -j ACCEPT

#udp
$IPTABLES -A INPUT -p udp --dport 0:65535 -m state --state
ESTABLISHED,RELATED  -j ACCEPT

#ami nem stimmel naplózni
$IPTABLES -A INPUT -j LOG --log-prefix tiltott protokoll be 

echo szabályos kapcsolat ki

# == KIMENET =

#jóváhagyott kapcsolat kimehet
$IPTABLES -I OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#ping kezdeményezés
$IPTABLES -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT

#tcp
$IPTABLES -A OUTPUT -p udp --dport 0:65535 -m state --state NEW -j
ACCEPT

#udp
$IPTABLES -A OUTPUT -p tcp --dport 0:65535 -m state --state NEW  -j
ACCEPT

#ami nem stimmel naplózni
$IPTABLES -A OUTPUT -j LOG --log-prefix tiltott protokoll ki 

echo IP maszkolás

#IP maszkolás
$IPTABLES -t nat -A POSTROUTING -o $CSATOLO -j MASQUERADE
***

A kérdés pedig a következő:
Mi okozza a logban az alábbi bejegyzést?

Feb  9 12:01:46 server kernel: tiltott protokoll be IN=ppp0 OUT= MAC=
SRC=IPcím DST=IPcím LEN=142 TOS=0x00 PREC=0x00 TTL=123
ID=50676 PROTO=UDP SPT=18168 DPT=39872 LEN=122

Persze tudom, hogy melyik sor szól be, csak azt nem, hogy mit akadályoz
meg, mert minden működik amit próbáltam.

Köszönettel:
Zs.
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables ismerkedés

[Attila SZALAY]

Gádori Zsolt wrote:
 Megfaragtam (?) életem első tűzfalát. Most az volna a kérésem, hogy
 akinek van kedve olvassa át a kódot. A végén lenne egy kérdésem, meg
 persze kíváncsi volnék minden szakmai tanácsra is. Próbáltam
 kommentezni hogy mi volt a szándékom egy adott paranccsal.
 #udp
 $IPTABLES -A INPUT -p udp --dport 0:65535 -m state --state
 ESTABLISHED,RELATED  -j ACCEPT

 Feb  9 12:01:46 server kernel: tiltott protokoll be IN=ppp0 OUT= MAC=
 SRC=IPcím DST=IPcím LEN=142 TOS=0x00 PREC=0x00 TTL=123
 ID=50676 PROTO=UDP SPT=18168 DPT=39872 LEN=122
az udp nem stateless protocol?

was


_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables faq volt:Re: 8000-e s port engedélyezése iptables-ben

[Fried Zoltan]

gt;csinál. Nagyjából értem is, de még mindig fenn áll az a hiba, hogy
gt;bizonyos külső szolgáltatásokat nem lehet elérni.

gt;A szerver gond nélkül routolja a netet a belső hálóra, de néhány
gt;szolgáltatás időtúllépés miatt elérhetetlen. Ilyen például a külső
gt;POP3, SMTP szolgáltatás, illetve a https:// oldalak. A szerveren Squid

Szia,

ha jol latom ezek a szabalyok hianyoznak neked:

-A PREROUTING -i ppp0 -p tcp -m tcp --dport 25
-j DNAT --to-destination CEL_IP1
-A PREROUTING -i ppp0 -p tcp -m tcp --dport 110
-j DNAT --to-destination CEL_IP2
-A PREROUTING -i ppp0 -p tcp -m tcp --dport 443
-j DNAT --to-destination CEL_IP3
-A FORWARD -i ppp0 -d CEL_IP1 -p tcp -m tcp 
--dport 25 -j ACCEPT
-A FORWARD -i ppp0 -d CEL_IP2 -p tcp -m tcp 
--dport 110 -j ACCEPT
-A FORWARD -i ppp0 -d CEL_IP3 -p tcp -m tcp 
--dport 443 -j ACCEPT

es igy tovabb...

zoli


_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables faq volt:Re: 8000-e s port engedélyezése iptables-ben

[Ilk Balázs Ferenc]

Szia!
 ha jol latom ezek a szabalyok hianyoznak neked:

 -A PREROUTING -i ppp0 -p tcp -m tcp --dport 25
 -j DNAT --to-destination CEL_IP1
 ...
 -A FORWARD -i ppp0 -d CEL_IP1 -p tcp -m tcp
 --dport 25 -j ACCEPT

Ezek szerint nekem fel kell vennem külön-külön az összes megnyitni és
használni kívánt smtp, pop3, https:// stb. szervereket? Erre nincs
valami átfogó megoldás?

Köszi:
Bazsi
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables faq volt:Re: 8000-e s port engedélyezése iptables-ben

[Ilk Balázs Ferenc]

Bocsi, most olvastam, mekkora marhaságot kérdeztem... A FORWARD láncon
simán kihagyom a destination IP-t :)

Remélem működni fog, ma du. kipróbálom!

Bazsi
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables faq volt:Re: 8000-e s port engedélyezése iptables-ben

[Ilk Balázs Ferenc]

Szia!

Átnéztem az ajánlott IPtables leírást, próbáltam megérteni, de azt
hiszem túlnő rajtam a feladat.

Az Easy Firewall Generator-ral készítettem egy scriptet, ami elvileg
megfelelne az igényeimnek, és ezt igyekeztem is megérteni, hogy mit is
csinál. Nagyjából értem is, de még mindig fenn áll az a hiba, hogy
bizonyos külső szolgáltatásokat nem lehet elérni.

A szerver gond nélkül routolja a netet a belső hálóra, de néhány
szolgáltatás időtúllépés miatt elérhetetlen. Ilyen például a külső
POP3, SMTP szolgáltatás, illetve a https:// oldalak. A szerveren Squid
proxy fut transzparens módban, és csak a 80-as port forgalma van bele
irányítva.

Próbáltam azt is, hogy csak a route-olást állítottam be a NAT láncon
és az INPUT, FORWARD, OUTPUT láncon a default policy-t ACCEPT-re
állítottam, de így sem ment.

Merre keressem a megoldást? Az IPtables-ben vagy máshol van a hiba?
Nagyon megköszönném a segítséget, mert már leharapják a fejemet a
szüleim, mert enélkül nem megy a hálózat és egyenlőre minden még
bonyolultabb lett, mint volt a cégünknél

Most ez a konfig fájl, amit kiokoskodtam, módosítva néhol a EFG script-jét:

 # Generated by iptables-save v1.3.6 on Sun Nov 18 19:57:38 2007
 *filter
 :INPUT DROP [0:0]
 :FORWARD DROP [0:0]
 :OUTPUT DROP [0:0]
 :bad_packets - [0:0]
 :bad_tcp_packets - [0:0]
 :icmp_packets - [0:0]
 :tcp_inbound - [0:0]
 :tcp_outbound - [0:0]
 :udp_inbound - [0:0]
 :udp_outbound - [0:0]
 :syn_flood - [0:0]
 -A INPUT -i lo -j ACCEPT
 -A INPUT -j bad_packets
 -A bad_packets -i ppp0 -s 192.168.15.0/255.255.255.0 -j LOG --log-prefix 
 bad_packets: Inv.src.-DROP
 -A bad_packets -i ppp0 -s 192.168.15.0/255.255.255.0 -j DROP
 -A bad_packets -m state --state INVALID -j LOG --log-prefix bad_packets: 
 Inv. st.-DROP
 -A bad_packets -m state --state INVALID -j DROP
 -A bad_packets -p tcp -j bad_tcp_packets
 -A bad_tcp_packets -i eth1 -p tcp -j RETURN
 -A bad_tcp_packets -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state 
 --state NEW -j LOG --log-prefix bad_tcp_packets: sz=1-DROP
 -A bad_tcp_packets -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state 
 --state NEW -j DROP
 -A bad_tcp_packets -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j 
 LOG --log-prefix bad_tcp_packets: sz=2-DROP
 -A bad_tcp_packets -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j 
 DROP
 -A bad_tcp_packets -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG 
 FIN,SYN,RST,PSH,ACK,URG -j LOG --log-prefix bad_tcp_packets: sz=3-DROP
 -A bad_tcp_packets -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG 
 FIN,SYN,RST,PSH,ACK,URG -j DROP
 -A bad_tcp_packets -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG 
 FIN,PSH,URG -j LOG --log-prefix bad_tcp_packets: sz=4-DROP
 -A bad_tcp_packets -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG 
 FIN,PSH,URG -j DROP
 -A bad_tcp_packets -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG 
 FIN,SYN,RST,ACK,URG -j LOG --log-prefix bad_tcp_packets: sz=5-DROP
 -A bad_tcp_packets -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG 
 FIN,SYN,RST,ACK,URG -j DROP
 -A bad_tcp_packets -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j LOG 
 --log-prefix bad_tcp_packets: sz=6-DROP
 -A bad_tcp_packets -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
 -A bad_tcp_packets -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j LOG 
 --log-prefix bad_tcp_packets: sz=7-DROP
 -A bad_tcp_packets -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
 -A INPUT -i ppp0 -p tcp -m tcp --tcp-flags SYN SYN -j syn_flood
 -A syn_flood -j LOG --log-prefix syn_flood: SYN_flood detected
 -A syn_flood -m limit --limit 20/sec --limit-burst 4 -j RETURN
 -A syn_flood -j DROP
 -A INPUT -d 224.0.0.1 -j DROP
 -A INPUT -i eth1 -p tcp -d !192.168.15.1 -j FORWARD
 -A INPUT -i eth1 -p udp -d !192.168.15.1 -j FORWARD
 -A INPUT -i eth1 -s 192.168.15.0/255.255.255.0 -j ACCEPT
 -A INPUT -i eth1 -d 192.168.15.255 -j ACCEPT
 -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
 -A INPUT -i ppp0 -p tcp -j tcp_inbound
 -A tcp_inbound -p tcp -m tcp --dport 113 -j REJECT --reject-with 
 icmp-port-unreachable
 -A tcp_inbound -p tcp -m tcp --dport 5353 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --dport 80 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --dport 443 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --dport 1 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --dport 21 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --sport 20 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --dport 62000:64000 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --dport 25 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --dport 465 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --dport 110 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --dport 143 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --dport 995 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --dport 993 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --dport 22 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --dport 5000:5100 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --dport 6891:6900 -j ACCEPT
 -A tcp_inbound -p tcp -m tcp --dport 8000:8010 -j ACCEPT
 -A tcp_inbound -p tcp -j

Re: 8000-es port engedélyezése iptables-ben

[Ilk Balázs Ferenc]

Szia,

nagyon szépen köszönöm a segítséged. A mai nap folyamán letesztelem a
rendszert a beállításokkal.

Egyébként a script nagy részét az Easy Firewall Generatorral
készítettem és azt igyekeztem a saját igényeimnek megfelelően
finom-hangolni...

Még 1× nagyon szépen köszönöm a segítséged és ha elakadok, akkor
remélem még fordulhatok hozzád?!

Bazsi

-- 
Ilk Balázs Ferenc
egyetemi hallgató

Kaposvári Egyetem Gazdaságtudományi Kar
University of Kaposvár Faculty of Economic Science

Cím / Address: H-7627 Pécs, Avar u. 36.
Telefon / Phone: +36 (72) 224-917
Fax / Fax: +36 (72) 327-137
Mobil / Mobile:   +36 (30) 552-1432
E-mail / E-mail:  [EMAIL PROTECTED]

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: 8000-es port engedélyezése iptables-ben

[Ilk Balázs Ferenc]

Szia!

Ebben igazad van, hogy nem ismerem túl jól a programot, de igyekszem
megtanulni... Az igazság az, hogy a hétvégéig meg kellene oldani a
problémát, mert nagyon sürgős, hogy szüleim tudják használni a
programot. Utána lesz időm tanulni és ismerkedni a programmal és
könyebben is megértem a működését, ha látom a kész programot és tudom,
hogy mit csinál.

 iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to kulso ip cime
 Es a belso gep tud kommunikalni az internet barmely gepevel. Tovabb
 ugy finomitod, ahogy akarod. A legjobb amugy, ha MASQUERADE-t
 hasznalsz (man iptables).
Ez szerepel a konfigban...

Beillesztem a kész konfigomat, hogy lássátok, mi van benne és
könnyebben tudjatok segíteni.
A cél a következő lenne:
A belső hálózatról (192.168.15.0/24), vagy csak annak egyik gépéről
(192.168.15.4) tudjak csatlakozni az interneten lévő szerverhez, ami a
8000-es és 8010-es portokat használja kommunikációra. A szerver
ADSL-lel kapcsolódik a netre (ppp0) és fixIP címe van.

Akkor a konfig (iptables-save paranccsal mentve):
# Generated by iptables-save v1.3.6 on Thu Nov  8 19:18:43 2007
*filter
:INPUT DROP [92:16224]
:FORWARD DROP [0:0]
:OUTPUT DROP [30:7172]
:icmp_csomagok - [0:0]
:rossz_csomagok - [0:0]
:rossz_tcp_csomagok - [0:0]
:syn_flood - [0:0]
:tcp_bejovo_csomagok - [0:0]
:tcp_kimeno_csomagok - [0:0]
:udp_bejovo_csomagok - [0:0]
:udp_kimeno_csomagok - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -j rossz_csomagok
-A INPUT -i ppp0 -p tcp -m tcp --tcp-flags SYN SYN -j syn_flood
-A INPUT -s 192.168.15.0/255.255.255.0 -i eth1 -j ACCEPT
-A INPUT -s 192.168.15.255 -i eth1 -j ACCEPT
-A INPUT -i eth1 -p udp -m udp --sport 68 --dport 67 -j ACCEPT
-A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i ppp0 -p tcp -m tcp -j tcp_bejovo_csomagok
-A INPUT -i ppp0 -p udp -m udp -j udp_bejovo_csomagok
-A INPUT -i ppp0 -p icmp -j icmp_csomagok
-A INPUT -p tcp -m tcp -m limit --limit 1/min -j LOG
-A INPUT -p tcp -m tcp -m limit --limit 1/min -j DROP
-A INPUT -m limit --limit 3/min --limit-burst 3 -j LOG
-A FORWARD -j rossz_csomagok
-A FORWARD -i eth1 -p tcp -m tcp -j tcp_kimeno_csomagok
-A FORWARD -i eth1 -p udp -m udp -j udp_kimeno_csomagok
-A FORWARD -i eth1 -j ACCEPT
-A FORWARD -d 192.168.15.0/255.255.255.0 -i ppp0 -p tcp -m tcp -m
multiport --dports 8000,8010 -j ACCEPT
-A FORWARD -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m limit --limit 3/min --limit-burst 3 -j LOG
-A OUTPUT -p icmp -m state --state INVALID -j DROP
-A OUTPUT -s 127.0.0.1 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -s 192.168.15.1 -j ACCEPT
-A OUTPUT -o eth1 -j ACCEPT
-A OUTPUT -o ppp0 -j ACCEPT
-A OUTPUT -m limit --limit 3/min --limit-burst 3 -j LOG
-A icmp_csomagok -p icmp -f -j LOG
-A icmp_csomagok -p icmp -f -j DROP
-A icmp_csomagok -p icmp -m icmp --icmp-type 8 -j LOG
-A icmp_csomagok -i eth1 -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A icmp_csomagok -p icmp -m icmp --icmp-type 8 -j DROP
-A icmp_csomagok -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A icmp_csomagok -p icmp -j RETURN
-A rossz_csomagok -s 192.168.15.0/255.255.255.0 -i ppp0 -j LOG
-A rossz_csomagok -s 192.168.15.0/255.255.255.0 -i ppp0 -j DROP
-A rossz_csomagok -m state --state INVALID -j LOG
-A rossz_csomagok -m state --state INVALID -j DROP
-A rossz_csomagok -p tcp -m tcp -j rossz_tcp_csomagok
-A rossz_csomagok -j RETURN
-A rossz_tcp_csomagok -i eth1 -p tcp -m tcp -j RETURN
-A rossz_tcp_csomagok -i eth1 -p tcp -m tcp ! --tcp-flags SYN SYN -m
state --state NEW -j DROP
-A rossz_tcp_csomagok -p tcp -m tcp ! --tcp-flags SYN SYN -m state
--state NEW -j LOG
-A rossz_tcp_csomagok -p tcp -m tcp ! --tcp-flags SYN SYN -m state
--state NEW -j DROP
-A rossz_tcp_csomagok -p tcp -m tcp --tcp-flags
FIN,SYN,RST,PSH,ACK,URG NONE -j LOG
-A rossz_tcp_csomagok -p tcp -m tcp --tcp-flags
FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A rossz_tcp_csomagok -p tcp -m tcp --tcp-flags
FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j LOG
-A rossz_tcp_csomagok -p tcp -m tcp --tcp-flags
FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A rossz_tcp_csomagok -p tcp -m tcp --tcp-flags
FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j LOG
-A rossz_tcp_csomagok -p tcp -m tcp --tcp-flags
FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A rossz_tcp_csomagok -p tcp -m tcp --tcp-flags
FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j LOG
-A rossz_tcp_csomagok -p tcp -m tcp --tcp-flags
FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j DROP
-A rossz_tcp_csomagok -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j LOG
-A rossz_tcp_csomagok -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A rossz_tcp_csomagok -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j LOG
-A rossz_tcp_csomagok -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A rossz_tcp_csomagok -p tcp -m tcp -j RETURN
-A syn_flood -j LOG
-A syn_flood -m limit --limit 20/sec --limit-burst 4 -j RETURN
-A syn_flood -j DROP
-A tcp_bejovo_csomagok -p tcp -m tcp --dport 80 -j ACCEPT
-A tcp_bejovo_csomagok -p tcp -m tcp --dport 443 -j ACCEPT

Re: iptables faq volt:Re: 8000-e s port engedélyezése iptables-ben

[Ilk Balázs Ferenc]

Szia!

Köszi a választ. Ezt az oldalt nem olvastam, de ígérem átnézem...

Még 1× köszi!

Bazsi
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

iptables - portforward

[Otto Szilagyi]

Sziasztok

Segitsetek mert ez mar magas nekem :-)

Programozok és most megakadtam. 
A problémám a következő: szeretnék egy windows-os Web-et elérni kintröl a belső 
gépröl (Windows XP) és nem megy.
Portforward müködik mert az SQL server, RDP, vagy barmi mas müködik (tuzfalat 
az XP-röl kivettem) de ha Web-et forwardolok
nem megy. még a webes RDP (tsweb) is müködik a windows2003-an de a sima http 
nem :-(

a Debianrol siman ,megnyitom, a kérések pedig érkeznek a  szerverhez (iptraf-al 
nézem, meg Log-oltam az Iptables-t)
Probálkoztam a TCPDump-al de ez más sok nekem :-) magyarul nem tudom használni 
mit nézzek hogyan stb :-)

a 7111 es portot irányitom át a 192.168.0.21:80 -ra

iptables -A FORWARD -j ACCEPT -p tcp -s 0.0.0.0/0 --dport 7111
iptables -t nat -A PREROUTING -i $WAN_NIC -p tcp -s 0.0.0.0/0 --dport 7111 -j 
DNAT --to 192.168.0.21:80


a forward-logok ezt mutatják
Sep 24 13:50:23 otto kernel: IN=ppp0 OUT=eth0 SRC=77.101.66.222 
DST=192.168.0.21 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=55468 DF PROTO=TCP 
SPT=1451 DPT=80 WINDOW=25200 RES=0x00 SYN URGP=0
Sep 24 13:50:26 otto kernel: IN=ppp0 OUT=eth0 SRC=77.101.66.222 
DST=192.168.0.21 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=55486 DF PROTO=TCP 
SPT=1451 DPT=80 WINDOW=25200 RES=0x00 SYN URGP=0

(ezt ugy értelmezem hogy DROP-olta mert ha egy müködő forwardnal nem látok 
semmit a LOG-ba) csak azt nem értem miért.


A debian tuzfalat meg az pppd-t egy ismerős csinálta, (ugy nagy vonalakban 
értem is ,és eddig boldogultam is vele)
Magyarul ismereteim hiányosak ezen a téren. Próbálkozom megtanulni de talán 
segitséggel gyorsabban megy :-)

Azt nem értem hogy lehet hogy minden portforward-om müködik de a web-es nem. 
Mit csinálok rosszul vagy mit nem tudok ? :-)

Ja viszont nem tudom hogy köze lehet-e a dolgohoz de microsoft oldalakat nem 
tudok a belső gépekröl nézni, (nem mintha nagyon hiányozna ) eddig is volt pár 
ilyen oldal és akkor a srác azt monta állitsam át az MTU-t (mármint a 
windows-on). 
Mondjuk a syslog-ba mikor felmaszik a modem ezt látom és ezt nem tudom hogy 
tudom beállitani, lehet-e ez hiba...

23 otto named[987]: Err/TO getting serial# for e-ingatlanok.hu
52 otto pppd[12776]: No response to 3 echo-requests
52 otto pppd[12776]: Serial link appears to be disconnected.
52 otto pppd[12776]: Connect time 16742.8 minutes.
52 otto pppd[12776]: Sent 2195674468 bytes, received 3375644742 bytes.
52 otto pppd[12776]: Couldn't increase MTU to 1500
52 otto pppd[12776]: Couldn't increase MRU to 1500
58 otto pppd[12776]: Connection terminated.
58 otto pppd[12776]: Modem hangup
28 otto pppd[12776]: PPP session is 38
28 otto pppd[12776]: Using interface ppp0
28 otto pppd[12776]: Connect: ppp0 -- eth1
28 otto pppd[12776]: Couldn't increase MTU to 1500
28 otto pppd[12776]: Couldn't increase MRU to 1500
28 otto pppd[12776]: PAP authentication succeeded
28 otto pppd[12776]: peer from calling number 00:E0:81:5E:99:C3 authorized
28 otto pppd[12776]: Cannot determine ethernet address for proxy ARP
28 otto pppd[12776]: local  IP address 195.38.101.205
28 otto pppd[12776]: remote IP address 195.38.98.200




ADSL Modem  ---  ppp0 - eth1
   eth0    Wifi Router  
   - Windows xp  192.168.0.21

 - Windows 2003   192.168.0.100 (ezen müködik a /tsweb
   Debian Sarge
 
A router gondolom nem lehet, mert csak elosztónak használom és mikor 
változtatok portforwardot a routert nem piszkálom.

Remélem elég infót adtam hogy tudjatok segiteni.
   
Üdv
Otto







   

Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for 
today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow  
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

iptables - portforward

[Otto Szilagyi]

Elnézést, de kicsit féradt vagyok ést  elsőzör irok a levlistára.

de igaz, nem ezért nem muködik az portforward-om ?  :-)

u.i.
a viccet félretéve, ennek van most következménye ? (nem kapják meg a lista 
tagok, trash-be landolt,stb.) ?
Még 1xer elnézést.

Otto





   

Be a better Heartthrob. Get better relationship answers from someone who knows. 
Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=listsid=396545433
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables - portforward

[Mihaly Zachar]

Otto Szilagyi wrote:
 Sziasztok


 a 7111 es portot irányitom át a 192.168.0.21:80 -ra

 iptables -A FORWARD -j ACCEPT -p tcp -s 0.0.0.0/0 --dport 7111
 iptables -t nat -A PREROUTING -i $WAN_NIC -p tcp -s 0.0.0.0/0 --dport 7111 -j 
 DNAT --to 192.168.0.21:80


 a forward-logok ezt mutatják
 Sep 24 13:50:23 otto kernel: IN=ppp0 OUT=eth0 SRC=77.101.66.222 
 DST=192.168.0.21 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=55468 DF PROTO=TCP 
 SPT=1451 DPT=80 WINDOW=25200 RES=0x00 SYN URGP=0
 Sep 24 13:50:26 otto kernel: IN=ppp0 OUT=eth0 SRC=77.101.66.222 
 DST=192.168.0.21 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=55486 DF PROTO=TCP 
 SPT=1451 DPT=80 WINDOW=25200 RES=0x00 SYN URGP=0
   

probald ki, hogy:

iptables -A FORWARD -j ACCEPT -p tcp -s 0.0.0.0/0 --dport 80


mert a prerouting lanc utan mar a dest port at van irva 80-ra


udv
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables - portforward

[Otto Szilagyi]

Siker ! Müködik...

Köszönöm. 
(mondjuk csak azt nem értem hogy a többi portforward miért ment/megy ?) 
de mindegy... a lányeg hogy mostmár ma este nyugodtan kialszom magam. :-)

majd megpróblom ezt megfejteni magamtól mert mostmár nagyon érdekel (ha már 
ennyi időt foglakoztam vele )

Még 1xer köszönöm. 

Üdv
 


- Original Message 
From: Mihaly Zachar [EMAIL PROTECTED]
To: Linux kérdések/válaszok linux@mlf.linux.rulez.org
Sent: Monday, September 24, 2007 5:36:21 PM
Subject: Re: iptables - portforward

Otto Szilagyi wrote:
 Sziasztok


 a 7111 es portot irányitom át a 192.168.0.21:80 -ra

 iptables -A FORWARD -j ACCEPT -p tcp -s 0.0.0.0/0 --dport 7111
 iptables -t nat -A PREROUTING -i $WAN_NIC -p tcp -s 0.0.0.0/0 --dport 7111 -j 
 DNAT --to 192.168.0.21:80


 a forward-logok ezt mutatják
 Sep 24 13:50:23 otto kernel: IN=ppp0 OUT=eth0 SRC=77.101.66.222 
 DST=192.168.0.21 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=55468 DF PROTO=TCP 
 SPT=1451 DPT=80 WINDOW=25200 RES=0x00 SYN URGP=0
 Sep 24 13:50:26 otto kernel: IN=ppp0 OUT=eth0 SRC=77.101.66.222 
 DST=192.168.0.21 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=55486 DF PROTO=TCP 
 SPT=1451 DPT=80 WINDOW=25200 RES=0x00 SYN URGP=0
   

probald ki, hogy:

iptables -A FORWARD -j ACCEPT -p tcp -s 0.0.0.0/0 --dport 80


mert a prerouting lanc utan mar a dest port at van irva 80-ra


udv
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux





  

Shape Yahoo! in your own image.  Join our Network Research Panel today!   
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 


_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: ftp es iptables nat

[Fried Zoltan]

Ezek szerint nem mennek keresztul ezek a csomagok az eth0-n ??
Csak azert kerdezem, mert a tcpdump mutat forgalmat ott is, habar most nem 
remlik hogy melyek is voltak azok.
akkor ezt hetvegen kimerem, aztan meglatjuk.

gt;a -o kapcsolo arra az interfeszre illeszkedik, ahol el fogja hagyni a 
gt;csomag a geped, ez mar akkor eldol, amikor megkapod a csomagot (a 
gt;PREROUTING lanc utan, de meg az INPUT vagy a FORWARD lanc elott)

es ez mitol fugg? mondjuk a forward nem erinti az eth0-t a output meg igen?
most itt ebben az esetben ha van ppp0 is, mert mint fent irtam az eth0 nem 
teljesen suket.

gt;tehat a -o eth0 a netre kuldott csomagokra nem illeszkedik, mert a 
gt;ppp0-n fogjak ezek a csomagok elhagyni a geped, ezert nem volt 
gt;jelentosege a -o eth0-s szabaly a szabalyaid kozott a _netre_ kimeno 
gt;csomagokra (szerintem)...
ez eddig sem volt kerdes, csak azt nem ertem 
miert erinti vagy nem es mitol fuggott ez?
mert miutam bekerult a szabaly es mukodott, megertettem hogy nem illeszkedett.


ezek miatt eszembe sem jutott, hogy a tcpmss miatt nem mukodik, es teljesen mas 
problemara gondoltam :(

Zoli







_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: ftp es iptables nat

[Kosa Attila]

On Wed, Jul 04, 2007 at 11:19:11PM +0200, Fried Zoltan wrote:
 Egy furcsak kerdesem volna hozzatok. Volt egy problemam a 
 cimbeli parossal, de megoldodott. A leveliras kozben rajottem
 mi javitotta meg, de pontosan nem ertem.

Es szerinted mi javitotta meg?

 A szitu: van ket linux, mintketto gyari etch. 
 az egyik natol az inet fele legyen a neve gepnat. 
 a masik nem, legyen a neve gepkliens. a gepkliensen 
 kiadok egy apt-get update parancsot, aminek a 
 configjaban (sources.list) egy ftp cim van megadva. 
 (ftp://ftp.hu.debian.org). A jelenseg az volt, 
 hogy a letoltes elindult, a monitor szerint 1-3% 
 utan megalt, es nem ment tovabb. ue a parancs 
 a gepnat gepen ue. configgal mukodott. Ha a 
 gepkliensen az ftp-s cimet egy http-s cimre 
 helyetesitem minden mukodik. A gepnatos gepen van 

A monitor hazudik :) Szerintem pusztan arrol van szo, hogy az
ftp nem mukodik. Az a linux-kezdo listara valo, hogy mi a
kulonbseg a http es a ftp mukodese kozott...

 tuzfal a masikon nincs. a tcpdump szerint a csomagok 
 elhagytak a gepnat ppp0 halokartyajat, de mindtha nem 
 jonne valasz. legalabbis a tcpdump szerint. a 
 logokban semmi olyan ami arra utalna hogy a 
 tuzfal blokkolna valamit.

Toltsd be az ip_conntrack_ftp es az ip_nat_ftp modulokat, es
mukodni fog.

 A megoldas a lenti ket sor kulonbsegeben van.

Ha a fenti modulok megis be voltak toltve, akkor meg a forward
agon nem engedted at a csomagokat, azert nem ment a dolog. De
ennek ellentmond az, hogy a http mukodott...

 Ahogy latom a lenyegi resz az interfeszben van.
 Amikor nem mukodik, a forward sor hianyzik.
 
 -t mangle -A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN 
  -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu
 -t mangle -A POSTROUTING -o eth0 -p tcp -m tcp --tcp-flags 
   SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Szerintem semmi koze ehhez.

-- 
Udvozlettel
Zsiga
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: ftp es iptables nat

[Szládovics Péter]

Kosa Attila írta:
 On Wed, Jul 04, 2007 at 11:19:11PM +0200, Fried Zoltan wrote:
 A megoldas a lenti ket sor kulonbsegeben van.
 Ha a fenti modulok megis be voltak toltve, akkor meg a forward
 agon nem engedted at a csomagokat, azert nem ment a dolog. De
 ennek ellentmond az, hogy a http mukodott...

Ha van pl. transzparens proxy, akkor a http működhet jól, és az ftp meg
lehet rossz.
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: ftp es iptables nat

[Fried Zoltan]

Bocs, lehet hogy nem voltam egyertelmu, a modulok be voltak toltve,
a http mukodott, a monitor tenylet hazudott, ami kesobb le is esett.
A kerdesem inkabb az volt a hibabol levont konkluzio alapjan, hogy
mi a kulonbseg az eth0 es az adsl ppp0 interfaceja kozott a 
csomagszures es csomagkezeles tekinteteben, 
ha az eth0-s iface-hoz van kotve a ppp0.
mert  ez okozta nalam a kavarodast. Tegnap teszteltem. 
A tcpmss-t en az eth0ra kotottem, de
csak akkor mukododtt az ftp amikor a ppp0-ra is rakerult a tcpmss.
Merre jarnak a csomagok, amikor kikuldom az inetre oket, 
mi tortenik es mi nem az eth0-s inteface-en a csomagokkal.

Zoli





_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: ftp es iptables nat

[Kosa Attila]

On Thu, Jul 05, 2007 at 10:50:13AM +0200, Fried Zoltan wrote:
 Bocs, lehet hogy nem voltam egyertelmu, a modulok be voltak toltve,

Szerintem nem voltal :)

 Merre jarnak a csomagok, amikor kikuldom az inetre oket, 
 mi tortenik es mi nem az eth0-s inteface-en a csomagokkal.

tcpdump segitsegevel tudod ellenorizni, hogy merre jarnak a
csomagjaid.

-- 
Udvozlettel
Zsiga
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: ftp es iptables nat

[Mihaly Zachar]

Fried Zoltan wrote:
 Merre jarnak a csomagok, amikor kikuldom az inetre oket, 
 mi tortenik es mi nem az eth0-s inteface-en a csomagokkal.
   

a -o kapcsolo arra az interfeszre illeszkedik, ahol el fogja hagyni a 
csomag a geped, ez mar akkor eldol, amikor megkapod a csomagot (a 
PREROUTING lanc utan, de meg az INPUT vagy a FORWARD lanc elott)

tehat a -o eth0 a netre kuldott csomagokra nem illeszkedik, mert a 
ppp0-n fogjak ezek a csomagok elhagyni a geped, ezert nem volt 
jelentosege a -o eth0-s szabaly a szabalyaid kozott a _netre_ kimeno 
csomagokra (szerintem)...

de, hogy megbizonyosodj, logold le a csomagokat a a POSTROUTING lancban, 
ugyanazokkal a feltetelekkel...
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

ftp es iptables nat

[Fried Zoltan]

Sziasztok,
Egy furcsak kerdesem volna hozzatok. Volt egy problemam a 
cimbeli parossal, de megoldodott. A leveliras kozben rajottem
mi javitotta meg, de pontosan nem ertem.
Szeretnek segitsegek kerni abban hogy mi javitotta meg.
A szitu: van ket linux, mintketto gyari etch. 
az egyik natol az inet fele legyen a neve gepnat. 
a masik nem, legyen a neve gepkliens. a gepkliensen 
kiadok egy apt-get update parancsot, aminek a 
configjaban (sources.list) egy ftp cim van megadva. 
(ftp://ftp.hu.debian.org). A jelenseg az volt, 
hogy a letoltes elindult, a monitor szerint 1-3% 
utan megalt, es nem ment tovabb. ue a parancs 
a gepnat gepen ue. configgal mukodott. Ha a 
gepkliensen az ftp-s cimet egy http-s cimre 
helyetesitem minden mukodik. A gepnatos gepen van 
tuzfal a masikon nincs. a tcpdump szerint a csomagok 
elhagytak a gepnat ppp0 halokartyajat, de mindtha nem 
jonne valasz. legalabbis a tcpdump szerint. a 
logokban semmi olyan ami arra utalna hogy a 
tuzfal blokkolna valamit.
A megoldas a lenti ket sor kulonbsegeben van.
Ahogy latom a lenyegi resz az interfeszben van.
Amikor nem mukodik, a forward sor hianyzik.

-t mangle -A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN 
 -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu
-t mangle -A POSTROUTING -o eth0 -p tcp -m tcp --tcp-flags 
  SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Szeretnem megkerdezni, hogy mi az. Azon kivul hogy az egyik eth0 a masik ppp0.
Eddig ugy gondoltam, hogy a natolt csomagok atmennek az itt eth0-s 
interfeszen es utanna kerulnek ra a ppp0-ra. Esetleg rosszul gondolom ?
Hogy is mukodik most ez ebben az esetben? Merre jarnak a ilyakor a csomagok ?

Koszi a segitseget.
Zoli



_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

iptables

[Hóbor István]

Sziasztok!
Van egy szerver fedora core5-tel, de nem tudm hogyan kell beállítani az 
iptables szabályokat úgy, hogy a belhálóra (eth1-en , ip 192.168.1.52, 
dhcp-vel kapott) ne blokkoljon szolgáltatást, de kifelé (eth0 -n ,ip 
195.199.93.xxx) viszont a httpd 80 as,  443 -as és az ssh 22 -es portján 
kívül ne engedjen be semmit, és legyenek rejtettek a portok. Véleménytek 
szerint ezt hogyan lehet kivitelezni?

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables

[Gábor Lénárt]

On Fri, Jan 26, 2007 at 05:02:39PM +0100, Hóbor István wrote:
 Van egy szerver fedora core5-tel, de nem tudm hogyan kell beállítani az 
 iptables szabályokat úgy, hogy a belhálóra (eth1-en , ip 192.168.1.52, 
 dhcp-vel kapott) ne blokkoljon szolgáltatást, de kifelé (eth0 -n ,ip 
 195.199.93.xxx) viszont a httpd 80 as,  443 -as és az ssh 22 -es portján 
 kívül ne engedjen be semmit, és legyenek rejtettek a portok. Véleménytek 
 szerint ezt hogyan lehet kivitelezni?

Hat ha halokartyatol fugg, akkor ugye jelen esetben az iptables -i
kapcsolojat erdemes tanulmanyozni, lasd man iptables. Ezzek meg tudod
hatarozni hogy az adott szabaly melyik inteface-en bejovo csomagokra
vonatkozzon.

-- 
- Gábor
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables

[Hóbor István]

Gábor Lénárt írta:
 On Fri, Jan 26, 2007 at 05:02:39PM +0100, Hóbor István wrote:
   
 Van egy szerver fedora core5-tel, de nem tudm hogyan kell beállítani az 
 iptables szabályokat úgy, hogy a belhálóra (eth1-en , ip 192.168.1.52, 
 dhcp-vel kapott) ne blokkoljon szolgáltatást, de kifelé (eth0 -n ,ip 
 195.199.93.xxx) viszont a httpd 80 as,  443 -as és az ssh 22 -es portján 
 kívül ne engedjen be semmit, és legyenek rejtettek a portok. Véleménytek 
 szerint ezt hogyan lehet kivitelezni?
 

 Hat ha halokartyatol fugg, akkor ugye jelen esetben az iptables -i
 kapcsolojat erdemes tanulmanyozni, lasd man iptables. Ezzek meg tudod
 hatarozni hogy az adott szabaly melyik inteface-en bejovo csomagokra
 vonatkozzon.

   
[EMAIL PROTECTED] /]# iptables -i
iptables v1.3.5: Unknown arg `-i'
Try `iptables -h' or 'iptables --help' for more information.

Ez nem sikerült...
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables

[Fried Zoltan]

 Van egy szerver fedora core5-tel, de nem tudm hogyan kell beállítani az
 iptables szabályokat úgy, hogy a belhálóra (eth1-en , ip 192.168.1.52,
 dhcp-vel kapott) ne blokkoljon szolgáltatást, de kifelé (eth0 -n ,ip 
 195.199.93.xxx) viszont a httpd 80 as,  443 -as és az ssh 22 -es portján
 kívül ne engedjen be semmit, és legyenek rejtettek a portok. Véleménytek
 szerint ezt hogyan lehet kivitelezni?

Kb igy nezne ki egy script arra amit kertel.
Pl. pontosan a
http://iptables-tutorial.frozentux.net/iptables-tutorial.html -ban van
leirva minden.

Zoli

#!/bin/sh

echo Firewall start ...
PATH=/sbin:/bin:/usr/sbin:/usr/bin

test -x /sbin/iptables || exit 0
IPTABLES=/sbin/iptables

echo Setting kernel variables ...

# ha kell
# echo 1  /proc/sys/net/ipv4/ip_forward
# echo 1  /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

BAD_IFACE='eth0'
BAD_IP=195.199.93.xxx/255.255.255.yyy

GOOD_IFACE='eth1'
GOOD_ADDR=192.168.1.0/24
GOOD_IP=192.168.1.52

echo Create policies ...
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP

echo Flush and delete all rules ...
for table in mangle nat filter; do
iptables -t $table -F
iptables -t $table -X
iptables -t $table -Z
done

$IPTABLES -N stateful

# stateful
echo ... stateful ...
$IPTABLES -A stateful -m state --state RELATED,ESTABLISHED -j ACCEPT

$IPTABLES -A INPUT -i lo -j ACCEPT

$IPTABLES -A INPUT -j stateful
$IPTABLES -A INPUT -i $GOOD_IFACE -p {tcp/udp/icmp/...} --dport
   {portszam} -j ACCEPT
$IPTABLES -A INPUT -i $BAD_IFACE  -p tcp --dport 80 -j ACCEPT
$IPTABLES -A INPUT -i $BAD_IFACE  -p tcp --dport 443 -j ACCEPT
$IPTABLES -A INPUT -i $BAD_IFACE  -p tcp --dport 22 -j ACCEPT
$IPTABLES -A INPUT -j LOG --log-prefix INPUT drop: 
   --log-tcp-sequence --log-tcp-options --log-ip-options
$IPTABLES -A INPUT -j DROP

$IPTABLES -A FORWARD -j ACCEPT

$IPTABLES -A OUTPUT -j ACCEPT



_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables

[Gábor Lénárt]

On Fri, Jan 26, 2007 at 05:21:58PM +0100, Hóbor István wrote:
 iptables v1.3.5: Unknown arg `-i'
 Try `iptables -h' or 'iptables --help' for more information.
 
 Ez nem sikerült...

Ize :) Ez az '-i' termeszetesen nem magaban hasznalando, hanem sok mas
dologgal egyutt, ami maga leirja a szabalyt, stb. Ha a kerdes ilyen szintu,
akkor elobb egy iptables howto-t olvass el, mert anelkul nehez valaszolni
kerdesedre. Nade hogy segitsek, itt van egy pelda;

iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT

Ez az INPUT chain-hez hozzaad egy szabalyt ami azt mondja hogy fogadd el a
csomagot (ACCEPT) abban az esetben ha az az eth0 nic-en jon be, es celport
tcp/22 (ez ssh szokott lenni altalaban).

-- 
- Gábor
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables

[Szabo Istvan]

  Hat ha halokartyatol fugg, akkor ugye jelen esetben az iptables -i
  kapcsolojat erdemes tanulmanyozni, lasd man iptables. Ezzek meg tudod
  hatarozni hogy az adott szabaly melyik inteface-en bejovo csomagokra
  vonatkozzon.
 
 [EMAIL PROTECTED] /]# iptables -i
 iptables v1.3.5: Unknown arg `-i'
 Try `iptables -h' or 'iptables --help' for more information.

 Ez nem sikerült...

Ajánlott elolvasni/utánanézni, hogy hogyan használjuk az iptables-t, ezen
a listán szerintem a Te kérdésed nem kérdés (nem megbántani akarlak).

A hibaüzenet elejéből:
iptables -h

Vagy magyarul:
http://www.szabilinux.hu/iptables/chapter7.html

Itt olvashatsz a -i kapcsolóról is.

Sok sikert!

-- 
  (O__--
  //\   /  Varosi Csokonai Konyvtar
 //  ) |   Tel.: 59/503-152
 V__/_[EMAIL PROTECTED]   \  [EMAIL PROTECTED]

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables

[BORBELY Zoltan]

Sziasztok!

On Fri, Jan 26, 2007 at 05:02:39PM +0100, Hóbor István wrote:
 Van egy szerver fedora core5-tel, de nem tudm hogyan kell beállítani az 
 iptables szabályokat úgy, hogy a belhálóra (eth1-en , ip 192.168.1.52, 

A tobbiek mar megirtak, hogy hol talalsz doksit az iptables
hasznalatarol. fc5 eseten a szabalyokat a /etc/sysconfig/iptables
fajlba kell irni, es ha bootkor elindul az iptables akkor azt betolti.

Udv
Bozo
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables nat: se a masq, se a snat nem megy rendesen

[Mezei Zoltan]

On 12/4/06, Krusó Krisztián [EMAIL PROTECTED] wrote:
 sajnos jol van beallitva. Az eth0 az alapertelmezett kijarat,
 es arra is mennek. tcpdump mutatja is a csomagokat.

Nem toppostolunk.

Ha az eth0-n mennek ki a csomagok, es nem maszkolodnak, akkor a -s -s
192.168.0.0/16 feltetel lehet, hogy nem teljesul? Vagy esetleg egy
masik MASQUERADE szabaly elobb szerepel a POSTROUTING chainben, mint
ez, es illeszkedik a csomagokra? Mi az iptables -L -t nat -v -n
kimenete?
-- 
Zizi

- After all A. J. one does need to do something other than play World
of Warcraft.
- Um. Like what?
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

RE: iptables nat: se a masq, se a snat nem megy rendesen

[Krusó Krisztián]

A feltetel (192.168.0.0/16) teljesul, mert mas portok (22,25,110...)
elmaszkolodnak rendesen. A masquerade szabaly elott nincs semmilyen mas
szabaly. Ez benne az erdekes! Es egyaltalan nem ertem, hogy miert
nem maszkol bizonyos csomagokat.

Chris
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables nat: se a masq, se a snat nem megy rendesen

[Mezei Zoltan]

On 12/4/06, Krusó Krisztián [EMAIL PROTECTED] wrote:
 A feltetel (192.168.0.0/16) teljesul, mert mas portok (22,25,110...)
 elmaszkolodnak rendesen. A masquerade szabaly elott nincs semmilyen mas
 szabaly. Ez benne az erdekes! Es egyaltalan nem ertem, hogy miert
 nem maszkol bizonyos csomagokat.

Mi az iptables -L -t nat -v -n kimenete?
-- 
Zizi

- After all A. J. one does need to do something other than play World
of Warcraft.
- Um. Like what?
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

RE: iptables nat: se a masq, se a snat nem megy rendesen

[Krusó Krisztián]

Hello,


sajnos jol van beallitva. Az eth0 az alapertelmezett kijarat,
es arra is mennek. tcpdump mutatja is a csomagokat.


Chris

On 11/30/06, Krusó Krisztián [EMAIL PROTECTED] wrote:
 Egy szabaly: -s 192.168.0.0/16 -o eth0 -j MASQUERADE
 Ennek ellenere a legtobb olyan csomagot maszkolas nelkul
 atengedi, aminek: sport 1024:65535 és dport 1024:65535 tcp
 Kulon szabalyt betettem erre is, de alig nehanyat
 maszkol belole.

Lehet, hogy félreértelek, de az, hogy

-s 192.168.0.0/16 -o eth0

csak azt mondja, hogy az eth0-s interface-en megy ki a csomag, és a
forrása a 192.168.0.0/16-os alháló, a portok kapcsán semmit nem mond.
Szerintem nem a portokkal van itt gond, hanem az, hogy ezek a csomagok
nem az adott interface-en akarnak kimenni, és nem az adott alhálóból
jöttek.

Honnan-hova, melyik interface-eket érintve akarsz maszkolni?
-- 
Zizi

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables nat: se a masq, se a snat nem megy rendesen

[Mezei Zoltan]

On 11/30/06, Krusó Krisztián [EMAIL PROTECTED] wrote:
 Egy szabaly: -s 192.168.0.0/16 -o eth0 -j MASQUERADE
 Ennek ellenere a legtobb olyan csomagot maszkolas nelkul
 atengedi, aminek: sport 1024:65535 és dport 1024:65535 tcp
 Kulon szabalyt betettem erre is, de alig nehanyat
 maszkol belole.

Lehet, hogy félreértelek, de az, hogy

-s 192.168.0.0/16 -o eth0

csak azt mondja, hogy az eth0-s interface-en megy ki a csomag, és a
forrása a 192.168.0.0/16-os alháló, a portok kapcsán semmit nem mond.
Szerintem nem a portokkal van itt gond, hanem az, hogy ezek a csomagok
nem az adott interface-en akarnak kimenni, és nem az adott alhálóból
jöttek.

Honnan-hova, melyik interface-eket érintve akarsz maszkolni?
-- 
Zizi

- After all A. J. one does need to do something other than play World
of Warcraft.
- Um. Like what?
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

iptables nat: se a masq, se a snat nem megy rendesen

[Krusó Krisztián]

Sziasztok,

adott egy 2.6.18-as kernellel ellátott debian 3.1-es
szerver, iptables 1.3.6-tal.(forrásból fordítva)

A gond az, hogy a nat tablaban van jo par masquerade
es sajnos nem minden csomagra hasznalja.
Egy szabaly: -s 192.168.0.0/16 -o eth0 -j MASQUERADE
Ennek ellenere a legtobb olyan csomagot maszkolas nelkul
atengedi, aminek: sport 1024:65535 és dport 1024:65535 tcp
Kulon szabalyt betettem erre is, de alig nehanyat
maszkol belole. 
Probaltam azt is, hogy SNAT-tal megoldjam, de a helyzet
valtozatlan.
A MASQ-ok a legelsők a nat/postroutingban, tehat nincs elott
semmi ami kiengedje!

ip_conntrack_max 32000
ip_conntrack_buckets 32000
a valos ip_conntrack szam 6000 korul mozog.


Mit tudok tenni? Hol keressek?


Kossz mindenkinek!


Chris

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

iptables rules konvertalas shorewall rules-be

[Hose]

Sziasztok!

Van egy tuzfalszabaly file (iptables-save) hoogy lehet shorewall rules 
fajlba konvertalni ezt?


Koszonettel:
Hose 


_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables rules konvertalas shorewall rules-be

[Kiss Gabor]

In article [EMAIL PROTECTED],
Hose [EMAIL PROTECTED] writes:
 Van egy tuzfalszabaly file (iptables-save) hoogy lehet shorewall rules 
 fajlba konvertalni ezt?

Esszel. :-)
A shorewall magasszintu leirast hasznal.
Fogalmazd meg ertelmes mondatokban, hogy kinek mit akarsz
engedni, aztan azt mar konnyu shorewallositani.

A felvetett feladat hasonlo nehezsegu, mint amikor egy szabad kezzel
irt assembly programot Pascalba akarna atrakni az ember.
Nem lehet mindent megoldani a magasszintu nyelvvel, amit
az elemi utasitasok szintjen osszebuheralhatsz.

Gabor
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: iptables script - átnéznétek ?

[Laszlo Baranyai]

MORE_F_TCP_PORTS=544 1755 2628 6881 81

A vegen direkt 81 van?

Udv.: Laci

--
Laszlo Baranyai [EMAIL PROTECTED]
Corvinus University of Budapest
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

iptables script - átnéznétek ?

[Nagy Imre]

Pár napon belül be kel üzemelnem egy szervert, amin egy squid fog 
müködni transzparens proxy-ként, a gépen még dhcp szolgáltatás fog 
futni.(+ssh,apache2 stb..)

Átnéznétek az alábbi scriptet, mert valami nem jó benne :(
Belső hálon nem látszik a 80 és a 21 port se :(

kösszi, fontos lenne
Imre


#!/bin/sh

echo -n 'Configuring firewall '
echo 1  /proc/sys/net/ipv4/ip_forward
#allandok
NET_INT=192.168.0.0/255.255.0.0 #belsĂľ halozatot lefedĂľ teljes 
cimtartomany
IFACE_INT=eth0 #belsĂľ csatolo
IFACE_EXT=eth1 #kulsĂľ csatolo
IP_GW=192.168.1.1

PORT_SSH_EXT=1 #SSH external port
MORE_F_TCP_PORTS=544 1755 2628 6881 81
MORE_F_UDP_PORTS=544 1755
#544-RealMedia 1755-WindowsMedia 2628-JDictionary 6880-BitTorrent

#IP_INT=192.168.100.1 #belsĂľ IP cim
IP_INT=`ifconfig $IFACE_INT | grep inet\ addr | cut -f2 -d: | cut -f1 -d\ 
`
IP_EXT=`ifconfig $IFACE_EXT | grep inet\ addr | cut -f2 -d: | cut -f1 -d\ 
` #külső IP cím

#regi szabalyok tĂľrlese
iptables -F
iptables --delete-chain
iptables -t nat -F
iptables -t nat --delete-chain
iptables -Z

#alapertelemzetten mindent eldob
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

#visszahurkolo engedĂŠlyezĂŠse
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

#tovabbi lancok letrehozasa:
iptables -N security
iptables -N dosattack
iptables -N sinput
iptables -N portscan

#gw elerhetĂľsege
iptables -A INPUT -s $IP_GW -j ACCEPT
iptables -A OUTPUT -d $IP_GW -j ACCEPT

#Portscan  PoD loggolas
iptables -A security -p tcp --tcp-flags ALL FIN,URG,PSH -j LOG --log-
prefix FW: Xmas-tree scan (?) 
iptables -A security -p tcp --tcp-flags ALL NONE -m state --state ! 
ESTABLISHED -j LOG --log-prefix FW: Null scan (?) 
iptables -A security -p icmp --icmp-type echo-request -m limit --limit 1/s -
j ACCEPT
iptables -A security -p icmp --icmp-type echo-request -j LOG --log-
prefix FW: PingofDeath attack (?) 
iptables -A security -p icmp --icmp-type echo-request -j DROP

iptables -A INPUT -j security
iptables -A FORWARD -j security

#DoS tamadasok  portscanek szurese, loggolasa
iptables -A dosattack -p tcp --syn -m limit --limit 8/s -j sinput
iptables -A dosattack -p tcp --syn -j LOG --log-prefix FW: Syn-Flood 
attack (?) 
iptables -A dosattack -p tcp --syn -j DROP
iptables -A dosattack -j sinput

#bejovo szabalyok

iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED 
#jovahagyott kapcsolatok elfogadasa
iptables -A INPUT -j dosattack

iptables -A sinput -p tcp ! --syn -m state --state NEW -j LOG --log-
prefix FW: hidded portscan ? 
iptables -A sinput -p tcp ! --syn -m state --state NEW -j DROP

iptables -A sinput -i $IFACE_INT -p tcp -s $NET_INT -m multiport --dport 
20,21,25,53,80,3128 -m state --state NEW -j ACCEPT
iptables -A sinput -i $IFACE_INT -p udp -s $NET_INT -m multiport --
dport 20,21,25,53,80,3128 -m state --state NEW -j ACCEPT

iptables -A sinput -p tcp --dport 443 -j ACCEPT
iptables -A sinput -p icmp -j ACCEPT
#iptables -A sinput -j LOG --log-prefix FW: Rejected default (in) 
iptables -A sinput -j REJECT

#kimenĂľ szabalyok
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-request -j DROP
iptables -A OUTPUT -p icmp -j ACCEPT

iptables -A OUTPUT -p tcp -m multiport --dport 20,21,25,53,80,110,443 -
m state --state NEW,RELATED -j ACCEPT
iptables -A OUTPUT -p udp -m multiport --dport 
20,21,25,53,80,110,443 -m state --state NEW,RELATED -j ACCEPT

iptables -A OUTPUT -p tcp -d $NET_INT --sport 3128 -j ACCEPT
iptables -A OUTPUT -p tcp -d $NET_INT --sport 25 -j ACCEPT

iptables -A OUTPUT -j LOG --log-prefix FW: Rejected default (out) 
iptables -A OUTPUT -j REJECT

#tovabbitt szabalyok
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-
mss-to-pmtu

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -p tcp ! --syn -m state --state NEW -j DROP
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 
16/s -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -j DROP
iptables -A FORWARD -p icmp -j ACCEPT

iptables -A FORWARD -i $IFACE_INT -p tcp -m multiport --dport 
20,21,53,80,110,123,443 -m state --state NEW,RELATED -j ACCEPT
iptables -A FORWARD -i $IFACE_INT -p udp -m multiport --dport 
20,21,53,80,110,123,44

#Tovabbitasra a MORE_F_TCP_PORTS tombben tarolt portok kinyitasa
if test -n $MORE_F_TCP_PORTS
then
for i in $MORE_F_TCP_PORTS
do iptables -A FORWARD -i $IFACE_INT -p tcp --dport $i -m state --state 
NEW,RELATED -j ACCEPT
done
fi
if test -n $MORE_F_UDP_PORTS
then
for i in $MORE_F_UDP_PORTS
do iptables -A FORWARD -i $IFACE_INT -p udp --dport $i -m state --
state NEW,RELATED -j ACCEPT
done
fi

#iptables -A FORWARD -j LOG --log-prefix FW: Rejected default (fwd) 
iptables -A FORWARD -j REJECT

#NAT
iptables -t nat -A POSTROUTING -o $IFACE_EXT -j MASQUERADE

#transzparens proxy engedalyezase
iptables -t nat -A PREROUTING -i $IFACE_INT -s $NET_INT -p tcp --dport 
80 -j REDIRECT --to-ports 3128

Re: IPTables kerdes

[Lajber Zoltan]

On Thu, 25 May 2006, Zidarics Zoltan wrote:

 az iptables -L meg is jeleniti:

 DROP   all  --  193.254.0.0/16   anywhere


Ez forward vagy input lancon van?
A mai kozvetlen abbol a tartomanybol jon, vagy valami kozvetiton at?
Ha utobbi, akkor az MTA-ban (vagy a spamfilterben) kell szurnod.

Udv,
-=Lajbi=
 LAJBER Zoltan   Szent Istvan Egyetem,  Informatika Hivatal
  Experience is something you don't get until just after you need it
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: IPTables kerdes

[Zidarics Zoltan]

Hello,
Opppsss! 
Kiverte a szememet es nem vettem eszre :)
koszi...

2006. május 25. 12.09 dátummal [EMAIL PROTECTED] ezt írta:
 On Thu, 25 May 2006, Zidarics Zoltan wrote:
  hello,
 
  2006. május 25. 10.39 dátummal Lajber Zoltan ezt írta:
  On Thu, 25 May 2006, Zidarics Zoltan wrote:
  az iptables -L meg is jeleniti:
 
  DROP   all  --  193.254.0.0/16   anywhere
 
  Ez forward vagy input lancon van?
  A mai kozvetlen abbol a tartomanybol jon, vagy valami kozvetiton at?
  Ha utobbi, akkor az MTA-ban (vagy a spamfilterben) kell szurnod.
 
  Az input lancban van:
  vili:~# iptables -L INPUT
  Chain INPUT (policy DROP)
  target prot opt source   destination
  ACCEPT all  --  anywhere anywhere
  ...
  DROP   all  --  192.168.0.0/16   anywhere
  DROP   all  --  193.254.0.0/16   anywhere
  DROP   all  --  194.185.0.0/16   anywhere
  DROP   all  --  220.165.0.0/16   anywhere

 Ha jól látom, az első szabályra illeszkedik minden csomag, a többit ezek
 után meg sem vizsgálja...
   Bye,NAR

-- 
udv,

Zoltan Zidarics programmer
PTE University Pecs, Hungary
icq: 43288694
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: IPTables kerdes

[Salamon Attila]

On Thu, 2006-05-25 at 12:19 +0200, Zidarics Zoltan wrote:
 Hello,
 Opppsss! 
 Kiverte a szememet es nem vettem eszre :)
Azért nézz egy  iptables -L -n -v -t is, mert lehet, hogy egy olyan
interfész forgalmára vonatkozik az az ACCEPT, ami mondjuk egy belső háló
felé néz. Mármint ugye, ha van egyáltalán ilyen.
üdv.
Salamon Attila


_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: IPTables kerdes

[Zidarics Zoltan]

hello,

2006. május 25. 13.04 dátummal Salamon Attila ezt írta:
  Opppsss!
  Kiverte a szememet es nem vettem eszre :)
 Azért nézz egy  iptables -L -n -v -t is, mert lehet, hogy egy olyan
 interfész forgalmára vonatkozik az az ACCEPT, ami mondjuk egy belső háló
 felé néz. Mármint ugye, ha van egyáltalán ilyen.
Nincs, csak egy kartya van benne es most mar latszik, hogy mukodik.

-- 
koszi,

Zoltan Zidarics programmer
PTE University Pecs, Hungary
icq: 43288694
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux