WEBVTT
00:00:00.000 --> 00:00:01.000
Translated by Esa Lammi
(KYBS2001 course assignment at JYU.FI)
00:00:01.000 --> 00:00:21.180
36c3 intromusiikki
00:00:22.180 --> 00:00:28.540
Herald: Oletteko koskaan miettineet kuinka
kuinka väärentää sähköposti hyvin? Siinä
00:00:28.540 --> 00:00:33.369
tapauksessa voitte olla oikealla luennolla.
Meillä on seuraava puhuja. Andrew, joka
00:00:33.369 --> 00:00:41.180
työskentelee nykyisin kansallisessa CERTssa
Latviassa tietoturvatutkijana. Ja hän aikoo
00:00:41.180 --> 00:00:50.120
puhua meille sähköpostin väärentämisestä
ja nykyaikaisista anti-spoofing strategioista.
00:00:50.120 --> 00:00:53.356
Lava on sinun.
00:00:53.356 --> 00:01:04.460
Aplodeja
00:01:04.460 --> 00:01:14.490
Andrew: Tervehdys. Olen Andrew ja työs-
kentelen Latvian kansallisessa CERTssa.
00:01:14.490 --> 00:01:21.440
Yksi tavoitteistamme on kehittää sähköpostin
turvallisuuden tilaa maassamme ja teemme
00:01:21.440 --> 00:01:26.400
tätä enimmäkseen nostamalla tietoisuutta
asiasta ja tiedottamalla parhaista
00:01:26.400 --> 00:01:30.770
toimintatavoista. Ja tietenkään emme ole
ainoa organisaatio joka tekee tätä.
00:01:30.770 --> 00:01:34.420
On monia CERT yksiköitä lisää eri maissa
ja on myös useita vapaaehtois
00:01:34.420 --> 00:01:39.299
järjestöjä jotka tekevät samaa.
Sekä kaupallisia tahoja.
00:01:39.299 --> 00:01:46.060
Kuitenkin, toistaiseksi, suoraan sanoen,
menestyksemme on ollut melko
00:01:46.060 --> 00:01:54.100
vaatimatonta. Esimerkiksi, tässä on yksi
tilasto, joka on käyttöaste yhdestä
00:01:54.100 --> 00:01:59.770
tietystä teknologiasta, DMARCsta, joka
kuten opitte esityksessä on melko
00:01:59.770 --> 00:02:06.770
tärkeä ja toivon, että kaikki alkavat
käyttämään sitä. Eli vasemmalla on
00:02:06.770 --> 00:02:11.060
20 tuhatta domainia ympäri maailmaa,
jotka ovat tärkeitä domaineja tärkeille
00:02:11.060 --> 00:02:15.880
organisaatioille, joiden pitäisi tosissaan
tietää paremmin. Ja oikealla puolella
00:02:15.880 --> 00:02:24.799
näemme top 50, top 500 EU kaupallisia
domaineja ja näistä kaksi kolmasosaa
00:02:24.799 --> 00:02:29.799
eivät ole konfiguroineet DMARCia vielä.
ja niistä jotka ovat näin tehneet, valtaosa
00:02:29.799 --> 00:02:36.350
eivät ole määrittäneet tiukkaa politiikkaa.
Joten jos pitää poimia yksi asia tästä
00:02:36.350 --> 00:02:41.459
puheesta, toivon että kaikkien pitäisi
alkaa käyttämään DMARCia. Sitä on tärkeää
00:02:41.459 --> 00:02:49.120
käyttää myös domaineissa joiden ei pitäisi
lähettää sähköposteja ulos. Joten yksi
00:02:49.120 --> 00:02:56.760
selitys matalalle käyttöasteelle, luulen
olevan, että on näennäisesti liian monta
00:02:56.760 --> 00:03:04.310
kilpailevaa teknologiaa. Tämä on puheeni
sisältö. Ja tein todella parhaani
00:03:04.310 --> 00:03:12.449
tiivistääkseni sitä. Mutta kuten voitte
nähdä, on kolme lyhennettä, no myös
00:03:12.449 --> 00:03:18.739
SMTP ja näistä, SPF, DKIM ja DMARC.
Oikeastaan en muista mitkä ovat kahden
00:03:18.739 --> 00:03:25.570
kokonaiset nimet. Mutta silti ne ovat
kaikki tärkeitä. Ja tietenkin, tämä ongelma
00:03:25.570 --> 00:03:28.949
että on liikaa muotisanoja, liikaa
teknologioita, eikä ole selvää mitä kaikkia
00:03:28.949 --> 00:03:34.590
mitä meidän tulisi käyttää, se ei koske
pelkästään sähköpostia. Meillä on sama
00:03:34.590 --> 00:03:39.760
tilanne kaikkialla ja oh, tietoturvan
alueella, luulen että olemme nyt löytäneet
00:03:39.760 --> 00:03:47.880
yhden tavan ratkaista asia ja se on
penetraatiotestaus. Eli kun penetraatio
00:03:47.880 --> 00:03:53.370
testaus on tehty kunnolla ja tulokset
on julkaistu, me voimme alkaa
00:03:53.370 --> 00:03:58.190
puhumaan. Voimme siirtää keskustelun pois
suosiiko
00:03:58.190 --> 00:04:03.510
organisaatio teknologiaa A vai teknologiaa
B ja voimme sen sijaan alkaa puhumaan
00:04:03.510 --> 00:04:09.620
kysymyksistä, joilla on merkitystä, kuten
onko mahdollista jollekin kolmennelle
00:04:09.620 --> 00:04:15.310
osapuolelle väärentää organisaationne
sähköposteja ja lähettää sellaisia
00:04:15.310 --> 00:04:20.989
sähköposteja esimerkiksi asiakkaille tai
kumppaneille ja media organisaatioille
00:04:20.989 --> 00:04:24.970
siten, että he luulevat sähköpostien
tulleen todellisuudessa teidän
00:04:24.970 --> 00:04:31.810
organisaatiolta? Tästä syystä penetraatio
testaajat ovat tämän luennon avainyleisöä.
00:04:31.810 --> 00:04:36.020
Kuitenkin, toivon että kuka tahansa blue
teamilainen yleisössä kokee tämän puheen
00:04:36.020 --> 00:04:40.650
kiinnostavaksi. Olen varma, että tunnette
jo perusteet sähköpostista ja näistä
00:04:40.650 --> 00:04:43.620
teknologioista, mutta asian
tarkasteleminen toiselta puolelta,
00:04:43.620 --> 00:04:50.440
hyökkääjän puolelta, voi joskus asettaa
asiat todella oikeaan perspektiiviin.
00:04:50.440 --> 00:04:54.819
Se voi auttaa sinua ymmärtämään mihin
sinun pitäisi keskittyä ympäristöä
00:04:54.819 --> 00:05:01.009
suojatessasi. Ja lopuksi SMTP protokolla.
Teknologia, joka kulkee meidän
00:05:01.009 --> 00:05:07.720
sähköpostikeskustelujen alla on oikeasti
melko helppo ymmärtää.
00:05:07.720 --> 00:05:14.061
Ja myös vanhat opetukset koko
SMTPn matkasta, kuinka se kehittyi
00:05:14.061 --> 00:05:20.979
ja kuinka on mahdollista väärentää se
ja kuinka kaikki teknologiat koittavat
00:05:20.979 --> 00:05:27.530
estää väärentämistä. Mielestäni se on
kiinnostava tapaus ja sen pitäisi olla
00:05:27.530 --> 00:05:33.719
mielenkiintoista seurattavaksi jopa niille
joille email on uutta. Um, lopuksi. Uhka
00:05:33.719 --> 00:05:41.400
ympäristö. Eli email turvallisuus on laaja
alue. Ja tänään keskityn vain sen yhteen
00:05:41.400 --> 00:05:47.650
pieneen alueeseen, joka on onnistunut
sähköpostin väärentäminen. Tampering
00:05:47.650 --> 00:05:54.689
attacks. Ja tiedän että monet, pentestaajat
jo nyt hyödyntävät osin phishingia tai
00:05:54.689 --> 00:06:01.250
spearphishingia, emulointia heidän
toimeksiannoissaan ja. Mutta tietääkseni
00:06:01.250 --> 00:06:07.070
he tekevät sitä enimmäkseen sosiaalisen
hakkeroinnin näkökulmasta käyttäen
00:06:07.070 --> 00:06:13.090
social engineering toolkit:ia ja vastaavia
esimerkiksi. Ja se on, en halua kiistellä,
00:06:13.090 --> 00:06:16.949
tärkeää demonstroida asiakkaalle
00:06:16.949 --> 00:06:23.860
mitkä ovat riskit sosiaalisessa
hakkeroinnissa. Kuitenkin mielestäni teette
00:06:23.860 --> 00:06:28.099
asiakkaalle karhunpalveluksen jos se on
ainoa asia mitä testaatte
00:06:28.099 --> 00:06:32.650
sähköpostin näkökulmasta, koska asiakkaan,
managerin näkökulmasta joka lukee
00:06:32.650 --> 00:06:38.870
raporttinne, jos siinä mainitaan vain
social engineering hyökkäykset, silloin
00:06:38.870 --> 00:06:44.650
looginen johtopäätös on, että paras keino
mitigoida näitä uhkia on käyttäjien
00:06:44.650 --> 00:06:51.590
kouluttaminen, erityisesti niiden jotka
ovat vähiten teknisiä, kuten näet tässä
00:06:51.590 --> 00:06:55.379
esityksessä. On monia hyökkäyksiä ja
useat organisaatiot ovat niille
00:06:55.379 --> 00:07:00.230
alttiita, jotka ovat paljon niitä parempia.
Mikään määrä käyttäjäkoulutusta ei auta
00:07:00.230 --> 00:07:03.889
koska emme voi olettaa käyttäjien tutkivan
headereitä esimerkiksi käsin.
00:07:03.889 --> 00:07:10.699
Joten meidän täytyy oikeasti parantaa
sähköposti infrastruktuuriamme. Tätä ei
00:07:10.699 --> 00:07:17.009
voi kieltää. Ja lopuksi ennen siirtymistämme
oikeaan tekniseen asiaan, on pieni salaisuus
00:07:17.009 --> 00:07:21.889
jonka uskon auttavan ihmisiä, jotka eivät
työskentele sähköpostin parissa,
00:07:21.889 --> 00:07:28.159
ymmärtämään miksi meillä on näitä ongelmia
on, email admineille historiallisesti, um,
00:07:28.159 --> 00:07:38.040
he arvostavat saatavuutta järjestelmässä
ja luotettavuutta paljon enemmän
00:07:38.040 --> 00:07:44.680
kuin turvallisuutta. Ja koska tämä ei ole
ideologinen kysymys. Se on hyvin
00:07:44.680 --> 00:07:50.469
käytännön läheinen. Joten, esimerkiksi,
jos olet email, email admin organisaatiossa
00:07:50.469 --> 00:07:56.090
ja joltain käyttäjistäsi loppuu laskujen
vastaanottaminen, esimiehesi etsii
00:07:56.090 --> 00:08:01.470
sinut, kertoo tilanteesta ja pyytää
sinua kauniisti korjaamaan tilanteen
00:08:01.470 --> 00:08:06.210
niin pian kuin mahdollista, vaikka se ei
olisi sinun vikasi, jos sattuisi käymään
00:08:06.210 --> 00:08:13.509
niin että vika on emailin toisessa päässä.
Ei sinun palvelimella. Ja esimerkiksi jos,
00:08:13.509 --> 00:08:20.449
toinen esimerkki, jos sinä, jos joku sinun
työntekijöistä vastaanota sähköpostia
00:08:20.449 --> 00:08:24.969
tarpeeksi nopeasti, esimerkiksi salasanan
palauttamiseksi tai varmentaakseen
00:08:24.969 --> 00:08:30.190
sähköpostiosoitteen tai käyttääkseen usean
välineen tunnistautumista (MFA) ja he eivät
00:08:30.190 --> 00:08:33.969
voi kirjautua johonkin tärkeään järjestelmään
he etsivät sinut ja sinun täytyy
00:08:33.969 --> 00:08:39.539
ratkaista se. Mutta jos järjestelmässä on
joku tietuturva haavoittuvuus, jos se on
00:08:39.539 --> 00:08:45.540
altis spoofaus hyökkäykselle ja niin
edelleen silloin, ei käyttäjä, ei esimies
00:08:45.540 --> 00:08:50.670
normaalisti huomaa sitä. Sinä et välttämättä
huomaa, mutta olet. Sinulla on tämä
00:08:50.670 --> 00:08:55.930
haavoittuvuus. Joten siksi toki penetraatio
testaajat ovat tärkeitä. Okei.
00:08:55.930 --> 00:09:01.250
Nyt voimme viimein alkaa puhumaan teknisestä
asiasta. Ja me aloitamme lyhyellä
00:09:01.250 --> 00:09:07.190
perehtymisellä SMTP protokollaan.
SMTP on protokolla joka on kaiken email
00:09:07.190 --> 00:09:12.360
kommunikoinnin perusta ja sitä on oikeastaan
melko helpo seurata. Eli tässä on datavirta
00:09:12.360 --> 00:09:18.370
mitä tapahtuu kun yksi henkilö lähettää
sähköpostin toiselle henkilölle.
00:09:18.370 --> 00:09:21.269
Esimerkiksi Alice lähettää Bobille ja he
käyttävät eri, he työskentelevät
00:09:21.269 --> 00:09:24.970
eri yrityksissä. He käyttävät eri
domaineja. Eli mitä tapahtuu tässä on,
00:09:24.970 --> 00:09:29.290
että molemmat käyttävät, sanotaan, email
ohjelmaa kuten Outlook tai
00:09:29.290 --> 00:09:34.580
Thunderbird. Ja Alice lähettää sähköpostia.
Se kulkee SMTP protokollan läpi Alicen
00:09:34.580 --> 00:09:41.740
säkköpostipalvelimelle. Mutta on tärkeä
huomata että tämä on lähtevän postin palvelin.
00:09:41.740 --> 00:09:44.790
Yleensä organisaatioilla on kahden tyypin
palvelimia, yksi sisään tulevalle
00:09:44.790 --> 00:09:48.680
liikenteelle ja toinen lähtevälle. Pienillä
organisaatioilla se voi olla yksi palvelin
00:09:48.680 --> 00:09:52.470
mutta taas, on tärkeää pentestaajan
ajatella niitä eri järjestelminä
00:09:52.470 --> 00:09:56.680
koska niillä on, vaikka meillä olisi vain
yksi fyysinen palvelin, siinä on eri
00:09:56.680 --> 00:10:00.620
konfiguraatio lähtevälle postille ja
sisään tulevalle postille. Joten penetraatio
00:10:00.620 --> 00:10:04.899
testaajana sinun pitää tarkastaa molemmat.
Okei. Nyt, kun Alicen palvelin koittaa
00:10:04.899 --> 00:10:11.940
lähettää postin Bobin palvelimelle, on
ongelmana, että palvelimen täytyy jotenkin
00:10:11.940 --> 00:10:16.480
automaattisesti selvittää on se toinen
palvelin jolle lähettää se posti ja se
00:10:16.480 --> 00:10:25.220
tehdään käyttäen blue box MXaa, joka on
tietty DNS merkintä tyyppi MX. Eli se on
00:10:25.220 --> 00:10:29.680
jotain, jota ylläpitää Bob:in organisaatio.
Eli Bobon organisaatio, mikäli he haluavat
00:10:29.680 --> 00:10:35.360
vastaanottaa sähköpostia, he luovat tämän
DNS merkinnän. Ja sanon että. Okei. Jos
00:10:35.360 --> 00:10:38.830
haluatte lähettää sähköpostia meille,
käyttäkää tätä palvelinta. Eli sen pitäisi
00:10:38.830 --> 00:10:44.290
osoittaa Bobin palvelimeen. Ja Alicen lähtettävä
palvelin tietää Bobin vastaanottavan palvelimen
00:10:44.290 --> 00:10:50.670
osoitteen ja voi kommunikoida sille. Ja
myöhemmin Bob vastaanottaa sen postin.
00:10:50.670 --> 00:10:54.970
Eli kohta jota me pentestaajina koitamme
murtaa on todellisuudessa
00:10:54.970 --> 00:10:59.839
Alicen ja Bobin palvelimien välissä.
Ja meidän täytyy miettiä toista esimerkkiä
00:10:59.839 --> 00:11:03.511
joka on päinvastainen tapaus. Ja voit
ajatella että siinä ei ole
00:11:03.511 --> 00:11:07.110
mieltä, koska me periaatteessa
vain muutamme liikenteen suunnan.
00:11:07.110 --> 00:11:11.449
Mutta tärkeä osa tässä meille
pentestaajina on ymmärtää, että
00:11:11.449 --> 00:11:17.220
asiakas kontrolloi vain osaa tästä
transaktiosta. Jos asiakkaamme,
00:11:17.220 --> 00:11:20.760
sanotaan vaikka loppuesityksen ajan on
Alice tai Alicen organisaatio,
00:11:20.760 --> 00:11:26.750
niin toisena esimerkkinä kun lähetämme
postia Bobilta Alicelle
00:11:26.750 --> 00:11:34.600
silloin lähetämme vain sähköpostia.
Periaatteessa, osa tästä liikenteestä
00:11:34.600 --> 00:11:40.980
kulkisi Alicen palvelimien kautta. Ensim-
mäisessä esimerkissä jos lähetämme postia
00:11:40.980 --> 00:11:45.940
Alicelta Bobille, se ei menisi niin. Eli jos
se tuntuu hämmentävälle, se on OK. Palaamme
00:11:45.940 --> 00:11:51.600
tähän hieman myöhemmin. Ja lopuksi, on
kolmas esimerkki, joka näyttää samalta
00:11:51.600 --> 00:11:56.260
mutta ei ihan. Ja se on jos Alice
kommunikoi. Alice on asiakkaamme.
00:11:56.260 --> 00:12:01.070
Ja jos hän kommunikoi hänen työtoverien
kanssa, jotka ovat samassa organisaatiossa,
00:12:01.070 --> 00:12:04.320
samassa email palvelimessa, samassa
domainissa. Siinä tapauksessa, jälleen,
00:12:04.320 --> 00:12:09.000
on vähintään kaksi loogista email palvelinta,
lähtevä palvelin ja sisääntuleva palvelin.
00:12:09.000 --> 00:12:15.850
Mutta molemmat kuuluvat asiakkaallemme.
Eli nyt, jos et ollut tuttu sähköpostin kanssa,
00:12:15.850 --> 00:12:20.149
nyt olet. On todella mielenkiintoista
pohtia mitä näistä skenaarioista,
00:12:20.149 --> 00:12:27.740
kolmesta skenaariosta, on helponta suojata.
ja myöhemmin
00:12:27.740 --> 00:12:31.769
näemme miten se oikeasti tapahtuu.
Okei. Ja sitten meidän täytyy katsoa mitä
00:12:31.769 --> 00:12:38.410
oikeasti lähetetään, kun sähköpostia ollaan
lähettämässä. Eli jälleen, se käyttää SMTP
00:12:38.410 --> 00:12:44.790
protokollaa ja on tosi kiva protokolla
kuten. Kuten voit nähdä, se on vain tekstiä.
00:12:44.790 --> 00:12:48.029
Eli se on puhdas tekstiprotokolla ja sen
kanssa on helppo leikkiä, koska
00:12:48.029 --> 00:12:54.410
voit avata telnet yhteyden oikealle
palvelimelle ja voit koittaa kirjoittaa
00:12:54.410 --> 00:12:58.680
komentoja käsin. Voit koittaa väännellä
jotain tai muokata tai koittaa erilaisia
00:12:58.680 --> 00:13:05.149
erilaisia tyyppejä ja nähdä reaaliajassa
kuinka se menee. Eli vasemmalla
00:13:05.149 --> 00:13:11.209
näemme tässä kaksi osaa jotka
määrittää SMTP. Eli ensinnäkin
00:13:11.209 --> 00:13:14.720
siinä on SMTP kirjekuori, jonka periaatteessa
kytket palvelimeen. sanot hello,
00:13:14.720 --> 00:13:22.070
ja sitten sanot mitä. Määritä sähköpostin
lähettäjä ja vastaanottaja. "mail from"
00:13:22.070 --> 00:13:26.980
on lähettäjä. Vastaanottaja on Bob,
esimerkiksi. Ja sitten toinen osa alkaa
00:13:26.980 --> 00:13:32.160
datalla ja loppuu quit. Ja sitä osaa
kutsutaan kontentiksi / viestiksi.
00:13:32.160 --> 00:13:35.480
Jos haluat leikkiä sillä enemmän, tämän
määrittää eri standardi
00:13:35.480 --> 00:13:38.029
joka ei ole tärkeä pentestaajalle, mutta
jos haluat katsoa
00:13:38.029 --> 00:13:43.890
yksityiskohtia ja se voisi olla tärkeää.
Ja tämä sisäinen viesti, jota
00:13:43.890 --> 00:13:49.069
kutsutaan joko sisällöksi tai SMTP
viestiksi, se taas, se sisältää kaksi osaa.
00:13:49.069 --> 00:13:53.300
Yksi on headeri ja toinen on runko. Ja
luulen että jotkut eivät tunne emailia,
00:13:53.300 --> 00:13:57.569
mutta varmaan kaikki yleisössä tuntevat
HTTPn ja tämä
00:13:57.569 --> 00:14:02.600
näyttää melko, melko samalta. Eli helppoa
ymmärtää. Mutta mielenkiintoinen osa tässä
00:14:02.600 --> 00:14:08.550
että saatoit huomata, että meillä on
Alicen ja Bobin osoitteet kahdesti.
00:14:08.550 --> 00:14:14.350
Eli. Esimerkiksi, Alice on määritelty
toisella rivillä "mail from". Ja sitten
00:14:14.350 --> 00:14:19.709
meillä on sama osoite. alice @ hänen
organisaatio "From" headerissa. Punaiset
00:14:19.709 --> 00:14:26.810
ovat headereita. Ja sama tapahtuu Bobilla.
Miksi näin on? No, se johtuu siitä miten
00:14:26.810 --> 00:14:33.471
me näemme sähköpostin. Minä tavallisena
henkilönä, joka on käyttänyt sähköpostia
00:14:33.471 --> 00:14:39.139
jo aika paljon, näen ne yleensä kuten
vasemmalla, joka on kuin
00:14:39.139 --> 00:14:44.980
jonkinlainen postikortti. Eli postikortissa
on joku joka sen on lähettänyt. Lähettäjä.
00:14:44.980 --> 00:14:48.980
Siinä on vastaanottaja. Se olen yleensä minä.
Olen vastaanottaja. Ja sitten siinä on joku
00:14:48.980 --> 00:14:53.569
viesti. Näin ainakin koin asiat
ennen kuin opin siitä hieman lisää.
00:14:53.569 --> 00:14:58.670
Mutta email adminit ja standardointi
järjestöt, he näkevät asian näin
00:14:58.670 --> 00:15:04.610
kuten tässä oikealla on. Siinä on
kirjekuori ja kuoren sisällä
00:15:04.610 --> 00:15:10.480
siellä on viesti tai postikortti ehkä.
Eli sinulla on kaksi osoitetta
00:15:10.480 --> 00:15:15.350
tässä skenaariossa. Sinä määrittelit
osoitteet keneltä ja kenelle olet
00:15:15.350 --> 00:15:20.730
lähettämässä kuorta, joka on osa sitä mitä
postikonttori, esimerkiksi, katsoo.
00:15:20.730 --> 00:15:24.589
Mutta postikonttori ei yleensä katso sinun
kuoren sisään. Ja sisällä kuoressa
00:15:24.589 --> 00:15:28.880
on toinen viesti ja tämä sisäinen viesti
on todellisuudessa tarkoitettu
00:15:28.880 --> 00:15:33.889
vastaanottajalle. Eli todellisuudessa,
voisit tehdä vielä enemmän ja jopa laittaa
00:15:33.889 --> 00:15:40.060
koko kirjekuoren postikorttiviesteineen
toisen kirjekuoren sisään. Ja tämä voi
00:15:40.060 --> 00:15:46.500
kuulostaa hullulta minulle tavallisena
henkilönä, mutta email sallii tämän.
00:15:46.500 --> 00:15:50.029
Ja RFC dokumentissa, siinä on esimerkkejä
miksi tämä voi olla välttämätöntä.
00:15:50.029 --> 00:15:56.939
Miksi, miksi, miksi moiset asiat on sallittu.
Mutta ne ovat hämäriä. Ja niin seurauksena
00:15:56.939 --> 00:16:03.009
se on tässä ensimmäisessä esimerkissä,
näemme, että yleisesti määritämme
00:16:03.009 --> 00:16:07.940
saman osoitteen kahdesti. Mutta kysymys
joka meidän pentestaajina tulisi
00:16:07.940 --> 00:16:12.170
kysyä on: Vaaditaanko sitä, oikeasti?
Onko se oikeasti totta vai ainoastaan
00:16:12.170 --> 00:16:17.120
toiveajattelua? Ja se on vain
toiveajattelua. Eli standardi
00:16:17.120 --> 00:16:20.870
ei erityisesti sano, että sinun pitäisi
määrittää sama osoite vastaanottajalle
00:16:20.870 --> 00:16:27.140
tai "From" lähettäjän osoitteelle kuoressa
ja viestin sisällä. Eli, voit virittää,
00:16:27.140 --> 00:16:32.300
niitä ja lähettää erilaista, eri tavaraa.
Eli, oikeasti,
00:16:32.300 --> 00:16:38.519
on monia headereita lisää kuin mitä juuri
näytin. Ne mitä näytin ovat, luulen, niitä
00:16:38.519 --> 00:16:42.850
joista meillä kaikilla on kokemusta, koska
vaikka vain käyttäisit emailia, ne ovat
00:16:42.850 --> 00:16:45.920
yleensä se juttu jonka näet tai näet
päiväyksen, näet otsikon. näet
00:16:45.920 --> 00:16:52.680
kuka on lähettänyt sinulle jotain ja
kenelle se on lähetetty. Yleensä sinulle.
00:16:52.680 --> 00:16:57.800
Ja siinä voi olla, toki, useita vastaanottajia.
Oh, yeah. Ja kysymys silloin, toinen kysymys
00:16:57.800 --> 00:17:03.769
on: Mikä on oikeasti, jos olemme määritelleet
jostain syystä vahingossa tai erityisesti
00:17:03.769 --> 00:17:07.300
jos olemme määritelleet eri osoitteen
tähän kirjekuoreen tässä viestissä
00:17:07.300 --> 00:17:11.890
minkä käyttäjä näkee vastaanottajana,
se on oikeasti headeri.
00:17:11.890 --> 00:17:18.010
Eli viestin sisällä on se, mikä on
tarkoitettu käyttäjälle. OK. Eli kuten
00:17:18.010 --> 00:17:22.510
olin sanomassa, standardit sallivat vähän
enemmän headereita. Ja oikeasti
00:17:22.510 --> 00:17:25.880
3 headeria "From", "Sender", "Reply to"
jotka ovat semanttisesti hyvin
00:17:25.880 --> 00:17:31.080
lähekkäin ja standardi oikeasti selittää
Milloin sinun pitäisi käyttää mitäkin.
00:17:31.080 --> 00:17:34.040
Ja hassu juttu minulle on, että esimerkiksi
"From" headeri, joka on yleensä se
00:17:34.040 --> 00:17:39.310
minkä näemme mitä se voi sisältää. RFCta
lukiessa selviää ettei
00:17:39.310 --> 00:17:44.450
niitä headereita pitäisi olla kuin yksi,
mutta headeri itsessään voi
00:17:44.450 --> 00:17:48.020
sisältää useita osoitteita. Henkilökohtaisesti
en ole ikinä saanut postia usealta
00:17:48.020 --> 00:17:53.110
eri lähettäjältä, mutta se on sallittua.
Tärkeä asia ymmärtää on tässä
00:17:53.110 --> 00:17:57.530
jälleen on taaksepäin yhteensopivuus,
josta mainitsin aikaisemmin. Eli vaikka
00:17:57.530 --> 00:18:02.480
standardi selittää kuinka sinun pitäisi
käyttää kutakin headeria ja ettei
00:18:02.480 --> 00:18:07.130
sinun pitäisi käyttää kuin yhtä kappaletta
niistä, käytännössä voi lähettää
00:18:07.130 --> 00:18:12.480
väärinmuotoillun sähköpostin. Voisit lähettää
emailin useilla headereilla, sama "From"
00:18:12.480 --> 00:18:17.040
header useita kertoja tai voit lähettää
headerin joka ei sisällä "From" mutta
00:18:17.040 --> 00:18:21.240
sisältää "Sender" headerin, RFCn mukaan
väärin. Todellisuudessa se toimii.
00:18:21.240 --> 00:18:27.550
Useimmilla organisaatioilla, useimmat email
palvelut pyrkivät parhaansa mukaan välittämään
00:18:27.550 --> 00:18:33.720
täysin vääristetyn emailin, koska ne oikeasti
haluavat alentaa ylläpitokustannuksia.
00:18:33.720 --> 00:18:37.580
Eli jos joku ei toimi, silloin tulet heidän
luokseen. Joten on parempi
00:18:37.580 --> 00:18:42.160
saada kaikki toimimaan suurimman osan
ajasta. Tietenkin pentestaajalle tämä
00:18:42.160 --> 00:18:45.670
tarkoittaa, että voit leikkiä sillä
koska on
00:18:45.670 --> 00:18:49.480
erilaisia implementointeja ja juuri mikä
headeri esimerkiksi, jos sinulla
00:18:49.480 --> 00:18:53.830
on kaksi näytetään tai mitä käytetään
johinkin algoritmiin. Se riippuu kyseisestä
00:18:53.830 --> 00:18:59.150
implementaatiosta. Eli koska on niin monta
implementaatiota, ne ovat kytkeytyneinä
00:18:59.150 --> 00:19:03.720
toisiinsa erilaisilla tavoilla. Sinä voisit
ja sinun pitäisi pentestaajana yrittää
00:19:03.720 --> 00:19:09.270
eri asioita, esimerkiksi, lisätä sama
headeri useaan kertaan. OK.
00:19:09.270 --> 00:19:13.990
Nyt kun olemme läpikäyneet perusteet,
katsotaan miten oikeasti koittaisit
00:19:13.990 --> 00:19:18.360
väärentää emailin, esimerkiksi, yeah. Ja
tässä taas, tulemme takaisin tähän
00:19:18.360 --> 00:19:23.930
kuvaan jonka näimme aiemmin. Ja,
esimerkiksi, ensimmäisessä esimerkissä
00:19:23.930 --> 00:19:29.960
Alice lähetti postia Bobille. Sanotaan, että
olemme Chuck. Eli olemme kolmas osapuoli.
00:19:29.960 --> 00:19:33.700
Olemme lisensoituja pentestaajia, meillä
on sopimus että voimme tehdä näin
00:19:33.700 --> 00:19:38.920
ja koitamme lähettää väärennetyn emailin
Bobille. Ja tässä esimerkissä koitamme
00:19:38.920 --> 00:19:44.440
väärentää Alicen viestin. Eli aikeena on
että Bob haluaa, Bon vastaanottaa emailin.
00:19:44.440 --> 00:19:52.580
Sen pitäisi näyttää heille, Bobille, että
emailin lähettäjä on Alice. Eli riski on tämä.
00:19:52.580 --> 00:19:57.580
Okei, en käy läpi riskiä. Luulen, että
voitte kuvitella sen. Eli esimerkiksi,
00:19:57.580 --> 00:20:01.430
voisit lähettää vääriä uutisia, se on yksi
ongelmista, joita olemme nähneet Latviassa.
00:20:01.430 --> 00:20:06.330
Tätä on käytetty valtionhallintoa vastaan.
Ja kun joku lähettää valeuutisia sähköpostilla
00:20:06.330 --> 00:20:13.660
toisille ihmisille ja niin edelleen, ja
koitamme matkia jotain valtiollista
00:20:13.660 --> 00:20:19.510
henkilöä. Ja kuten voit kuvitella itse,
ei ole hyvä juttu
00:20:19.510 --> 00:20:23.710
sinulle jos se on mahdollista. Mutta
mielenkiintoinen juttu on, että vaikka
00:20:23.710 --> 00:20:28.450
Chuck tekee hyökkäystä, riippuu sinun
näkökulmasta. Se voi näyttää, että Alice
00:20:28.450 --> 00:20:32.480
hyökkää Bobille. Mutta tässä tapauksessa
email ei mene Alicen järjestelmän läpi.
00:20:32.480 --> 00:20:37.590
Kuten näette, Chuck lähettää emailin suoraan
Bobin sisääntulevalle palvelimelle.
00:20:37.590 --> 00:20:44.490
Nyt, on olemassa toisen tyyppinen hyökkäys
jota katsotaan. Jos lähetämme emailia
00:20:44.490 --> 00:20:48.540
toiseen suuntaan Bobilta Alicelle.
Ja asiakkaamme on Alice. Eli testaamme
00:20:48.540 --> 00:20:52.900
Alicen palvelinta. Ja tässä tapauksessa,
koitamme, taas olemme Chuck.
00:20:52.900 --> 00:20:58.570
Lähetämme emailia. Tässä tapauksessa, email
menee Alicen järjestelmän läpi.
00:20:58.570 --> 00:21:03.790
Eli kiinnostava kysymys on, kumpaa on
helpompi suojata. Voi vaikuttaa, koska
00:21:03.790 --> 00:21:07.270
toisessa esimerkissä, email oikeasti kulkee
Alicen järjestelmän läpi, se tarkoittaa,
00:21:07.270 --> 00:21:11.880
että Alicella on voimaa tehdä jotain,
tehdä lisätarkastuksia, tutkia jne.
00:21:11.880 --> 00:21:16.190
Mutta kuten näet jatkossa, on helpompaa
suojata ensimmäistä esimerkkiä.
00:21:16.190 --> 00:21:21.710
Eli, vaikka asiakkaamme on Alice, me
koitamme suojata Alicea,
00:21:21.710 --> 00:21:26.540
mutta se on helpompaa suojata käytännössä
tässä esimerkissä kun toinen on myy...
00:21:26.540 --> 00:21:32.800
lähettämässä emailia, yrittämässä matkia
Alicea. Okei, Oh, Yeah. On myös kolmas
00:21:32.800 --> 00:21:37.690
esimerkki, jossa Alice kommunikoi hänen
kollegoidensa kanssa saman
00:21:37.690 --> 00:21:41.821
organisaation sisäisesti. Jälleen, olemme
Chuck. Taas, me vain lähetämme emailia
00:21:41.821 --> 00:21:47.590
Alicen sisääntulevalle palvelimelle. Ei
lähtevälle. Oikein. Tärkeää huomata.
00:21:47.590 --> 00:21:54.460
Ja taas, periaatteessa, tämä kolmas
esimerkki on helpoin huomata, koska
00:21:54.460 --> 00:21:59.790
Alicen organisaatio oletettavasti tietää,
että hänen emailien pitäisi aina tulla
00:21:59.790 --> 00:22:03.790
Tältä tietyltä lähtevien palvelimelta.
Just. Jos vaikka lähetetään emailia
00:22:03.790 --> 00:22:08.780
Alicen kollegalta, silloin saapuvien
palvelimella pitäisi olla kaikki valta
00:22:08.780 --> 00:22:15.610
Ilman mitään standardeja ja sellaisia.
Todellisuudessa, joskus, oikeastaan aika
00:22:15.610 --> 00:22:24.140
usein, siinä on erityinen whitelist Alicen
omalle organisaatiolle. Joten joitain
00:22:24.140 --> 00:22:28.880
tarkastuksia ei tapahdu jos Alicen saapuvien
palvelin ottaa emailin vastaan, joka tulee
00:22:28.880 --> 00:22:34.610
taas, Alicelta. Ja muuten, meillä on tämä
esimerkki. Olemme nähneet sitä parina
00:22:34.610 --> 00:22:38.730
viime vuonna. Luulen että se ei ole ainoastaan
Latviassa. Eli tässä, esimerkiksi, on Canada
00:22:38.730 --> 00:22:43.590
ja muut, jos näette. Nämä ovat näitä
emaileja, jotka ovat fakeja, ransomwarea yms.
00:22:43.590 --> 00:22:48.290
Periaatteessa ne kertovat, että he ovat
hakkeroineet tietokoneesi tai
00:22:48.290 --> 00:22:53.820
sähköpostisi. Tässä tapauksessa, ja he ovat
järjestelleet kaikenlaisia talous juttuja tai
00:22:53.820 --> 00:22:59.160
joku kiristää sinua. Ja pyytävät sinua
lähettämään heille rahaa. Sinun rahaasi.
00:22:59.160 --> 00:23:04.520
Tarkoitan, rahaasi bitcoineina heidän
osoitteeseen. Eli nämä sähköpostit.
00:23:04.520 --> 00:23:08.920
Kiinnostavaa näissä emaileissa on, että
yleensä todistaakseen sinulle että heillä
00:23:08.920 --> 00:23:13.210
on pääsy sähköpostiisi. He lähettävät
sähköpostin sinun osoitteestasi sinun
00:23:13.210 --> 00:23:20.100
osoitteeseen. Ja monelle ihmiselle, se
toimii. Eli he näkevät, että joku on
00:23:20.100 --> 00:23:22.730
hakkeroinut heidän tilinsä, selkeästi,
koska he saivat sähköpostin itseltään.
00:23:22.730 --> 00:23:28.620
Kuten näet hetken päästä, on oikeasti
helppoa väärentää sellainen email, jos
00:23:28.620 --> 00:23:34.100
mitään suojauksia ei ole asetettu
paikoilleen. Eli tärkeä
00:23:34.100 --> 00:23:38.120
asia. Toivon, että nyt kukaan yleisössä
ei sorru tällaiseen huijaukseen.
00:23:38.120 --> 00:23:43.910
Mutta jos teillä on ystäviä tai kollegoja,
jotka ovat ottaneet yhteyttä ja kertoneet
00:23:43.910 --> 00:23:48.230
sellaisista emaileista joita he ovat saaneet.
Mutta yksi asia sen lisäksi, että tarkastavat
00:23:48.230 --> 00:23:53.110
salasanansa on alkaa käyttämään tehokkaampia
autentikointeja on, että ehkä voisit
00:23:53.110 --> 00:23:57.770
pyytää heitä ottamaan yhteyttä
email admineihin tai
00:23:57.770 --> 00:24:03.470
IT teamiin ja kysyä heiltä anti-spoofing
suojauksista, koska todella jos he voivat
00:24:03.470 --> 00:24:09.020
vastaanottaa sellaisen emailin ja sitä
ei suodateta, jotain on vialla.
00:24:09.020 --> 00:24:16.990
Okei, ja nyt katsotaanpa väärennettyä email
keskustelua, tämä esimerkki on vastaava
00:24:16.990 --> 00:24:22.090
kuin edellinen. Mutta tässä olemme oikeasti
Chuck. Eli tämän on lähettänyt Chuck Bobille,
00:24:22.090 --> 00:24:25.920
mutta esitämme olevamme Alice. Kysymys
on, voitko nähdä eron
00:24:25.920 --> 00:24:30.110
kuinka tämä on erilainen kuin edellinen.
Ja on vaikeaa havaita
00:24:30.110 --> 00:24:33.230
eroa, koska sitä ei ole.
Tämä on sama keskustelu.
00:24:33.230 --> 00:24:39.540
Eli, juttu tässä on, että SMTP protokollassa
ei itsessään oikeasti ole mitään suojausta.
00:24:39.540 --> 00:24:43.640
Eli, yeah, voisit vain esimerkiksi, jos
olet tuo tyyppi, joka lähettää fake
00:24:43.640 --> 00:24:49.580
kiristyskirjeitä, voit vain kirjoittaa
tämän tekstin ja dumpata sen
00:24:49.580 --> 00:24:55.830
telnetiin ja se toimii monelle
organisaatiolle. Ei kaikille tietenkään,
00:24:55.830 --> 00:25:01.210
email adminit tietävät nämä jutut, tietävät
että SMTP ei ole luotettava tällä tavalla.
00:25:01.210 --> 00:25:05.070
Se on helppo väärentää ja niin edelleen.
Ja on ollut useita yrityksiä lisätä jotain
00:25:05.070 --> 00:25:11.520
suojausta, vähän ad hoc tapaisesti. Eli
ei standardeja, jotain kiristyksiin, lisää
00:25:11.520 --> 00:25:15.950
filttereitä ja juttuja omaan mailiisi.
Ja jotkut näistä suojauksista rikkovat
00:25:15.950 --> 00:25:20.640
oikeasti RFCta. Jos luet sitä, mutta ketä
kiinnostaa? RFC ei ole kuten pyhä teksti,
00:25:20.640 --> 00:25:26.260
vai onko. Hyväksyn tämän täysin, esimerkiksi.
Yeah, jatketaan. Mutta ongelma on, ettei
00:25:26.260 --> 00:25:31.640
ole tarpeeksi tietoa.
Eli, jos mietit täällä, jos olemme Bob
00:25:31.640 --> 00:25:35.100
ja koitamme suojata järjestelmämme.
Eli olemme Bob, joku system admin varmaan
00:25:35.100 --> 00:25:39.730
tai Bob on sys admin ja koitamme lisätä
joitain sääntöjä ja juttuja,
00:25:39.730 --> 00:25:44.590
mitä voimme oikeasti tehdä. Eli yksi
esimerkki jonka listasin tähän on tehdä
00:25:44.590 --> 00:25:49.980
tämä SMTP takaisinsoitto, ja se tarkoittaa
että juuri kun vastaanotamme emailin
00:25:49.980 --> 00:25:56.970
Alicelta, me oikeasti tarkistamme että se
email on olemassa. Koska monet spammerit,
00:25:56.970 --> 00:26:02.000
mitä ne tekevät, ne vain lähettävät emailia
olemattomista osoitteista se toimii
00:26:02.000 --> 00:26:08.640
jos sinä ajat vain raakaa SMTP palvelinta.
Eli SMTP takaisinsoitossa, periaatteessa
00:26:08.640 --> 00:26:13.300
kun olet vastaanottamassa emailia,
esimerkiksi Alicelta, koitat. Ajat,
00:26:13.300 --> 00:26:17.220
käynnistät erillisen prosessin, joka
yrittää ottaa yhteyttä takaisin Aliceen, jne.
00:26:17.220 --> 00:26:24.500
Ja se koittaa lähettää hänelle emailia, jos
palvelin sanoo Yeah, se on OK. Sellainen
00:26:24.500 --> 00:26:27.540
sähköposti on olemassa jne. Sinä et ole,
Sinä oikeasti lopetat keskustelun.
00:26:27.540 --> 00:26:31.290
Et jatka emailin lähetystä, mutta sinun
järjestelmä voi automaattisesti huomata
00:26:31.290 --> 00:26:36.570
että tämä sähköposti on olemassa.
Toinen tapa tehdä tämä on tarkastamalla
00:26:36.570 --> 00:26:42.030
tämä "Hello". Ja tämä on ensimmäinen rivi
ja ensimmäisellä rivillä, sen tavallisesti
00:26:42.030 --> 00:26:48.000
pitäisi kertoa sinulle hostname
palvelimella joka lähettää emailia.
00:26:48.000 --> 00:26:52.580
Kiinnostava osa. Eli RFCn mukaan jälleen,
sinun ei pitäisi tarkastaa että olet
00:26:52.580 --> 00:26:56.540
varmentanut sen. Ja jos se ei onnistu, jos
se on satunnainen, sinun pitäisi hyväksyä
00:26:56.540 --> 00:27:04.520
email silti. Mutta mitä monet palvelimet
tekevät, ne koittavat varmentaa sen.
00:27:04.520 --> 00:27:07.800
Ensinnäkin, tällä hostnamella kerrot, että
sinulla on tämä hostname joka
00:27:07.800 --> 00:27:12.800
oikeasti osoittaa samaan IP osoitteeseen
ja he tekevät päinvastoin. Eli he
00:27:12.800 --> 00:27:18.880
ottavat IP osoitteen ja koittavat ajaa
käänteisen DNS PTR kyselyn ja koittavat
00:27:18.880 --> 00:27:23.150
selvittää täsmääkö IP osoite oikeasti
tähän hostnameen. Eli jälleen,
00:27:23.150 --> 00:27:26.520
pentestaajina meidän tulisi olla tietoisia
näistä suojauksista, ad hoc, suojauksista
00:27:26.520 --> 00:27:31.040
koska jos et tunne niitä, koitat
ajaa jotain ja se ei toimi
00:27:31.040 --> 00:27:34.700
sinulla. Mutta ne ovat helppoja jos
olet niistä tietoinen ja jos sinun täytyy
00:27:34.700 --> 00:27:40.470
tunnistaa, että tämä organisaatio käyttää
niitä. Ne ovat helppoja ohittaa, eli ne eivät
00:27:40.470 --> 00:27:44.530
tarjoa hyvää suojaa. Niiden tarkoitus on
suojata massa hyväksikäytöltä, spammilta.
00:27:44.530 --> 00:27:52.910
OK, eli SMTP, kuten näimme, itsessään ei
tarjoa minkäänlaisia suojauksia.
00:27:52.910 --> 00:27:59.380
Eli mitä lisäyksiä protokollaan voimme
oikeasti käyttää suojataksemme itseämme ?
00:27:59.380 --> 00:28:06.860
Yksi sellainen protokolla on SPF. Ja mitä
SPF tekee, se koittaa olla kuten peili
00:28:06.860 --> 00:28:12.870
MX järjestelmässä. MX järjestelmä on se,
jota periaatteessa Alica voi käyttää,
00:28:12.870 --> 00:28:18.150
Jota Alicen palvelin voi käyttää löytämään
automaattisesti palvelimen joka kuuluu Bobille
00:28:18.150 --> 00:28:24.580
ja sen saapuvien palvelimen. Eli SPF on sen
vastakohta. Eli sen idea tässä on
00:28:24.580 --> 00:28:30.270
olla automaattisesti ajossa Bobin saapuvien
palvelimella. Ja nyt kun Bob
00:28:30.270 --> 00:28:35.720
vastaanottaa emailin, ne voivat ajaa taas
DNS kyselyn ja selvittää minkä IP osoitteiden
00:28:35.720 --> 00:28:41.820
oikeasti pitäisi kuulua Alicen lähtevien
palvelimelle. Just. Eli mielestäni se on
00:28:41.820 --> 00:28:45.780
helppoa ymmärtää, se on merkityksellinen
tapa. Se kuulostaa merkittävälle
00:28:45.780 --> 00:28:52.570
lisäykselle. Ja yksi asia, joka tarkastetaan
tässä esimerkissä on kirjekuoren
00:28:52.570 --> 00:28:59.360
lähettäjä. OK. Ja tässä on esimerkki
minimi SPF syntaxista ja kuten voimme
00:28:59.360 --> 00:29:04.610
nähdä. Mielestäni sitä on helppo ymmärtää,
vaikka et tietäisi mikä syntaxi on, se listaa
00:29:04.610 --> 00:29:08.470
IP osoitteet, mikä on IP, pitäisi olla IP
osoite lähtevien palvelimelle, oikealle
00:29:08.470 --> 00:29:12.780
lähtevien palvelimelle. Ja sitten se sanoo
tässä "-all", joka taas on helppo ymmärtää
00:29:12.780 --> 00:29:18.700
Tässä tapauksessa, se tarkoittaa, että se
on ainoa. Eli jos vastaanotat viestin,
00:29:18.700 --> 00:29:22.980
viesti tulee tästä IP osoitteesta. Se on
hyvä. Hyväksy se. Jos se on jotain muuta
00:29:22.980 --> 00:29:27.190
sitten poista se. Ja on monia tapoja
määrittää IP osoite. Voisit vain
00:29:27.190 --> 00:29:31.610
määrittää IP osoitteen, voisi määrittää
IP aliverkon, voisit määrittää DNS nimen
00:29:31.610 --> 00:29:37.070
Eli se on ainoastaan admineille. Eli
periaatteessa pentestaajalle se ei tee
00:29:37.070 --> 00:29:44.750
paljoa eroa, admineille se vain helpottaa
järjestelmien ylläpitoa. Ja sitten ovat
00:29:44.750 --> 00:29:49.620
nämä määreet, määreet. Tämä on jotain
jotat laitat
00:29:49.620 --> 00:29:56.160
ennen metodeja. Esimerkiksi, tässä
esimerkissä, IPv4:ssa ei ollut mitään
00:29:56.160 --> 00:30:00.100
määreitä. Siinä ei ole plussaa tai miinus
tai jotain. Se johtuu siitä, että plus
00:30:00.100 --> 00:30:03.910
on oletus vakiona. Eli vakiona, kaikki
mikä on listattu SPF määrityksissä pitäisi
00:30:03.910 --> 00:30:12.600
täsmätä johinkin oikeaan SMTP palvelimeen,
lähtevien palvelimeen. Kuitenkin, on muita
00:30:12.600 --> 00:30:15.850
vaihtoehtoja, voit käyttää miinusta joka
on fail. Ja se tarkoittaa että jos jokin
00:30:15.850 --> 00:30:20.380
täsmää kirjaukseen, esimerkiksi, miinus
all, joka on eniten käytetty,
00:30:20.380 --> 00:30:26.710
se tarkoittaa, että jos se täsmää tähän,
se on yleensä viimeinen, niin tuhoa
00:30:26.710 --> 00:30:32.090
sähköposti. Se ei ole oikea. Se on fake
email. Ja sitten on kolmas vaihtoehto,
00:30:32.090 --> 00:30:37.150
joka on soft fail, joka on tarkoitettu
testauksen ajaksi. Eli kun olet juuri
00:30:37.150 --> 00:30:42.690
alkamassa implementoimaan SPFaa, siinä
voisi olla. Eli ongelma on, että saattaisit
00:30:42.690 --> 00:30:47.730
unohtaa, esimerkiksi, lisätä joitain SMTP
palvelimia. Eli, koska et ole tehnyt sitä
00:30:47.730 --> 00:30:52.750
ennen, ehkä luulit, että sinulla on vain
yksi oikea SMTP lähtevien palvelin, mutta
00:30:52.750 --> 00:30:56.360
oikeasti sinulla on useita, tai useita
tapoja lähettää sähköpostia. Eli siinä
00:30:56.360 --> 00:31:03.600
tapauksessa, jos alkaisit asettamaan SPF
asetuksia "fail" tiukalla politiikalla,
00:31:03.600 --> 00:31:07.230
sinun käyttäjät eivät voisi lähettää enää
viestejä. Eli sen takia testaaminen on
00:31:07.230 --> 00:31:13.460
hyvä. Kuitenkin. On myös muita esimerkkejä,
vähän monimutkaisempia, yksi niistä oli
00:31:13.460 --> 00:31:16.400
include. Eli sen sijaan, että määrität
policyn itse, koska käytät kolmatta
00:31:16.400 --> 00:31:19.270
osapuolta, esimerkiksi, Googlea tässä
tapauksessa, ja sitten vain
00:31:19.270 --> 00:31:24.720
sisällytät mitä tahansa Google on
julkaissut. Ja kiinostava juttu tässä on
00:31:24.720 --> 00:31:31.530
tämä SPFn käyttö. Jos me vain, jos vain
katsomme niiden domainien määrää
00:31:31.530 --> 00:31:36.890
jolle olemme laittaneet jonkun policyn,
se näyttää hyvältä. Arvaan, että esimerkiksi
00:31:36.890 --> 00:31:42.290
kaikkein suosituimmat domainit, se olisi
noin 70 prosenttia. Mutta ongelma on,
00:31:42.290 --> 00:31:45.710
ettö valtaosa niistä on joko huonosti
konfiguroituja tai ne käyttävät ainoastaan
00:31:45.710 --> 00:31:51.790
softail optiota. Ja soft fail ei käytännössä
tee mitään. Voit siitä huolimatta, että
00:31:51.790 --> 00:31:56.700
policy on soft failissa, voit useimmissa
tapauksissa väärentää sähköpostisi
00:31:56.700 --> 00:32:00.720
ja se menee läpi, koska vastaanttava puoli
ajattelee että se on vain testimoodissa.
00:32:00.720 --> 00:32:07.940
Sinun pitäisi poistaa email automaattisesti.
Yeah. Eli. Oikeasti prosentit eivöt
00:32:07.940 --> 00:32:13.910
ole kovin hyvät. Kuitenkin, tärkeintä
meille penetraatiotestaajina on
00:32:13.910 --> 00:32:18.420
ymmärtää. Eli mitä teemme kun näemme
tämän SPFn. Se tarkoittaa että emme voi
00:32:18.420 --> 00:32:24.670
väärentää postiaja. Ei, ei niin. Että se
olisi game over meille. Voimme tehdä
00:32:24.670 --> 00:32:30.060
juttuja. Ensinnäkin, on tämä soft fail jonka
mainitsin. Ja siinä periaatteessa sinulla
00:32:30.060 --> 00:32:33.830
on jotain sääntöjä, sääntöjä, sääntöjä, ja
lopuksi, laitat tavallisesti tämän
00:32:33.830 --> 00:32:41.460
soft failin kaikille. Joten jos me
pentestaajina koitamme väärentää jostain
00:32:41.460 --> 00:32:46.330
tuntemattomasta IP osoitteesta. jota ei ole
listattu edellisissä säännöissä. Älä tee
00:32:46.330 --> 00:32:51.520
mitään. Tee mitään. Tarkoitan älä estä
emailia. Se on hyvä meille, eikös ?
00:32:51.520 --> 00:32:56.720
Se tarkoittaa, että voimme väärentää aivan
vanhaan tapaan ja se yleensä toimii.
00:32:56.720 --> 00:33:02.250
Yksi hyvä huomio tässä on, että jotkut
järjestelmät ovat, eivät käytä vain tätä
00:33:02.250 --> 00:33:06.590
binääristä luokittelua, onko jokun hyvä
tai paha, vaan ne koittavat tehdä jotain
00:33:06.590 --> 00:33:11.320
pisteytystä. Ja voi olla, että vaikka
olisikin tämä soft fail, he eivät
00:33:11.320 --> 00:33:16.370
automaattisesti estä sinun emailia, vaan
ehkä he lisäävät jotain epäilyksen tasoa
00:33:16.370 --> 00:33:22.540
siihen. Mutta tärkeä asia on, ettei se
ole automaattisesti game over.
00:33:22.540 --> 00:33:29.970
Toinen juttu on tämä include. Eli include
on hyvin käytännöllinen jos käytät kolmansia
00:33:29.970 --> 00:33:36.330
osapuolia. Mutta ongelma on, että se ei
ole sitä miltä kuulostaa joillekin, edes
00:33:36.330 --> 00:33:43.100
standardissa, se mainitsee, että se oli
huonosti valittu nimi. Ja syy tähän
00:33:43.100 --> 00:33:48.110
ettei se ole macro. Eli ymmärtääksesi
mitä tapahtuu kun tämä includataan,
00:33:48.110 --> 00:33:52.720
sinun ei pitäisi vain leikata ja liimata
kaikkea rekursiivisesti ylätasolle.
00:33:52.720 --> 00:33:58.340
Se ei ole miten se toimii. Se koittaa
ajaa kaikkia testejä tämän includen
00:33:58.340 --> 00:34:05.480
sisäpuolella. Mutta jos se epäonnistuu, se
ai automaattisesti poista viestiä. Se menee
00:34:05.480 --> 00:34:10.250
yhtä tasoa ylemmäs ja se koittaa ajaa
toisia sääntöjä. Ongelmana siinä
00:34:10.250 --> 00:34:14.510
on, että kaksi tapausta jotka ovat
tavallisimipia ovat, että joko vain
00:34:14.510 --> 00:34:20.570
unohdat lisätä miinuksen kaikkiin tai
se on sinun system admin joka on
00:34:20.570 --> 00:34:26.470
unohtanut sen. Siitä tapauksessa, vaikka
he lisäävät miinuksen kaikkiin, se ei toimi
00:34:26.470 --> 00:34:34.089
koska, tarkoitan, se toimisi kun vastaan-
ottaja tarkastaa sitä miinus kaikki
00:34:34.089 --> 00:34:39.569
includen sisällä ei tarkoita samaa, kuin
mitä se tarkoittaa top levelillä. Ja
00:34:39.569 --> 00:34:43.799
toinen olisi, että he ovat lisänneet kaiken,
mutta soft failanneet. Ja sitten adminit
00:34:43.799 --> 00:34:47.809
miettivät. Mutta se in okei, koska sisällytän
GMailin ja GMailissa on tämä hard fail.
00:34:47.809 --> 00:34:54.409
Se ei toimi niin. Ja lisäksi, tämä on
todellisuudessa mielestäni yleisin tapaus,
00:34:54.409 --> 00:35:00.000
on, että usein kun näet oikeasti tämän
tyyppisen SPF listan, mutta siinä
00:35:00.000 --> 00:35:03.569
listan sisällä on paljon juttuja IP
osoitteita. Siellä on A kirjauksia
00:35:03.569 --> 00:35:07.890
siellä on MX kirjauksia, Siellä on pointer.
Periaatteessa, mitä vain admin voisi
00:35:07.890 --> 00:35:12.990
kuvitella ja syy tähän yleensä on että
he eivät ole varmoja miten se toimii.
00:35:12.990 --> 00:35:17.100
He eivät ole varmojja mitä sinne tulisi
laittaa. Eli esimerkiksi, yksi juttu
00:35:17.100 --> 00:35:24.840
jonka osoittaa on, että jos siellä on MX
tietue SPF listan sisällä, yleensä useissa
00:35:24.840 --> 00:35:27.930
organisaatioissa, elleivät ne ole hyvin
pieniä ja heillä on vain yksi palvelin
00:35:27.930 --> 00:35:31.059
heillä on eri palvelimia, eri IP osoitteita
lähtevälle postille ja saapuvalle
00:35:31.059 --> 00:35:34.500
postille. Tämä tarkoittaa,ettei ole
käytännön syytä tälle organisaatiolle
00:35:34.500 --> 00:35:41.109
ei käytännön syytä lisätä MXaa SPFaan
koska ei, ei postia pitäisi lähteä läpi
00:35:41.109 --> 00:35:45.900
heidän saapuvan postin palvelimesta. Ja
toinen juttu voi olla, että admin tietää
00:35:45.900 --> 00:35:51.470
tietää miten se toimii, mutta heidän oma
arkkitehtuuri on tosi sekainen ja he
00:35:51.470 --> 00:35:55.730
lähettävät postia ulos monesta, monesta eri
pisteestä, mikä on kiva pentestaajille.
00:35:55.730 --> 00:36:03.359
Se tarkoittaa etteivät he ole hyvin
organisoituneita. OK ja on vielä yksi vika,
00:36:03.359 --> 00:36:09.220
joka on, ettei hienojakoisuus sovi hyvin.
Eli ainoa juttu jota voit.
00:36:09.220 --> 00:36:13.799
On useita näitä kirjaus tyyppejä. Mutta
ne kaikki varsinaisesti resolvaavat IP
00:36:13.799 --> 00:36:19.650
osoitteen. Mutta kuten voit kuvitella,
usein IP ei ole yhdistetty vain email
00:36:19.650 --> 00:36:24.230
palvelimeen. Eli yhdessä IPssa voi olla mail
palvelin ja web palvelin tai tietokanta tai
00:36:24.230 --> 00:36:28.069
jotan muuta. Ja se tarkoittaa, että
pentestaajana, voit exploitata tämän
00:36:28.069 --> 00:36:32.339
jonkun muun. EI mail serveriä itseään,
koska postipalvelin on yleensä aika pieni
00:36:32.339 --> 00:36:36.740
kohde. Niissä ei ole paljon haavoittuvuuksia.
SInä vain päivität ne ja se siitä.
00:36:36.740 --> 00:36:42.740
Mutta muissa järjestelmissä, esimerkiksi
web on helppo murtaa. Yleensä.
00:36:42.740 --> 00:36:46.680
Sitten voit nostaa, kuten tavallaan nostaa
oikeustasoa saadessasi pääsyn jonkun
00:36:46.680 --> 00:36:50.809
toisen palvelun kautta siinä IP osoitteessa
tai IP alueessa. Voit alkaa lähettämään
00:36:50.809 --> 00:36:59.859
posteja. Ne läpäisevät kaikki SPF suodatukset.
OK. Eli yksi esimerkki ovat jaetut hostaukset
00:36:59.859 --> 00:37:04.950
joka on hyvin tavallista ja ongelma jaetussa
hostauksessa on se. Tässä tapauksessa.
00:37:04.950 --> 00:37:10.359
Okei. Sinulla on IP osoite SMTP palvelimelle.
Ehkä sitä palvelinta käytetään vain lähettämään
00:37:10.359 --> 00:37:15.900
postia. Mutta palvelin itsessään ei tee
työtä vain sinulle. Se palvelee monia
00:37:15.900 --> 00:37:18.849
domaineja, ehkä satoja tai tuhansia. Se
tarkoittaa, että hyökkääjänä, taas, voit
00:37:18.849 --> 00:37:24.289
exploitata vain yhden niistä, tai jaetussa
hostauksessa voit vain ostaa. Voit tulla
00:37:24.289 --> 00:37:26.940
asiakkaaksi siihen jaettuun hostaukseen.
Sinun ei tarvitse murtaa mitään.
00:37:26.940 --> 00:37:31.750
Ja sitten voit ehkä alkaa lähettämään
emailia, joka näyttää hyvältä SPFaa
00:37:31.750 --> 00:37:38.140
ajatellen, kuten heidän omaansa. Eli. Ja
toinen on että tarkastetaan väärä identifier.
00:37:38.140 --> 00:37:44.960
Ja tämä on varmaankin pahin, pahin
ongelma SPFn kanssa. Se on, kuten
00:37:44.960 --> 00:37:49.640
kerroin aiemmin, se että on ainakin
kaksi identifieria. Tyypillisesti kuoren
00:37:49.640 --> 00:37:53.740
lähettäjä, ulompi, joka listaa lähettäjän
sitten on se sisempi,
00:37:53.740 --> 00:37:58.589
joka on yleensä "from" headeri.
Mutta näistä kahdesta SPF tarkastaa,
00:37:58.589 --> 00:38:03.140
jos SPF on ainoa teknologia jota käytät,
SPF tarkastaa vain ensimmäisen:
00:38:03.140 --> 00:38:09.059
Kuoren lähettäjän. Kuten kerroin aiemmin,
useimmissa tapauksissa, oikeat käyttäjät
00:38:09.059 --> 00:38:13.279
jotka saavat mailin, he eivät näe kuoren
lähettäjiä. He näkevät tämän toisen
00:38:13.279 --> 00:38:17.559
"from" esimerkiksi, tai jonkun niistä
toisista headereista joita mainittiin.
00:38:17.559 --> 00:38:22.830
Tämä käytös on oikeasti korjattu DMARCssa,
joka on teknologia jonka mainitsin. Mutta
00:38:22.830 --> 00:38:27.319
valtaosassa SPF asennuksista, domaineissa,
joissa SPF käytössä ei ole DMARCia,
00:38:27.319 --> 00:38:31.329
eli ne eivät ole suojassa tältä. Eli vaikka
heidän SPF olisi hienosti hyökkääjälle,
00:38:31.329 --> 00:38:36.630
se tarkoittaa, että sinun tarvitsee vain,
sinun pitää vain ohittaa SPF asettaaksesi
00:38:36.630 --> 00:38:40.430
kuoren lähettäjän joksikin toiseksi.
Esimerkiksi, sinun kontrolloima osoite,
00:38:40.430 --> 00:38:49.010
joka läpäisee SPF tarkastuksen. Mutta sitten
"from" sisällä voit näyttää headerin, joka
00:38:49.010 --> 00:38:56.776
täsmää organisaatioon, joka haluat matkia
olevasi. Okei. Sitten on toinen
00:38:56.776 --> 00:39:02.309
teknologia, jonka pitäisi korjata tämä
ja se on DKIM. Kuten olemme nähneet
00:39:02.309 --> 00:39:11.450
SPF ei ole riittävä. Eli DKIM. Anteeksi,
väärät kirjaimet, DomainKeys Identified Mail.
00:39:11.450 --> 00:39:15.099
Se on DKIM ja sinun ei tarvitse muistaa
pitkää nimeä, vain lyhyt nimi.
00:39:15.099 --> 00:39:20.223
Ja mitä se tekee, periaatteessa se käyttää
kryptografiaa, mikä on kiva, eikös? Se on
00:39:20.223 --> 00:39:24.640
matikkaa. Se on hankalaa murtaa hyökkääjälle.
Ja mitä se tekee, se allekirjoittaa jokaisen
00:39:24.640 --> 00:39:29.870
postin eli jokainen posti joka lähtee
DKIM käyttävältä palvelimelta saa
00:39:29.870 --> 00:39:35.059
allekirjoitujsen, jonka voit, vastaanottajana,
kryptografisesti varmistaa. Joten kuten näet,
00:39:35.059 --> 00:39:39.940
se vaikuttaa aika vaikealta nähdä, koska
sitä ei ole tarkoitettu ihmisten
00:39:39.940 --> 00:39:44.160
prosessoitavaksi. Se on kryptografiaa.
se on tarkoitettu prosessoitavaksi tietokoneille.
00:39:44.160 --> 00:39:48.300
Mutta tärkeä osa tässä on periaatteessa
keltainen osa joka on kryptografinen
00:39:48.300 --> 00:39:55.880
allekirjoitus. Mutta vihreä osa on, mitä
kutsutaan domain tunnisteeksi. Ja punaista
00:39:55.880 --> 00:40:02.269
osaa kutsutaan. En muista miksi sitä
sanotaan nauraa. Mutta periaatteessa sen
00:40:02.269 --> 00:40:07.160
idea on, että sinulla voi olla useita avaimia
organisaatiollasi, esimerkiksi, organisaatiosi
00:40:07.160 --> 00:40:12.390
voisi lähettää posteja sinun alkuperäiseltä
SMTP palvelimelta, sitten sinulla voisi olla
00:40:12.390 --> 00:40:17.650
varalla yksi, tai voisi olla, voisit
lähettää joitain viestejä Googlesta tai
00:40:17.650 --> 00:40:21.759
joku markkinointikampanja ja niin edelleen.
Ja jokaisella näistä voisi olla erilainen
00:40:21.759 --> 00:40:26.970
"punainen" parametrina. Ongelma on ja
sitten vastaanottajan pitää ajaa DNS kysely,
00:40:26.970 --> 00:40:32.532
joka on toinen esimerkki käyttäen tätä
yhdistelmää vihreä ja punainen.
00:40:32.532 --> 00:40:36.993
Ja sitten ne hakevat julkisen avaimen ja
voivat käyttää sitä varmistamaan alle-
00:40:36.993 --> 00:40:43.799
kirjoituksen. Eli se kuulostaa hyvälle.
Ongelma on, ei, toinen ongelma vielä.
00:40:43.799 --> 00:40:48.730
Kuinka käyttää sitä? Luulen sitä helpoksi
jos osaat julkisen avaimen salausta. Eli
00:40:48.730 --> 00:40:52.440
lähetys päässä, sinun pitää ensin luoda
julkinen ja salainen avainpari. Sitten
00:40:52.440 --> 00:40:56.270
julkaiset julkisen osan DNSaan. Sitten
käytät salaista avainta allekirjoittamaan
00:40:56.270 --> 00:41:00.480
viestit. Nyt vastaanottaja tekee tavallaan
päinvastoin. Kun he saavat emailin, he
00:41:00.480 --> 00:41:04.380
päättelevät tästä punaisesta ja vihreästä
osasta he päättelevät oikean DNS tiedon
00:41:04.380 --> 00:41:09.000
jonka ajaa, ajavat sen, saavat julkisen
avaimen ja vertaavat sitä täsmääkö tämä
00:41:09.000 --> 00:41:12.526
julkinen avain viestin allekirjoitukseen.
Kuulostaa kivalta, eikös? Mikä on ongelma?
00:41:12.526 --> 00:41:19.170
Eli asiakkaat. Selektorit, se on se nimi.
Eli ongelma siinä on se, että selektoreina
00:41:19.170 --> 00:41:27.309
voi olla useita selektoreita DKIM:na
kun teet konfiguraatiota,
00:41:27.309 --> 00:41:31.670
voit voit valita niin monta kustom
selektoria kuin haluat ja vastaanottaja
00:41:31.670 --> 00:41:37.170
ei tiedä, olisiko sinun oikeasti pitänyt
käyttää selektoria ja mitä
00:41:37.170 --> 00:41:41.599
selektoria sinun olisi pitänyt käyttää.
Eli ongelma on että kun, jos puhumme vain
00:41:41.599 --> 00:41:48.690
vanilja DKIMsta, olemassa olevan alle-
kirjoituksen muokkaaminen on vaikeaa
00:41:48.690 --> 00:41:52.630
penaajalle ja hyökkääjälle. Mutta on helppoa
vain poistaa se, koska jos olet poistanut
00:41:52.630 --> 00:41:57.619
DKIMn kaikista headereista, vastaanottaja
ei tiedä, että sen olisi pitänyt olla
00:41:57.619 --> 00:42:03.550
siinä, koska tarkistaakseen sen, se pitää
olla. Eli, esimerkiksi, tarkastaakseni
00:42:03.550 --> 00:42:08.640
allekirjoituksen, minun pitää tietää tämä
vihreä osa. Tämä domain tunniste ja
00:42:08.640 --> 00:42:14.712
selektori, jotka ovat osa headeria. Just.
Eli se on valtava ongelma. Ja se tarkoittaa
00:42:14.712 --> 00:42:20.818
että. Yeah. Se tarkoittaa, että vaikka
me emme voi huijata DKIMaa itseään
00:42:20.818 --> 00:42:26.700
voimme vain leikata DKIMn, lähettää viestin
ilman sitä. Ja jos DKIM oli ainoa asia joka
00:42:26.700 --> 00:42:31.499
suojasi tätä järjestelmää, se toimii. Eli
se ei välttämättä saisi vihreää merkkiä
00:42:31.499 --> 00:42:37.310
tai jotain, mutta se menisi vastaanottajalle.
Ja toinen juttu on tämä
00:42:37.310 --> 00:42:43.040
domain selektor. Miksi meidän pitää edes
asettaa se? Koska parhaissa käytännöissä,
00:42:43.040 --> 00:42:48.280
tietenkin, on että kuoren lähettäjä on sama
kuin "from" header ja tämä DKIM domain
00:42:48.280 --> 00:42:52.430
selektori. Just. Eli jos olet jos minä
lähetän Alicelta, niin kaikkien kolmen
00:42:52.430 --> 00:42:59.029
pitäisi olla Alice.org tai jotain. Ongelma
on ettei sitä ole mainittu RFCssa että
00:42:59.029 --> 00:43:04.029
näin pitäisi olla. Eli mitä tapahtuu jos
asia ei ole näin ?
00:43:04.029 --> 00:43:09.619
Erimerkiksi, oikealla on joku oikea domain
joka käyttää Gmailia, Google Appsia
00:43:09.619 --> 00:43:17.470
Google suitea ja siinä tapauksessa vakiona
vakiona Google suite allekirjoittaa kaikki
00:43:17.470 --> 00:43:22.430
viestit. Mutta jos et tee omaa
konfiguraatiota, se allekirjoittaa ne
00:43:22.430 --> 00:43:28.369
domainilla jota hallinnoi, joka on tämä
"gappssmtp". Ja se tarkoittaa, että vaikka
00:43:28.369 --> 00:43:32.579
teknisesti jotain on allekirjoitettu DKIMlla
sitä ei ollut allekirjoitettu siten, että
00:43:32.579 --> 00:43:36.406
voisit jäljittää sen takaisin sinun
organisaatioon. Se on jotain aivan
00:43:36.406 --> 00:43:40.069
muuta. Mitä vastaanottajan pitäisi tehdä
siinä tapauksessa? Pitäisikö jättää väliin?
00:43:40.069 --> 00:43:43.859
Pitäisikö hylätä viesti tai jotain? Eli oikea
tapa ei olisi hylätä sitä,
00:43:43.859 --> 00:43:49.380
mutta vaan arvioida, ettei se ole oikea,
ainakaan oikea DKIM, mutta oikeasti
00:43:49.380 --> 00:43:53.829
se riippuu. Osa tarkastajista näkevät vain
jonkin DKIMn, tarkastavat sen ja
00:43:53.829 --> 00:44:01.228
savovat että cool, se täsmää RFChen.
Eli, mutta nyt kiinostava osa. DKIM
00:44:01.228 --> 00:44:06.710
muokkaaminen, johon minulla ei ole aikaa.
Mutta ajatus on, että joissain tapauksissa
00:44:06.710 --> 00:44:11.339
ei aina, mutta joskus voit oikeasti muokata.
Helpoin osa muokata viestissä
00:44:11.339 --> 00:44:17.190
ovat headerit koska DKIM, koska se laitetaan
headereihin itse, se ei automaattisesti
00:44:17.190 --> 00:44:21.304
allekirjoita vanhoja headereita. On
tavallaan kana ja muna ongelma. Vakiona
00:44:21.304 --> 00:44:26.170
se allekirjoittaa vain yhden tai kaksi headeria
ja voit määrittää lisää headereita joita pitää
00:44:26.170 --> 00:44:30.910
allekirjoittaa, mutta se ei tapahdu auto-
maatisesti. Eli helppo osa hyökkääjälle
00:44:30.910 --> 00:44:35.569
on lisätä headeri. Jos se jotenkin
auttaa sinua suunnitelmassasi, se on
00:44:35.569 --> 00:44:40.400
helppo tehdä. Sinä vain lisäät toisen
headerin. Kiinnostava osa on, että
00:44:40.400 --> 00:44:43.940
vaikka RFC, kuten mainitsin aiemmin,
mainitsee, että jotkut headerit kuten
00:44:43.940 --> 00:44:49.180
"subject" tai "from" pitäisi olla paikalla
vain yhtenä kopiona. Oikeasti voit lisätä
00:44:49.180 --> 00:44:53.093
enemmänkin, esimerkiksi "from" headerin ja
mitä tapahtuu siinä tapauksessa on aika
00:44:53.093 --> 00:44:59.367
kiinnostavaa. DKIM täsmää jos olet kertonut
DKIMlle että "from" headerin pitäisi olla
00:44:59.367 --> 00:45:04.150
esimerkiksi, allekirjoitettu, sitten se täsmää
ja allekirjoittaa ensimmäisen "from" headerin
00:45:04.150 --> 00:45:11.279
alhaalta. Mutta monet ohjelmat meidän software
email ohjelmista todellisuudessa ainoastaan
00:45:11.279 --> 00:45:16.807
näyttävät käyttättäjälle ensimmäisen toiselta
puolelta, ylhäältä. Eli se tarkoittaa, että
00:45:16.807 --> 00:45:23.940
hyökkääjä voi muokkailla tai ylikirjoittaa
headereita vain lisäämällä uusia headereita
00:45:23.940 --> 00:45:29.546
päälle. Ja tämä oikea ongelma on
mainittu DKIM RFCssa ja suojaus
00:45:29.546 --> 00:45:33.089
jota he ehdottavat on tämä code
Over-Signing tai voit mennä ja lukea RFCn.
00:45:33.089 --> 00:45:38.885
Mutta kaikki eivät tee sitä oikeasti. Ja
kuitenkin, se toimii vain headereille.
00:45:38.885 --> 00:45:44.919
Eli joskus se on hyvä. Joskus ei niin hyvä.
Viestin rungon
00:45:44.919 --> 00:45:49.499
muokkaaminen on oikeasti vaikeampi toteuttaa.
Periaatteessa naivi tapa tehdä se kryptauksen
00:45:49.499 --> 00:45:54.069
kautta, jota emme halua tehdä. Ja toinen
tapa on tämän yhden parametrin
00:45:54.069 --> 00:45:58.140
kautta, joka on body lenght, ja se on aikaa
kyseenalainen toiminnallisuus
00:45:58.140 --> 00:46:05.118
DKIMssa. Joskus voit määrittää
että tiiviste vaikka. Allekirjoittamiseen,
00:46:05.118 --> 00:46:08.789
meidän ei pitäisi ajatella koko runkoa,
vaan ensimmäisiä joitain tavuja.
00:46:08.789 --> 00:46:13.790
Eli se on oikeasti käytännöllistä joissain
tapauksissa postituslistoissa, mutta yleensä
00:46:13.790 --> 00:46:18.866
se ei ole kovin käytännöllistä. Ja käytännössä
valtaosa email ohjelmista ei tee sitä.
00:46:18.866 --> 00:46:24.500
Jos se tekee, se on altis mahdollisesti
tälle koko
00:46:24.500 --> 00:46:28.869
rungon ylikirjoittamiselle. Voit lisätä
uuden mime tyypin ja sitten muokata
00:46:28.869 --> 00:46:34.245
headereita näyttääksesi eri mime tyypin
ja se ohittaa DKIMn. Eli tässä tapauksessa
00:46:34.245 --> 00:46:37.569
se näyttää, esimerkiksi, vihreän painikkeen
tai mitä vaan, koska DKIM, se on oikein.
00:46:37.569 --> 00:46:42.634
Eli nyt on kolman teknologia, jota
kutsutaan DMARCiksi. Ja taas,
00:46:42.634 --> 00:46:47.640
siinä on koko nimi, joka on pitkä. Mutta
tässä tapauksessa se tarkoittaa jotain.
00:46:47.640 --> 00:46:52.424
Siinä on kaksi avainsanaa: Reporting and
Conformance. Reporting on se
00:46:52.424 --> 00:46:56.660
jonka suurin osa admineista tuntee, koska
sillä DMARC, luulen, usein myydään
00:46:56.660 --> 00:47:01.619
heille. Raportointi tarkoittaa, että
kun sinulla on jotain ongelmia tässä
00:47:01.619 --> 00:47:08.390
tapauksessa, sinä voit päästä kertomaan
toiselle puolelle mitä tehdä siinä tapauksessa.
00:47:08.390 --> 00:47:13.309
Eli voit käskeä niitä lähettämään sinulle
raportteja kerran päivässä, tai joka kerta
00:47:13.309 --> 00:47:16.886
ja niin edelleen. Eli pentestaajalle se ei
ole niin hyödyllistä. Mahdollisesti voisimme
00:47:16.886 --> 00:47:20.509
käyttää sitä ymmästääksemme minkälainen
konfiguraatio toimii toisella puolella.
00:47:20.509 --> 00:47:25.000
Mutta nykyisin tämä toiminnallisuus ei ole
kovin laajasti implementoitu.
00:47:25.000 --> 00:47:30.309
Kuitenkin toinen osa, Conformance, se on
oikeasti todella, todella voimakas.
00:47:30.309 --> 00:47:35.251
Mitä se tekee, se korjaa nämä suuret viat
joista mainitsin, SPFssa ja DKIMssa.
00:47:35.251 --> 00:47:39.381
Ensinnäkin, DKIMssa oli tämä valtava ongelma
että jos poistit headerin, vastaanottajalla
00:47:39.381 --> 00:47:43.109
ei ollut mahdollista tietää mikäli sinä,
mikäli siinä oli, olisi
00:47:43.109 --> 00:47:49.377
pitänyt olla DKIM alunperin. Jos käytät
DKIMaa yhdessä DMARCin kanssa, se
00:47:49.377 --> 00:47:55.269
korjaa ongelman, koska DMARC määrittää
että sinulla on DMARC itsensä.
00:47:55.269 --> 00:47:59.220
Se tarkoittaa, että sinulla automaattiesti
toinen, joko SPF tai DKIM pitäisi mennä läpi.
00:47:59.220 --> 00:48:03.576
Eli automaattisesti DKIM mittaus ongelma
ratkaistu. Toinen asia, joka muuttuu on,
00:48:03.576 --> 00:48:08.599
se muuttaa semantiikkaa SPFaan. Nyt SPF,
jos sinulla on sekä SPF, että
00:48:08.599 --> 00:48:13.150
DMARC, se tarkoittaa, ettö SPF pitäisi
tarkastaa "from" headerista. Ja kuten mainitsin,
00:48:13.150 --> 00:48:17.319
se oli suuri vika SPFssa, koska jos käytit
SPFaa itseään, vaikka, se on hard fail
00:48:17.319 --> 00:48:21.440
tilassa ja niin edelleen, se tarkoittaa
että hyökkääjä voi muokata "from"
00:48:21.442 --> 00:48:26.710
headereita ja vastaanottaja ei tiedä sitä.
Pienin esimerkki DMARCsta on hyvin,
00:48:26.710 --> 00:48:31.210
hyvin pieni. Ja mielestäni se on helppo
ymmärtää. Sinulla on vain DMARC hylkää.
00:48:31.210 --> 00:48:36.890
Sinun pitää tavallaan löytää oikea paikka
määrittää, mutta se on helppoa ja kaikki
00:48:36.890 --> 00:48:40.740
mitä sinun pitää tehdä, on luoda tämä DNS
merkintä. Ja kaikki hyödyt tähän ovat,
00:48:40.740 --> 00:48:46.190
vaikka sinulla ei olisi DKIM ja DMARCia, jos
olet luonut. Anteeksi, jos sinulle ei ole SPF
00:48:46.190 --> 00:48:50.680
ja DKIM, mutta olet luonut DMARCin, oikeasti
se tarkoittaa että tämän domainin ei
00:48:50.680 --> 00:48:57.550
pitäisi lähettää yhtään postia, koska vastaan-
ottajan pitäessä mailia oikeana, pitäisi
00:48:57.550 --> 00:49:02.279
SPF tai DKIM olla oikein myös. Jos ne
eivät ole, se ei oi olla oikea.
00:49:02.279 --> 00:49:07.480
Eli oikeasti se tarkoittaa, että suurin osa
domaineista tuolla pitäisi harkita DMARC
00:49:07.480 --> 00:49:15.471
enablointia. Se on oikea asia tehdä. OK.
Eli on lisää tageja. Eli luonnossa,
00:49:15.471 --> 00:49:22.019
nämä DMARC kirjoukset voivat olla paljon
pidempiä, mutta niistä ei ole paljon hyötyä
00:49:22.019 --> 00:49:26.009
pentestaajille. Eli tärkeä osa tässä jälleen,
on tämä policy jossa voi olla
00:49:26.009 --> 00:49:31.184
kolme arvoa "none", "quarantine" ja
"reject". Ja jos se on "quarantine", se
00:49:31.184 --> 00:49:39.109
tarkoittaa, että jos, jos ei onnistu,
viestin pitäisi mennä spam kansioon.
00:49:39.109 --> 00:49:42.619
Jos se on "reject" se pitäisi hylätä heti.
Ja jos se on "none", se tarkoittaa, että
00:49:42.619 --> 00:49:47.960
se on tutkinta moodi. Ja tämä on kuva
jonka näytin aikaisemmin, joka näyttää
00:49:47.960 --> 00:49:52.400
että vaikkakin DMARC on oikeasti paras
teknologia näistä kolmesta,
00:49:52.400 --> 00:49:59.655
sitä ei oikeasti käytetä laajalti, ikävää
puolustajien kannalta. Aika kiva seikka
00:49:59.655 --> 00:50:05.070
kaikille penetraatio testaajille siellä.
Tämä tarkoittaa, että voit oikeasti
00:50:05.070 --> 00:50:14.550
väärentää suurimman osan sähköposteista.
Okei, kuinka kierrämme sen? Anteeksi. No.
00:50:14.550 --> 00:50:18.480
Mitä tapahtuu jos joku on oikeasti
implementoinut DMARCin? Tarkoittaako se
00:50:18.480 --> 00:50:23.526
että pentestaajat eivät voi tehdä mitään?
Sinun ei tarvitse edes tutkia mitään ?
00:50:23.526 --> 00:50:29.039
Ei, se ei tarkoita. Eli käytännössä, jos joku
on implementoinut DKIM ja DMARCin, mutta
00:50:29.039 --> 00:50:33.859
ei SPFaa, eli nyt heillä on kaksi niistä.
Se on kiva yhdistelmä. DKIM on melko
00:50:33.859 --> 00:50:38.470
voimakas ja sen merkittävän vian joka oli,
DMARC ratkaisi. Eli tämä yhdistelmä on
00:50:38.470 --> 00:50:44.680
tosi hyvä teoriassa. Käytännössä, ongelma
on, että suojataksesi omat sähköpostisi,
00:50:44.680 --> 00:50:49.751
vastaanottajan pitäisi tarkastaa molemmat
DKIM ja DMARC ja valitettavasti,
00:50:49.751 --> 00:50:53.932
melko monet ohjelmat eivät edelleen
tee sitä. Yksi niistä ohjelmista on
00:50:53.932 --> 00:50:57.920
Microsoft Exchange. Ja mikäli et käytä
Microsoft Exchangea, on hyvä todennäköisyys
00:50:57.920 --> 00:51:02.049
että joku kumppeneista jonka kanssa
kommunikoit käyttää Microsoft
00:51:02.049 --> 00:51:05.700
Exchangea ja vakiona siinä ei ole mitään
toimintoa DKIM parsimiseen.
00:51:05.700 --> 00:51:12.619
Eli oikeasti, valtaosan järjestelmistä pitää
enabloida SPF ihan käytännön syistä, mikä
00:51:12.619 --> 00:51:16.609
on hyvä pentestaajille, koska mikäli
SPF ja DMARC on enabloitu vakiona
00:51:16.609 --> 00:51:21.502
yhdessä, silloin se korjaa yhden suuren
ongelman SPFn kanssa, mutta ei
00:51:21.502 --> 00:51:25.864
automaattisesti korjaa muita ongelmia,
koska ei ole riittävää hienojakoisuutta ja
00:51:25.864 --> 00:51:32.119
virhe konfiguraation mahdollisuutta. Eli.
Ja mielenkiintoinen fakta on, että DMARC
00:51:32.119 --> 00:51:37.970
vaatii vain yhden toisen teknologian
SPFn tai DKIMn läpäisyn
00:51:37.970 --> 00:51:42.749
Tulkitakseen emailin oikeaksi. Ei ole muuta
tapaa DMARCssa, vaikka on monia muitakin
00:51:42.749 --> 00:51:45.680
selektoreja. Ei ole mahdollista määrittää,
että molempien niistä pitäisi olla oikein
00:51:45.680 --> 00:51:50.019
tai, että DKIM pitäisi olla edellä SPFaa.
Käytännössä, se tarkoittaa että useimmissa
00:51:50.019 --> 00:51:54.950
järjestelmissä, joissa on päällä kaikki
kolme niistä, mikä on hyvä käytännöllinen
00:51:54.950 --> 00:51:59.849
ratkaisu pentestaajan puolelta, voimme vain
unohtaa DKIM heti ja keskittyä SPFaan
00:51:59.849 --> 00:52:05.170
koska SPF on heikoin lenkki tässä tilanteessa.
Okei, vain yksi minuutti kertaukseen.
00:52:05.170 --> 00:52:11.559
En ole varma, onko minulla enää aikaa.
Minulla ei ole paljoa aikaa. Okei. Eli,
00:52:11.559 --> 00:52:17.140
anteeksi. Yeah. Eli yksi tärkeä asia huomata
on, että testatessasi järjestelmää, harkitse
00:52:17.140 --> 00:52:22.270
molempia skenaarioita. Eli älä keskity vain
lähettämiseen. Jos olet, esimerkiksi,
00:52:22.270 --> 00:52:27.599
testaamassa Alicea. Alice on organisaatio,
joka on asiakkaasi. Älä keskity vain testaamaan
00:52:27.599 --> 00:52:33.569
sähköpostien lähettämistä teeskennellen Alicea,
mutta myös toista puolta. Koska tässä voit
00:52:33.569 --> 00:52:38.670
nähdä, että on helppo implementoida,
esimerkiksi SPF ja DMARC, koska
00:52:38.670 --> 00:52:43.961
molempiin niistä, sinä tarvitset vain DNS
konfiguraation. Vain yksi merkintä kumpaankin.
00:52:43.961 --> 00:52:48.779
Kuitenkin niiden testaaminen, siis
todentaminen kunnolla on vaikeampaa.
00:52:48.779 --> 00:52:52.643
Ensinnäkinen tarvitset ohjelmistotuen ja
sinun pitää konfiguroida se oikein myös.
00:52:52.643 --> 00:52:56.585
Eli käytännössä voi olla, että useat
organisaatiot, jotka ovat enabloineet
00:52:56.585 --> 00:53:01.500
DMARCin tai SPFn DNS puolella lähteville
posteille, he eivät ole oikeasti kunnolla
00:53:01.500 --> 00:53:07.960
tarkastaneet sitä. Yeah. Okei. Anteeksi.
Minulla ei ole aikaa siihen. Eli varmaankin.
00:53:07.960 --> 00:53:16.009
Se on siinä, anteeksi. Ehkä pari kysymystä.
00:53:16.009 --> 00:53:24.601
aplodeja
00:53:24.601 --> 00:53:29.719
Herald: Kiitos, Andrew, tästä hyvästä
esityksestä. Toki. Meillä on aikaa parille
00:53:29.719 --> 00:53:33.839
kysymykselle. Eli tuolla näen jo yhden
henkilön, mikrofoni numero kaksi.
00:53:33.839 --> 00:53:40.150
M2: Hei, kiitos paljon. Tesdätkö jotain
hyvää työkalua valvomaan DMARC raportteja
00:53:40.150 --> 00:53:44.339
joita minulle lähettävät vastaanottajani.
A: Yeah. Tämä on todella hyvä kysymys.
00:53:44.339 --> 00:53:49.940
Me CERTna, me todella suositamme kaikille
tämän työkalun käyttöönottoa, mutta
00:53:49.940 --> 00:53:55.190
valitettavasti, tietääkseni, kaikki
työkalut, jotka ovat suosittuja netissä,
00:53:55.190 --> 00:53:59.670
ne keräävät jotain dataa sinusta. Eli
ne käyttävät sitä markkinointitarkoituksiin,
00:53:59.670 --> 00:54:04.412
ne eivät ole hyviä yksityisyyden kannalta,
jos olet siitä huolissaan.
00:54:04.412 --> 00:54:07.880
Eli sinun pitää implementoida jotain itse
tai sinun pitää katsoa jotain, aloita
00:54:07.880 --> 00:54:12.180
joku open source projekti ehkä.
Herald: OK. Mikrofoni numero yksi, kiitos.
00:54:12.180 --> 00:54:16.428
M1: Kiitos hyvästä esityksestä. Minä itse,
pidän itseäni email pääkäyttäjänä.
00:54:16.428 --> 00:54:23.609
Minua joskus ohjeistetaan lyhentämään
meidän SPF listaa, koska jos se on liian
00:54:23.609 --> 00:54:28.859
pitkä, se poistetaan kuitenkin. Siksi
minua joskus neuvotaan pudottamaan
00:54:28.859 --> 00:54:34.930
PTR kirjaus. Mutta esityksessäsi, sanot,
että PTR merkintä on hyödyllinen reverse
00:54:34.930 --> 00:54:39.549
DNS tarkastuksessa, jonka koen myös hyödyl-
lisenä. Miten ajattelet SPF listan lyhentämisestä
00:54:39.549 --> 00:54:42.920
ja mitä ajattelet PTR merkinnöistä yleensä.
00:54:42.920 --> 00:54:47.530
A: No, se oikeastaan riippuu juuri sinun
tapauksesta. Eli voi olla tilanne, että
00:54:47.530 --> 00:54:51.230
jotkut organisaatiot todella tarvitsevat
tämän pitkän SPF listan ja sitä ei voi
00:54:51.230 --> 00:54:55.799
kiertää sinun toimesta. Mitä voisit tehdä
on sisällyttää tämä, sisällytä käytä includea
00:54:55.799 --> 00:55:01.479
koska ne eivät ole, ne eivät ole makroja,
eli ne eivät tule laajennetuiksi. Ne eivät
00:55:01.479 --> 00:55:07.755
kuten, sinun lista ei tule pidemmäksi jos
sisällytät ja käytät useita includeja. Mutta
00:55:07.755 --> 00:55:12.119
ongelma, jota suosittelisin sinulle on,
harkitse tarvitsetko todella, todellako
00:55:12.119 --> 00:55:16.970
tarvitset niin monta merkintää jos se
on silti niin pitkä, koska ne ovat hyvin
00:55:16.970 --> 00:55:20.499
yleinen ongelma, on että ellet ole Google
tai jotain sellaista, et oikeasti tarvitse
00:55:20.499 --> 00:55:26.660
niin pitkää SPF listaa. Se on varmaan
ongelma jossain. Yeah. Eli se on varmaan
00:55:26.660 --> 00:55:36.489
virhe useimmissa organisaatioissa.
Herald: OK. Sopii, kyllä. Vain lyhyesti.
00:55:36.489 --> 00:55:40.496
Numero 1
M1: PTR record kirjauksesta. Kuulin, että
00:55:40.496 --> 00:55:43.489
se pudotetaan. Ei pudoteta standardeista,
mutta sitä ei ole standardeissa.
00:55:43.489 --> 00:55:48.859
A: Se on standardeissa. Ei. PRT kirjaus
itsenään, jos se on todella sinun tapaus.
00:55:48.859 --> 00:55:53.599
En tiedä, En ole tietoinen että sitä
automaattisesti pudotetaan jonnekin.
00:55:53.599 --> 00:55:56.380
Ei pitäisi olla ongelma.
Herald: Meillä on pari
00:55:56.380 --> 00:55:59.349
kysymystä lisää täällä. Eli numero
kuusi, siellä ihan takana.
00:55:59.349 --> 00:56:07.420
M6: Kiitos, kiitos esityksestä. Tämä ei
suoraan liity, mutta vaikka sen pitäisi
00:56:07.420 --> 00:56:13.800
liittyä. Jos postipalvelin hyväksyy, koska
DKIM, DMARC ja SPF, kaikki on hyvin,
00:56:13.800 --> 00:56:18.779
mutta erityisesti Google, useille organi-
saatioille, posti toimitetaan mutta
00:56:18.779 --> 00:56:24.089
luokitellaan spamiksi. Se tarkoittaa, että
vastaanottajan inboxissa, sitä ei näytetä.
00:56:24.089 --> 00:56:28.069
Onko sinulla ratkaisua jolla ratkaistaan
tämä ongelma Googlea vastaan.
00:56:28.069 --> 00:56:33.630
A: Yeah. OK. Eli minulla on erilaisia
mielipiteitä siitä, koska yksi asia joka
00:56:33.630 --> 00:56:38.787
oikeasti saa meidät tekemään, mitä meidän
pitäisi tehdä. Kiitos Google. On, että he
00:56:38.787 --> 00:56:42.859
ovat niin tiukkoja, että koska se on ainoa
syy miksi meillä edes on näin korkea
00:56:42.859 --> 00:56:47.879
prosentti edes huonosti konfiguroituja SPFia.
Ainoa syy miksi 70 prosenttia web-sivuista
00:56:47.879 --> 00:56:52.829
käyttää SPFaa on, koska heidän pitää
kommunikoida Googlelle.
00:56:52.829 --> 00:56:56.690
Ja Google ei hyväksy postiasi, jos sillä ei
ole edes SPF perusteita. Eli minä
00:56:56.690 --> 00:57:04.269
oikeastaan pidän työstä jota teen. Minä.
Minä suosisin, että Google tekee mitä tekee.
00:57:04.269 --> 00:57:09.527
Mutta ymmärrän oikeita admineja, joilla
on tämä ongelma. Googlella on työkalu.
00:57:09.527 --> 00:57:15.239
Te varmaan tiedätte siitä. Missä voit
tarkastaa mitä se ajattelee sinun domainista.
00:57:15.239 --> 00:57:19.323
Eli sinun pitää harkita tätä ongelmaa
tapaus tapaukselta. Aika usein
00:57:19.323 --> 00:57:23.559
mitä tapahtuu on, että vaikka sinulla on
tämä DKIM, DMARC ja niin edelleen, sitä ei
00:57:23.559 --> 00:57:28.576
ole konfiguroitu oikein. Eli mistä esitys
oli. Siinä se on. Sinä varmaankin
00:57:28.576 --> 00:57:31.259
ajattelet konfiguroineesi sen oikein,
mutta siinä on virheitä.
00:57:31.259 --> 00:57:35.249
Herald: Okei, annetaan etusija
Internetille.
00:57:35.249 --> 00:57:40.170
Signal Angel: Meillä on kysymys Internetistä.
No, Yrittäessä varmistaa ja päättää
00:57:40.170 --> 00:57:43.819
miten käsitellä "älä vastaa" email
osoitteita.
00:57:43.819 --> 00:57:49.999
A: Ei vastausta, anteeksi. Voitko lukea sen
uudelleen.
00:57:49.999 --> 00:57:55.170
Signal Angel: Kun yrittäessä varmistaa
osoitetta, kuinka käsitellä No Reply
00:57:55.170 --> 00:58:04.529
email osoitteita.
A: Ehkä se oli noreply headereista kyse?
00:58:04.529 --> 00:58:10.650
Tai olemattomista IP osoitteista?
Signal Angel: Kuinka käsitellä emailia
00:58:10.650 --> 00:58:14.809
"No Reply" email osoitteesta.
A: Koitan vastata kuten kuinka käsitän sen.
00:58:14.809 --> 00:58:21.532
Eli mitä usein tapahtuu on, mitä usein
tapahtuu on, että sähköposti
00:58:21.532 --> 00:58:25.294
lähetetään olemattomasta osoitteesta. Eli
ehkä siitä oli kysymys. Esimerkiksi
00:58:25.294 --> 00:58:29.789
siinä on "no reply" ja se ei ole ongelma
itsessään. No Reply. Ongelma on, ettei
00:58:29.789 --> 00:58:34.339
se ole oikea osoite. Ei ole olemassa sitä
osoitetta. Just. Ja niin minulle ei ole
00:58:34.339 --> 00:58:38.816
vastausta tähän, koska RFCn mukaan, sinun
pitäisi, pitäisi silti hyväksyä se.
00:58:38.816 --> 00:58:43.627
Käytännössä. kuten sanoin, useat sähköposti
järjestelmät jo hylkäävät tämän osoitteen
00:58:43.627 --> 00:58:46.420
jos lähetät olemattomasta, ellet ole
Google tai jotain
00:58:46.420 --> 00:58:50.150
suurta, jolloin sinut on laitettu whitelistalle.
Et vain voi tehdä sitä.
00:58:50.150 --> 00:58:54.779
Et voi lähettää sähköpostia olemattomasta
osoitteesta. Eli jos se on sinun tilanteesi,
00:58:54.779 --> 00:59:00.309
luo se osoite, laita se vaikka poistamaan
kaikki email joka sinne tulee,
00:59:00.309 --> 00:59:03.640
mutta luo oikea osoite, joka sinun on
hyväksyttävä. Jos olet toisella puolella.
00:59:03.640 --> 00:59:08.269
Eli jos saat tämän emailin. Se riippuu
siitä tietystä tapauksesta.
00:59:08.269 --> 00:59:12.099
Eli katso mitä on meneillään. Jos voit ottaa
heihin yhteyttä, ota yhteyttä. Jos et voi
00:59:12.099 --> 00:59:16.220
ottaa yhteyttä, sitten sinun pitää päättää
mikä on riski, jos hylkäät nämä osoitteet,
00:59:16.220 --> 00:59:23.920
ovatko ne tärkeitä sinulle? Eli RFCn
mukaan sinun pitää ottaa vastaan ja
00:59:23.920 --> 00:59:28.660
prosessoida tämä osoite.
Herald. Okei, Mikrofoni numero neljä,
00:59:28.660 --> 00:59:33.040
ole hyvä.
M4: Hei, kiitos esityksestäsi. Tiedätkö
00:59:33.040 --> 00:59:40.630
yrityksistä ratkaista ongelma suurten email
lähettäjien osalta kuten online kirjakauppojen,
00:59:40.630 --> 00:59:47.450
jotka ovat kivoja, koska niillä ei näytä
olevan omia SPF kirjauksia, esimerkiksi
00:59:47.450 --> 00:59:53.253
omassa hallinnassaan.
A: Yeah. Eli monessa tapauksessa voit vain
00:59:53.253 --> 00:59:56.711
ottaa heihin yhteyttä. Eli kyse on vain
siitä, että he eivät ajatelleet sitä.
00:59:56.711 --> 01:00:01.770
Tai ehkä kukaan ei ole kertonut mitä tehdä,
tai ehkä he eivät kuinka tehdä paremmin. Just.
01:00:01.770 --> 01:00:05.249
Eli se on yksi asioista, joita CERTna me
olemme tekemässä. Jos teillä joillain on
01:00:05.249 --> 01:00:10.619
tämä ongelma suuren yrityksen kanssa
jossain tietyssä maassa, suosittelen puhumaan
01:00:10.619 --> 01:00:14.470
CERTlle. Vaikka se ei olisi valtiollinen
organisaatio, esimerkiksi, Latviassa,
01:00:14.470 --> 01:00:18.700
jos se olisi Latvialainen yritys.
Me teemme triagen. Me yrittäisimme
01:00:18.700 --> 01:00:21.892
puhua heille, selittää miksi he tarvitsevat
muutosta ja niin edelleen.
01:00:21.892 --> 01:00:26.289
Eli se on yksi vaihtoehto sinulle. Mutta
käytännössä jos joku näyttää sinusta
01:00:26.289 --> 01:00:30.060
kolmantena osapuolena väärältä
konfiguraatiolta, en voinut sitä mainita
01:00:30.060 --> 01:00:34.400
tässä esityksessä. Jos joku ei ole täysin
turvallinen, se ei tarkoita, että se olisi
01:00:34.400 --> 01:00:39.460
väärin. Voi olla oikeasti liiketoiminta
vaatimus miksi sen pitää olla niin.
01:00:39.460 --> 01:00:42.229
Just. Koska esimerkiksi, jos se on iso,
en tiedä, Amazon ja joku tai
01:00:42.229 --> 01:00:46.700
jotain sellaista. Ja jos he ovat testanneet
ja tietävät, että jos he kytkevät todella tiukan
01:00:46.700 --> 01:00:51.697
konfiguraation, tietty prosentti heidän
emaileista vain jää saapumatta. Ei heidän
01:00:51.697 --> 01:00:55.762
ongelman takia, vaan jonkun toisen
ongelman. Just. Mutta sitten on
01:00:55.762 --> 01:00:59.759
ihan oikea bsiness case, jota he
eivät ole. Olisi heidän kannalta typerää
01:00:59.759 --> 01:01:04.489
laittaa se päälle, tiedäthän, tiukka
konfiguraatio, tietäen että se
01:01:04.489 --> 01:01:08.970
vahingoittaa heidän liiketoimintaa.
Siinä on järkeä, eikö vain?
01:01:08.970 --> 01:01:13.479
Herald: Okei, Meillä on valitettavasti aika
loppumassa niille, jotka ovat mikrofoneilla.
01:01:13.479 --> 01:01:17.755
Olkaa hyvä ja tulkaa vain jonoon puhujalle
pöydän viereen. Hän puhuu
01:01:17.755 --> 01:01:21.195
teille. Varmastikin. Ja.
01:01:21.195 --> 01:01:25.159
aplodeja
01:01:25.159 --> 01:01:40.959
36c3 esityksen jälkimusiikki
01:01:40.959 --> 01:01:53.000
Translated by Esa Lammi
(KYBS2001 course assignment at JYU.FI)