NOD32 pre Linux Mail Server

linux_pas V pre­doš­lej úvod­nej čas­ti sme si po­ve­da­li nie­čo o mož­nos­tiach NO­D32 pre Li­nux Mail Server (LMS) a pre Li­nux Fi­le Server (LFS). Ta­kis­to sme uvied­li, že od ver­zie 2.50 sú oba prog­ra­my v jed­nom je­di­nom ba­lí­ku, ozna­če­nom no­d32ls-x.y.z.i368.xxx.bin. A vie­me, že po spus­te­ní toh­to ba­lí­ka a po pre­čí­ta­ní a od­súh­la­se­ní li­cen­čných po­dmie­nok dos­ta­ne­me kla­sic­ký ba­lí­ček, nap­rík­lad pre Red­Hat a Fe­do­ru to bu­de no­d32ls-2.50-2.i386.rpm. Te­raz sa bu­de­me ve­no­vať NO­D32 pre Li­nux Mail Server.

In­šta­lá­cia
Po zís­ka­ní prís­luš­né­ho ba­lí­ka vy­ko­ná­me in­šta­lá­ciu. Tre­ba si uve­do­miť, že ide o ko­merč­ný pro­dukt, kto­rý nie je ší­re­ný pod li­cen­ciou GPL, tak­že ne­dos­ta­ne­me ni­ja­ké zdro­jo­vé kó­dy. Pre­to pod slo­vom in­šta­lá­cia bu­de­me ten­to­raz ro­zu­mieť umies­tne­nie bi­nár­nych, kon­fi­gu­rač­ných a ma­nuá­lo­vých sú­bo­rov do prís­luš­ných ad­re­sá­rov.

Upo­zor­ne­nie:
Eš­te pred spus­te­ním in­šta­lá­cie ba­lí­ka mu­sí­me do ad­re­sá­ra /etc/no­d32/li­cen­ce na­ko­pí­ro­vať sú­bor s li­cen­čným kľú­čom, nap­rík­lad no­d32.lic. Ten­to sú­bor zís­ka­me od pre­daj­cu (fir­my Eset) spo­lu s prih­la­so­va­cím me­nom a hes­lom, kto­ré slú­žia na stiah­nu­tie prís­luš­ných ba­líč­kov. To­to me­no a hes­lo si od­lo­ží­me, bu­de­me ho eš­te po­tre­bo­vať.

In­šta­lá­ciu mô­že­me vy­ko­nať via­ce­rý­mi spô­sob­mi. Buď pria­mo v Mid­night Com­man­de­ri klik­ne­me na sú­bor no­d32ls-2.50-2.i386.rpm a po je­ho roz­ba­le­ní klik­ne­me na sú­bor IN­STALL, prí­pad­ne UP­GRA­DE. In­šta­lá­cia pre­beh­ne sa­ma a my len skon­tro­lu­je­me, či ne­doš­lo k ne­ja­kým chy­bám.

Ak chce­me in­šta­lo­vať na prí­ka­zo­vom riad­ku, za­dá­me prí­kaz

 [root@ru­bin in­stall] # rpm –i no­d32ls-2.50-2.i386.rpm

V prí­pa­de vý­pi­su hlá­se­nia o tom, že už je po­dob­ný ba­lí­ček nain­šta­lo­va­ný, spus­tí­me prí­kaz s pa­ra­met­rom –u:

 [root@ru­bin in­stall] # rpm –u no­d32ls-2.50-2.i386.rpm

Pre dis­tri­bú­ciu De­bian po­uži­je­me prí­kaz

dpkg –i rpm –u no­d32ls-2.50-2.i386.deb

Po nain­šta­lo­va­ní ba­lí­ka sa pres­ved­čí­me, či na po­za­dí bež­ia naj­me­nej dve in­štan­cie dé­mo­na no­d32d. Za­dá­me prí­kaz

 [root@ru­bin in­stall] # ps -C no­d32d

Ak na ob­ra­zov­ke mo­ni­to­ra vi­dí­me nie­čo ta­ké­to:

PID      TTY             TI­ME          CMD
2631      ?              00:00:00         no­d32d
2632      ?              00:00:00         no­d32d
 

je to v po­riad­ku. Ak po­dob­ný vý­pis neu­vi­dí­me, niek­de je chy­ba. Naj­čas­tej­šie to bý­va prá­ve ab­sen­cia li­cen­čné­ho sú­bo­ru v ad­re­sá­ri /etc/no­d32/li­cen­ce/.

Opis sú­bo­rov
Po vy­ko­na­ní in­šta­lá­cie sa vy­tvo­rí ad­re­sár /etc/no­d32/. V ňom sa nac­hád­za nie­koľ­ko dô­le­ži­tých sú­bo­rov.

/etc/no­d32/no­d32.cfg
To­to je naj­dô­le­ži­tej­ší kon­fi­gu­rač­ný sú­bor ce­lé­ho anti­ví­ru­so­vé­ho sys­té­mu. V ňom sa nas­ta­vu­jú rôz­ne pa­ra­met­re, kto­ré ov­plyv­ňu­jú sprá­va­nie ce­lé­ho sys­té­mu. Je roz­de­le­ný do sek­cií a kaž­dá sek­cia sa za­čí­na me­nom sek­cie, uzav­re­tým v hra­na­tých zá­tvor­kách [ a ]. Nie je te­raz mož­né preb­rať v ča­so­pi­se kon­fi­gu­rá­ciu všet­kých pa­ra­met­rov, spo­me­nie­me len tie naj­dô­le­ži­tej­šie. Os­tat­né si mu­sí­me naš­tu­do­vať v ma­nuá­lo­vej strán­ke prí­ka­zom man no­d32.cfg.

/etc/no­d32/no­d32.auth
To­to je auten­ti­fi­kač­ný sú­bor, kto­rý sa po­uží­va na nas­ta­ve­nie prís­tu­po­vých práv na ak­tua­li­zá­ciu da­ta­bá­zy ví­ru­so­vých sig­na­túr (vzo­riek) z cen­trál­ne­ho server­a. Je­ho nas­ta­ve­nie si uká­že­me nes­kôr.

/etc/no­d32/sig_*.html.examp­le
To sú v po­dsta­te šty­ri sú­bo­ry – sig_foo­ter_clean.html.examp­le, sig_hea­der_clean.html.examp­le, sig_foo­ter_in­fec­ted.html.examp­le a sig_hea­der_in­fec­ted.html.examp­le. Sú to vzo­ro­vé sú­bo­ry, kto­ré na zá­kla­de kon­tro­ly bu­dú pri­da­né do po­što­vej sprá­vy. Aby to tak bo­lo, mu­sí­me v sú­bo­re no­d32.cfg v sek­cii [glo­bal] nas­ta­viť po­lož­ku wri­te_to_emails. Zá­ro­veň mu­sí­me z uve­de­ných sú­bo­rov od­tr­hnúť prí­po­nu .examp­le. Ta­kis­to mô­že­me tie­to sú­bo­ry vhod­ne up­ra­viť, nap­rík­lad pre­pí­sať z an­glič­ti­ny do slo­ven­či­ny a po­dob­ne.

/etc/no­d32/li­cen­ce/
Do toh­to ad­re­sá­ra uk­la­dá­me sú­bo­ry s li­cen­čný­mi kľúč­mi, kto­ré dos­ta­ne­me pri ná­ku­pe anti­ví­ru­so­vé­ho prog­ra­mu.

/etc/no­d32/no­d32d_script
Ak ske­ner NO­D32náj­de ví­rus v ske­no­va­nej sprá­ve, ten­to spus­ti­teľ­ný skrip­to­va­cí sú­bor po­šle ozná­me­nie o náj­de­nom ví­ru­se vop­red de­fi­no­va­né­mu po­uží­va­te­ľo­vi. Aby sme ten­to skript moh­li vy­užiť, mu­sí­me v sú­bo­re no­d32.cfg mať po­lož­ku exec_script = yes.

Ako to fun­gu­je?
Aby sme ve­de­li NO­D32LMS správ­ne vy­užiť a nas­ta­viť, mu­sí­me naj­prv po­cho­piť, ako v po­dsta­te fun­gu­je. Ob­čer­stvi­me si na­še zna­los­ti z teórie fun­go­va­nia po­šty na li­nuxovom server­i. Na ob­ráz­ku č. 1 je zá­klad­ná sché­ma po­što­vé­ho server­a, tak ako sme si ju dáv­nej­šie vy­svet­ľo­va­li.

obr.č.1 - principA.BMP
Obr. 1

Te­raz si to veľ­mi struč­ne zo­pa­kuj­me. Keď po­uží­va­teľ vy­tvo­rí po­što­vú sprá­vu vo svo­jom klien­tskom prog­ra­me MUA, po­mo­cou pro­to­ko­lu SMTP (na po­rte č. 25) ju od­ov­zdá hlav­né­mu po­što­vé­mu prog­ra­mu MTA. Ten tú­to po­štu od­oš­le za­se po­mo­cou pro­to­ko­lu SMTP do inter­ne­tu po­dob­né­mu prog­ra­mu MTA na stra­ne ad­re­sá­ta. Nao­pak, ak je z inter­ne­tu pre náš­ho po­uží­va­te­ľa do­ru­če­ná poš­ta, bu­de od­ov­zda­ná náš­mu prog­ra­mu MTA (za­se pro­to­ko­lom SMTP). Ten ju mô­že pria­mo do­ru­čiť do schrán­ky po­uží­va­te­ľa ale­bo ju mô­že od­ov­zdať do­ru­čo­va­cie­mu prog­ra­mu MDA a ten sprá­vu do­ru­čí do po­što­vej schrán­ky MAIL­BOX náš­ho po­uží­va­te­ľa. Po­uží­va­teľ si mô­že pri­ja­tú po­štu stiah­nuť na svoj po­čí­tač pro­to­ko­lom PO­P3 na po­rte 110 ale­bo ju mô­že čí­tať pria­mo v mail­boxe pro­to­ko­lom IMAP (po­rt 143). Toľ­ko teória.

A prá­ve na tej­to teó­rii je za­lo­že­ná fi­lo­zo­fia anti­ví­ru­so­vé­ho prog­ra­mu NO­D32. Ten vy­uží­va pre­nos po­što­vej sprá­vy med­zi MUA, MTA, MDA a mail­boxom. Bo­dy inter­nej ko­mu­ni­ká­cie pre­no­su sprá­vy sú na ob­ráz­ku č. 1 ozna­če­né ako S1, S2 a S3. Tým vzni­ka­jú tri mož­né sce­ná­re anti­ví­ru­so­vej oc­hra­ny:

1. Kon­tro­la pric­hád­za­jú­cej po­šty
Bod S1 uka­zu­je, kde mož­no vy­ko­ná­vať kon­tro­lu sprá­vy, kto­rá pric­hád­za z inter­ne­tu do mies­tnej po­što­vej schrán­ky náš­ho po­uží­va­te­ľa.
2. Kon­tro­la od­chád­za­jú­cej sprá­vy
Bod S2 uka­zu­je, kde mož­no vy­ko­ná­vať kon­tro­lu sprá­vy, kto­rú vy­tvo­ril po­uží­va­teľ a kto­rá bu­de od­os­la­ná do inter­ne­tu.
3. Oboj­smer­ná kon­tro­la
Bod S3 uka­zu­je, kde mož­no vy­ko­ná­vať kon­tro­lu obid­vo­ma smer­mi – pric­hád­za­jú­cej aj od­chád­za­jú­cej sprá­vy. Ten­to sce­nár je kom­pli­ko­va­nej­ší ako pred­chád­za­jú­ce dva. Zá­ro­veň však mô­že fun­go­vať ako anti­ví­ru­so­vá oc­hra­na nie­len vlas­tnej po­šty, ale aj po­šty, kto­rá je cez náš po­što­vý sys­tém pre­po­sie­la­ná ďa­lej do inter­ne­tu (open re­lay). V prí­pa­de, že ne­bu­de­me vy­ko­ná­vať pre­po­sie­la­nie po­šty, ne­mu­sí­me ten­to sce­nár po­užiť, pre­to­že zby­toč­ne za­ťa­žu­je po­što­vý sys­tém, a te­da aj ce­lý li­nuxový server.
A te­raz si jed­not­li­vé sce­ná­re ro­zo­be­rie­me.

Sce­nár S1 - kon­tro­la pric­hád­za­jú­cej po­šty
Na ob­ráz­ku č. 2a je vý­sek z ob­ráz­ka č. 1, zná­zor­ňu­jú­ci vet­vu pric­hád­za­jú­cej po­šty.

obr.č.2a - inboundA.BMP
obr. 2a

MTA po­štu po pri­ja­tí (nap­rík­lad z inter­ne­tu, ale mô­že to byť poš­ta aj od iné­ho lo­kál­ne­ho po­uží­va­te­ľa) od­ov­zdá do­ru­čo­va­cie­mu prog­ra­mu MDA, kto­rý ju od­ov­zdá do po­što­vej schrán­ky – mail­boxu po­uží­va­te­ľa.

Aby sme moh­li vy­ko­ná­vať kon­tro­lu pric­hád­za­jú­cej po­šty, med­zi MTA a MDA vlo­ží­me agen­ta NO­D32MDA (po­zri ob­rá­zok č. 2b).

obr.č.2b - inboundA.BMP
obr. 2b

Do­ru­čo­va­cí prog­ram – agent NO­D32MDA – za­chy­tí pric­hád­za­jú­cu po­štu, za po­mo­ci prog­ra­mu NO­D32D ju skon­tro­lu­je na prí­tom­nosť ví­ru­sov a po kon­tro­le sprá­vu od­ov­zdá sku­toč­né­mu prog­ra­mu MDA. Ten­to sce­nár je v po­dsta­te ne­zá­vis­lý od prog­ra­mov MTA a MDA. NO­D32MDA pra­cu­je s naj­zná­mej­ší­mi prog­ra­ma­mi MDA, ako je proc­mail, maildrop de­li­ver a lo­cal.mail.

Ako však po­ve­dať prog­ra­mu MTA (nap­rík­lad po­stfixu), aby po­štu od­ov­zdal prog­ra­mu NO­D32MDA?
To mô­že­me do­siah­nuť dvo­ma spô­sob­mi:
a) pre­me­no­va­ním ori­gi­nál­ne­ho MDA a je­ho náh­ra­dou
b) nas­ta­ve­ním MTA na no­d32mda
Ukáž­me si obid­va spô­so­by.

Pre­me­no­va­nie ori­gi­nál­ne­ho MDA a je­ho náh­ra­da prog­ra­mom NO­D32MDA
Pre lep­šiu pred­sta­vi­vosť si po­ved­zme, že ako MTA nám slú­ži prog­ram po­stfix (ako­že ináč...) a ako MDA po­uží­va­me dob­re zná­my proc­mail.

Ten­to spô­sob je po­mer­ne jed­no­duc­hý a vhod­ný, le­bo ne­mu­sí­me vy­ko­ná­vať ni­ja­ké zme­ny v kon­fi­gu­rač­nom sú­bo­re MTA po­stfixu a ani MDA proc­mai­lu. Pred­stav­me si, že má­me po­stfix a proc­mail už nas­ta­ve­ný a funkč­ný – tak ako sme si to opi­so­va­li v pred­chád­za­jú­cich čas­tiach se­riá­lu.

Ako pr­vý krok za­dá­me v shel­li prí­kaz:

 [root@ru­bin root] # which proc­mail

kto­rým vy­hľa­dá­me mies­to, kde sa nac­hád­za bi­nár­ny sú­bor prog­ra­mu proc­mail. Na ob­ra­zov­ke uvi­dí­me úpl­nú ces­tu k to­mu­to sú­bo­ru, nap­rík­lad /usr/bin/proc­mail. Te­raz pre­me­nu­je­me sú­bor proc­mail na iný, nap­rík­lad proc­mail.real. To do­siah­ne­me prí­ka­zom

 [root@ru­bin root] # mv /usr/bin/proc­mail /usr/bin/proc­mail.real

Keď­že sa prog­ram po­stfix vo svo­jom kon­fi­gu­rač­nom sú­bo­re od­vo­lá­va na prog­ram proc­mail, vy­tvo­rí­me sym­bo­lic­kú lin­ku s náz­vom proc­mail, kto­rá bu­de v sku­toč­nos­ti od­ka­zo­vať na prog­ram no­d32mda:

 [root@ru­bin root] # ln –s /usr/bin/no­d32mda /usr/bin/proc­mail

Tým­to sme sa vy­hli zby­toč­ným zme­nám kon­fi­gu­rá­cie po­stfixu. Od­te­raz sí­ce po­stfix sprá­vu od­ov­zdá prog­ra­mu s náz­vom proc­mail, ale to je v sku­toč­nos­ti prog­ram no­d32mda, kto­rý sa za ná­zov proc­mail po­mo­cou sym­bo­lic­kej lin­ky iba scho­vá­va!

Aby prog­ram no­d32mda mo­hol po ví­ru­so­vej kon­tro­le po­štu od­ov­zdať sku­toč­né­mu prog­ra­mu proc­mail (kto­rý sa vlas­tne te­raz na­zý­va proc­mail.real), mu­sí­me up­ra­viť kon­fi­gu­rač­ný sú­bor /etc/no­d32/no­d32.cfg.

Vy­hľa­dá­me ria­dok s textom mda_path a up­ra­ví­me ho tak­to:

mda_path = “/usr/bin/proc­mail.real”

Po tom­to kro­ku reš­tar­tu­je­me dé­mon no­d32d, aby si na­čí­tal no­vú kon­fi­gu­rá­ciu sú­bo­ru no­d32.cfg.

Ho­ci ten­to va­riant je v po­dsta­te jed­no­duc­hý a asi naj­vhod­nej­ší, je tu ur­či­té ri­zi­ko. Keď bu­de­me z ne­ja­ké­ho dô­vo­du vy­ko­ná­vať up­gra­de prog­ra­mu proc­mail, in­šta­lač­ný prog­ram vy­tvo­rí no­vý sú­bor s náz­vom proc­mail a po­ru­ší na­šu ce­lú fi­lo­zo­fiu. Pre­to bu­de­me mu­sieť spo­mí­na­né kro­ky uro­biť po kaž­dej vý­me­ne proc­mai­lu zno­va.

Nas­ta­ve­nie no­d32mda v MTA na sku­toč­ný MDA
Aby sme sa vy­hli spo­mí­na­ným prob­lé­mom, mô­že­me ce­lé nas­ta­ve­nie uro­biť inak. Ten­to­raz mu­sí­me za­siah­nuť do kon­fi­gu­rač­né­ho sú­bo­ru prog­ra­mu po­stfix. Je to sú­bor /etc/po­stfix/main.cf. Vy­hľa­dá­me po­lož­ku s náz­vom mail­box_com­mand a up­ra­ví­me ju tak­to:

mail­box_com­mand = no­d32mda –d “$USER” “$EXTEN­SION”
Po tej­to úp­ra­ve bu­de po­stfix od­ov­zdá­vať po­štu prog­ra­mu no­d32mda. Ten v spo­lup­rá­ci s dé­mo­nom no­d32d vy­ko­ná anti­ví­ru­so­vú kon­tro­lu a po­tom od­ov­zdá po­štu na ďal­šie spra­co­va­nie prog­ra­mu proc­mail. Ale kde ho má hľa­dať? Up­ra­ví­me sú­bor /etc/no­d32/no­d32.cfg. V sek­cii [mda] vy­hľa­dá­me po­lož­ku mda_path a up­ra­ví­me tak­to:
mda_path = “/usr/bin/proc­mail”

Ten­to­raz sa od­vo­lá­va­me na nao­zajst­ný prog­ram proc­mail. Reš­tar­tu­je­me po­stfix aj no­d32d, aby si na­čí­ta­li no­vú kon­fi­gu­rá­ciu z kon­fi­gu­rač­ných sú­bo­rov.

Sce­nár S2 - kon­tro­la od­chád­za­jú­cej po­šty
Kon­tro­lu od­chád­za­jú­cej po­šty je vhod­né vy­ko­ná­vať v mies­te, kde sprá­va od­chád­za z klien­tske­ho prog­ra­mu MUA (napr. Ope­ra, Thun­der­bird, Out­look a iné) do prog­ra­mu MTA (po­stfix). Na ob­ráz­ku č. 1 je to naz­na­če­né ako bod S2. Pri­po­jiť do toh­to bo­du anti­ví­ru­so­vú kon­tro­lu je troc­hu zlo­ži­tej­šie ako v prí­pa­de kon­tro­ly pric­hád­za­jú­cej po­šty. Na ob­ráz­ku č. 3 je sché­ma sce­ná­ra kon­tro­ly od­chád­za­jú­cej po­šty.

obr.č.3 - outboundA.BMP
obr. 3

Po­dsta­ta kon­tro­ly od­chád­za­jú­cej po­šty je za­lo­že­ná na prog­ra­me no­d32smtp. Je to fil­ter (dé­mon), kto­rý na­čú­va na po­rte 2525 a má tie­to tri hlav­né úlo­hy:
pri­jí­mať po­što­vé sprá­vy cez so­ket INET
po­sie­lať sprá­vy dé­mo­nu no­d32d na kon­tro­lu
skon­tro­lo­va­né sprá­vy od­ov­zdá­vať prog­ra­mu MTA

Prog­ram no­d32smtp, sa­moz­rej­me, ko­mu­ni­ku­je po­mo­cou pro­to­ko­lu SMTP. Je­ho kon­fi­gu­rá­ciu nas­ta­ví­me v sú­bo­re no­d32.cfg v sek­cii [smtp]. Sú to tie­to pa­ra­met­re:
lis­ten_addr – ur­ču­je ad­re­su, na kto­rej bu­de na­čú­vať
lis­ten_port – ur­ču­je po­rt SMTP, kde bu­de na­čú­vať
server_addr – ur­ču­je ad­re­su SMTP server­a, kto­ré­mu bu­de poš­ta po kon­tro­le od­ov­zda­ná
server_port – ur­ču­je po­rt SMTP server­a, kto­ré­mu bu­de poš­ta po kon­tro­le od­ov­zda­ná

Keď­že ce­lá fi­lo­zo­fia kon­tro­ly od­chád­za­jú­cej po­šty je za­lo­že­ná na myš­lien­ke, že po­štu bu­de­me pri­jí­mať od MUA na po­rte 2525 a po kon­tro­le bu­de od­ov­zda­ná lo­kál­ne­mu prog­ra­mu MTA (po­stfixu), kto­rý na­čú­va na po­rte 25, hod­no­ty spo­me­nu­tých pa­ra­met­rov bu­dú (naj­čas­tej­šie) ta­ké­to:
lis­ten_addr = “lo­cal­host”
lis­ten_port = 2525
server_addr = “lo­cal­host”
server_port = 25

Len­že my vie­me, že po­što­vé klien­tske prog­ra­my ko­mu­ni­ku­jú so server­om pro­to­ko­lom SMTP na po­rte čís­lo 25! Tak ako dos­tať po­štu na po­rt 2525? Na to vy­uži­je­me zvlášt­ny, nám eš­te nez­ná­my prog­ram ip­tab­les. Pred­stav­me si, že má­me čís­lo na­šej lo­kál­nej sie­te 192.168.1.0 a mas­ku 255.255.255.0

Prí­ka­zom

ip­tab­les -I PRE­ROU­TING -t nat -p tcp -s 192.168.1.0/24 --dport 25 -j RE­DI­RECT --to-po­rts 2525

za­bez­pe­čí­me, že kaž­dý pa­ket, kto­rý pô­jde na po­rt 25, sa pres­me­ru­je na po­rt 2525!

Zna­ko­vá po­znám­ka:
Ip­tab­les mí­nus veľ­ké i. Po­čet mí­nu­sov pred slo­vom to-po­rts je dva a sú dô­le­ži­té!

Po­tom už len sta­čí prí­ka­zom

servic­e no­d32smtp start 

spus­tiť kon­tro­lu od­chád­za­jú­cej po­šty. A ho­to­vo! Ale­bo nie? Zna­lej­ší mô­žu vi­dieť, že dé­mon no­d32smtp fun­gu­je, ale vzni­ká je­den neo­ča­ká­va­ný efekt. V tom­to nas­ta­ve­ní dé­mon no­d32smtp fun­gu­je ako open re­lay. To pre­to, že dé­mon ak­cep­tu­je všet­ky pa­ke­ty, kto­ré prí­du na po­rt 2525, a to aj mi­mo na­šej lo­kál­nej sie­te. Tie po­tom no­d32smtp dé­mon pre­poš­le na po­rt 25 a prog­ram MTA po­stfix ich nor­mál­ne spra­cu­je, pre­to­že to po­va­žu­je za lo­kál­nu pre­vád­zku. Tým vznik­ne v na­šom sys­té­me ne­dob­rá di­era. Pre­to ju mu­sí­me za­plá­tať. Po­uži­je­me na to zno­vu prog­ram ip­tab­les. Za­dá­me prí­kaz

ip­tab­les -I IN­PUT -p tcp -s ! 192.168.1.0/24 --dport 2525 -j DROP

kto­rý ho­vo­rí, že všet­ky pa­ke­ty, kto­ré ne­poc­hád­za­jú z na­šej sie­te a pris­tu­pu­jú na po­rt č.2525, bu­dú za­ho­de­né.

Nas­ta­ve­nie
Aby nám to­to všet­ko fun­go­va­lo už po za­pnu­tí po­čí­ta­ča a boo­to­va­ní Li­nuxu, mu­sí­me uro­biť nie­koľ­ko úp­rav. In­šta­lač­ný skript anti­ví­ru­so­vé­ho prog­ra­mu sám za­bez­pe­čil už pri in­šta­lá­cii, aby sa vy­tvo­ril štar­to­va­cí skript pre dé­mon no­d32d v pat­rič­ných úrov­niach be­hu. Ok­rem to­ho my mu­sí­me za­bez­pe­čiť, aby sa auto­ma­tic­ky spúš­ťal aj prog­ram no­d32smtp. To do­siah­ne­me prí­ka­zom

 [root@ru­bin root] # chkcon­fig --add no­d32smtp

čím sa ta­kis­to vy­tvo­ria po­ža­do­va­né štar­to­va­cie skrip­ty.

Na­ko­niec mu­sí­me za­bez­pe­čiť, aby sa všet­ky pres­me­ro­va­nia po­mo­cou ip­tab­les vy­ko­na­li už pri štar­te. To do­siah­ne­me tým, že uve­de­né prí­ka­zy s ip­tab­les za­pí­še­me do sú­bo­ru /etc/rc.d/rc.lo­cal.

Auto­ma­tic­ká ak­tua­li­zá­cia da­ta­bá­zy ví­ru­so­vých vzo­riek
To, čo dá­va pred­nosť ko­mer­čným anti­ví­ru­so­vým prog­ra­mom pred free prog­ra­ma­mi, je veľ­mi čas­tá ak­tua­li­zá­cia da­ta­bá­zy vzo­riek so špe­ci­fic­ký­mi znak­mi ví­ru­sov. Bez pra­vi­del­nej ak­tua­li­zá­cie sí­ce bu­de anti­ví­ru­so­vá oc­hra­na fun­go­vať, ale pro­ti naj­nov­ším ví­ru­som ne­bu­de účin­ná. Kto za­žil na­pad­nu­tie svoj­ho po­čí­ta­ča len pre­to, že neak­tua­li­zo­val da­ta­bá­zu vzo­riek, vie, o čom ho­vo­rím!

Na auto­ma­tic­kú ak­tua­li­zá­ciu slú­ži skript /usr/sbin/no­d32_up­da­te. Ten ak­tua­li­zu­je da­ta­bá­zu z ad­re­sy http://www.no­d32.com. To­to mož­no, sa­moz­rej­me, zme­niť jed­no­duc­hým edi­to­va­ním uve­de­né­ho skrip­tu. Aby sme moh­li ak­tua­li­zá­ciu vy­ko­ná­vať, mu­sí­me up­ra­viť už spo­mí­na­ný kon­fi­gu­rač­ný sú­bor /etc/no­d32/no­d32.auth.

Do toh­to sú­bo­ru za­dá­me me­no a hes­lo, kto­ré sme dos­ta­li od pre­daj­cu anti­ví­ru­so­vé­ho prog­ra­mu, nap­rík­lad tak­to:

user­na­me=AV-2631455
password=dv3q7nrm76

Po­znám­ka:
Tu uve­de­né me­no a hes­lo nie sú sku­toč­né! Eš­te sa mu­sí­me pres­ved­čiť, či ten­to sú­bor má at­ri­bú­ty rw------- (600), inak ich sta­no­ví­me prí­ka­zom

 [root@ru­bin no­d32] # chmod 600 /etc/no­d32/no­d32.auth

Na­ko­niec mu­sí­me za­bez­pe­čiť, aby bol skript vy­ko­ná­va­jú­ci ak­tua­li­zá­ciu da­ta­bá­zy pra­vi­del­ne spúš­ťa­ný, naj­lep­šie kaž­dú ce­lú ho­di­nu. Na to vy­uži­je­me nám už zná­my prog­ram cron. Za­dá­me prí­kaz cron­tab -e a dopl­ní­me ria­dok

0 * * * * /usr/sbin/no­d32_up­da­te

Od­ov­zdá­va­nie vzo­riek ví­ru­sov
Už sme uvied­li, že ak­tua­li­zá­cia vzo­riek je vý­bor­ná vec. Ale aby moh­li špe­cia­lis­ti na ví­ru­sy ak­tua­li­zá­cie vy­tvá­rať, mu­sia od nie­ko­ho dos­tá­vať vzor­ky no­vých ví­ru­sov, kto­ré bo­li od­ha­le­né heu­ris­tic­kou me­tó­dou. Pre­to by sme aj my moh­li pris­pieť „svo­jou troš­kou do mly­na“ a na na­šom anti­ví­ru­so­vom sys­té­me za­pne­me od­ov­zdá­va­nie ví­ru­so­vých vzo­riek – tak­zva­ný samp­le sub­mis­sion sys­tem.

To uro­bí­me tak, že v sú­bo­re /etc/no­d32/no­d32.cfg nas­ta­ví­me po­lož­ky sam­ples_enab­led a sam­ples_send_enab­led na yes.

To by na­te­raz sta­či­lo, na­bu­dú­ce sa bu­de­me ve­no­vať NO­D32 pre Li­nux Fi­le Server.

Ďal­šie čas­ti >>

Zdroj: Infoware 2/2006



Ohodnoťte článok:
   
 

24 hodín

týždeň

mesiac

Najnovšie články

Li­nux prak­tic­ky ako server úvod
Linux ako server je pomerne zložitá technológia. Jej výhodou je určitá modularita, keď sa nemusí nastaviť celý server naraz, ale postupne. čítať »
 
Syn­chro­ni­zá­cia ča­su v Li­nuxe
V predchádzajúcich dvoch častiach sme si ukázali, že Linux a všeobecne open source softvér sa nenachádza iba v serveroch a počítačových sieťach, ale aj v iných zariadeniach bežnej domácej potreby a v oblasti hobby. čítať »
 
Za­ria­de­nia za­lo­že­né na Li­nuxe
V predchádzajúcej časti sme si spomenuli definície nie - ktorých pojmov z oblasti nášho záujmu, teda Linuxu. Vysvetlili sme si, čo je to Open Source, Public Domain, proprietárny softvér a GNU GPL. Tentoraz ukážeme, ako sa tieto pojmy využívajú v praxi. čítať »
 
Po­jmy z ob­las­ti
Tentoraz na chvíľu trochu odbočíme od bezpečnosti Linuxu a jeho siete. V tejto neštandardnej časti seriálu sa mu budeme venovať len okrajovo. čítať »
 
Bez­peč­nosť bez­drô­to­vých sie­tí II.
V predchádzajúcej časti sme sa začali zaoberať bezpečnosťou bezdrôtových sietí. Poukázali sme na rôzne faktory zneužitia siete, podstatu rizika a vysvetlili sme základné prvky bezpečnosti. čítať »
 
Bez­peč­nosť bez­drô­to­vých sie­tí I.
V predchádzajúcich častiach sme sa venovali bezpečnosti linuxového servera. Riešili sme firewall, bezpečnosť prístupu na internet, zaoberali sme sa demilitarizovanou zónou a podobne. čítať »
 
Údr­žba lo­gov – kon­fi­gu­rá­cia log­ro­ta­te
V predchádzajúcej časti sme sa venovali rotácii logov. Vysvetlili sme princíp ukladania logov, spôsob, ako sa rotujú, a uviedli sme niečo o tom, čo a ako treba nastaviť čítať »
 
Údr­žba lo­gov – ro­tá­cia
V predošlej časti sme sa zaoberali spôsobom logovania informácií na iný alebo vzdialený počítač a ukázali sme, ako riešiť problém s logovaním uzavretých procesov pomocou chroot. čítať »
 
 
 
  Zdieľaj cez Facebook Zdieľaj cez Google+ Zdieľaj cez Twitter Zdieľaj cez LinkedIn Správy z RSS Správy na smartfóne Správy cez newsletter