firewall a HTTP
Vlastimil Kupsky
pri konfiguraci firewallu (SQUID + iptables) jsem si uvedomil jednu vec.
Ve vsech vzorovych konfiguracich pro filtrovani HTTP protokolu na firewallu
se uvadi, ze se ma povolit port 80 pro odchozi TCP spojeni.
Existuji vsak i webove servery, ktere jsou provozovany na jinych portech nez
80.
Je nejaka rozumna cesta, jak se s dotazy na tyto servery vyporadat, nebo se
naplni moje obava, ze
pro bezchybnou funkcnost vsech webovych stranek je treba povolit vsechny NEW
pakety na TCP.
-----------
Vlastimil Kupsky
kups...@pbsvb.cz
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Hledate Linuxovy software? Zkuste http://www.tuxfinder.com/
Michal Kubecek
>
> Ve vsech vzorovych konfiguracich pro filtrovani HTTP protokolu na
> firewallu se uvadi, ze se ma povolit port 80 pro odchozi TCP spojeni.
>
> Existuji vsak i webove servery, ktere jsou provozovany na jinych
> portech nez 80.
>
> Je nejaka rozumna cesta, jak se s dotazy na tyto servery vyporadat,
> nebo se naplni moje obava, ze pro bezchybnou funkcnost vsech webovych
> stranek je treba povolit vsechny NEW pakety na TCP.
Především byste si měl položit otázku, proč a jak (a zda vůbec) chcete
filtrovat provoz směrem ven.
Michal Kubeček
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Konference o Perlu: perl na list...@muni.cz
Vlada Macek
>Existuji vsak i webove servery, ktere jsou provozovany na jinych portech nez
>80.
>
>
Jiste, i kdyz jich neni moc. Tak zacnete s tim, ze povolite TCP 80,
8080, 8081 a 443. Dale sdelte uzivatelum "za firewallem", ze provoz ven
je omezeny a (pokud to neni bezne) ze problemy s pripojenim vam maji
hlasit s popisem toho, kam chteli, kterym programem a proc. Po uvazeni
to pridate do prislusneho retizku. Myslim, ze to je bezny postup.
Dalsi moznosti je nejaky cas logovat "zajmy" Vasich uzivatelu na siti a
tomu prizpusobit firewall, abyste je co nejmene omezoval.
Vlada
Jan Houstek
> Dalsi moznosti je nejaky cas logovat "zajmy" Vasich uzivatelu na siti a
> tomu prizpusobit firewall, abyste je co nejmene omezoval.
Tahle logika mi ponekud unika.
Firewall ma chranit predevsim vnitrni sit, k dosazeni tohoto ucelu neni
nutne nijak omezovat aktivity iniciovane zevnitr te site (az na par
vyjimek, kdy nejaky podivny protokol vyzaduje spojeni zvenku a neni to
podchycene ip_conntrack nebo necim podobnym).
Pokud tyka omezeni aktivity vnitrnich uzivatelu, pak ji firewall
bud
- ma omezovat (jakkoliv je to pochybne, viz nize) a neni tedy nutne
uzivatele smirovat
- nema omezovat, pak tuplem neni nutne uzivatele smirovat
-- Honza Houstek
P.S. Chcete-li neco uzivatelum zakazat, musite jim to predevsim zakazat
nejakym netechnickym zpusobem (narizeni, smernice apod.). Jakykoliv
firewall, ktery umozni byt jen bazalni komunikaci smerem ven (i kdyby to
bylo treba jen DNS) totiz schopny uzivatel hrave obejde.
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Prectete si Linux Documentation Project: http://www.linux.cz/linuxdoc/
Peter Surda
> On Wed, 4 Aug 2004, Vlada Macek wrote:
> > Dalsi moznosti je nejaky cas logovat "zajmy" Vasich uzivatelu na siti a
> > tomu prizpusobit firewall, abyste je co nejmene omezoval.
> Tahle logika mi ponekud unika.
>
> Firewall ma chranit predevsim vnitrni sit, k dosazeni tohoto ucelu neni
> nutne nijak omezovat aktivity iniciovane zevnitr te site (az na par
> vyjimek, kdy nejaky podivny protokol vyzaduje spojeni zvenku a neni to
> podchycene ip_conntrack nebo necim podobnym).
> P.S. Chcete-li neco uzivatelum zakazat, musite jim to predevsim zakazat
> nejakym netechnickym zpusobem (narizeni, smernice apod.).
S tymto plne suhlasim.
> Jakykoliv firewall, ktery umozni byt jen bazalni komunikaci smerem ven (i
> kdyby to bylo treba jen DNS) totiz schopny uzivatel hrave obejde.
Jasne, castejsia je vsak horeuvedena kategoria, a sice ze pocitac robi nieco o
com vlastnik nevie.
S pozdravom,
Peter Surda (Shurdeek) <shur...@routehat.org>, ICQ 10236103, +436505122023
--
Where do you think you're going today?
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Hledate software? Zkuste http://freshmeat.net/
Jan Houstek
> > Firewall ma chranit predevsim vnitrni sit, k dosazeni tohoto ucelu neni
> > nutne nijak omezovat aktivity iniciovane zevnitr te site (az na par
> > vyjimek, kdy nejaky podivny protokol vyzaduje spojeni zvenku a neni to
> > podchycene ip_conntrack nebo necim podobnym).
> Je kopa inych vynimiek, hlavne kategoria "viry, cervy, spyware, zombie,
> ...".
Ta zavorka byla myslena trochu jinak, slo o to, ze restrikce spojeni z
venku dovnitr se v urcite male mnozine pripadu dotknou i komunikace
iniciovane zevnitr.
> Jasne, castejsia je vsak horeuvedena kategoria, a sice ze pocitac robi
> nieco o com vlastnik nevie.
Jiste. Takove veci je ovsem potreba predevsim detekovat a prislusne
problemove zarizeni az do vyreseni problemu zcela odpojit od site (at uz
jakymkoliv zpusobem, napr. fyzickou likvidaci toho zarizeni).
Alibisticky zakaz nektereho druhu komunikace smerem ven tezko neco vyresi,
primarne je treba odstranit pricinu toho problemu. Takove zarizeni totiz
svou cinnosti ohrozuje predevsim ostatni zarizeni v siti a proti tomu
firewall nic moc nezmuze.
-- Honza Houstek
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
Michal Kubecek
>
> > Jakykoliv firewall, ktery umozni byt jen bazalni komunikaci smerem ven (i
> > kdyby to bylo treba jen DNS) totiz schopny uzivatel hrave obejde.
> Jasne, castejsia je vsak horeuvedena kategoria, a sice ze pocitac robi nieco o
> com vlastnik nevie.
Já jsem tedy žádný takový program nepsal, ale kdyby ano, určitě bych
komunikaci směrem ven maskoval jako dotaz na normální webový server,
tedy TCP na port 80 a pokud možno ještě aby to vypadalo jako HTTP. Zdá
se mi to celkem logické. Takže mi taková "obrana" připadá poněkud
nesmyslná a zbytečná.
Michal Kubeček
Chlopcik Ales
>
> On Thu, Aug 05, 2004 at 12:27:55AM +0200, Peter Surda wrote:
> >
> > > Jakykoliv firewall, ktery umozni byt jen bazalni komunikaci smerem ven (i
> > > kdyby to bylo treba jen DNS) totiz schopny uzivatel hrave obejde.
> > Jasne, castejsia je vsak horeuvedena kategoria, a sice ze pocitac robi nieco o
> > com vlastnik nevie.
>
> Já jsem tedy žádný takový program nepsal, ale kdyby ano, určitě bych
> komunikaci směrem ven maskoval jako dotaz na normální webový server,
> tedy TCP na port 80 a pokud možno ještě aby to vypadalo jako HTTP. Zdá
> se mi to celkem logické. Takže mi taková "obrana" připadá poněkud
> nesmyslná a zbytečná.
>
> Michal Kubeček
Sorry, ale Vy mate povolene napr. porty 137-9 ? A to mate cistou
(NonWhoKnows) sit ? Pokud ano, pak Vam zavidim.
Ja osobne povazuji za podstatne vyhodnejsi povolit ven jen _nektere_
porty, ostatni logovat a pak (na zaklade tech logu ciniti akce. Dost
jsem se divil, co vsechno (z WhoKnows stroju :-) a kudy se dobyva ven.
Nakonec jsme to vyresili tak, ze vsichni chodi pouze na jediny stroj
(proxy) a pouze ten (a pouze _nekterymi_ porty) smi jit ven.
IMHO neni v lidskych silach uhlidat 50 (a vic) koncu (pokud clovek
nedela jen FW, ale i jinou praci).
Ales
Michal Kubecek
>
> Sorry, ale Vy mate povolene napr. porty 137-9 ? A to mate cistou
> (NonWhoKnows) sit ? Pokud ano, pak Vam zavidim.
Proč ne? To, co dělá ten šílený chaos, jsou UDP broadcasty na portech
137 a 138, ty se ven ze segmentu stejně nedostanou. TCP komunikace na
portu 139 nevzniká "sama od sebe", pro tu už platí stejná pravidla jako
pro jakýkoli jiný provoz.
> Ja osobne povazuji za podstatne vyhodnejsi povolit ven jen _nektere_
> porty, ostatni logovat a pak (na zaklade tech logu ciniti akce. Dost
> jsem se divil, co vsechno (z WhoKnows stroju :-) a kudy se dobyva ven.
> Nakonec jsme to vyresili tak, ze vsichni chodi pouze na jediny stroj
> (proxy) a pouze ten (a pouze _nekterymi_ porty) smi jit ven.
Takové opatření má dobrý smysl, i když to přináší určité negativní
důsledky. Co ale IMHO nemá smysl, je blokovat jakoukoli komunikaci
zevnitř ven z důvodu ochrany proti spyware a spol. a přitom povolit
přímou TCP komunikaci ven na port 80 - protože to je to první, za co se
bude jakýkoli spyware maskovat. Přesně na to jsem upozorňoval ve svém
minulém příspěvku.
Michal Kubeček
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Dopis si pred odeslanim jeste jednou prectete
Jaroslav Lukesh
> On Wed, 4 Aug 2004, Vlada Macek wrote:
>
>
>>Dalsi moznosti je nejaky cas logovat "zajmy" Vasich uzivatelu na siti a
>>tomu prizpusobit firewall, abyste je co nejmene omezoval.
>
>
> Tahle logika mi ponekud unika.
>
> Firewall ma chranit predevsim vnitrni sit, k dosazeni tohoto ucelu neni
> nutne nijak omezovat aktivity iniciovane zevnitr te site (az na par
> vyjimek, kdy nejaky podivny protokol vyzaduje spojeni zvenku a neni to
> podchycene ip_conntrack nebo necim podobnym).
kdysi jsem kdesi instalil FW konfigurovany tak, ze byl definovan i
zpusob navazovani spojeni (bylo to jeste nad ipchains), s tim aby se
zamezilo sireni pripadnych ziskanych cervu a podobnych nezadoucich
softiku do podnikove site v emerice pripojene pres satelit.
Kdysi jsem to daval annonci i sem, ale jsou to tak 3+ roky.
--
Jaroslav Lukeš
--
Tento e-mail nemůže obsahovat VIRY
jelikož nepocházi z virózního systému M$ Windows!
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
Chlopcik Ales
Michal Kubecek wrote:
>
> On Thu, Aug 05, 2004 at 02:19:42AM +0200, Chlopcik Ales wrote:
> >
> > Sorry, ale Vy mate povolene napr. porty 137-9 ? A to mate cistou
> > (NonWhoKnows) sit ? Pokud ano, pak Vam zavidim.
>
> Proč ne? To, co dělá ten šílený chaos, jsou UDP broadcasty na portech
> 137 a 138, ty se ven ze segmentu stejně nedostanou. TCP komunikace na
> portu 139 nevzniká "sama od sebe", pro tu už platí stejná pravidla jako
> pro jakýkoli jiný provoz.
>
Pokud NATujete jen _nektere_ porty (coz je IMHO totez, ale nevim jak na
to), pak TO jste uz nenapsal. Pokud vsechny, pak se i UDP vesele siri
siti dal a mozna by se na ne mohlo i navazat otevreni spojeni
_jakoby_zevnitr_ (ale tady si jist nejsem /nonGURU/). No a v ramcim
_moja_paranoia_, pokud si nejsem jist, tak radsi resim.
> > Ja osobne povazuji za podstatne vyhodnejsi povolit ven jen _nektere_
> > porty, ostatni logovat a pak (na zaklade tech logu ciniti akce. Dost
> > jsem se divil, co vsechno (z WhoKnows stroju :-) a kudy se dobyva ven.
>
> > Nakonec jsme to vyresili tak, ze vsichni chodi pouze na jediny stroj
> > (proxy) a pouze ten (a pouze _nekterymi_ porty) smi jit ven.
>
> Takové opatření má dobrý smysl, i když to přináší určité negativní
> důsledky.
Jediny negativni dusledek (s kterym se obcas potykam) je, ze musim
explicitne (a presne) vyjmenovat vyjimky. Neco mi uniklo ?
> Co ale IMHO nemá smysl, je blokovat jakoukoli komunikaci
> zevnitř ven z důvodu ochrany proti spyware a spol. a přitom povolit
> přímou TCP komunikaci ven na port 80 - protože to je to první, za co se
> bude jakýkoli spyware maskovat. Přesně na to jsem upozorňoval ve svém
> minulém příspěvku.
To pripoustim/S tim bych i souhlasil.
>
> Michal Kubeček
Ales
Peter Surda
> On Thu, Aug 05, 2004 at 02:19:42AM +0200, Chlopcik Ales wrote:
> > Sorry, ale Vy mate povolene napr. porty 137-9 ? A to mate cistou
> > (NonWhoKnows) sit ? Pokud ano, pak Vam zavidim.
> Proč ne? To, co dělá ten šílený chaos, jsou UDP broadcasty na portech
> 137 a 138, ty se ven ze segmentu stejně nedostanou. TCP komunikace na
> portu 139 nevzniká "sama od sebe", pro tu už platí stejná pravidla jako
> pro jakýkoli jiný provoz.
ti nepretazili linku, ze? Nepotrebujes na to ani desiatky pocitacov, staci tak
5.
> Takové opatření má dobrý smysl, i když to přináší určité negativní
> důsledky. Co ale IMHO nemá smysl, je blokovat jakoukoli komunikaci
> zevnitř ven z důvodu ochrany proti spyware a spol. a přitom povolit
> přímou TCP komunikaci ven na port 80 - protože to je to první, za co se
> bude jakýkoli spyware maskovat. Přesně na to jsem upozorňoval ve svém
> minulém příspěvku.
Zmysel to samozrejme ma. Autori windowsovskych zlych programov nezvyknu
mysliet unixovsky. Port 80 mozes regulovat dodatocne.
> Michal Kubeček
S pozdravom,
Peter Surda (Shurdeek) <shur...@routehat.org>, ICQ 10236103, +436505122023
--
Where do you think you're going today?
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Konference o textovych editorech: editor...@linux.cz
Peter Surda
> > Jasne, castejsia je vsak horeuvedena kategoria, a sice ze pocitac robi
> > nieco o com vlastnik nevie.
> Jiste. Takove veci je ovsem potreba predevsim detekovat a prislusne
> problemove zarizeni az do vyreseni problemu zcela odpojit od site (at uz
> jakymkoliv zpusobem, napr. fyzickou likvidaci toho zarizeni).
> Alibisticky zakaz nektereho druhu komunikace smerem ven tezko neco vyresi,
> primarne je treba odstranit pricinu toho problemu. Takove zarizeni totiz
> svou cinnosti ohrozuje predevsim ostatni zarizeni v siti a proti tomu
> firewall nic moc nezmuze.
No, je to jedna vrstva ochrany navyse, pomoze napriklad oddialit pretazenie.
> -- Honza Houstek
S pozdravom,
Peter Surda (Shurdeek) <shur...@routehat.org>, ICQ 10236103, +436505122023
--
Where do you think you're going today?
---------------------------------------------------------------------------
Vlada Macek
> On Wed, 4 Aug 2004, Vlada Macek wrote:
>> Dalsi moznosti je nejaky cas logovat "zajmy" Vasich uzivatelu na
>> siti a tomu prizpusobit firewall, abyste je co nejmene omezoval.
>
> Tahle logika mi ponekud unika.
Logika je prosta. Jako spravce site v podstate zodpovedny za to, co leta
mezi ni a providerem, chci mit nad tim v ramci moznosti co nejlepsi
prehled, ale zatim bez zavadeni aplikacniho firewallu (napr. webove
proxy). To zahrnuje restrikce nevedomych pokusu o spojeni ven. Firma je
liberalni, kdyz prijde oduvodneny pozadavek uzivatele, ze na tento port
a toto IP ma z tohoto duvodu zajem se pripojit, nebudu mu branit.
Nechci proste mit stav, kdy je povoleno vsechno kamkoli, ale mit danou
mnozinu povolenych aktivit za soucasneho minimalniho obtezovani
uzivatelu v souladu se zajmy firmy. Verim, ze tim predchazim problemum.
K velice paranoidnimu nastaveni firewallu smerem dovnitr a privreni
dvirek smerem ven jsem se odhodlal pote, co jsem spatril, jak
neuveritelny provoz by obema smery bez toho firewallu letal.
Zcela souhlasim s tim, ze firewall jakozto technicke zarizeni je uzce
svazan se socialni a zamestnaneckou politikou vnitrni site. Jista temata
nelze resit technicky, ale zaroven smluvne (ci umluvou). Z toho vyplyva,
ze moje zkusenosti a opatreni nemuze nikdo jiny beze zbytku aplikovat na
svou situaci, pravidla firewallu jsou vzdy individualni.
> Firewall ma chranit predevsim vnitrni sit, k dosazeni tohoto ucelu
> neni nutne nijak omezovat aktivity iniciovane zevnitr te site
Jisty port je podle meho nazoru velmi prakticke omezit smerem ven, a to
je SMTP. Je casto vhodne, aby veskera posta, ktera odchazi z firmy,
prochazela pres jediny MTA. Opet samozrejme mohou existovat individualni
vyjimky.
Sam pisete "predevsim". Zastavam nazor, ze firewall by mel mit prehled o
obou svych stranach, chranit i vnejsi site od (alespon nekterych)
nevedomych aktivit site vnitrni. To jsem tu sam, kdo si tohle mysli?
> Pokud tyka omezeni aktivity vnitrnich uzivatelu, pak ji firewall bud
> - ma omezovat (jakkoliv je to pochybne, viz nize) a neni tedy nutne
> uzivatele smirovat
> - nema omezovat, pak tuplem neni nutne uzivatele
> smirovat
Je videt, ze se snazite o diplomacii za kazdou cenu. V situaci, kdy
spravuji i souborove a postovni servery teze firmy, mi uz byla dana
znacna duvera. Z toho, jak _tato_konkretni_firma_ (kterou Vy neznate)
funguje, vyplyva, ze uz tak jako tak musim byt zasvecen do mnozstvi
duvernych informaci proto, abych mohl pomahat zajistovat plynuly chod.
Ten je vzdy (bohuzel) to nejdulezitejsi.
> P.S. Chcete-li neco uzivatelum zakazat, musite jim to predevsim
> zakazat nejakym netechnickym zpusobem (narizeni, smernice apod.).
> Jakykoliv firewall, ktery umozni byt jen bazalni komunikaci smerem
> ven (i kdyby to bylo treba jen DNS) totiz schopny uzivatel hrave
> obejde.
Nevim, proc zavadite tema zakazovani neceho uzivatelum, o nic takoveho
tu nejde. Jedna se o malou firmu, kde panuje pratelska atmosfera. Se
svymi uzivateli jsem myslim ve velmi dobrem vztahu. Zakazovat jim
pristupy ven, ktere potrebuji k plneni pracovnich povinnosti, by bylo
samozrejme proti zajmum firmy. O omezovani pristupu soukromych --
nepracovnich -- nepadlo od vedeni nikdy ani slovo, proto zadne neni.
Jsou povolene napr. i IRC servery. Jedine co chci, je mit prehled.
Nebudu to uz dal prodluzovat. Myslim, ze kdo chtel pochopit, pochopil.
Vlada Macek
Lubomír Klubus
>je SMTP. Je casto vhodne, aby veskera posta, ktera odchazi z firmy,
>prochazela pres jediny MTA. Opet samozrejme mohou existovat individualni
>vyjimky.
Ale to je přece naprosto zbytečné, vy zapomínáte, že drtivá většina zdarma
služeb na internetu , která nabízí připojení na SMTP to nemá povolené z
jiných IP adres než vlastních. To znamená pokud jste připojen například přes
telefonické připojení modemem ke Contactelu, můžete používat SMTP jen z
tohoto připojení, z jejich rozsahu IP.
Takže když se někdo z Vaší firmy připojí na SMTP nějakého providera,
protože nejste v jejich rozsahu IP, nebude to fungovat, jedině kdybyste
posílal e-maily do jejich domény. Takže si stejně musí nastavit SMTP Vašeho
serveru aby mohl e-maily odesílat.
Samozřejmě můžete narazit na openrelay SMTP, který odešle cokoliv
odkudkoliv, ale myslímm, že na tohle si dávají všichni v dnešní době bacha.
Lubomír Klubus
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
Michal Kubecek
>
> Takže když se někdo z Vaší firmy připojí na SMTP nějakého providera,
> protože nejste v jejich rozsahu IP, nebude to fungovat, jedině kdybyste
> posílal e-maily do jejich domény. Takže si stejně musí nastavit SMTP Vašeho
> serveru aby mohl e-maily odesílat.
Zapomínáte na to, že ten mail může poslat přímo cílovému příjemci, jak
se to dělávalo za Starých Dobrých Časů (TM).
Michal Kubeček
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
Michal Kubecek
> Michal Kubecek wrote:
> >
> > Proč ne? To, co dělá ten šílený chaos, jsou UDP broadcasty na portech
> > 137 a 138, ty se ven ze segmentu stejně nedostanou. TCP komunikace na
> > portu 139 nevzniká "sama od sebe", pro tu už platí stejná pravidla jako
> > pro jakýkoli jiný provoz.
>
> Pokud NATujete jen _nektere_ porty (coz je IMHO totez, ale nevim jak na
> to), pak TO jste uz nenapsal. Pokud vsechny, pak se i UDP vesele siri
> siti dal a mozna by se na ne mohlo i navazat otevreni spojeni
> _jakoby_zevnitr_ (ale tady si jist nejsem /nonGURU/). No a v ramcim
> _moja_paranoia_, pokud si nejsem jist, tak radsi resim.
Chcete mi tvrdit, že klasický NAT "všeho" přenatuje _broadcasty_ vnitřní
sítě na... na co vlastně? Na broadcasty nejbližšího segmentu vnější
sítě? Tak ničeho takového jsem si zatím nevšiml a ani v dokumentaci jsem
na takovou featuru nenarazil. Pouze Samba něco takového umí dělat, pokud
se to zapne, ale že by to netfilter dělal sám od sebe, tomu nevěřím.
Jinak v tom, jak NATovat jen některé porty, nevidím naprosto žádný
problém. I pravidla v tabulce nat, kterými se NAT provádí, mohou
používat podmínky '-p', '--sport' a '--dport'.
Michal Kubeček
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Hardwarova kompatibilita? http://hardware.penguin.cz/
Vlada Macek
> Takže když se někdo z Vaší firmy připojí na SMTP nějakého providera,
> protože nejste v jejich rozsahu IP, nebude to fungovat, jedině
> kdybyste posílal e-maily do jejich domény. Takže si stejně musí
> nastavit SMTP Vašeho serveru aby mohl e-maily odesílat.
Ale me prece nejde o obranu proti openrelay. Opakuju, ze mi jde zejmena
o malware, ktery je schopen vcetne resolvovani spravneho MX technicky
legalne odeslat mnozstvi e-mailu na SMTP servery. Ty to prijmou, protoze
se jedna o zpravy pro jejich site.
Tim, ze soustredim veskery e-mailovy tok na svuj server + nektere
povolene dalsi (pusti-li nektereho uzivatele pro jeho soukromou postu
nejaky SMTP server, napr. freemail), budu moci takove aktivity odchytit
ci filtrovat.
Pred casem jsem videl statistiku, ktera rikala, ze nejvice casu
administratori stravi u e-mailoveho systemu. Tuto smutnou informaci za
sebe muzu zcela potvrdit a dost me to stve.
VM
Vlastimil Kupsky
vsechny webove stranky
bez ohledu na jakem portu bezi, musim:
- povolit vsechny odchozi TCP pakety
nebo
- sledovat log squida a postupne povolovat TCP spojeni na server:port, ktery
squid chce
otevrit a nemuze
nebo
- cekat na uzivatele az prijdou, ze se jim nedari otevrit danou webovou
stranku a podle toho povolit
odchozi TCP spojeni na dany server:port
Jeste bych podotkl - nemyslim si, ze by bylo vhodne povolit vsechny odchozi
pakety jen tak.
Prece jen muze existovat spousta programu, ktere (at uz to uzivatel vi nebo
ne) se snazi nejak
komunikovat ven. A abych o tom mel jako spravce alespon trochu prehled, tak
si myslim, ze
je lepsi videt v logu nejaky zaznam o pokusu jit ven. Potom zjistim, ma-li
tento pokus nejaky
opravneny duvod. V tomto bode je mozne aplikovat nejake firemni smernice,
kde se rekne, zda-li
je to duvod opravneny nebo ne. Pokud ano, povolim dane odchozi spojeni s
tim, ze vim co jsem
povolil a mam prehled o tom co z me site odchazi.
To je asi tak vsechno.
Dekuji za Vase reakce
-----------
Vlastimil Kupsky
kups...@pbsvb.cz
---------------------------------------------------------------------------
Meta-FAQ (odhlaseni, archiv, FAQ a dalsi): http://www.linux.cz/mailing-list
TIP: Prohledejte nejprve archiv konference