Forum » Omrežja in internet » e-mail spoofing s telnet povezavo na port 25 SMTP strežnika
e-mail spoofing s telnet povezavo na port 25 SMTP strežnika
zalla ::
Hej.
Zanima me če kdo ve kaj več o tej zadevi.
Našla sem:
1)SMTP strežniki ne poznajo autentikacije, zaradi česar se lahko, če to dopuščajo njegove nastavitve (če jih, take strežnike imenujemo open relay oz strežniki, ki omogočajo odprto povezavo), nanj s telnetom poveže kdorkoli in s posebnimi ukazi pošlje elektronsko sporočilo, pri katerem oseba za pošiljatelja lahko navede katerikoli naslov, pravi ali izmišljeni, le oblikovan mora biti pravilno.
2) Telnet to Port 25
• Mail is sent across the Internet using SMTP (Simple Mail Transfer Protocol) servers listening on port 25.
• An attacker can telnet to port 25 of a mail servers pretending to be another mail server:
telnet ip-address 25
Once connected, the spoofer types:
helo
mail from:spoofed-emailaddress
rcpt to: target-email-address
datat
he message you want to send, followed by a period
Telnet to Port 25
• In mail relaying, an attacker uses a mail server to send mail to someone in adifferent domain.
• The most basic form of mail spoofing protection is to check that the recipient’s domain is the same as the mail server’s.
• Newer SMTP servers also check for any remote connection that the To: and From: addresses are from the server’s domain.
• To bypass the previous restrictions: An attacker can run his own mail server.
Sledeče sem prevedla takole:
Napadalec se lahko s pomočjo telneta poveže direktno na »open relay« poštni strežnik preko vrat 25, pri čemer se pretvarja, da je nek drug poštni strežnik. S pomočjo teleneta nato na tem poštnem strežniku sestavi elektronsko sporočilo in ga pošlje tarči, ki ima drugo domeno - uporablja drug SMTP strežnik.
Kako lahko to prevaro odkrijemo? Preveriti moramo, ali je domena prejemnika (administrator@gmail.com) enaka kot domena poštnega strežnika pošiljatelja. Novejši poštni strežniki pa tudi že preverjajo za možnost oddaljene povezave , torej da sta From in To polji iz iste strežniške domene.Če napadalec uporablja svoj poštni strežnik, pa si z omenjenim ne moremo kaj dosti pomagati. Je pa res, da se bo v glavi elektronskega sporočila pokazal naslov »napadalčevega« strežnika, zaradi česar se ga da izslediti.
Delov, ki so označeni krepko ne razumem ravno. Oziroma zakaj je važno da tarča uporablja drug smtp strežnik, itd.
Če kdo pozna to ali pa pozna kak dober vir, ki to malce bolj razloži, bi mu/ji bila FUL hvaležna za pomoč.
Zanima me če kdo ve kaj več o tej zadevi.
Našla sem:
1)SMTP strežniki ne poznajo autentikacije, zaradi česar se lahko, če to dopuščajo njegove nastavitve (če jih, take strežnike imenujemo open relay oz strežniki, ki omogočajo odprto povezavo), nanj s telnetom poveže kdorkoli in s posebnimi ukazi pošlje elektronsko sporočilo, pri katerem oseba za pošiljatelja lahko navede katerikoli naslov, pravi ali izmišljeni, le oblikovan mora biti pravilno.
2) Telnet to Port 25
• Mail is sent across the Internet using SMTP (Simple Mail Transfer Protocol) servers listening on port 25.
• An attacker can telnet to port 25 of a mail servers pretending to be another mail server:
telnet ip-address 25
Once connected, the spoofer types:
helo
mail from:spoofed-emailaddress
rcpt to: target-email-address
datat
he message you want to send, followed by a period
Telnet to Port 25
• In mail relaying, an attacker uses a mail server to send mail to someone in adifferent domain.
• The most basic form of mail spoofing protection is to check that the recipient’s domain is the same as the mail server’s.
• Newer SMTP servers also check for any remote connection that the To: and From: addresses are from the server’s domain.
• To bypass the previous restrictions: An attacker can run his own mail server.
Sledeče sem prevedla takole:
Napadalec se lahko s pomočjo telneta poveže direktno na »open relay« poštni strežnik preko vrat 25, pri čemer se pretvarja, da je nek drug poštni strežnik. S pomočjo teleneta nato na tem poštnem strežniku sestavi elektronsko sporočilo in ga pošlje tarči, ki ima drugo domeno - uporablja drug SMTP strežnik.
Kako lahko to prevaro odkrijemo? Preveriti moramo, ali je domena prejemnika (administrator@gmail.com) enaka kot domena poštnega strežnika pošiljatelja. Novejši poštni strežniki pa tudi že preverjajo za možnost oddaljene povezave , torej da sta From in To polji iz iste strežniške domene.Če napadalec uporablja svoj poštni strežnik, pa si z omenjenim ne moremo kaj dosti pomagati. Je pa res, da se bo v glavi elektronskega sporočila pokazal naslov »napadalčevega« strežnika, zaradi česar se ga da izslediti.
Delov, ki so označeni krepko ne razumem ravno. Oziroma zakaj je važno da tarča uporablja drug smtp strežnik, itd.
Če kdo pozna to ali pa pozna kak dober vir, ki to malce bolj razloži, bi mu/ji bila FUL hvaležna za pomoč.
BlueRunner ::
Tole je nekdo zelo narobe napisal.
To drži.
To ne drži. To ni zaščita pred lažnim predstavljanjem (spoofing == lažno predstavljanje) ampak zaščita pred posredovanjem tuje pošte (3rd party mail relaying).
Tuja pošta je tista, za katero velja, da moj strežnik ni izvor in moj strežnik ni končna destinacija.
To je neumnost, ki je ne počne nihče, ker tudi ne bi pri ničemer pomagala. To bi pomenilo, da bi lahko strežnik npr. za email.si prejemal pošto samo od uporabnikov, ki imajo "From" iz email.si in so naslovljeni za email.si. Lahko si misliš, da če bi bili strežniki tako nastavljeni, verjetno ne bi mogla kaj veliko komunicirati s svetom.
Znova neumnost. SMTP strežnik ne loči med vrstami odjemalcev, ki se na njega povezujejo. To je lahko drug SMTP strežnik, navaden poštni odjemalec, odjemalec za telnet ali pa kar goli netcat. Če poznaš SMTP protokol in RFC2822 lahko stvari odkucaš na roke odkucaš in ne rabiš nikakršnega "dodatnega SMTP strežnika".
Sicer ne vem kaj pišeš/prevajaš, ampak vir, ki si ga našla je b.v. Primer ne deluje, sklepi pa so 75% napačni in 25% pa ne govorijo o lažnem predstavljanju.
In mail relaying, an attacker uses a mail server to send mail to someone in adifferent domain.
To drži.
The most basic form of mail spoofing protection is to check that the recipient's domain is the same as the mail server's.
To ne drži. To ni zaščita pred lažnim predstavljanjem (spoofing == lažno predstavljanje) ampak zaščita pred posredovanjem tuje pošte (3rd party mail relaying).
Tuja pošta je tista, za katero velja, da moj strežnik ni izvor in moj strežnik ni končna destinacija.
Newer SMTP servers also check for any remote connection that the To: and From: addresses are from the server's domain.
To je neumnost, ki je ne počne nihče, ker tudi ne bi pri ničemer pomagala. To bi pomenilo, da bi lahko strežnik npr. za email.si prejemal pošto samo od uporabnikov, ki imajo "From" iz email.si in so naslovljeni za email.si. Lahko si misliš, da če bi bili strežniki tako nastavljeni, verjetno ne bi mogla kaj veliko komunicirati s svetom.
To bypass the previous restrictions: An attacker can run his own mail server.
Znova neumnost. SMTP strežnik ne loči med vrstami odjemalcev, ki se na njega povezujejo. To je lahko drug SMTP strežnik, navaden poštni odjemalec, odjemalec za telnet ali pa kar goli netcat. Če poznaš SMTP protokol in RFC2822 lahko stvari odkucaš na roke odkucaš in ne rabiš nikakršnega "dodatnega SMTP strežnika".
Sicer ne vem kaj pišeš/prevajaš, ampak vir, ki si ga našla je b.v. Primer ne deluje, sklepi pa so 75% napačni in 25% pa ne govorijo o lažnem predstavljanju.
zalla ::
Sledeče rabim za diplomsko nalogo ;)
Vir se sicer zdi korekten. Napisano sem namreč našla na spodnjem naslovu:
http://www.scribd.com/doc/19362354/-web... (str. 9)
Drugače pa ful hvala ;)
Vir se sicer zdi korekten. Napisano sem namreč našla na spodnjem naslovu:
http://www.scribd.com/doc/19362354/-web... (str. 9)
Drugače pa ful hvala ;)
BlueRunner ::
Sicer pa gre zgodba tako:
3rd party relaying je bolj ali manj povsod onemogočen zato, ker se ga izkorišča za razpošiljanje SPAM-a. Poanta je v temu, da če pošiljaš 1,000.000.000 kopij sporočila iz enega računalnika s počasno povezavo, bo to traaaaaaaaajalo. Lahko pa najdeš 3rd party relay, ki mu pošlješ 1 kopijo sporočila in seznam 1,000.000.000 naslovnikov. Potem pa ta strežnik (tipično z dobro povezljivostjo do preostalega sveta) razpošilja namesto tebe.
Zakaj tega vzdrževalci ne prenašajo je iz razlage upam, da možno sklepati...
Tako imaš danes strežnike pri sprejemanju pošte nastavljene, da delajo po naslednjem postopku.
1) Sprejmi podatek iz "MAIL FROM".
2) Sprejmi podatek iz "RCPT TO".
3) Preveri, če sem jaz (strežnik) končna destinacija sporočila.
4) Sprejmi sporočilo, če sem in zaključi.
5) Preveri, če je pošiljatelj povezan iz domačega IP omrežja.
6) Sprejmi sporočilo, če je pošiljatelj povezan iz domačega IP omrežja in zaključi.
7) V ostalih primerih zavrni sprejem sporočila.
Variacija na temo je v 6. koraku, kjer ponudniki, kot so npr. Google ali pa Yahoo nimajo svojega omrežja, kot ga sicer imajo ISP-ji in podjetja (v podjetjih je to tipično samo notranje, zasebno omrežje). Takšni ponudniki "svojo stranko" razpoznajo s pomočjo avtentikacije (SMTP AUTH in variacije na temo).
Sicer pa gre štetje tako:
- 1st party je strežnik
- 2nd party so stranke ISP-ja, zaposleni v podjetju, registrirani uporabniki sistema, ...
- 3rd party so tretje - neznane osebe
Za 1st party vedno sprejmem pošto.
Za 2nd party vedno posredujem pošto (allow 2nd party relay)
Za 3rd party vedno zavrnem pošto (forbidden 3rd party relay)
Pravila pa upoštevam v zgoraj napisanem vrstnem redu. Če vrstni red zamenjam, stvar ne bo delovala pravilno.
Lažno predstavljanje (spoofing) pa je čisto ločen problem.... zato pod črto.
Večina ljudi misli, da je to, kar preberejo v svojem priljubljenem poštnem odjemalcu pod "From" in "To" kakorkoli verodostojno. Dejstvo je, da ni. Karkoli narediš na protokolu, ta podatek ni verodostojen. Lahko se greš pregledovanje celotne glave RFC2822 sporočila, pa še vedno ne boš mogla biti 100% prepričana kdo je res poslal sporočilo.
SMTP e-mail NI ekvivalent navadne pošte.
No, sedaj, ko je to razčiščeno, pa lahko povem nekaj več o temu.
Prva zadeva, ki jo srečaš sta pošiljatelj na ovojnici in prejemnik na ovojnici (envelope sender in envelope recipient). To sta podatka, ki sta navedena na nivoju SMTP protokola z ukazi "MAIL FROM" in "RCPT TO". Za pošiljatelja lahko napišeš karkoli, kar izgleda kot pravilen e-mail naslov. Za prejemnika pa moraš navesti pravilen naslov poštnega predala v katerega želiš, da sporočilo dejansko prispe.
To so bistveni podatki. Če "RCPT TO" ne bo pravilno izpolnjen in, če ga boš vpisovala na napačnem strežniku (gl. pravila za preprečevanje 3rd party relay), potem sporočilo ne bo prispelo do naslovnika.
Potem pa sledi ukaz "DATA" s katerim strežniku poveš, da sledijo podatki, ki dejansko predstavljajo vsebino sporočila. Če govorimo o RFC2822 sporočilu, je to znova razdeljeno (malo poenostavljam, zato naj mi puristi ne zamerijo - za ilustracijo bo moralo zadoščati) na dva dela: glavo in vsebino.
Glava je sestavljena iz polj, ki so zapisana v obliki "Ime_Polja: vsebina polja". V vsako vrstico pride eno polje, če odmislimo pravilo kako se polje deli na več vrstic. Nikoli pa ni v eni vrstici več kot eno polje.
Glava se zaključi tako, da zadnjemu polju sledi prazna vrstica. Za njo pa se začne tisto, kar vidiš kot vsebino sporočila.
Vsebina glave sporočila se tipično ne prikazuje v celoti, ampak se prikažejo samo osnovni in za prejemnika bistveni podatki: naslov pošiljateljev, naslov prejemnika, naslov avtorja, naslovi prejemnikov vidnih kopij, datum, ko je bilo sporočilo poslano in seveda tema sporočila (subject).
To so po istem vrstnem redu polja: From, To, Sender, CC, Date, Subject. Če katero izmed teh polj manjka, se ga pač prikaže kot praznega.
Tukaj notri pa moraš razumeti, da so polja pomembna samo za prikaz, ne pa za dejansko usmerjanje sporočila. Tako lahko na roke spišeš sporočilo, ki ga bo na podlagi naslova v ovojnici ("RCPT TO: pepe@firma.com") prejel Pepe, v glavi sporočila pa bo lahko pisalo tudi, da je prejemnik "To: metka@firma.com". Tudi tako lahko zavedeš nasprotnika in ne samo s potvarjanjem naslova pošiljatelja.
Z nekaj razmisleka lahko tako ugotoviš, da se daj spisati in poslati sporočilo, ki bo prišlo na naslov enega prejemnika, vsi podatki, ki se mu bodo privzeto prikazali, pa bodo lahko lažni (spoofani). Ravno zato, ker je eno vsebina sporočila (informativno), nekaj drugega pa naslov, ki ga navedeš "na ovojnici SMTP protokola".
Kljub temu pa SMTP strežniki v glavo dodajajo še svojo lastno vsebino, ki je pogosto dovolj bogata, da lahko sam dokaj dobro sklepaš od kje sporočilo prihaja. Morda celo od koga. Če seveda ni "napadalec" uporabil še drugih tehnik za zakrivanje izvora sporočila na IP nivoju (recimo Tor).
Moraš pa za te stvari dobiti nekaj občutka tudi tako, da pomaga, če greš v živo čez nekaj različnih glav sporočil z nekom, ki te stvari pozna in ti jih lahko lepo razkaže. Če je to včasih težko zapisato kot lep primer, pa se da zelo lepo na praktično katerem koli sporočilu demonstrirati vse osnovne tehnike ugotavljanja izvora.
Če pa želiš sporočila, pri katerih se ve kdo je pošiljatelj z visoko stopnjo zanesljivosti, pa bo potrebno poseči po digitalnih podpisih in dodatnih stvareh, kot sta recimo S/MIME ali pa PGP. Ti pristopi pa semantično popolnoma zaobidejo te težave, saj je vsa identifikacija potem vezana na preverjanje verodostojnosti digitalnega podpisa in ne na vsebine, ki jih je trivialno zapisati na zavajajoč način.
Kar se tiče pa tvojega vira, pa na njega kar pozabi. Najdi nekaj verodostojnega in ne nepreverjeno seminarsko. Knjige so dober vir, če boš poklicala na SI-CERT ti bodo tudi verjetno prisluhnili in kaj dobrega predlagali, kar boš lahk tudi citirala in ne samo prevajala.
Na žalost pa ti ne morem predlagati svoje knjige, ker je še nisem napisal.
3rd party relaying je bolj ali manj povsod onemogočen zato, ker se ga izkorišča za razpošiljanje SPAM-a. Poanta je v temu, da če pošiljaš 1,000.000.000 kopij sporočila iz enega računalnika s počasno povezavo, bo to traaaaaaaaajalo. Lahko pa najdeš 3rd party relay, ki mu pošlješ 1 kopijo sporočila in seznam 1,000.000.000 naslovnikov. Potem pa ta strežnik (tipično z dobro povezljivostjo do preostalega sveta) razpošilja namesto tebe.
Zakaj tega vzdrževalci ne prenašajo je iz razlage upam, da možno sklepati...
Tako imaš danes strežnike pri sprejemanju pošte nastavljene, da delajo po naslednjem postopku.
1) Sprejmi podatek iz "MAIL FROM".
2) Sprejmi podatek iz "RCPT TO".
3) Preveri, če sem jaz (strežnik) končna destinacija sporočila.
4) Sprejmi sporočilo, če sem in zaključi.
5) Preveri, če je pošiljatelj povezan iz domačega IP omrežja.
6) Sprejmi sporočilo, če je pošiljatelj povezan iz domačega IP omrežja in zaključi.
7) V ostalih primerih zavrni sprejem sporočila.
Variacija na temo je v 6. koraku, kjer ponudniki, kot so npr. Google ali pa Yahoo nimajo svojega omrežja, kot ga sicer imajo ISP-ji in podjetja (v podjetjih je to tipično samo notranje, zasebno omrežje). Takšni ponudniki "svojo stranko" razpoznajo s pomočjo avtentikacije (SMTP AUTH in variacije na temo).
Sicer pa gre štetje tako:
- 1st party je strežnik
- 2nd party so stranke ISP-ja, zaposleni v podjetju, registrirani uporabniki sistema, ...
- 3rd party so tretje - neznane osebe
Za 1st party vedno sprejmem pošto.
Za 2nd party vedno posredujem pošto (allow 2nd party relay)
Za 3rd party vedno zavrnem pošto (forbidden 3rd party relay)
Pravila pa upoštevam v zgoraj napisanem vrstnem redu. Če vrstni red zamenjam, stvar ne bo delovala pravilno.
Lažno predstavljanje (spoofing) pa je čisto ločen problem.... zato pod črto.
Večina ljudi misli, da je to, kar preberejo v svojem priljubljenem poštnem odjemalcu pod "From" in "To" kakorkoli verodostojno. Dejstvo je, da ni. Karkoli narediš na protokolu, ta podatek ni verodostojen. Lahko se greš pregledovanje celotne glave RFC2822 sporočila, pa še vedno ne boš mogla biti 100% prepričana kdo je res poslal sporočilo.
SMTP e-mail NI ekvivalent navadne pošte.
No, sedaj, ko je to razčiščeno, pa lahko povem nekaj več o temu.
Prva zadeva, ki jo srečaš sta pošiljatelj na ovojnici in prejemnik na ovojnici (envelope sender in envelope recipient). To sta podatka, ki sta navedena na nivoju SMTP protokola z ukazi "MAIL FROM" in "RCPT TO". Za pošiljatelja lahko napišeš karkoli, kar izgleda kot pravilen e-mail naslov. Za prejemnika pa moraš navesti pravilen naslov poštnega predala v katerega želiš, da sporočilo dejansko prispe.
To so bistveni podatki. Če "RCPT TO" ne bo pravilno izpolnjen in, če ga boš vpisovala na napačnem strežniku (gl. pravila za preprečevanje 3rd party relay), potem sporočilo ne bo prispelo do naslovnika.
Potem pa sledi ukaz "DATA" s katerim strežniku poveš, da sledijo podatki, ki dejansko predstavljajo vsebino sporočila. Če govorimo o RFC2822 sporočilu, je to znova razdeljeno (malo poenostavljam, zato naj mi puristi ne zamerijo - za ilustracijo bo moralo zadoščati) na dva dela: glavo in vsebino.
Glava je sestavljena iz polj, ki so zapisana v obliki "Ime_Polja: vsebina polja". V vsako vrstico pride eno polje, če odmislimo pravilo kako se polje deli na več vrstic. Nikoli pa ni v eni vrstici več kot eno polje.
Glava se zaključi tako, da zadnjemu polju sledi prazna vrstica. Za njo pa se začne tisto, kar vidiš kot vsebino sporočila.
Vsebina glave sporočila se tipično ne prikazuje v celoti, ampak se prikažejo samo osnovni in za prejemnika bistveni podatki: naslov pošiljateljev, naslov prejemnika, naslov avtorja, naslovi prejemnikov vidnih kopij, datum, ko je bilo sporočilo poslano in seveda tema sporočila (subject).
To so po istem vrstnem redu polja: From, To, Sender, CC, Date, Subject. Če katero izmed teh polj manjka, se ga pač prikaže kot praznega.
Tukaj notri pa moraš razumeti, da so polja pomembna samo za prikaz, ne pa za dejansko usmerjanje sporočila. Tako lahko na roke spišeš sporočilo, ki ga bo na podlagi naslova v ovojnici ("RCPT TO: pepe@firma.com") prejel Pepe, v glavi sporočila pa bo lahko pisalo tudi, da je prejemnik "To: metka@firma.com". Tudi tako lahko zavedeš nasprotnika in ne samo s potvarjanjem naslova pošiljatelja.
Z nekaj razmisleka lahko tako ugotoviš, da se daj spisati in poslati sporočilo, ki bo prišlo na naslov enega prejemnika, vsi podatki, ki se mu bodo privzeto prikazali, pa bodo lahko lažni (spoofani). Ravno zato, ker je eno vsebina sporočila (informativno), nekaj drugega pa naslov, ki ga navedeš "na ovojnici SMTP protokola".
Kljub temu pa SMTP strežniki v glavo dodajajo še svojo lastno vsebino, ki je pogosto dovolj bogata, da lahko sam dokaj dobro sklepaš od kje sporočilo prihaja. Morda celo od koga. Če seveda ni "napadalec" uporabil še drugih tehnik za zakrivanje izvora sporočila na IP nivoju (recimo Tor).
Moraš pa za te stvari dobiti nekaj občutka tudi tako, da pomaga, če greš v živo čez nekaj različnih glav sporočil z nekom, ki te stvari pozna in ti jih lahko lepo razkaže. Če je to včasih težko zapisato kot lep primer, pa se da zelo lepo na praktično katerem koli sporočilu demonstrirati vse osnovne tehnike ugotavljanja izvora.
Če pa želiš sporočila, pri katerih se ve kdo je pošiljatelj z visoko stopnjo zanesljivosti, pa bo potrebno poseči po digitalnih podpisih in dodatnih stvareh, kot sta recimo S/MIME ali pa PGP. Ti pristopi pa semantično popolnoma zaobidejo te težave, saj je vsa identifikacija potem vezana na preverjanje verodostojnosti digitalnega podpisa in ne na vsebine, ki jih je trivialno zapisati na zavajajoč način.
Kar se tiče pa tvojega vira, pa na njega kar pozabi. Najdi nekaj verodostojnega in ne nepreverjeno seminarsko. Knjige so dober vir, če boš poklicala na SI-CERT ti bodo tudi verjetno prisluhnili in kaj dobrega predlagali, kar boš lahk tudi citirala in ne samo prevajala.
Na žalost pa ti ne morem predlagati svoje knjige, ker je še nisem napisal.
x.sci ::
Odgovor na prvotno vprasanje, ker TLDR odstalega: Pri posiljanju poste posiljateljev (SMTP) streznik prejemnikovemu (SMTP) strezniku pove, od koga je posta prisla. Seveda pa posiljateljevemu strezniku nic ne preprecuje, da se ne bi lagal. In ravno to ti naredis, ko se delas, da si posiljateljev streznik (z uporabo telneta) -- prvi del bold teksta.
Zato je treba, poenostavljeno, biti previden, da ne sprejemas kar katerekoli poste (tj. da nisi open relay). Drugi del bold teksta pove, kako skonfigurirati postni streznik, da ni open relay. Ce se postavim v vlogo mojega SMTP streznika; enostavno e-mail sprejmem, ce:
- je posta zame (prejemnik v moji domeni)
- preverim se ali je To: ali From: polje (ne nujno oboje skupaj) v isti domeni kot posiljateljev server -- beri: povezava preko katere dobivam posto (to delajo "novejsi serverji" :)
Ce kaj od tegale ni res, je pa velika verjetnost, da nas hoce nekdo izrabit za spoofanje.
Je sicer res, da je zgoraj malce okorno napisano (verjetno bi bilo bolje kak or namesto and), ni pa tako zelo narobe.
Zato je treba, poenostavljeno, biti previden, da ne sprejemas kar katerekoli poste (tj. da nisi open relay). Drugi del bold teksta pove, kako skonfigurirati postni streznik, da ni open relay. Ce se postavim v vlogo mojega SMTP streznika; enostavno e-mail sprejmem, ce:
- je posta zame (prejemnik v moji domeni)
- preverim se ali je To: ali From: polje (ne nujno oboje skupaj) v isti domeni kot posiljateljev server -- beri: povezava preko katere dobivam posto (to delajo "novejsi serverji" :)
Ce kaj od tegale ni res, je pa velika verjetnost, da nas hoce nekdo izrabit za spoofanje.
Je sicer res, da je zgoraj malce okorno napisano (verjetno bi bilo bolje kak or namesto and), ni pa tako zelo narobe.
BlueRunner ::
Je sicer res, da je zgoraj malce okorno napisano (verjetno bi bilo bolje kak or namesto and), ni pa tako zelo narobe.
Kakšna je razlika med "številka mora biti manjša od 1 ALI večja od 10" ter "številka mora biti manjša od 1 IN večja od 10".
Eno je okorno, drugo je napačno. Če pa se gre za diplomo, pa je razlika še posebej pomembna (even doubly so). Zlasti zato, ker OP ne pozna tehničnega ozadja in lahko napačno izjavo pravilno prevede in jo nevede v vsej razkošni napačnosti zapiše v svoje diplomsko delo.
Zgodovina sprememb…
- spremenilo: BlueRunner ()
x.sci ::
Sem uspel prevest kot: ... izvajajo tudi pregledovanje To: in From: polj oddaljene povezave, ki morajo pripadati streznikovi domeni.
Po ponovnem branju imas verjetno prav, ker to ni dobeseden prevod originala.
Edit: Vsega so krivi Anglezi in njihova (ne)uporaba vejic... :)
Po ponovnem branju imas verjetno prav, ker to ni dobeseden prevod originala.
Edit: Vsega so krivi Anglezi in njihova (ne)uporaba vejic... :)
Zgodovina sprememb…
- spremenil: x.sci ()
zalla ::
Hvala obema - ful sta mi pomagala :)
Se mi je marsi kaj razjasnilo. Pa sedaj bom tudi vedela kaj in kje iskati ;)
Se mi je marsi kaj razjasnilo. Pa sedaj bom tudi vedela kaj in kje iskati ;)
l0g1t3ch ::
Samo nekaj.
A potem more sedaj vsak email it direktno iz pošiljateljevega na prejemnikom SMTP strežnik ?
A potem more sedaj vsak email it direktno iz pošiljateljevega na prejemnikom SMTP strežnik ?
BlueRunner ::
Zakaj bi šel koderkoli drugje?
Tvoj odjemalec pošlje SMTP strežniku, ki si ga izbral za "svojega", zato, ker ne vsebuje polne MTA funkcionalnosti.
Ta SMTP strežnik izvede potrebne DNS zahteve s katerimi najde SMTP strežnik(e) kamor mora biti sporočilo posredovano in ga poskusi tam tudi dostaviti. S tem je zgodba iz vidika prenosa sporočila preko interneta zaključena. Vmes ni potrebe za kakšne tretje javne SMTP strežnike, ker ti niso potrebni.
Še več. Če bi odjemalec imel vgrajen "pameten MTA", da bi znal sam najti naslovnikov SMTP strežnik, potem "svojega/ponudnikovega/prijateljevega/..." za samo pošiljanje sploh ne bi potreboval. Potreboval ga bi samo še za prejemanje. Tako recimo delujejo nekateri SPAM boti in nekatere namenske aplikacije za razpošiljanje SPAM pošte.
Interno pa imaš v podjetjih/ISP-ih velikokrat zunanji MTA, ki sporočilo sprejme in ga preda v naslednji strežnik, ki preveri za SPAM/AV, nato pa ta odloži na tretji strežnik, ki sporočila dejansko shrani v poštne predale.
Tvoj odjemalec pošlje SMTP strežniku, ki si ga izbral za "svojega", zato, ker ne vsebuje polne MTA funkcionalnosti.
Ta SMTP strežnik izvede potrebne DNS zahteve s katerimi najde SMTP strežnik(e) kamor mora biti sporočilo posredovano in ga poskusi tam tudi dostaviti. S tem je zgodba iz vidika prenosa sporočila preko interneta zaključena. Vmes ni potrebe za kakšne tretje javne SMTP strežnike, ker ti niso potrebni.
Še več. Če bi odjemalec imel vgrajen "pameten MTA", da bi znal sam najti naslovnikov SMTP strežnik, potem "svojega/ponudnikovega/prijateljevega/..." za samo pošiljanje sploh ne bi potreboval. Potreboval ga bi samo še za prejemanje. Tako recimo delujejo nekateri SPAM boti in nekatere namenske aplikacije za razpošiljanje SPAM pošte.
Interno pa imaš v podjetjih/ISP-ih velikokrat zunanji MTA, ki sporočilo sprejme in ga preda v naslednji strežnik, ki preveri za SPAM/AV, nato pa ta odloži na tretji strežnik, ki sporočila dejansko shrani v poštne predale.
680x0 ::
BlueRunner je izjavil:
SMTP e-mail NI ekvivalent navadne pošte.
Jaz pa bi rekel ravno obratno, email je zelo podoben navadni pošti.
Po žigu na kuverti (pri pravi) / Received: from (pri elektronski) lahko precej dobro sklepaš katera pošta / strežnik je pošto odposlala, garancija, da je pošiljatelj napisan na kuverti / v from: polju res tisti, za katerega se izdaja, pa je v obeh primerih nična.
Zalla, pri preprečevanju spoofanja pošiljateljevega naslova ne smeš mimo SPF mehanizma, ki lastniku domene omogoča, da preko DNS sistema javno oznani, kateri IP naslovi so edini sprejemljivi pošiljatelji pošte za to domeno. To informacijo končni SMTP strežnik lahko enostavno preveri in pošto, katere pošiljatelj naj bi bil s te domene, hkrati pa je ni poslal z nastavljenih IP naslovov, zavrne. Več o težavah, ki ljub temu nastajajo, pa na zogrnji povezavi.
BlueRunner ::
Jaz pa bi rekel ravno obratno, email je zelo podoben navadni pošti.
Razen treh "malenkosti", ki so:
- vsebino sporočila v prenosu lahko vidi vsakdo, ki mu gre tvoje sporočilo skozi roke
- vsebina tega, kar je napisano na SMTP "ovojnici" naslovniku tipično/velikokrat ni na razpolago
- podpis in štampiljka, ki sta v običajni pisni komunikaciji zadostna garanta o istovetnosti avtorja sporočila, v elektronski pošti brez dodatnih mehanizmov ne obstajata
x.sci ::
l0g1t3ch ::
Ja samo to sta posebna primera in logično, da gre prek večih.
Zanimal me je pa zato, ker ne vidim smisla zakaj so nekoč obstajali open relay strežniki.
Zanimal me je pa zato, ker ne vidim smisla zakaj so nekoč obstajali open relay strežniki.
BlueRunner ::
Ker je bil internet včasih (<1992) mnogo lepši in varnejši kraj za "bivakiranje".
Včasih si lahko tudi neposredno kopiral iz enega FTP strežnika na drugega.
Pa včasih svetovni splet ni bil sinonim za internet.
... in tako naprej greš lahko po stopinjah nostalgije.
Včasih si lahko tudi neposredno kopiral iz enega FTP strežnika na drugega.
Pa včasih svetovni splet ni bil sinonim za internet.
... in tako naprej greš lahko po stopinjah nostalgije.
Zgodovina sprememb…
- spremenilo: BlueRunner ()
x.sci ::
Kolikor vem, je bila stvar zastavljena s kompatibilnostjo z uucp v mislih, kjer niso (bili) vsi hosti vedno povezani in si zato rabil relaye.
BlueRunner ::
Mnja.
Po moji izkušnji se je šlo predvsem za to, da bi bil sistem robusten v smislu "slej kot prej bom našel enega, ki bo lahko sprejel in posredoval spročilo". Glede na to, da so strežniki imeli svoje težave in "težave" pa je to pomenilo, da je bil velikokrat edini način, da sporočilo spraviš skozi, samo ta, da si nekje našel en strežnik, ki ga je sprejel... Ker je bil tvoj domač trenutno nedosegljiv.
Druga stvar pa je bila ta, da je bilo veliko strežnikov tudi prehodov med različnimi e-mail svetovi: X.400, UUCP, FidoNet in morda še čim... Na UEK, če se prav spomnim, je bil tudi prehod na DecNET. Tudo to so bili strežniki, ki so sprejeli praktično karkoli, vključno s sporočilom, ki ni šlo skozi prehod na drug protokol, ampak je naprej potovalo po istem.
Za kompatibilnost z UUCP pa nisem prepričan... mislim, da ni bila stvar v kompatibilnosti ampak v možnosti uporabe za prehod.
No, SPAM je s tem zelo hitro počistil.
Po moji izkušnji se je šlo predvsem za to, da bi bil sistem robusten v smislu "slej kot prej bom našel enega, ki bo lahko sprejel in posredoval spročilo". Glede na to, da so strežniki imeli svoje težave in "težave" pa je to pomenilo, da je bil velikokrat edini način, da sporočilo spraviš skozi, samo ta, da si nekje našel en strežnik, ki ga je sprejel... Ker je bil tvoj domač trenutno nedosegljiv.
Druga stvar pa je bila ta, da je bilo veliko strežnikov tudi prehodov med različnimi e-mail svetovi: X.400, UUCP, FidoNet in morda še čim... Na UEK, če se prav spomnim, je bil tudi prehod na DecNET. Tudo to so bili strežniki, ki so sprejeli praktično karkoli, vključno s sporočilom, ki ni šlo skozi prehod na drug protokol, ampak je naprej potovalo po istem.
Za kompatibilnost z UUCP pa nisem prepričan... mislim, da ni bila stvar v kompatibilnosti ampak v možnosti uporabe za prehod.
No, SPAM je s tem zelo hitro počistil.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Težava pri pošiljanju e-pošte (T-2)Oddelek: Omrežja in internet | 2777 (2703) | jRk0 |
| » | e-mail serverOddelek: Omrežja in internet | 2249 (1790) | 'FireSTORM' |
| » | Po menjavi ponudnika problem s pošiljanjem pošteOddelek: Omrežja in internet | 5429 (4818) | Matko |
| » | vprašanja v zvezi z novico "Siol does it again" (strani: 1 2 3 )Oddelek: Omrežja in internet | 13476 (10953) | Bakunin |
| » | Siol does it again (strani: 1 2 3 4 )Oddelek: Novice / Omrežja / internet | 17175 (17175) | Bakunin |