ICO wiki - User contributions [en]

IT infrastruktuuri teenused 2013 kevad

2013-05-13T12:27:11Z

Mignatje: /* IT infrastruktuuri teenused kirjatükid 2013 kevad päevaõpe */

[[Category:IT infrastruktuuri teenused]]
=IT infrastruktuuri teenused kirjatükid 2013 kevad päevaõpe=

* Nimi, rühm - referaadi link
* Marju Ignatjeva, DK41 - [[HTTPS_liikluse_uurimine_tcpdump,_Wireshark_ja_mitmproxy_abil | HTTPS liikluse uurimine tcpdump, Wireshark ja mitmproxy abil]]
*
*

HTTPS liikluse uurimine tcpdump, Wireshark ja mitmproxy abil

2013-05-05T20:27:21Z

Mignatje: /* Teeseldud CA */ Väike sisuline parandus

See artikkel räägib HTTPS liikluse analüüsimisest (HTTP päringute avatekstiks lahtivõtmise teel) kahes olukorras.
Esiteks -- kui nii klient kui server on meie hallata ja me soovime testida, kas server saab just selliseid HTTP päringuid ja saadab selliseid vastuseid, nagu me eeldame.
Teiseks -- kui serveriks on mõni avalik veebiteenus, millega suhtleme üle HTTPS protokolli, ja soovime teada, mida meie brauser serveriga räägib. Sisuliselt on siin tegemist olukorraga, kus me ei pruugi usaldada ei klienti (brauser jooksutab meie teadmata mingit kuritahtlikku skripti) ega ka serverit. Tegu võib olla ka mõne mobiilirakendusega, mille kohta soovime teada, mis andmeid ta meie telefoni kaudu edastab ja vastu võtab.

'''NB! Siin artiklis toodud juhised on mõeldud võrguliikluse heatahtlikuks uurimiseks, mitte kolmandate osapoolte andmevahetusse sissemurdmiseks!'''

''Autor: Marju Ignatjeva''

==Töövahendid ja keskkond==
Kasutame töövahenditena <tt>tcpdump</tt>-i ja Wiresharki ning <tt>mitmproxy</tt>-t, HTTP kliendina ka <tt>curl</tt>-i.

Läbivalt on kasutusel serveri aadress 192.168.56.201.

Artikli lugejalt eeldan, et HTTPS üldine tööpõhimõte on selge ja et lugeja oskab Linuxi keskkonnas paigaldada tarkvara nii süsteemsest pakimajandusest kui ka Pythoni pakendussüsteemide (eeskätt <tt>pip</tt>) vahenditega, samuti saab hakkama käsureal. Töövahendite paigaldamise juhised on siiski ka artiklis olemas.

Artiklis toodud näited põhinevad katsetustel 64-bitise Kubuntu 12.10 operatsioonisüsteemi all.

===Töövahendite paigaldamine===
Kui <tt>tcpdump</tt> ei ole paigaldatud, tuleb see juurkasutajana paigaldada käsuga
<pre>
apt-get install tcpdump
</pre>

Wiresharki paigaldame käsuga
<pre>
apt-get install wireshark
</pre>

HTTP päringuid on käsurealt mugav teha <tt>curl</tt> nimelise tööriistaga, paigaldame ka selle.
<pre>
apt-get install curl
</pre>

Kuna erinevate Linuxi distributsioonide pakimajanduses ei pruugi alati olla Pythonis kirjutatud tarkvarast väga värskeid versioone, siis <tt>mitmproxy</tt> paigaldamiseks on mõistlik kasutada <tt>pip</tt>-i.
<pre>
apt-get install python-pip
pip install mitmproxy
</pre>

==tcpdump ja Wireshark==
HTTPS liikluse püüdmiseks kasutame käsureavahendit <tt>tcpdump</tt> seetõttu, et servereid hallates ei ole meil tihtipeale ligipääsu graafilisele keskkonnale. Samas on Wireshark mugav ja kasutajasõbralik võrguliikluse uurimise töövahend ja <tt>tcpdump</tt>-i abil salvestatud liiklust saab Wiresharki abil hiljem suvalises teises masinas analüüsida.

Kuna veebiserver on meie hallata, siis on meil olemas tema privaatvõti. See on ainus vajalik sisend Wiresharkile, et ta oskaks kinnipüütud pakette lahti krüpteerida.

===Pakettide püüdmine===
Kõigepealt paneme <tt>tcpdump</tt>-i kuulama liiklust liidesel <tt>eth1</tt> (antud juhul on see Virtualboxi ''host-only'' võrguliides), aadressil 192.168.56.201, pordil 443 (meil on sinna konfitud üks HTTPS toega ''virtualhost''). Seda tuleb teha juurkasutaja õigustes, et meile antaks ligipääs võrguliidesele.
<pre>
tcpdump -w https_dump.pcap -i eth1 host 192.168.56.201 and port 443
</pre>

Teeme klientmasinast päringu (öeldes, et usaldame serveri enda poolt allkirjastatud sertifikaati):
<pre>
curl --insecure https://192.168.56.201
</pre>

Nüüd lõpetame Ctrl+C abil serveris <tt>tcpdump</tt>i töö -- too ütleb lõpetades käsureale midagi sellist:
<pre>
15 packets captured
15 packets received by filter
0 packets dropped by kernel
</pre>

===Püütud pakettide uurimine===
Järgmiseks on vaja <tt>tcpdump</tt>-i väljundfail saada masinasse, kus meil on võimalik kasutada Wiresharki (kusjuures salvestatud faili uurimiseks ei ole juurkasutaja õiguseid vaja).
Käivitame Wiresharki ja avame oma .pcap faili. Esialgu näitab Wireshark küll HTTPS-iga seotud andmevahetust, kuid HTTP päringuid avatekstina pole võimalik näha.
Wireshark võimaldab seda krüpteeritud sisuga andmevoogu ka eraldi aknas uurida ("Follow TCP Stream" suvalise paketi kontekstimenüüst).

Järgmiseks hangime serverist tema privaatvõtme (NB! Erinevate ''virtualhost''ide olemasolul pead hankima just antud päringus kasutatud IP-le vastava võtme!)

Wiresharkis võtame menüüst "Edit"->"Preferences" avanevas aknas "Protocols" alt "SSL" ja lisame serveri võtme:

[[File:Marju ignatjeva Screenshot wireshark ssl keys.png|600px]]

Kasulik on seadistada ka SSL ''debuglog''i failitee, et probleemide korral saaks vigu otsida. Näiteks võib juhtuda, et brauseri või serveri krüpto vaikeseadistused on sellised, et Wireshark ei saa pakettide sisu lahti krüpteerida, kuigi serveri privaatvõti ja muud parameetrid on korrektsed (failitee seadistamine jääb lugejale väljauurimiseks).

Nimelt võib juhtuda, et peale võtmefaili määramist ja HTTPS suhtlusega seotud paketi kontekstimenüüs "Follow SSL Stream" valimist näidatakse tühjust.

Sellisel juhul võiks debuglogist otsida sääraseid ridu:
<pre>
ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt
dissect_ssl3_handshake can't decrypt pre master secret
</pre>

Nimelt Apache2 <tt>mod_ssl</tt> vaikimisi konfis on lubatud Diffie-Hellman võtmevahetuse protokolli kasutamine, mis aga muudab HTTPS liikluse Wireshark-i jaoks lahtivõetamatuks (erinevate krüptoprotokollide detailid on väljaspool selle artikli mahtu, kuid võtmefraasiks on siin ''perfect forward secrecy'').
Lähemalt loe näiteks:
[http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange Wikipediast]
ja
[http://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls Stackexchange'ist].

Üks võimalikke lahendusi on Apache2 <tt>mod_ssl</tt> konfis (<tt>/etc/apache2/mods-available/ssl.conf</tt>) keelata Diffie-Hellman võtmevahetuse tugi, näiteks võtmesõna DH abil:
<pre>
SSLCipherSuite ALL:!EXP:!NULL:!DH:!LOW
</pre>

Vt. lähemalt: [http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite]

Peale veebiserveri restarti tuleb teha uus paketipüüdmine. Kui kõik muu on korrektselt tehtud, võib Wiresharkis uue .pcap faili avamisel näha umbes sellist pilti ja HTTP päringut-vastust avatekstina uurida:

[[File:Marju ignatjeva Screenshot wireshark https decrypted.png|600px]]

==mitmproxy==

===Kliendi proxy seadistamine===
Selleks, et <tt>mitmproxy</tt> abil HTTPS liikluse sisu uurida, tuleb ta kõigepealt HTTP kliendis (brauseris, <tt>curl</tt>-is vms) seadistada ''proxy''-ks.
Nimelt, kui <tt>mitmproxy</tt> käivitada, siis vaikimisi kuulab ta aadressil 0.0.0.0 pordil 8080. Seega <tt>curl</tt>-ile anname need parameetrid ''proxy'' jaoks ja teeme HTTPS päringu oma serveri pihta.

curl -x localhost:8080 --insecure https://192.168.56.201

See päring ja vastus kajastuvad nüüd <tt>mitmproxy</tt> interaktiivses aknas.

Päriselus kasutame vingemate veebirakenduste kasutamiseks siiski graafilist brauserit ja edasi läheme Chromiumi näitel, kus samuti on kõigepealt vaja seadistada ''proxy'' (ja brauser restartida). Seda siin ei kirjelda.

===Teeseldud CA===
Kui <tt>mitmproxy</tt> on seadistatud ''proxy''-ks, siis HTTPS päringute korral pakub ta brauserile tegeliku serveri sertifikaadi asemel omaenda n-ö ''dummy'' sertifikaati (e. mängib CA-d) ja on seetõttu võimeline ka HTTPS liiklust "vahelt võtma", termineerides kliendi päringu ja suheldes omakorda ise serveriga. Peale esimest käivitust tekivad kasutaja kodukataloogi alamkataloogi <tt>.mitmproxy</tt> selle dummy CA-ga seotud failid.
<pre>
ls ~/.mitmproxy/
mitmproxy-ca-cert.cer mitmproxy-ca-cert.p12 mitmproxy-ca-cert.pem mitmproxy-ca.pem
</pre>

Sellist dummy CA-d brauser vaikimisi ei usalda ja reageerib nagu tüüpiliselt ka iseallkirjastatud sertifikaatide puhul. Kui "harjumuspäraselt" vajutada "Proceed anyway", saame vaatlusalusele saidile tehtud HTTPS päringuid ja vastuseid üsna mugavalt uurida. Muidugi on <tt>mitmproxy</tt> CA võimalik lisada ka brauseri poolt usaldatavate CA-de hulka, aga seda siin ei kirjelda.

===HTTPS päringute vaheltvõtmine===
Edasi seadistame konkreetsele aadressile tehtavate päringute vaheltvõtmise. Selleks tuleb <tt>mitmproxy</tt> peaaknas vajutada "i" ja sisestada regulaaravaldis, mis meil on "192\.168\.56\.200".

Kui nüüd minna aadressile https://192.168.56.201, siis brauser jääb ootele ja <tt>mitmproxy</tt> aknasse tekib päringukirje, ning vaheltvõetud päringu edasisaatmiseks tuleb vajutada "a". Seda tuleb teha ka vastusega, kui me vastust muuta ei soovi, et brauser vastuse kätte saaks.

Päringuid ja vastuseid, mis veel ei ole "a" abil "aktsepteeritud", saame avatekstina uurida ja muuta! Lugejale jääb välja uurimiseks, mida mitmproxy peab silmas teatega "<tt>[decoded gzip] Couldn't parse: falling back to Raw</tt>" ja kas see takistab meil vastuse muutmist avatekstina.

Näide vaheltvõetud vastusest:

[[File:Marju ignatjeva Screenshot mitmproxy response.png|600px]]

Põhjalikum <tt>mitmproxy</tt> [http://mitmproxy.org/doc/index.html kasutusjuhend] kirjeldab nii päringute filtreerimist kui päringute ja vastuste redigeerimist ja palju muud.

Head eksperimenteerimist! ;-)

==Kasutatud materjalid==
* [http://segfault.in/2010/11/decrypt-https-traffic-using-wireshark-and-key-file/ Decrypt HTTPS Traffic Using Wireshark And Key File]
* [http://www.youtube.com/watch?v=kQ1-0G90lQg mitmproxy - use and abuse of a hackable SSL-capable man-in-the-middle proxy - YouTube]

[[Category:IT infrastruktuuri teenused]]

HTTPS liikluse uurimine tcpdump, Wireshark ja mitmproxy abil

2013-05-05T20:05:18Z

Mignatje: typo

See artikkel räägib HTTPS liikluse analüüsimisest (HTTP päringute avatekstiks lahtivõtmise teel) kahes olukorras.
Esiteks -- kui nii klient kui server on meie hallata ja me soovime testida, kas server saab just selliseid HTTP päringuid ja saadab selliseid vastuseid, nagu me eeldame.
Teiseks -- kui serveriks on mõni avalik veebiteenus, millega suhtleme üle HTTPS protokolli, ja soovime teada, mida meie brauser serveriga räägib. Sisuliselt on siin tegemist olukorraga, kus me ei pruugi usaldada ei klienti (brauser jooksutab meie teadmata mingit kuritahtlikku skripti) ega ka serverit. Tegu võib olla ka mõne mobiilirakendusega, mille kohta soovime teada, mis andmeid ta meie telefoni kaudu edastab ja vastu võtab.

'''NB! Siin artiklis toodud juhised on mõeldud võrguliikluse heatahtlikuks uurimiseks, mitte kolmandate osapoolte andmevahetusse sissemurdmiseks!'''

''Autor: Marju Ignatjeva''

==Töövahendid ja keskkond==
Kasutame töövahenditena <tt>tcpdump</tt>-i ja Wiresharki ning <tt>mitmproxy</tt>-t, HTTP kliendina ka <tt>curl</tt>-i.

Läbivalt on kasutusel serveri aadress 192.168.56.201.

Artikli lugejalt eeldan, et HTTPS üldine tööpõhimõte on selge ja et lugeja oskab Linuxi keskkonnas paigaldada tarkvara nii süsteemsest pakimajandusest kui ka Pythoni pakendussüsteemide (eeskätt <tt>pip</tt>) vahenditega, samuti saab hakkama käsureal. Töövahendite paigaldamise juhised on siiski ka artiklis olemas.

Artiklis toodud näited põhinevad katsetustel 64-bitise Kubuntu 12.10 operatsioonisüsteemi all.

===Töövahendite paigaldamine===
Kui <tt>tcpdump</tt> ei ole paigaldatud, tuleb see juurkasutajana paigaldada käsuga
<pre>
apt-get install tcpdump
</pre>

Wiresharki paigaldame käsuga
<pre>
apt-get install wireshark
</pre>

HTTP päringuid on käsurealt mugav teha <tt>curl</tt> nimelise tööriistaga, paigaldame ka selle.
<pre>
apt-get install curl
</pre>

Kuna erinevate Linuxi distributsioonide pakimajanduses ei pruugi alati olla Pythonis kirjutatud tarkvarast väga värskeid versioone, siis <tt>mitmproxy</tt> paigaldamiseks on mõistlik kasutada <tt>pip</tt>-i.
<pre>
apt-get install python-pip
pip install mitmproxy
</pre>

==tcpdump ja Wireshark==
HTTPS liikluse püüdmiseks kasutame käsureavahendit <tt>tcpdump</tt> seetõttu, et servereid hallates ei ole meil tihtipeale ligipääsu graafilisele keskkonnale. Samas on Wireshark mugav ja kasutajasõbralik võrguliikluse uurimise töövahend ja <tt>tcpdump</tt>-i abil salvestatud liiklust saab Wiresharki abil hiljem suvalises teises masinas analüüsida.

Kuna veebiserver on meie hallata, siis on meil olemas tema privaatvõti. See on ainus vajalik sisend Wiresharkile, et ta oskaks kinnipüütud pakette lahti krüpteerida.

===Pakettide püüdmine===
Kõigepealt paneme <tt>tcpdump</tt>-i kuulama liiklust liidesel <tt>eth1</tt> (antud juhul on see Virtualboxi ''host-only'' võrguliides), aadressil 192.168.56.201, pordil 443 (meil on sinna konfitud üks HTTPS toega ''virtualhost''). Seda tuleb teha juurkasutaja õigustes, et meile antaks ligipääs võrguliidesele.
<pre>
tcpdump -w https_dump.pcap -i eth1 host 192.168.56.201 and port 443
</pre>

Teeme klientmasinast päringu (öeldes, et usaldame serveri enda poolt allkirjastatud sertifikaati):
<pre>
curl --insecure https://192.168.56.201
</pre>

Nüüd lõpetame Ctrl+C abil serveris <tt>tcpdump</tt>i töö -- too ütleb lõpetades käsureale midagi sellist:
<pre>
15 packets captured
15 packets received by filter
0 packets dropped by kernel
</pre>

===Püütud pakettide uurimine===
Järgmiseks on vaja <tt>tcpdump</tt>-i väljundfail saada masinasse, kus meil on võimalik kasutada Wiresharki (kusjuures salvestatud faili uurimiseks ei ole juurkasutaja õiguseid vaja).
Käivitame Wiresharki ja avame oma .pcap faili. Esialgu näitab Wireshark küll HTTPS-iga seotud andmevahetust, kuid HTTP päringuid avatekstina pole võimalik näha.
Wireshark võimaldab seda krüpteeritud sisuga andmevoogu ka eraldi aknas uurida ("Follow TCP Stream" suvalise paketi kontekstimenüüst).

Järgmiseks hangime serverist tema privaatvõtme (NB! Erinevate ''virtualhost''ide olemasolul pead hankima just antud päringus kasutatud IP-le vastava võtme!)

Wiresharkis võtame menüüst "Edit"->"Preferences" avanevas aknas "Protocols" alt "SSL" ja lisame serveri võtme:

[[File:Marju ignatjeva Screenshot wireshark ssl keys.png|600px]]

Kasulik on seadistada ka SSL ''debuglog''i failitee, et probleemide korral saaks vigu otsida. Näiteks võib juhtuda, et brauseri või serveri krüpto vaikeseadistused on sellised, et Wireshark ei saa pakettide sisu lahti krüpteerida, kuigi serveri privaatvõti ja muud parameetrid on korrektsed (failitee seadistamine jääb lugejale väljauurimiseks).

Nimelt võib juhtuda, et peale võtmefaili määramist ja HTTPS suhtlusega seotud paketi kontekstimenüüs "Follow SSL Stream" valimist näidatakse tühjust.

Sellisel juhul võiks debuglogist otsida sääraseid ridu:
<pre>
ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt
dissect_ssl3_handshake can't decrypt pre master secret
</pre>

Nimelt Apache2 <tt>mod_ssl</tt> vaikimisi konfis on lubatud Diffie-Hellman võtmevahetuse protokolli kasutamine, mis aga muudab HTTPS liikluse Wireshark-i jaoks lahtivõetamatuks (erinevate krüptoprotokollide detailid on väljaspool selle artikli mahtu, kuid võtmefraasiks on siin ''perfect forward secrecy'').
Lähemalt loe näiteks:
[http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange Wikipediast]
ja
[http://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls Stackexchange'ist].

Üks võimalikke lahendusi on Apache2 <tt>mod_ssl</tt> konfis (<tt>/etc/apache2/mods-available/ssl.conf</tt>) keelata Diffie-Hellman võtmevahetuse tugi, näiteks võtmesõna DH abil:
<pre>
SSLCipherSuite ALL:!EXP:!NULL:!DH:!LOW
</pre>

Vt. lähemalt: [http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite]

Peale veebiserveri restarti tuleb teha uus paketipüüdmine. Kui kõik muu on korrektselt tehtud, võib Wiresharkis uue .pcap faili avamisel näha umbes sellist pilti ja HTTP päringut-vastust avatekstina uurida:

[[File:Marju ignatjeva Screenshot wireshark https decrypted.png|600px]]

==mitmproxy==

===Kliendi proxy seadistamine===
Selleks, et <tt>mitmproxy</tt> abil HTTPS liikluse sisu uurida, tuleb ta kõigepealt HTTP kliendis (brauseris, <tt>curl</tt>-is vms) seadistada ''proxy''-ks.
Nimelt, kui <tt>mitmproxy</tt> käivitada, siis vaikimisi kuulab ta aadressil 0.0.0.0 pordil 8080. Seega <tt>curl</tt>-ile anname need parameetrid ''proxy'' jaoks ja teeme HTTPS päringu oma serveri pihta.

curl -x localhost:8080 --insecure https://192.168.56.201

See päring ja vastus kajastuvad nüüd <tt>mitmproxy</tt> interaktiivses aknas.

Päriselus kasutame vingemate veebirakenduste kasutamiseks siiski graafilist brauserit ja edasi läheme Chromiumi näitel, kus samuti on kõigepealt vaja seadistada ''proxy'' (ja brauser restartida). Seda siin ei kirjelda.

===Teeseldud CA===
Kui <tt>mitmproxy</tt> on seadistatud ''proxy''-ks, siis HTTPS päringute korral pakub ta brauserile tegeliku serveri sertifikaadi asemel omaenda n-ö ''dummy'' sertifikaati (e. mängib CA-d) ja on seetõttu võimeline ka HTTPS liiklust "vahelt võtma", kuna HTTPS osapoolteks on klient ja <tt>mitmproxy</tt>, mitte enam server. Peale esimest käivitust tekivad kasutaja kodukataloogi alamkataloogi <tt>.mitmproxy</tt> selle dummy CA-ga seotud failid.
<pre>
ls ~/.mitmproxy/
mitmproxy-ca-cert.cer mitmproxy-ca-cert.p12 mitmproxy-ca-cert.pem mitmproxy-ca.pem
</pre>

Sellist dummy CA-d brauser vaikimisi ei usalda ja reageerib nagu tüüpiliselt ka iseallkirjastatud sertifikaatide puhul. Kui "harjumuspäraselt" vajutada "Proceed anyway", saame vaatlusalusele saidile tehtud HTTPS päringuid ja vastuseid üsna mugavalt uurida. Muidugi on <tt>mitmproxy</tt> CA võimalik lisada ka brauseri poolt usaldatavate CA-de hulka, aga seda siin ei kirjelda.

===HTTPS päringute vaheltvõtmine===
Edasi seadistame konkreetsele aadressile tehtavate päringute vaheltvõtmise. Selleks tuleb <tt>mitmproxy</tt> peaaknas vajutada "i" ja sisestada regulaaravaldis, mis meil on "192\.168\.56\.200".

Kui nüüd minna aadressile https://192.168.56.201, siis brauser jääb ootele ja <tt>mitmproxy</tt> aknasse tekib päringukirje, ning vaheltvõetud päringu edasisaatmiseks tuleb vajutada "a". Seda tuleb teha ka vastusega, kui me vastust muuta ei soovi, et brauser vastuse kätte saaks.

Päringuid ja vastuseid, mis veel ei ole "a" abil "aktsepteeritud", saame avatekstina uurida ja muuta! Lugejale jääb välja uurimiseks, mida mitmproxy peab silmas teatega "<tt>[decoded gzip] Couldn't parse: falling back to Raw</tt>" ja kas see takistab meil vastuse muutmist avatekstina.

Näide vaheltvõetud vastusest:

[[File:Marju ignatjeva Screenshot mitmproxy response.png|600px]]

Põhjalikum <tt>mitmproxy</tt> [http://mitmproxy.org/doc/index.html kasutusjuhend] kirjeldab nii päringute filtreerimist kui päringute ja vastuste redigeerimist ja palju muud.

Head eksperimenteerimist! ;-)

==Kasutatud materjalid==
* [http://segfault.in/2010/11/decrypt-https-traffic-using-wireshark-and-key-file/ Decrypt HTTPS Traffic Using Wireshark And Key File]
* [http://www.youtube.com/watch?v=kQ1-0G90lQg mitmproxy - use and abuse of a hackable SSL-capable man-in-the-middle proxy - YouTube]

[[Category:IT infrastruktuuri teenused]]

HTTPS liikluse uurimine tcpdump, Wireshark ja mitmproxy abil

2013-05-05T20:03:39Z

Mignatje: kasutatud materjalid

See artikkel räägib HTTPS liikluse analüüsimisest (HTTP päringute avatekstiks lahtivõtmise teel) kahes olukorras.
Esiteks -- kui nii klient kui server on meie hallata ja me soovime testida, kas server saab just selliseid HTTP päringuid ja saadab selliseid vastuseid, nagu me eeldame.
Teiseks -- kui serveriks on mõni avalik veebiteenus, millega suhtleme üle HTTPS protokolli, ja soovime teada, mida meie brauser serveriga räägib. Sisuliselt on siin tegemist olukorraga, kus me ei pruugi usaldada ei klienti (brauser jooksutab meie teadmata mingit kuritahtlikku skripti) ega ka serverit. Tegu võib olla ka mõne mobiilirakendusega, mille kohta soovime teada, mis andmeid ta meie telefoni kaudu edastab ja vastu võtab.

'''NB! Siin artiklis toodud juhised on mõeldud liikluse heatahtlikuks uurimiskes, mitte kolmandate osapoolte andmevahetusse sissemurdmiseks!'''

''Autor: Marju Ignatjeva''

==Töövahendid ja keskkond==
Kasutame töövahenditena <tt>tcpdump</tt>-i ja Wiresharki ning <tt>mitmproxy</tt>-t, HTTP kliendina ka <tt>curl</tt>-i.

Läbivalt on kasutusel serveri aadress 192.168.56.201.

Artikli lugejalt eeldan, et HTTPS üldine tööpõhimõte on selge ja et lugeja oskab Linuxi keskkonnas paigaldada tarkvara nii süsteemsest pakimajandusest kui ka Pythoni pakendussüsteemide (eeskätt <tt>pip</tt>) vahenditega, samuti saab hakkama käsureal. Töövahendite paigaldamise juhised on siiski ka artiklis olemas.

Artiklis toodud näited põhinevad katsetustel 64-bitise Kubuntu 12.10 operatsioonisüsteemi all.

===Töövahendite paigaldamine===
Kui <tt>tcpdump</tt> ei ole paigaldatud, tuleb see juurkasutajana paigaldada käsuga
<pre>
apt-get install tcpdump
</pre>

Wiresharki paigaldame käsuga
<pre>
apt-get install wireshark
</pre>

HTTP päringuid on käsurealt mugav teha <tt>curl</tt> nimelise tööriistaga, paigaldame ka selle.
<pre>
apt-get install curl
</pre>

Kuna erinevate Linuxi distributsioonide pakimajanduses ei pruugi alati olla Pythonis kirjutatud tarkvarast väga värskeid versioone, siis <tt>mitmproxy</tt> paigaldamiseks on mõistlik kasutada <tt>pip</tt>-i.
<pre>
apt-get install python-pip
pip install mitmproxy
</pre>

==tcpdump ja Wireshark==
HTTPS liikluse püüdmiseks kasutame käsureavahendit <tt>tcpdump</tt> seetõttu, et servereid hallates ei ole meil tihtipeale ligipääsu graafilisele keskkonnale. Samas on Wireshark mugav ja kasutajasõbralik võrguliikluse uurimise töövahend ja <tt>tcpdump</tt>-i abil salvestatud liiklust saab Wiresharki abil hiljem suvalises teises masinas analüüsida.

Kuna veebiserver on meie hallata, siis on meil olemas tema privaatvõti. See on ainus vajalik sisend Wiresharkile, et ta oskaks kinnipüütud pakette lahti krüpteerida.

===Pakettide püüdmine===
Kõigepealt paneme <tt>tcpdump</tt>-i kuulama liiklust liidesel <tt>eth1</tt> (antud juhul on see Virtualboxi ''host-only'' võrguliides), aadressil 192.168.56.201, pordil 443 (meil on sinna konfitud üks HTTPS toega ''virtualhost''). Seda tuleb teha juurkasutaja õigustes, et meile antaks ligipääs võrguliidesele.
<pre>
tcpdump -w https_dump.pcap -i eth1 host 192.168.56.201 and port 443
</pre>

Teeme klientmasinast päringu (öeldes, et usaldame serveri enda poolt allkirjastatud sertifikaati):
<pre>
curl --insecure https://192.168.56.201
</pre>

Nüüd lõpetame Ctrl+C abil serveris <tt>tcpdump</tt>i töö -- too ütleb lõpetades käsureale midagi sellist:
<pre>
15 packets captured
15 packets received by filter
0 packets dropped by kernel
</pre>

===Püütud pakettide uurimine===
Järgmiseks on vaja <tt>tcpdump</tt>-i väljundfail saada masinasse, kus meil on võimalik kasutada Wiresharki (kusjuures salvestatud faili uurimiseks ei ole juurkasutaja õiguseid vaja).
Käivitame Wiresharki ja avame oma .pcap faili. Esialgu näitab Wireshark küll HTTPS-iga seotud andmevahetust, kuid HTTP päringuid avatekstina pole võimalik näha.
Wireshark võimaldab seda krüpteeritud sisuga andmevoogu ka eraldi aknas uurida ("Follow TCP Stream" suvalise paketi kontekstimenüüst).

Järgmiseks hangime serverist tema privaatvõtme (NB! Erinevate ''virtualhost''ide olemasolul pead hankima just antud päringus kasutatud IP-le vastava võtme!)

Wiresharkis võtame menüüst "Edit"->"Preferences" avanevas aknas "Protocols" alt "SSL" ja lisame serveri võtme:

[[File:Marju ignatjeva Screenshot wireshark ssl keys.png|600px]]

Kasulik on seadistada ka SSL ''debuglog''i failitee, et probleemide korral saaks vigu otsida. Näiteks võib juhtuda, et brauseri või serveri krüpto vaikeseadistused on sellised, et Wireshark ei saa pakettide sisu lahti krüpteerida, kuigi serveri privaatvõti ja muud parameetrid on korrektsed (failitee seadistamine jääb lugejale väljauurimiseks).

Nimelt võib juhtuda, et peale võtmefaili määramist ja HTTPS suhtlusega seotud paketi kontekstimenüüs "Follow SSL Stream" valimist näidatakse tühjust.

Sellisel juhul võiks debuglogist otsida sääraseid ridu:
<pre>
ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt
dissect_ssl3_handshake can't decrypt pre master secret
</pre>

Nimelt Apache2 <tt>mod_ssl</tt> vaikimisi konfis on lubatud Diffie-Hellman võtmevahetuse protokolli kasutamine, mis aga muudab HTTPS liikluse Wireshark-i jaoks lahtivõetamatuks (erinevate krüptoprotokollide detailid on väljaspool selle artikli mahtu, kuid võtmefraasiks on siin ''perfect forward secrecy'').
Lähemalt loe näiteks:
[http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange Wikipediast]
ja
[http://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls Stackexchange'ist].

Üks võimalikke lahendusi on Apache2 <tt>mod_ssl</tt> konfis (<tt>/etc/apache2/mods-available/ssl.conf</tt>) keelata Diffie-Hellman võtmevahetuse tugi, näiteks võtmesõna DH abil:
<pre>
SSLCipherSuite ALL:!EXP:!NULL:!DH:!LOW
</pre>

Vt. lähemalt: [http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite]

Peale veebiserveri restarti tuleb teha uus paketipüüdmine. Kui kõik muu on korrektselt tehtud, võib Wiresharkis uue .pcap faili avamisel näha umbes sellist pilti ja HTTP päringut-vastust avatekstina uurida:

[[File:Marju ignatjeva Screenshot wireshark https decrypted.png|600px]]

==mitmproxy==

===Kliendi proxy seadistamine===
Selleks, et <tt>mitmproxy</tt> abil HTTPS liikluse sisu uurida, tuleb ta kõigepealt HTTP kliendis (brauseris, <tt>curl</tt>-is vms) seadistada ''proxy''-ks.
Nimelt, kui <tt>mitmproxy</tt> käivitada, siis vaikimisi kuulab ta aadressil 0.0.0.0 pordil 8080. Seega <tt>curl</tt>-ile anname need parameetrid ''proxy'' jaoks ja teeme HTTPS päringu oma serveri pihta.

curl -x localhost:8080 --insecure https://192.168.56.201

See päring ja vastus kajastuvad nüüd <tt>mitmproxy</tt> interaktiivses aknas.

Päriselus kasutame vingemate veebirakenduste kasutamiseks siiski graafilist brauserit ja edasi läheme Chromiumi näitel, kus samuti on kõigepealt vaja seadistada ''proxy'' (ja brauser restartida). Seda siin ei kirjelda.

===Teeseldud CA===
Kui <tt>mitmproxy</tt> on seadistatud ''proxy''-ks, siis HTTPS päringute korral pakub ta brauserile tegeliku serveri sertifikaadi asemel omaenda n-ö ''dummy'' sertifikaati (e. mängib CA-d) ja on seetõttu võimeline ka HTTPS liiklust "vahelt võtma", kuna HTTPS osapoolteks on klient ja <tt>mitmproxy</tt>, mitte enam server. Peale esimest käivitust tekivad kasutaja kodukataloogi alamkataloogi <tt>.mitmproxy</tt> selle dummy CA-ga seotud failid.
<pre>
ls ~/.mitmproxy/
mitmproxy-ca-cert.cer mitmproxy-ca-cert.p12 mitmproxy-ca-cert.pem mitmproxy-ca.pem
</pre>

Sellist dummy CA-d brauser vaikimisi ei usalda ja reageerib nagu tüüpiliselt ka iseallkirjastatud sertifikaatide puhul. Kui "harjumuspäraselt" vajutada "Proceed anyway", saame vaatlusalusele saidile tehtud HTTPS päringuid ja vastuseid üsna mugavalt uurida. Muidugi on <tt>mitmproxy</tt> CA võimalik lisada ka brauseri poolt usaldatavate CA-de hulka, aga seda siin ei kirjelda.

===HTTPS päringute vaheltvõtmine===
Edasi seadistame konkreetsele aadressile tehtavate päringute vaheltvõtmise. Selleks tuleb <tt>mitmproxy</tt> peaaknas vajutada "i" ja sisestada regulaaravaldis, mis meil on "192\.168\.56\.200".

Kui nüüd minna aadressile https://192.168.56.201, siis brauser jääb ootele ja <tt>mitmproxy</tt> aknasse tekib päringukirje, ning vaheltvõetud päringu edasisaatmiseks tuleb vajutada "a". Seda tuleb teha ka vastusega, kui me vastust muuta ei soovi, et brauser vastuse kätte saaks.

Päringuid ja vastuseid, mis veel ei ole "a" abil "aktsepteeritud", saame avatekstina uurida ja muuta! Lugejale jääb välja uurimiseks, mida mitmproxy peab silmas teatega "<tt>[decoded gzip] Couldn't parse: falling back to Raw</tt>" ja kas see takistab meil vastuse muutmist avatekstina.

Näide vaheltvõetud vastusest:

[[File:Marju ignatjeva Screenshot mitmproxy response.png|600px]]

Põhjalikum <tt>mitmproxy</tt> [http://mitmproxy.org/doc/index.html kasutusjuhend] kirjeldab nii päringute filtreerimist kui päringute ja vastuste redigeerimist ja palju muud.

Head eksperimenteerimist! ;-)

==Kasutatud materjalid==
* [http://segfault.in/2010/11/decrypt-https-traffic-using-wireshark-and-key-file/ Decrypt HTTPS Traffic Using Wireshark And Key File]
* [http://www.youtube.com/watch?v=kQ1-0G90lQg mitmproxy - use and abuse of a hackable SSL-capable man-in-the-middle proxy - YouTube]

[[Category:IT infrastruktuuri teenused]]

HTTPS liikluse uurimine tcpdump, Wireshark ja mitmproxy abil

2013-05-05T19:59:10Z

Mignatje: /* HTTPS päringute vaheltvõtmine */ Üks nüanss lisaks

See artikkel räägib HTTPS liikluse analüüsimisest (HTTP päringute avatekstiks lahtivõtmise teel) kahes olukorras.
Esiteks -- kui nii klient kui server on meie hallata ja me soovime testida, kas server saab just selliseid HTTP päringuid ja saadab selliseid vastuseid, nagu me eeldame.
Teiseks -- kui serveriks on mõni avalik veebiteenus, millega suhtleme üle HTTPS protokolli, ja soovime teada, mida meie brauser serveriga räägib. Sisuliselt on siin tegemist olukorraga, kus me ei pruugi usaldada ei klienti (brauser jooksutab meie teadmata mingit kuritahtlikku skripti) ega ka serverit. Tegu võib olla ka mõne mobiilirakendusega, mille kohta soovime teada, mis andmeid ta meie telefoni kaudu edastab ja vastu võtab.

'''NB! Siin artiklis toodud juhised on mõeldud liikluse heatahtlikuks uurimiskes, mitte kolmandate osapoolte andmevahetusse sissemurdmiseks!'''

''Autor: Marju Ignatjeva''

==Töövahendid ja keskkond==
Kasutame töövahenditena <tt>tcpdump</tt>-i ja Wiresharki ning <tt>mitmproxy</tt>-t, HTTP kliendina ka <tt>curl</tt>-i.

Läbivalt on kasutusel serveri aadress 192.168.56.201.

Artikli lugejalt eeldan, et HTTPS üldine tööpõhimõte on selge ja et lugeja oskab Linuxi keskkonnas paigaldada tarkvara nii süsteemsest pakimajandusest kui ka Pythoni pakendussüsteemide (eeskätt <tt>pip</tt>) vahenditega, samuti saab hakkama käsureal. Töövahendite paigaldamise juhised on siiski ka artiklis olemas.

Artiklis toodud näited põhinevad katsetustel 64-bitise Kubuntu 12.10 operatsioonisüsteemi all.

===Töövahendite paigaldamine===
Kui <tt>tcpdump</tt> ei ole paigaldatud, tuleb see juurkasutajana paigaldada käsuga
<pre>
apt-get install tcpdump
</pre>

Wiresharki paigaldame käsuga
<pre>
apt-get install wireshark
</pre>

HTTP päringuid on käsurealt mugav teha <tt>curl</tt> nimelise tööriistaga, paigaldame ka selle.
<pre>
apt-get install curl
</pre>

Kuna erinevate Linuxi distributsioonide pakimajanduses ei pruugi alati olla Pythonis kirjutatud tarkvarast väga värskeid versioone, siis <tt>mitmproxy</tt> paigaldamiseks on mõistlik kasutada <tt>pip</tt>-i.
<pre>
apt-get install python-pip
pip install mitmproxy
</pre>

==tcpdump ja Wireshark==
HTTPS liikluse püüdmiseks kasutame käsureavahendit <tt>tcpdump</tt> seetõttu, et servereid hallates ei ole meil tihtipeale ligipääsu graafilisele keskkonnale. Samas on Wireshark mugav ja kasutajasõbralik võrguliikluse uurimise töövahend ja <tt>tcpdump</tt>-i abil salvestatud liiklust saab Wiresharki abil hiljem suvalises teises masinas analüüsida.

Kuna veebiserver on meie hallata, siis on meil olemas tema privaatvõti. See on ainus vajalik sisend Wiresharkile, et ta oskaks kinnipüütud pakette lahti krüpteerida.

===Pakettide püüdmine===
Kõigepealt paneme <tt>tcpdump</tt>-i kuulama liiklust liidesel <tt>eth1</tt> (antud juhul on see Virtualboxi ''host-only'' võrguliides), aadressil 192.168.56.201, pordil 443 (meil on sinna konfitud üks HTTPS toega ''virtualhost''). Seda tuleb teha juurkasutaja õigustes, et meile antaks ligipääs võrguliidesele.
<pre>
tcpdump -w https_dump.pcap -i eth1 host 192.168.56.201 and port 443
</pre>

Teeme klientmasinast päringu (öeldes, et usaldame serveri enda poolt allkirjastatud sertifikaati):
<pre>
curl --insecure https://192.168.56.201
</pre>

Nüüd lõpetame Ctrl+C abil serveris <tt>tcpdump</tt>i töö -- too ütleb lõpetades käsureale midagi sellist:
<pre>
15 packets captured
15 packets received by filter
0 packets dropped by kernel
</pre>

===Püütud pakettide uurimine===
Järgmiseks on vaja <tt>tcpdump</tt>-i väljundfail saada masinasse, kus meil on võimalik kasutada Wiresharki (kusjuures salvestatud faili uurimiseks ei ole juurkasutaja õiguseid vaja).
Käivitame Wiresharki ja avame oma .pcap faili. Esialgu näitab Wireshark küll HTTPS-iga seotud andmevahetust, kuid HTTP päringuid avatekstina pole võimalik näha.
Wireshark võimaldab seda krüpteeritud sisuga andmevoogu ka eraldi aknas uurida ("Follow TCP Stream" suvalise paketi kontekstimenüüst).

Järgmiseks hangime serverist tema privaatvõtme (NB! Erinevate ''virtualhost''ide olemasolul pead hankima just antud päringus kasutatud IP-le vastava võtme!)

Wiresharkis võtame menüüst "Edit"->"Preferences" avanevas aknas "Protocols" alt "SSL" ja lisame serveri võtme:

[[File:Marju ignatjeva Screenshot wireshark ssl keys.png|600px]]

Kasulik on seadistada ka SSL ''debuglog''i failitee, et probleemide korral saaks vigu otsida. Näiteks võib juhtuda, et brauseri või serveri krüpto vaikeseadistused on sellised, et Wireshark ei saa pakettide sisu lahti krüpteerida, kuigi serveri privaatvõti ja muud parameetrid on korrektsed (failitee seadistamine jääb lugejale väljauurimiseks).

Nimelt võib juhtuda, et peale võtmefaili määramist ja HTTPS suhtlusega seotud paketi kontekstimenüüs "Follow SSL Stream" valimist näidatakse tühjust.

Sellisel juhul võiks debuglogist otsida sääraseid ridu:
<pre>
ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt
dissect_ssl3_handshake can't decrypt pre master secret
</pre>

Nimelt Apache2 <tt>mod_ssl</tt> vaikimisi konfis on lubatud Diffie-Hellman võtmevahetuse protokolli kasutamine, mis aga muudab HTTPS liikluse Wireshark-i jaoks lahtivõetamatuks (erinevate krüptoprotokollide detailid on väljaspool selle artikli mahtu, kuid võtmefraasiks on siin ''perfect forward secrecy'').
Lähemalt loe näiteks:
[http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange Wikipediast]
ja
[http://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls Stackexchange'ist].

Üks võimalikke lahendusi on Apache2 <tt>mod_ssl</tt> konfis (<tt>/etc/apache2/mods-available/ssl.conf</tt>) keelata Diffie-Hellman võtmevahetuse tugi, näiteks võtmesõna DH abil:
<pre>
SSLCipherSuite ALL:!EXP:!NULL:!DH:!LOW
</pre>

Vt. lähemalt: [http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite]

Peale veebiserveri restarti tuleb teha uus paketipüüdmine. Kui kõik muu on korrektselt tehtud, võib Wiresharkis uue .pcap faili avamisel näha umbes sellist pilti ja HTTP päringut-vastust avatekstina uurida:

[[File:Marju ignatjeva Screenshot wireshark https decrypted.png|600px]]

==mitmproxy==

===Kliendi proxy seadistamine===
Selleks, et <tt>mitmproxy</tt> abil HTTPS liikluse sisu uurida, tuleb ta kõigepealt HTTP kliendis (brauseris, <tt>curl</tt>-is vms) seadistada ''proxy''-ks.
Nimelt, kui <tt>mitmproxy</tt> käivitada, siis vaikimisi kuulab ta aadressil 0.0.0.0 pordil 8080. Seega <tt>curl</tt>-ile anname need parameetrid ''proxy'' jaoks ja teeme HTTPS päringu oma serveri pihta.

curl -x localhost:8080 --insecure https://192.168.56.201

See päring ja vastus kajastuvad nüüd <tt>mitmproxy</tt> interaktiivses aknas.

Päriselus kasutame vingemate veebirakenduste kasutamiseks siiski graafilist brauserit ja edasi läheme Chromiumi näitel, kus samuti on kõigepealt vaja seadistada ''proxy'' (ja brauser restartida). Seda siin ei kirjelda.

===Teeseldud CA===
Kui <tt>mitmproxy</tt> on seadistatud ''proxy''-ks, siis HTTPS päringute korral pakub ta brauserile tegeliku serveri sertifikaadi asemel omaenda n-ö ''dummy'' sertifikaati (e. mängib CA-d) ja on seetõttu võimeline ka HTTPS liiklust "vahelt võtma", kuna HTTPS osapoolteks on klient ja <tt>mitmproxy</tt>, mitte enam server. Peale esimest käivitust tekivad kasutaja kodukataloogi alamkataloogi <tt>.mitmproxy</tt> selle dummy CA-ga seotud failid.
<pre>
ls ~/.mitmproxy/
mitmproxy-ca-cert.cer mitmproxy-ca-cert.p12 mitmproxy-ca-cert.pem mitmproxy-ca.pem
</pre>

Sellist dummy CA-d brauser vaikimisi ei usalda ja reageerib nagu tüüpiliselt ka iseallkirjastatud sertifikaatide puhul. Kui "harjumuspäraselt" vajutada "Proceed anyway", saame vaatlusalusele saidile tehtud HTTPS päringuid ja vastuseid üsna mugavalt uurida. Muidugi on <tt>mitmproxy</tt> CA võimalik lisada ka brauseri poolt usaldatavate CA-de hulka, aga seda siin ei kirjelda.

===HTTPS päringute vaheltvõtmine===
Edasi seadistame konkreetsele aadressile tehtavate päringute vaheltvõtmise. Selleks tuleb <tt>mitmproxy</tt> peaaknas vajutada "i" ja sisestada regulaaravaldis, mis meil on "192\.168\.56\.200".

Kui nüüd minna aadressile https://192.168.56.201, siis brauser jääb ootele ja <tt>mitmproxy</tt> aknasse tekib päringukirje, ning vaheltvõetud päringu edasisaatmiseks tuleb vajutada "a". Seda tuleb teha ka vastusega, kui me vastust muuta ei soovi, et brauser vastuse kätte saaks.

Päringuid ja vastuseid, mis veel ei ole "a" abil "aktsepteeritud", saame avatekstina uurida ja muuta! Lugejale jääb välja uurimiseks, mida mitmproxy peab silmas teatega "<tt>[decoded gzip] Couldn't parse: falling back to Raw</tt>" ja kas see takistab meil vastuse muutmist avatekstina.

Näide vaheltvõetud vastusest:

[[File:Marju ignatjeva Screenshot mitmproxy response.png|600px]]

Põhjalikum <tt>mitmproxy</tt> [http://mitmproxy.org/doc/index.html kasutusjuhend] kirjeldab nii päringute filtreerimist kui päringute ja vastuste redigeerimist ja palju muud.

Head eksperimenteerimist! ;-)

[[Category:IT infrastruktuuri teenused]]

HTTPS liikluse uurimine tcpdump, Wireshark ja mitmproxy abil

2013-05-05T19:52:39Z

Mignatje: /* HTTPS päringute vaheltvõtmine */ mitmproxy pilt ka

See artikkel räägib HTTPS liikluse analüüsimisest (HTTP päringute avatekstiks lahtivõtmise teel) kahes olukorras.
Esiteks -- kui nii klient kui server on meie hallata ja me soovime testida, kas server saab just selliseid HTTP päringuid ja saadab selliseid vastuseid, nagu me eeldame.
Teiseks -- kui serveriks on mõni avalik veebiteenus, millega suhtleme üle HTTPS protokolli, ja soovime teada, mida meie brauser serveriga räägib. Sisuliselt on siin tegemist olukorraga, kus me ei pruugi usaldada ei klienti (brauser jooksutab meie teadmata mingit kuritahtlikku skripti) ega ka serverit. Tegu võib olla ka mõne mobiilirakendusega, mille kohta soovime teada, mis andmeid ta meie telefoni kaudu edastab ja vastu võtab.

'''NB! Siin artiklis toodud juhised on mõeldud liikluse heatahtlikuks uurimiskes, mitte kolmandate osapoolte andmevahetusse sissemurdmiseks!'''

''Autor: Marju Ignatjeva''

==Töövahendid ja keskkond==
Kasutame töövahenditena <tt>tcpdump</tt>-i ja Wiresharki ning <tt>mitmproxy</tt>-t, HTTP kliendina ka <tt>curl</tt>-i.

Läbivalt on kasutusel serveri aadress 192.168.56.201.

Artikli lugejalt eeldan, et HTTPS üldine tööpõhimõte on selge ja et lugeja oskab Linuxi keskkonnas paigaldada tarkvara nii süsteemsest pakimajandusest kui ka Pythoni pakendussüsteemide (eeskätt <tt>pip</tt>) vahenditega, samuti saab hakkama käsureal. Töövahendite paigaldamise juhised on siiski ka artiklis olemas.

Artiklis toodud näited põhinevad katsetustel 64-bitise Kubuntu 12.10 operatsioonisüsteemi all.

===Töövahendite paigaldamine===
Kui <tt>tcpdump</tt> ei ole paigaldatud, tuleb see juurkasutajana paigaldada käsuga
<pre>
apt-get install tcpdump
</pre>

Wiresharki paigaldame käsuga
<pre>
apt-get install wireshark
</pre>

HTTP päringuid on käsurealt mugav teha <tt>curl</tt> nimelise tööriistaga, paigaldame ka selle.
<pre>
apt-get install curl
</pre>

Kuna erinevate Linuxi distributsioonide pakimajanduses ei pruugi alati olla Pythonis kirjutatud tarkvarast väga värskeid versioone, siis <tt>mitmproxy</tt> paigaldamiseks on mõistlik kasutada <tt>pip</tt>-i.
<pre>
apt-get install python-pip
pip install mitmproxy
</pre>

==tcpdump ja Wireshark==
HTTPS liikluse püüdmiseks kasutame käsureavahendit <tt>tcpdump</tt> seetõttu, et servereid hallates ei ole meil tihtipeale ligipääsu graafilisele keskkonnale. Samas on Wireshark mugav ja kasutajasõbralik võrguliikluse uurimise töövahend ja <tt>tcpdump</tt>-i abil salvestatud liiklust saab Wiresharki abil hiljem suvalises teises masinas analüüsida.

Kuna veebiserver on meie hallata, siis on meil olemas tema privaatvõti. See on ainus vajalik sisend Wiresharkile, et ta oskaks kinnipüütud pakette lahti krüpteerida.

===Pakettide püüdmine===
Kõigepealt paneme <tt>tcpdump</tt>-i kuulama liiklust liidesel <tt>eth1</tt> (antud juhul on see Virtualboxi ''host-only'' võrguliides), aadressil 192.168.56.201, pordil 443 (meil on sinna konfitud üks HTTPS toega ''virtualhost''). Seda tuleb teha juurkasutaja õigustes, et meile antaks ligipääs võrguliidesele.
<pre>
tcpdump -w https_dump.pcap -i eth1 host 192.168.56.201 and port 443
</pre>

Teeme klientmasinast päringu (öeldes, et usaldame serveri enda poolt allkirjastatud sertifikaati):
<pre>
curl --insecure https://192.168.56.201
</pre>

Nüüd lõpetame Ctrl+C abil serveris <tt>tcpdump</tt>i töö -- too ütleb lõpetades käsureale midagi sellist:
<pre>
15 packets captured
15 packets received by filter
0 packets dropped by kernel
</pre>

===Püütud pakettide uurimine===
Järgmiseks on vaja <tt>tcpdump</tt>-i väljundfail saada masinasse, kus meil on võimalik kasutada Wiresharki (kusjuures salvestatud faili uurimiseks ei ole juurkasutaja õiguseid vaja).
Käivitame Wiresharki ja avame oma .pcap faili. Esialgu näitab Wireshark küll HTTPS-iga seotud andmevahetust, kuid HTTP päringuid avatekstina pole võimalik näha.
Wireshark võimaldab seda krüpteeritud sisuga andmevoogu ka eraldi aknas uurida ("Follow TCP Stream" suvalise paketi kontekstimenüüst).

Järgmiseks hangime serverist tema privaatvõtme (NB! Erinevate ''virtualhost''ide olemasolul pead hankima just antud päringus kasutatud IP-le vastava võtme!)

Wiresharkis võtame menüüst "Edit"->"Preferences" avanevas aknas "Protocols" alt "SSL" ja lisame serveri võtme:

[[File:Marju ignatjeva Screenshot wireshark ssl keys.png|600px]]

Kasulik on seadistada ka SSL ''debuglog''i failitee, et probleemide korral saaks vigu otsida. Näiteks võib juhtuda, et brauseri või serveri krüpto vaikeseadistused on sellised, et Wireshark ei saa pakettide sisu lahti krüpteerida, kuigi serveri privaatvõti ja muud parameetrid on korrektsed (failitee seadistamine jääb lugejale väljauurimiseks).

Nimelt võib juhtuda, et peale võtmefaili määramist ja HTTPS suhtlusega seotud paketi kontekstimenüüs "Follow SSL Stream" valimist näidatakse tühjust.

Sellisel juhul võiks debuglogist otsida sääraseid ridu:
<pre>
ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt
dissect_ssl3_handshake can't decrypt pre master secret
</pre>

Nimelt Apache2 <tt>mod_ssl</tt> vaikimisi konfis on lubatud Diffie-Hellman võtmevahetuse protokolli kasutamine, mis aga muudab HTTPS liikluse Wireshark-i jaoks lahtivõetamatuks (erinevate krüptoprotokollide detailid on väljaspool selle artikli mahtu, kuid võtmefraasiks on siin ''perfect forward secrecy'').
Lähemalt loe näiteks:
[http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange Wikipediast]
ja
[http://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls Stackexchange'ist].

Üks võimalikke lahendusi on Apache2 <tt>mod_ssl</tt> konfis (<tt>/etc/apache2/mods-available/ssl.conf</tt>) keelata Diffie-Hellman võtmevahetuse tugi, näiteks võtmesõna DH abil:
<pre>
SSLCipherSuite ALL:!EXP:!NULL:!DH:!LOW
</pre>

Vt. lähemalt: [http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite]

Peale veebiserveri restarti tuleb teha uus paketipüüdmine. Kui kõik muu on korrektselt tehtud, võib Wiresharkis uue .pcap faili avamisel näha umbes sellist pilti ja HTTP päringut-vastust avatekstina uurida:

[[File:Marju ignatjeva Screenshot wireshark https decrypted.png|600px]]

==mitmproxy==

===Kliendi proxy seadistamine===
Selleks, et <tt>mitmproxy</tt> abil HTTPS liikluse sisu uurida, tuleb ta kõigepealt HTTP kliendis (brauseris, <tt>curl</tt>-is vms) seadistada ''proxy''-ks.
Nimelt, kui <tt>mitmproxy</tt> käivitada, siis vaikimisi kuulab ta aadressil 0.0.0.0 pordil 8080. Seega <tt>curl</tt>-ile anname need parameetrid ''proxy'' jaoks ja teeme HTTPS päringu oma serveri pihta.

curl -x localhost:8080 --insecure https://192.168.56.201

See päring ja vastus kajastuvad nüüd <tt>mitmproxy</tt> interaktiivses aknas.

Päriselus kasutame vingemate veebirakenduste kasutamiseks siiski graafilist brauserit ja edasi läheme Chromiumi näitel, kus samuti on kõigepealt vaja seadistada ''proxy'' (ja brauser restartida). Seda siin ei kirjelda.

===Teeseldud CA===
Kui <tt>mitmproxy</tt> on seadistatud ''proxy''-ks, siis HTTPS päringute korral pakub ta brauserile tegeliku serveri sertifikaadi asemel omaenda n-ö ''dummy'' sertifikaati (e. mängib CA-d) ja on seetõttu võimeline ka HTTPS liiklust "vahelt võtma", kuna HTTPS osapoolteks on klient ja <tt>mitmproxy</tt>, mitte enam server. Peale esimest käivitust tekivad kasutaja kodukataloogi alamkataloogi <tt>.mitmproxy</tt> selle dummy CA-ga seotud failid.
<pre>
ls ~/.mitmproxy/
mitmproxy-ca-cert.cer mitmproxy-ca-cert.p12 mitmproxy-ca-cert.pem mitmproxy-ca.pem
</pre>

Sellist dummy CA-d brauser vaikimisi ei usalda ja reageerib nagu tüüpiliselt ka iseallkirjastatud sertifikaatide puhul. Kui "harjumuspäraselt" vajutada "Proceed anyway", saame vaatlusalusele saidile tehtud HTTPS päringuid ja vastuseid üsna mugavalt uurida. Muidugi on <tt>mitmproxy</tt> CA võimalik lisada ka brauseri poolt usaldatavate CA-de hulka, aga seda siin ei kirjelda.

===HTTPS päringute vaheltvõtmine===
Edasi seadistame konkreetsele aadressile tehtavate päringute vaheltvõtmise. Selleks tuleb <tt>mitmproxy</tt> peaaknas vajutada "i" ja sisestada regulaaravaldis, mis meil on "192\.168\.56\.200".

Kui nüüd minna aadressile https://192.168.56.201, siis brauser jääb ootele ja <tt>mitmproxy</tt> aknasse tekib päringukirje, ning vaheltvõetud päringu edasisaatmiseks tuleb vajutada "a". Seda tuleb teha ka vastusega, kui me vastust muuta ei soovi, et brauser vastuse kätte saaks.

Päringuid ja vastuseid, mis veel ei ole "a" abil "aktsepteeritud", saame avatekstina uurida ja muuta!

Näide vaheltvõetud vastusest:

[[File:Marju ignatjeva Screenshot mitmproxy response.png|600px]]

Põhjalikum <tt>mitmproxy</tt> [http://mitmproxy.org/doc/index.html kasutusjuhend] kirjeldab nii päringute filtreerimist kui päringute ja vastuste redigeerimist ja palju muud.

Head eksperimenteerimist! ;-)

[[Category:IT infrastruktuuri teenused]]

File:Marju ignatjeva Screenshot mitmproxy response.png

2013-05-05T19:51:36Z

Mignatje: IT infra wiki artikli jaoks.

IT infra wiki artikli jaoks.

HTTPS liikluse uurimine tcpdump, Wireshark ja mitmproxy abil

2013-05-05T19:49:29Z

Mignatje: /* Püütud pakettide uurimine */ URL-id inimloetavamaks

See artikkel räägib HTTPS liikluse analüüsimisest (HTTP päringute avatekstiks lahtivõtmise teel) kahes olukorras.
Esiteks -- kui nii klient kui server on meie hallata ja me soovime testida, kas server saab just selliseid HTTP päringuid ja saadab selliseid vastuseid, nagu me eeldame.
Teiseks -- kui serveriks on mõni avalik veebiteenus, millega suhtleme üle HTTPS protokolli, ja soovime teada, mida meie brauser serveriga räägib. Sisuliselt on siin tegemist olukorraga, kus me ei pruugi usaldada ei klienti (brauser jooksutab meie teadmata mingit kuritahtlikku skripti) ega ka serverit. Tegu võib olla ka mõne mobiilirakendusega, mille kohta soovime teada, mis andmeid ta meie telefoni kaudu edastab ja vastu võtab.

'''NB! Siin artiklis toodud juhised on mõeldud liikluse heatahtlikuks uurimiskes, mitte kolmandate osapoolte andmevahetusse sissemurdmiseks!'''

''Autor: Marju Ignatjeva''

==Töövahendid ja keskkond==
Kasutame töövahenditena <tt>tcpdump</tt>-i ja Wiresharki ning <tt>mitmproxy</tt>-t, HTTP kliendina ka <tt>curl</tt>-i.

Läbivalt on kasutusel serveri aadress 192.168.56.201.

Artikli lugejalt eeldan, et HTTPS üldine tööpõhimõte on selge ja et lugeja oskab Linuxi keskkonnas paigaldada tarkvara nii süsteemsest pakimajandusest kui ka Pythoni pakendussüsteemide (eeskätt <tt>pip</tt>) vahenditega, samuti saab hakkama käsureal. Töövahendite paigaldamise juhised on siiski ka artiklis olemas.

Artiklis toodud näited põhinevad katsetustel 64-bitise Kubuntu 12.10 operatsioonisüsteemi all.

===Töövahendite paigaldamine===
Kui <tt>tcpdump</tt> ei ole paigaldatud, tuleb see juurkasutajana paigaldada käsuga
<pre>
apt-get install tcpdump
</pre>

Wiresharki paigaldame käsuga
<pre>
apt-get install wireshark
</pre>

HTTP päringuid on käsurealt mugav teha <tt>curl</tt> nimelise tööriistaga, paigaldame ka selle.
<pre>
apt-get install curl
</pre>

Kuna erinevate Linuxi distributsioonide pakimajanduses ei pruugi alati olla Pythonis kirjutatud tarkvarast väga värskeid versioone, siis <tt>mitmproxy</tt> paigaldamiseks on mõistlik kasutada <tt>pip</tt>-i.
<pre>
apt-get install python-pip
pip install mitmproxy
</pre>

==tcpdump ja Wireshark==
HTTPS liikluse püüdmiseks kasutame käsureavahendit <tt>tcpdump</tt> seetõttu, et servereid hallates ei ole meil tihtipeale ligipääsu graafilisele keskkonnale. Samas on Wireshark mugav ja kasutajasõbralik võrguliikluse uurimise töövahend ja <tt>tcpdump</tt>-i abil salvestatud liiklust saab Wiresharki abil hiljem suvalises teises masinas analüüsida.

Kuna veebiserver on meie hallata, siis on meil olemas tema privaatvõti. See on ainus vajalik sisend Wiresharkile, et ta oskaks kinnipüütud pakette lahti krüpteerida.

===Pakettide püüdmine===
Kõigepealt paneme <tt>tcpdump</tt>-i kuulama liiklust liidesel <tt>eth1</tt> (antud juhul on see Virtualboxi ''host-only'' võrguliides), aadressil 192.168.56.201, pordil 443 (meil on sinna konfitud üks HTTPS toega ''virtualhost''). Seda tuleb teha juurkasutaja õigustes, et meile antaks ligipääs võrguliidesele.
<pre>
tcpdump -w https_dump.pcap -i eth1 host 192.168.56.201 and port 443
</pre>

Teeme klientmasinast päringu (öeldes, et usaldame serveri enda poolt allkirjastatud sertifikaati):
<pre>
curl --insecure https://192.168.56.201
</pre>

Nüüd lõpetame Ctrl+C abil serveris <tt>tcpdump</tt>i töö -- too ütleb lõpetades käsureale midagi sellist:
<pre>
15 packets captured
15 packets received by filter
0 packets dropped by kernel
</pre>

===Püütud pakettide uurimine===
Järgmiseks on vaja <tt>tcpdump</tt>-i väljundfail saada masinasse, kus meil on võimalik kasutada Wiresharki (kusjuures salvestatud faili uurimiseks ei ole juurkasutaja õiguseid vaja).
Käivitame Wiresharki ja avame oma .pcap faili. Esialgu näitab Wireshark küll HTTPS-iga seotud andmevahetust, kuid HTTP päringuid avatekstina pole võimalik näha.
Wireshark võimaldab seda krüpteeritud sisuga andmevoogu ka eraldi aknas uurida ("Follow TCP Stream" suvalise paketi kontekstimenüüst).

Järgmiseks hangime serverist tema privaatvõtme (NB! Erinevate ''virtualhost''ide olemasolul pead hankima just antud päringus kasutatud IP-le vastava võtme!)

Wiresharkis võtame menüüst "Edit"->"Preferences" avanevas aknas "Protocols" alt "SSL" ja lisame serveri võtme:

[[File:Marju ignatjeva Screenshot wireshark ssl keys.png|600px]]

Kasulik on seadistada ka SSL ''debuglog''i failitee, et probleemide korral saaks vigu otsida. Näiteks võib juhtuda, et brauseri või serveri krüpto vaikeseadistused on sellised, et Wireshark ei saa pakettide sisu lahti krüpteerida, kuigi serveri privaatvõti ja muud parameetrid on korrektsed (failitee seadistamine jääb lugejale väljauurimiseks).

Nimelt võib juhtuda, et peale võtmefaili määramist ja HTTPS suhtlusega seotud paketi kontekstimenüüs "Follow SSL Stream" valimist näidatakse tühjust.

Sellisel juhul võiks debuglogist otsida sääraseid ridu:
<pre>
ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt
dissect_ssl3_handshake can't decrypt pre master secret
</pre>

Nimelt Apache2 <tt>mod_ssl</tt> vaikimisi konfis on lubatud Diffie-Hellman võtmevahetuse protokolli kasutamine, mis aga muudab HTTPS liikluse Wireshark-i jaoks lahtivõetamatuks (erinevate krüptoprotokollide detailid on väljaspool selle artikli mahtu, kuid võtmefraasiks on siin ''perfect forward secrecy'').
Lähemalt loe näiteks:
[http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange Wikipediast]
ja
[http://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls Stackexchange'ist].

Üks võimalikke lahendusi on Apache2 <tt>mod_ssl</tt> konfis (<tt>/etc/apache2/mods-available/ssl.conf</tt>) keelata Diffie-Hellman võtmevahetuse tugi, näiteks võtmesõna DH abil:
<pre>
SSLCipherSuite ALL:!EXP:!NULL:!DH:!LOW
</pre>

Vt. lähemalt: [http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite]

Peale veebiserveri restarti tuleb teha uus paketipüüdmine. Kui kõik muu on korrektselt tehtud, võib Wiresharkis uue .pcap faili avamisel näha umbes sellist pilti ja HTTP päringut-vastust avatekstina uurida:

[[File:Marju ignatjeva Screenshot wireshark https decrypted.png|600px]]

==mitmproxy==

===Kliendi proxy seadistamine===
Selleks, et <tt>mitmproxy</tt> abil HTTPS liikluse sisu uurida, tuleb ta kõigepealt HTTP kliendis (brauseris, <tt>curl</tt>-is vms) seadistada ''proxy''-ks.
Nimelt, kui <tt>mitmproxy</tt> käivitada, siis vaikimisi kuulab ta aadressil 0.0.0.0 pordil 8080. Seega <tt>curl</tt>-ile anname need parameetrid ''proxy'' jaoks ja teeme HTTPS päringu oma serveri pihta.

curl -x localhost:8080 --insecure https://192.168.56.201

See päring ja vastus kajastuvad nüüd <tt>mitmproxy</tt> interaktiivses aknas.

Päriselus kasutame vingemate veebirakenduste kasutamiseks siiski graafilist brauserit ja edasi läheme Chromiumi näitel, kus samuti on kõigepealt vaja seadistada ''proxy'' (ja brauser restartida). Seda siin ei kirjelda.

===Teeseldud CA===
Kui <tt>mitmproxy</tt> on seadistatud ''proxy''-ks, siis HTTPS päringute korral pakub ta brauserile tegeliku serveri sertifikaadi asemel omaenda n-ö ''dummy'' sertifikaati (e. mängib CA-d) ja on seetõttu võimeline ka HTTPS liiklust "vahelt võtma", kuna HTTPS osapoolteks on klient ja <tt>mitmproxy</tt>, mitte enam server. Peale esimest käivitust tekivad kasutaja kodukataloogi alamkataloogi <tt>.mitmproxy</tt> selle dummy CA-ga seotud failid.
<pre>
ls ~/.mitmproxy/
mitmproxy-ca-cert.cer mitmproxy-ca-cert.p12 mitmproxy-ca-cert.pem mitmproxy-ca.pem
</pre>

Sellist dummy CA-d brauser vaikimisi ei usalda ja reageerib nagu tüüpiliselt ka iseallkirjastatud sertifikaatide puhul. Kui "harjumuspäraselt" vajutada "Proceed anyway", saame vaatlusalusele saidile tehtud HTTPS päringuid ja vastuseid üsna mugavalt uurida. Muidugi on <tt>mitmproxy</tt> CA võimalik lisada ka brauseri poolt usaldatavate CA-de hulka, aga seda siin ei kirjelda.

===HTTPS päringute vaheltvõtmine===
Edasi seadistame konkreetsele aadressile tehtavate päringute vaheltvõtmise. Selleks tuleb <tt>mitmproxy</tt> peaaknas vajutada "i" ja sisestada regulaaravaldis, mis meil on "192\.168\.56\.200".

Kui nüüd minna aadressile https://192.168.56.201, siis brauser jääb ootele ja <tt>mitmproxy</tt> aknasse tekib päringukirje, ning vaheltvõetud päringu edasisaatmiseks tuleb vajutada "a". Seda tuleb teha ka vastusega, kui me vastust muuta ei soovi, et brauser vastuse kätte saaks.

Päringuid ja vastuseid, mis veel ei ole "a" abil "aktsepteeritud", saame avatekstina uurida ja muuta!

Näide vaheltvõetud vastusest:
FIXME: screenshot

Põhjalikum <tt>mitmproxy</tt> [http://mitmproxy.org/doc/index.html kasutusjuhend] kirjeldab nii päringute filtreerimist kui päringute ja vastuste redigeerimist ja palju muud.

Head eksperimenteerimist! ;-)

[[Category:IT infrastruktuuri teenused]]

HTTPS liikluse uurimine tcpdump, Wireshark ja mitmproxy abil

2013-05-05T19:48:03Z

Mignatje: /* Püütud pakettide uurimine */ termini parandus

See artikkel räägib HTTPS liikluse analüüsimisest (HTTP päringute avatekstiks lahtivõtmise teel) kahes olukorras.
Esiteks -- kui nii klient kui server on meie hallata ja me soovime testida, kas server saab just selliseid HTTP päringuid ja saadab selliseid vastuseid, nagu me eeldame.
Teiseks -- kui serveriks on mõni avalik veebiteenus, millega suhtleme üle HTTPS protokolli, ja soovime teada, mida meie brauser serveriga räägib. Sisuliselt on siin tegemist olukorraga, kus me ei pruugi usaldada ei klienti (brauser jooksutab meie teadmata mingit kuritahtlikku skripti) ega ka serverit. Tegu võib olla ka mõne mobiilirakendusega, mille kohta soovime teada, mis andmeid ta meie telefoni kaudu edastab ja vastu võtab.

'''NB! Siin artiklis toodud juhised on mõeldud liikluse heatahtlikuks uurimiskes, mitte kolmandate osapoolte andmevahetusse sissemurdmiseks!'''

''Autor: Marju Ignatjeva''

==Töövahendid ja keskkond==
Kasutame töövahenditena <tt>tcpdump</tt>-i ja Wiresharki ning <tt>mitmproxy</tt>-t, HTTP kliendina ka <tt>curl</tt>-i.

Läbivalt on kasutusel serveri aadress 192.168.56.201.

Artikli lugejalt eeldan, et HTTPS üldine tööpõhimõte on selge ja et lugeja oskab Linuxi keskkonnas paigaldada tarkvara nii süsteemsest pakimajandusest kui ka Pythoni pakendussüsteemide (eeskätt <tt>pip</tt>) vahenditega, samuti saab hakkama käsureal. Töövahendite paigaldamise juhised on siiski ka artiklis olemas.

Artiklis toodud näited põhinevad katsetustel 64-bitise Kubuntu 12.10 operatsioonisüsteemi all.

===Töövahendite paigaldamine===
Kui <tt>tcpdump</tt> ei ole paigaldatud, tuleb see juurkasutajana paigaldada käsuga
<pre>
apt-get install tcpdump
</pre>

Wiresharki paigaldame käsuga
<pre>
apt-get install wireshark
</pre>

HTTP päringuid on käsurealt mugav teha <tt>curl</tt> nimelise tööriistaga, paigaldame ka selle.
<pre>
apt-get install curl
</pre>

Kuna erinevate Linuxi distributsioonide pakimajanduses ei pruugi alati olla Pythonis kirjutatud tarkvarast väga värskeid versioone, siis <tt>mitmproxy</tt> paigaldamiseks on mõistlik kasutada <tt>pip</tt>-i.
<pre>
apt-get install python-pip
pip install mitmproxy
</pre>

==tcpdump ja Wireshark==
HTTPS liikluse püüdmiseks kasutame käsureavahendit <tt>tcpdump</tt> seetõttu, et servereid hallates ei ole meil tihtipeale ligipääsu graafilisele keskkonnale. Samas on Wireshark mugav ja kasutajasõbralik võrguliikluse uurimise töövahend ja <tt>tcpdump</tt>-i abil salvestatud liiklust saab Wiresharki abil hiljem suvalises teises masinas analüüsida.

Kuna veebiserver on meie hallata, siis on meil olemas tema privaatvõti. See on ainus vajalik sisend Wiresharkile, et ta oskaks kinnipüütud pakette lahti krüpteerida.

===Pakettide püüdmine===
Kõigepealt paneme <tt>tcpdump</tt>-i kuulama liiklust liidesel <tt>eth1</tt> (antud juhul on see Virtualboxi ''host-only'' võrguliides), aadressil 192.168.56.201, pordil 443 (meil on sinna konfitud üks HTTPS toega ''virtualhost''). Seda tuleb teha juurkasutaja õigustes, et meile antaks ligipääs võrguliidesele.
<pre>
tcpdump -w https_dump.pcap -i eth1 host 192.168.56.201 and port 443
</pre>

Teeme klientmasinast päringu (öeldes, et usaldame serveri enda poolt allkirjastatud sertifikaati):
<pre>
curl --insecure https://192.168.56.201
</pre>

Nüüd lõpetame Ctrl+C abil serveris <tt>tcpdump</tt>i töö -- too ütleb lõpetades käsureale midagi sellist:
<pre>
15 packets captured
15 packets received by filter
0 packets dropped by kernel
</pre>

===Püütud pakettide uurimine===
Järgmiseks on vaja <tt>tcpdump</tt>-i väljundfail saada masinasse, kus meil on võimalik kasutada Wiresharki (kusjuures salvestatud faili uurimiseks ei ole juurkasutaja õiguseid vaja).
Käivitame Wiresharki ja avame oma .pcap faili. Esialgu näitab Wireshark küll HTTPS-iga seotud andmevahetust, kuid HTTP päringuid avatekstina pole võimalik näha.
Wireshark võimaldab seda krüpteeritud sisuga andmevoogu ka eraldi aknas uurida ("Follow TCP Stream" suvalise paketi kontekstimenüüst).

Järgmiseks hangime serverist tema privaatvõtme (NB! Erinevate ''virtualhost''ide olemasolul pead hankima just antud päringus kasutatud IP-le vastava võtme!)

Wiresharkis võtame menüüst "Edit"->"Preferences" avanevas aknas "Protocols" alt "SSL" ja lisame serveri võtme:

[[File:Marju ignatjeva Screenshot wireshark ssl keys.png|600px]]

Kasulik on seadistada ka SSL ''debuglog''i failitee, et probleemide korral saaks vigu otsida. Näiteks võib juhtuda, et brauseri või serveri krüpto vaikeseadistused on sellised, et Wireshark ei saa pakettide sisu lahti krüpteerida, kuigi serveri privaatvõti ja muud parameetrid on korrektsed (failitee seadistamine jääb lugejale väljauurimiseks).

Nimelt võib juhtuda, et peale võtmefaili määramist ja HTTPS suhtlusega seotud paketi kontekstimenüüs "Follow SSL Stream" valimist näidatakse tühjust.

Sellisel juhul võiks debuglogist otsida sääraseid ridu:
<pre>
ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt
dissect_ssl3_handshake can't decrypt pre master secret
</pre>

Nimelt Apache2 <tt>mod_ssl</tt> vaikimisi konfis on lubatud Diffie-Hellman võtmevahetuse protokolli kasutamine, mis aga muudab HTTPS liikluse Wireshark-i jaoks lahtivõetamatuks (erinevate krüptoprotokollide detailid on väljaspool selle artikli mahtu, kuid võtmefraasiks on siin ''perfect forward secrecy'').
Lähemalt loe näiteks:
[http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange]
ja
[http://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls http://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls]

Üks võimalikke lahendusi on Apache2 <tt>mod_ssl</tt> konfis (<tt>/etc/apache2/mods-available/ssl.conf</tt>) keelata Diffie-Hellman võtmevahetuse tugi, näiteks võtmesõna DH abil:
<pre>
SSLCipherSuite ALL:!EXP:!NULL:!DH:!LOW
</pre>

Vt. lähemalt: [http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite]

Peale veebiserveri restarti tuleb teha uus paketipüüdmine. Kui kõik muu on korrektselt tehtud, võib Wiresharkis uue .pcap faili avamisel näha umbes sellist pilti ja HTTP päringut-vastust avatekstina uurida:

[[File:Marju ignatjeva Screenshot wireshark https decrypted.png|600px]]

==mitmproxy==

===Kliendi proxy seadistamine===
Selleks, et <tt>mitmproxy</tt> abil HTTPS liikluse sisu uurida, tuleb ta kõigepealt HTTP kliendis (brauseris, <tt>curl</tt>-is vms) seadistada ''proxy''-ks.
Nimelt, kui <tt>mitmproxy</tt> käivitada, siis vaikimisi kuulab ta aadressil 0.0.0.0 pordil 8080. Seega <tt>curl</tt>-ile anname need parameetrid ''proxy'' jaoks ja teeme HTTPS päringu oma serveri pihta.

curl -x localhost:8080 --insecure https://192.168.56.201

See päring ja vastus kajastuvad nüüd <tt>mitmproxy</tt> interaktiivses aknas.

Päriselus kasutame vingemate veebirakenduste kasutamiseks siiski graafilist brauserit ja edasi läheme Chromiumi näitel, kus samuti on kõigepealt vaja seadistada ''proxy'' (ja brauser restartida). Seda siin ei kirjelda.

===Teeseldud CA===
Kui <tt>mitmproxy</tt> on seadistatud ''proxy''-ks, siis HTTPS päringute korral pakub ta brauserile tegeliku serveri sertifikaadi asemel omaenda n-ö ''dummy'' sertifikaati (e. mängib CA-d) ja on seetõttu võimeline ka HTTPS liiklust "vahelt võtma", kuna HTTPS osapoolteks on klient ja <tt>mitmproxy</tt>, mitte enam server. Peale esimest käivitust tekivad kasutaja kodukataloogi alamkataloogi <tt>.mitmproxy</tt> selle dummy CA-ga seotud failid.
<pre>
ls ~/.mitmproxy/
mitmproxy-ca-cert.cer mitmproxy-ca-cert.p12 mitmproxy-ca-cert.pem mitmproxy-ca.pem
</pre>

Sellist dummy CA-d brauser vaikimisi ei usalda ja reageerib nagu tüüpiliselt ka iseallkirjastatud sertifikaatide puhul. Kui "harjumuspäraselt" vajutada "Proceed anyway", saame vaatlusalusele saidile tehtud HTTPS päringuid ja vastuseid üsna mugavalt uurida. Muidugi on <tt>mitmproxy</tt> CA võimalik lisada ka brauseri poolt usaldatavate CA-de hulka, aga seda siin ei kirjelda.

===HTTPS päringute vaheltvõtmine===
Edasi seadistame konkreetsele aadressile tehtavate päringute vaheltvõtmise. Selleks tuleb <tt>mitmproxy</tt> peaaknas vajutada "i" ja sisestada regulaaravaldis, mis meil on "192\.168\.56\.200".

Kui nüüd minna aadressile https://192.168.56.201, siis brauser jääb ootele ja <tt>mitmproxy</tt> aknasse tekib päringukirje, ning vaheltvõetud päringu edasisaatmiseks tuleb vajutada "a". Seda tuleb teha ka vastusega, kui me vastust muuta ei soovi, et brauser vastuse kätte saaks.

Päringuid ja vastuseid, mis veel ei ole "a" abil "aktsepteeritud", saame avatekstina uurida ja muuta!

Näide vaheltvõetud vastusest:
FIXME: screenshot

Põhjalikum <tt>mitmproxy</tt> [http://mitmproxy.org/doc/index.html kasutusjuhend] kirjeldab nii päringute filtreerimist kui päringute ja vastuste redigeerimist ja palju muud.

Head eksperimenteerimist! ;-)

[[Category:IT infrastruktuuri teenused]]

HTTPS liikluse uurimine tcpdump, Wireshark ja mitmproxy abil

2013-05-05T19:46:55Z

Mignatje: pisiparandused

See artikkel räägib HTTPS liikluse analüüsimisest (HTTP päringute avatekstiks lahtivõtmise teel) kahes olukorras.
Esiteks -- kui nii klient kui server on meie hallata ja me soovime testida, kas server saab just selliseid HTTP päringuid ja saadab selliseid vastuseid, nagu me eeldame.
Teiseks -- kui serveriks on mõni avalik veebiteenus, millega suhtleme üle HTTPS protokolli, ja soovime teada, mida meie brauser serveriga räägib. Sisuliselt on siin tegemist olukorraga, kus me ei pruugi usaldada ei klienti (brauser jooksutab meie teadmata mingit kuritahtlikku skripti) ega ka serverit. Tegu võib olla ka mõne mobiilirakendusega, mille kohta soovime teada, mis andmeid ta meie telefoni kaudu edastab ja vastu võtab.

'''NB! Siin artiklis toodud juhised on mõeldud liikluse heatahtlikuks uurimiskes, mitte kolmandate osapoolte andmevahetusse sissemurdmiseks!'''

''Autor: Marju Ignatjeva''

==Töövahendid ja keskkond==
Kasutame töövahenditena <tt>tcpdump</tt>-i ja Wiresharki ning <tt>mitmproxy</tt>-t, HTTP kliendina ka <tt>curl</tt>-i.

Läbivalt on kasutusel serveri aadress 192.168.56.201.

Artikli lugejalt eeldan, et HTTPS üldine tööpõhimõte on selge ja et lugeja oskab Linuxi keskkonnas paigaldada tarkvara nii süsteemsest pakimajandusest kui ka Pythoni pakendussüsteemide (eeskätt <tt>pip</tt>) vahenditega, samuti saab hakkama käsureal. Töövahendite paigaldamise juhised on siiski ka artiklis olemas.

Artiklis toodud näited põhinevad katsetustel 64-bitise Kubuntu 12.10 operatsioonisüsteemi all.

===Töövahendite paigaldamine===
Kui <tt>tcpdump</tt> ei ole paigaldatud, tuleb see juurkasutajana paigaldada käsuga
<pre>
apt-get install tcpdump
</pre>

Wiresharki paigaldame käsuga
<pre>
apt-get install wireshark
</pre>

HTTP päringuid on käsurealt mugav teha <tt>curl</tt> nimelise tööriistaga, paigaldame ka selle.
<pre>
apt-get install curl
</pre>

Kuna erinevate Linuxi distributsioonide pakimajanduses ei pruugi alati olla Pythonis kirjutatud tarkvarast väga värskeid versioone, siis <tt>mitmproxy</tt> paigaldamiseks on mõistlik kasutada <tt>pip</tt>-i.
<pre>
apt-get install python-pip
pip install mitmproxy
</pre>

==tcpdump ja Wireshark==
HTTPS liikluse püüdmiseks kasutame käsureavahendit <tt>tcpdump</tt> seetõttu, et servereid hallates ei ole meil tihtipeale ligipääsu graafilisele keskkonnale. Samas on Wireshark mugav ja kasutajasõbralik võrguliikluse uurimise töövahend ja <tt>tcpdump</tt>-i abil salvestatud liiklust saab Wiresharki abil hiljem suvalises teises masinas analüüsida.

Kuna veebiserver on meie hallata, siis on meil olemas tema privaatvõti. See on ainus vajalik sisend Wiresharkile, et ta oskaks kinnipüütud pakette lahti krüpteerida.

===Pakettide püüdmine===
Kõigepealt paneme <tt>tcpdump</tt>-i kuulama liiklust liidesel <tt>eth1</tt> (antud juhul on see Virtualboxi ''host-only'' võrguliides), aadressil 192.168.56.201, pordil 443 (meil on sinna konfitud üks HTTPS toega ''virtualhost''). Seda tuleb teha juurkasutaja õigustes, et meile antaks ligipääs võrguliidesele.
<pre>
tcpdump -w https_dump.pcap -i eth1 host 192.168.56.201 and port 443
</pre>

Teeme klientmasinast päringu (öeldes, et usaldame serveri enda poolt allkirjastatud sertifikaati):
<pre>
curl --insecure https://192.168.56.201
</pre>

Nüüd lõpetame Ctrl+C abil serveris <tt>tcpdump</tt>i töö -- too ütleb lõpetades käsureale midagi sellist:
<pre>
15 packets captured
15 packets received by filter
0 packets dropped by kernel
</pre>

===Püütud pakettide uurimine===
Järgmiseks on vaja <tt>tcpdump</tt>-i väljundfail saada masinasse, kus meil on võimalik kasutada Wiresharki (kusjuures salvestatud faili uurimiseks ei ole juurkasutaja õiguseid vaja).
Käivitame Wiresharki ja avame oma .pcap faili. Esialgu näitab Wireshark küll HTTPS-iga seotud andmevahetust, kuid HTTP päringuid avatekstina pole võimalik näha.
Wireshark võimaldab seda krüpteeritud sisuga andmevoogu ka eraldi aknas uurida ("Follow TCP Stream" suvalise paketi kontekstimenüüst).

Järgmiseks hangime serverist tema privaatvõtme (NB! Erinevate ''virtualhost''ide olemasolul pead hankima just antud päringus kasutatud IP-le vastava võtme!)

Wiresharkis võtame menüüst "Edit"->"Preferences" avanevas aknas "Protocols" alt "SSL" ja lisame serveri võtme:

[[File:Marju ignatjeva Screenshot wireshark ssl keys.png|600px]]

Kasulik on seadistada ka SSL ''debuglog''i failitee, et probleemide korral saaks vigu otsida. Näiteks võib juhtuda, et brauseri või serveri krüpto vaikeseadistused on sellised, et Wireshark ei saa pakettide sisu lahti krüpteerida, kuigi serveri privaatvõti ja muud parameetrid on korrektsed (failitee seadistamine jääb lugejale väljauurimiseks).

Nimelt võib juhtuda, et peale võtmefaili määramist ja HTTPS suhtlusega seotud paketi kontekstimenüüs "Follow SSL Stream" valimist näidatakse tühjust.

Sellisel juhul võiks debuglogist otsida sääraseid ridu:
<pre>
ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt
dissect_ssl3_handshake can't decrypt pre master secret
</pre>

Nimelt Apache2 <tt>mod_ssl</tt> vaikimisi konfis on lubatud Diffie-Hellman võtmevahetuse protokolli kasutamine, mis aga muudab HTTPS liikluse Wireshark-i jaoks lahtivõetamatuks (erinevate krüptoprotokollide detailid on väljaspool selle artikli mahtu, kuid võtmefraasiks on siin ''perfect forward security'').
Lähemalt loe näiteks:
[http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange]
ja
[http://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls http://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls]

Üks võimalikke lahendusi on Apache2 <tt>mod_ssl</tt> konfis (<tt>/etc/apache2/mods-available/ssl.conf</tt>) keelata Diffie-Hellman võtmevahetuse tugi, näiteks võtmesõna DH abil:
<pre>
SSLCipherSuite ALL:!EXP:!NULL:!DH:!LOW
</pre>

Vt. lähemalt: [http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite]

Peale veebiserveri restarti tuleb teha uus paketipüüdmine. Kui kõik muu on korrektselt tehtud, võib Wiresharkis uue .pcap faili avamisel näha umbes sellist pilti ja HTTP päringut-vastust avatekstina uurida:

[[File:Marju ignatjeva Screenshot wireshark https decrypted.png|600px]]

==mitmproxy==

===Kliendi proxy seadistamine===
Selleks, et <tt>mitmproxy</tt> abil HTTPS liikluse sisu uurida, tuleb ta kõigepealt HTTP kliendis (brauseris, <tt>curl</tt>-is vms) seadistada ''proxy''-ks.
Nimelt, kui <tt>mitmproxy</tt> käivitada, siis vaikimisi kuulab ta aadressil 0.0.0.0 pordil 8080. Seega <tt>curl</tt>-ile anname need parameetrid ''proxy'' jaoks ja teeme HTTPS päringu oma serveri pihta.

curl -x localhost:8080 --insecure https://192.168.56.201

See päring ja vastus kajastuvad nüüd <tt>mitmproxy</tt> interaktiivses aknas.

Päriselus kasutame vingemate veebirakenduste kasutamiseks siiski graafilist brauserit ja edasi läheme Chromiumi näitel, kus samuti on kõigepealt vaja seadistada ''proxy'' (ja brauser restartida). Seda siin ei kirjelda.

===Teeseldud CA===
Kui <tt>mitmproxy</tt> on seadistatud ''proxy''-ks, siis HTTPS päringute korral pakub ta brauserile tegeliku serveri sertifikaadi asemel omaenda n-ö ''dummy'' sertifikaati (e. mängib CA-d) ja on seetõttu võimeline ka HTTPS liiklust "vahelt võtma", kuna HTTPS osapoolteks on klient ja <tt>mitmproxy</tt>, mitte enam server. Peale esimest käivitust tekivad kasutaja kodukataloogi alamkataloogi <tt>.mitmproxy</tt> selle dummy CA-ga seotud failid.
<pre>
ls ~/.mitmproxy/
mitmproxy-ca-cert.cer mitmproxy-ca-cert.p12 mitmproxy-ca-cert.pem mitmproxy-ca.pem
</pre>

Sellist dummy CA-d brauser vaikimisi ei usalda ja reageerib nagu tüüpiliselt ka iseallkirjastatud sertifikaatide puhul. Kui "harjumuspäraselt" vajutada "Proceed anyway", saame vaatlusalusele saidile tehtud HTTPS päringuid ja vastuseid üsna mugavalt uurida. Muidugi on <tt>mitmproxy</tt> CA võimalik lisada ka brauseri poolt usaldatavate CA-de hulka, aga seda siin ei kirjelda.

===HTTPS päringute vaheltvõtmine===
Edasi seadistame konkreetsele aadressile tehtavate päringute vaheltvõtmise. Selleks tuleb <tt>mitmproxy</tt> peaaknas vajutada "i" ja sisestada regulaaravaldis, mis meil on "192\.168\.56\.200".

Kui nüüd minna aadressile https://192.168.56.201, siis brauser jääb ootele ja <tt>mitmproxy</tt> aknasse tekib päringukirje, ning vaheltvõetud päringu edasisaatmiseks tuleb vajutada "a". Seda tuleb teha ka vastusega, kui me vastust muuta ei soovi, et brauser vastuse kätte saaks.

Päringuid ja vastuseid, mis veel ei ole "a" abil "aktsepteeritud", saame avatekstina uurida ja muuta!

Näide vaheltvõetud vastusest:
FIXME: screenshot

Põhjalikum <tt>mitmproxy</tt> [http://mitmproxy.org/doc/index.html kasutusjuhend] kirjeldab nii päringute filtreerimist kui päringute ja vastuste redigeerimist ja palju muud.

Head eksperimenteerimist! ;-)

[[Category:IT infrastruktuuri teenused]]

HTTPS liikluse uurimine tcpdump, Wireshark ja mitmproxy abil

2013-05-05T19:41:14Z

Mignatje: mitmproxy jutt lisaks

See artikkel räägib HTTPS liikluse analüüsimisest (HTTP päringute avatekstiks lahtivõtmise teel) kahes olukorras.
Esiteks -- kui nii klient kui server on meie hallata ja me soovime testida, kas server saab just selliseid HTTP päringuid ja saadab selliseid vastuseid, nagu me eeldame.
Teiseks -- kui serveriks on mõni avalik veebiteenus, millega suhtleme üle HTTPS protokolli, ja soovime teada, mida meie brauser serveriga räägib. Sisuliselt on siin tegemist olukorraga, kus me ei pruugi usaldada ei klienti (brauser jooksutab meie teadmata mingit kuritahtlikku skripti) ega ka serverit. Tegu võib olla ka mõne mobiilirakendusega, mille kohta soovime teada, mis andmeid ta meie telefoni kaudu edastab ja vastu võtab.

'''NB! Siin artiklis toodud juhised on mõeldud liikluse uurimiseks tavaolukorras, mitte kolmandate osapoolte andmevahetusse sissemurdmiseks!'''

''Autor: Marju Ignatjeva''

==Töövahendid ja keskkond==
Kasutame töövahenditena <tt>tcpdump</tt>-i ja Wiresharki ning <tt>mitmproxy</tt>-t, HTTP kliendina ka <tt>curl</tt>-i.

Artikli lugejalt eeldan, et HTTPS üldine tööpõhimõte on selge ja et lugeja oskab Linuxi keskkonnas paigaldada tarkvara nii süsteemsest pakimajandusest kui ka Pythoni pakendussüsteemide (eeskätt <tt>pip</tt>) vahenditega, samuti saab hakkama käsureal. Töövahendite paigaldamise juhised on siiski ka artiklis olemas.

Artiklis toodud näited põhinevad katsetustel 64-bitise Kubuntu 12.10 operatsioonisüsteemi all.

===Töövahendite paigaldamine===
Kui <tt>tcpdump</tt> ei ole paigaldatud, tuleb see juurkasutajana paigaldada käsuga
<pre>
apt-get install tcpdump
</pre>

Wiresharki paigaldame käsuga
<pre>
apt-get install wireshark
</pre>

HTTP päringuid on käsurealt mugav teha <tt>curl</tt> nimelise tööriistaga, paigaldame ka selle.
<pre>
apt-get install curl
</pre>

Kuna erinevate Linuxi distributsioonide pakimajanduses ei pruugi alati olla Pythonis kirjutatud tarkvarast väga värskeid versioone, siis <tt>mitmproxy</tt> paigaldamiseks on mõistlik kasutada <tt>pip</tt>-i.
<pre>
apt-get install python-pip
pip install mitmproxy
</pre>

==tcpdump ja Wireshark==
HTTPS liikluse püüdmiseks kasutame käsureavahendit <tt>tcpdump</tt> seetõttu, et servereid hallates ei ole meil tihtipeale ligipääsu graafilisele keskkonnale. Samas on Wireshark mugav ja kasutajasõbralik võrguliikluse uurimise töövahend ja <tt>tcpdump</tt>-i abil salvestatud liiklust saab Wiresharki abil hiljem suvalises teises masinas analüüsida.

Kuna veebiserver on meie hallata, siis on meil olemas tema privaatvõti. See on ainus vajalik sisend Wiresharkile, et ta oskaks kinnipüütud pakette lahti krüpteerida.

===Pakettide püüdmine===
Kõigepealt paneme <tt>tcpdump</tt>-i kuulama liiklust liidesel <tt>eth1</tt> (antud juhul on see Virtualboxi ''host-only'' võrguliides), aadressil 192.168.56.201, pordil 443 (meil on sinna konfitud üks HTTPS toega ''virtualhost''). Seda tuleb teha juurkasutaja õigustes, et meile antaks ligipääs võrguliidesele.
<pre>
tcpdump -w https_dump.pcap -i eth1 host 192.168.56.201 and port 443
</pre>

Teeme klientmasinast päringu (öeldes, et usaldame serveri enda poolt allkirjastatud sertifikaati):
<pre>
curl --insecure https://192.168.56.201
</pre>

Nüüd lõpetame Ctrl+C abil serveris <tt>tcpdump</tt>i töö -- too ütleb lõpetades käsureale midagi sellist:
<pre>
15 packets captured
15 packets received by filter
0 packets dropped by kernel
</pre>

===Püütud pakettide uurimine===
Järgmiseks on vaja <tt>tcpdump</tt>-i väljundfail saada masinasse, kus meil on võimalik kasutada Wiresharki (kusjuures salvestatud faili uurimiseks ei ole juurkasutaja õiguseid vaja).
Käivitame Wiresharki ja avame oma .pcap faili. Esialgu näitab Wireshark küll HTTPS-iga seotud andmevahetust, kuid HTTP päringuid avatekstina pole võimalik näha.
Wireshark võimaldab seda krüpteeritud sisuga andmevoogu ka eraldi aknas uurida ("Follow TCP Stream" suvalise paketi kontekstimenüüst).

Järgmiseks hangime serverist tema privaatvõtme (NB! Erinevate ''virtualhost''ide olemasolul pead hankima just antud päringus kasutatud IP-le vastava võtme!)

Wiresharkis võtame menüüst "Edit"->"Preferences" avanevas aknas "Protocols" alt "SSL" ja lisame serveri võtme:

[[File:Marju ignatjeva Screenshot wireshark ssl keys.png|600px]]

Kasulik on seadistada ka SSL ''debuglog''i failitee, et probleemide korral saaks vigu otsida. Näiteks võib juhtuda, et brauseri või serveri krüpto vaikeseadistused on sellised, et Wireshark ei saa pakettide sisu lahti krüpteerida, kuigi serveri privaatvõti ja muud parameetrid on korrektsed.

Nimelt võib juhtuda, et peale võtmefaili määramist ja HTTPS suhtlusega seotud paketi kontekstimenüüs "Follow SSL Stream" valimist näidatakse tühjust.

Sellisel juhul võiks debuglogist otsida sääraseid ridu:
<pre>
ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt
dissect_ssl3_handshake can't decrypt pre master secret
</pre>

Nimelt Apache2 <tt>mod_ssl</tt> vaikimisi konfis on lubatud Diffie-Hellman võtmevahetuse protokolli kasutamine, mis aga muudab HTTPS liikluse Wireshark-i jaoks lahtivõetamatuks.
Lähemalt loe näiteks:
[http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange]
ja
[http://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls http://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls]

Üks võimalikke lahendusi on Apache2 <tt>mod_ssl</tt> konfis (<tt>/etc/apache2/mods-available/ssl.conf</tt>) keelata Diffie-Hellman võtmevahetuse tugi, näiteks võtmesõna DH abil:
<pre>
SSLCipherSuite ALL:!EXP:!NULL:!DH:!LOW
</pre>

Vt. lähemalt: [http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite]

Peale veebiserveri restarti tuleb teha uus paketipüüdmine. Kui kõik muu on korrektselt tehtud, võib Wiresharkis uue .pcap faili avamisel näha umbes sellist pilti:

[[File:Marju ignatjeva Screenshot wireshark https decrypted.png|600px]]

==mitmproxy==

===Kliendi proxy seadistamine===
Selleks, et <tt>mitmproxy</tt> abil HTTPS liikluse sisu uurida, tuleb ta kõigepealt HTTP kliendis (brauseris, <tt>curl</tt>-is vms) seadistada ''proxy''-ks.
Nimelt, kui <tt>mitmproxy</tt> käivitada, siis vaikimisi kuulab ta aadressil 0.0.0.0 pordil 8080. Seega <tt>curl</tt>-ile anname need parameetrid ''proxy'' jaoks ja teeme HTTPS päringu oma serveri pihta.

curl -x localhost:8080 --insecure https://192.168.56.201

See päring ja vastus kajastuvad nüüd <tt>mitmproxy</tt> interaktiivses aknas.

Päriselus kasutame vingemate veebirakenduste kasutamiseks siiski graafilist brauserit ja edasi läheme Chromiumi näitel, kus samuti on kõigepealt vaja seadistada ''proxy'' (ja brauser restartida). Seda siin ei kirjelda.

===Teeseldud CA===
Kui <tt>mitmproxy</tt> on seadistatud ''proxy''-ks, siis HTTPS päringute korral pakub ta brauserile tegeliku serveri sertifikaadi asemel omaenda n-ö ''dummy'' sertifikaati (e. mängib CA-d) ja on seetõttu võimeline ka HTTPS liiklust "vahelt võtma", kuna HTTPS osapoolteks on klient ja <tt>mitmproxy</tt>, mitte enam server. Peale esimest käivitust tekivad kasutaja kodukataloogi alamkataloogi <tt>.mitmproxy</tt> selle dummy CA-ga seotud failid.
<pre>
ls ~/.mitmproxy/
mitmproxy-ca-cert.cer mitmproxy-ca-cert.p12 mitmproxy-ca-cert.pem mitmproxy-ca.pem
</pre>

Sellist dummy CA-d brauser vaikimisi ei usalda ja reageerib nagu tüüpiliselt ka iseallkirjastatud sertifikaatide puhul. Kui "harjumuspäraselt" vajutada "Proceed anyway", saame vaatlusalusele saidile tehtud HTTPS päringuid ja vastuseid üsna mugavalt uurida. Muidugi on <tt>mitmproxy</tt> CA võimalik lisada ka brauseri poolt usaldatavate CA-de hulka, aga seda siin ei kirjelda.

===HTTPS päringute vaheltvõtmine===
Edasi seadistame konkreetsele aadressile tehtavate päringute vaheltvõtmise. Selleks tuleb <tt>mitmproxy</tt> peaaknas vajutada "i" ja sisestada regulaaravaldis, mis meil on "192\.168\.56\.200".

Kui nüüd minna aadressile https://192.168.56.201, siis brauser jääb ootele ja <tt>mitmproxy</tt> aknasse tekib päringukirje, ning vaheltvõetud päringu edasisaatmiseks tuleb vajutada "a". Seda tuleb teha ka vastusega, kui me vastust muuta ei soovi, et brauser vastuse kätte saaks.

Päringuid ja vastuseid, mis veel ei ole "a" abil "aktsepteeritud", saame avatekstina uurida ja muuta!

Näide vaheltvõetud vastusest:
FIXME: screenshot

Põhjalikum <tt>mitmproxy</tt> [http://mitmproxy.org/doc/index.html kasutusjuhend] kirjeldab nii päringute filtreerimist kui päringute ja vastuste redigeerimist ja palju muud.

Head eksperimenteerimist! ;-)

[[Category:IT infrastruktuuri teenused]]

HTTPS liikluse uurimine tcpdump, Wireshark ja mitmproxy abil

2013-05-05T18:29:10Z

Mignatje: Disclaimer ka igaks juhuks

HTTPS liikluse uurimine tcpdump, Wireshark ja mitmproxy abil

2013-05-05T15:32:31Z

Mignatje: Esimese osa pildid ja pisiparandused

File:Marju ignatjeva Screenshot wireshark https decrypted.png

2013-05-05T15:27:01Z

Mignatje: IT infra wiki artikli jaoks

IT infra wiki artikli jaoks

File:Marju ignatjeva Screenshot wireshark ssl keys.png

2013-05-05T15:22:35Z

Mignatje: IT infra wiki artikli jaoks

IT infra wiki artikli jaoks

HTTPS liikluse uurimine tcpdump, Wireshark ja mitmproxy abil

2013-05-05T15:21:01Z

Mignatje: Marju Ignatjeva artikli esimene osa

Category:I375/I803/I853 IT Infrastructure services

2013-03-13T13:51:18Z

Mignatje: /* Praktiline töö 1 NTP/DNS/DHCP (9p/15%) */ NTP labori kaitsmise lisa: iburst

=Uudised=

Tulemas on http://www.itcollege.ee/en/co-operation/dits2013/

=Üldinfo=
Aine info: [https://itcollege.ois.ee/study-material/round?round_id=2230 IT infrastruktuuri teenused ÕIS leht]

[http://enos.itcollege.ee/~mernits/infrastruktuur/ Aine õppematerjalid]

ECTS: 5

Hindamisviis: Arvestus

'''Rangelt soovituslik aine:''' Operatsioonisüsteemide administreerimine ja sidumine (I233)

==Õppejõud==
Margus Ernits >> margus (.) ernits (ät) itcollege (.) ee

Katrin Loodus >> katrin (.) loodus (ät) itcollege (.) ee

=Eesmärk ja sisu=
Tutvustada IT infrastruktuuri teenuste põhimõisteid. Anda oskused põhiliste teenuste paigaldamiseks ja turvamiseks. Anda oskused IT infrastruktuuri teenuste dokumenteerimiseks.
Eesmärgi saavutamiseks toimuvad laboratoorsed tööd, mille käigus installeeritakse ja konfigureeritakse teenuseid pöörates rõhku teenuse turvalisusele, millele eelnevad loengud alus- ja põhimõistete tutvustamiseks.

=Ainekaart=
Ainekaardi viimase, kuid mitte lõpliku versiooni leiab [https://wiki.itcollege.ee/images/6/67/I385_IT_infrastruktuuri_teenused_aineprogramm_2013.odt siit]

=Eelmiste aastate tagasiside=
[https://wiki.itcollege.ee/images/4/4d/It-infra-tagasiside-2012-1.pdf 2012 kaugõppe tagasiside]

[https://wiki.itcollege.ee/images/2/28/It-infra-tagasiside-2012-2.pdf 2012 päevaõppe tagasiside]

=Loengud=

[http://enos.itcollege.ee/~mernits/infrastruktuur/loeng00%20-%20Sissejuhatav%20loeng.odp Sissejuhatav loeng] - <span style="color: red;">NB siin on kirjas hindamiskriteeriumid ja tähtajad.</span> Lisaks on kirjas kontrolltööde ajad ja muu aine läbimiseks oluline info. (Päevaõppes toimus 04.02.2013)

[http://enos.itcollege.ee/~mernits/skriptimine/bash/src/juurteenused-ntp.html NTP teenus] (Päevaõppes toimus 04.02.2013)

<span style="color: red;">Kodutöö nr 1. Tähtaeg 11.02.2013. DNS loenguks lugeda läbi DNS põhimõisted.</span> Sobiva info leiate kuutõrvajas http://kuutorvaja.eenet.ee/wiki/DNS Soovi korral võite allkirjeldatud mõistete kohta infot lugeda ka mujalt.

=Mõisted kontrolltööks ja arvestuseks=

*DNS mõistete kohta leiab infot: http://kuutorvaja.eenet.ee/wiki/DNS
*hostinimi (mis märgid on hostinimes lubatud ja kus?)
*host täisnimi
*domeeni täisnimi
*DNS
*A-kirje
*alias ehk CNAME
*puhverdamine
*dig ja selle kasutamine
*DNS spoofing
*domeen ja domeeninimi
*Authoritative ehk pädev server
*Forwarding ehk edastamine
*FQDN
*Host
*PTR-kirje
*rekursiivne lahendus
*primaarne server
*sekundaarne server
*open resolver
*kuidas nimelahendus töötab, kirjelda näiteks "kui veebisirvijas avatakse leht, siis mis võiks toimuda?"

=Vanad loengumaterjalid=

[http://enos.itcollege.ee/~mernits/infrastruktuur/arhiiv/loeng00%20-%20Sissejuhatav%20loeng.odp Loeng 00 - Sissejuhatav loeng - NB Tähtajad ja nõuded]

[http://enos.itcollege.ee/~mernits/infrastruktuur/arhiiv/loeng01%20-%20E-post.odp Loeng 01 E-post]

[http://enos.itcollege.ee/~mernits/infrastruktuur/arhiiv/loeng03%20-%20Failiserver.odp Loeng 03 Failiserver]

[http://enos.itcollege.ee/~mernits/infrastruktuur/arhiiv/loeng04%20-%20Veebiserver.odp Loeng 04 Veebiserver]

[http://goo.gl/6XQ0U WordPress seadistamine]

[http://enos.itcollege.ee/~mernits/infrastruktuur/arhiiv/loeng05%20-%20Dokumentatsioon.odp Loeng 05 Dokumentatsioon]

[http://enos.itcollege.ee/~mernits/infrastruktuur/arhiiv/loeng06%20-%20VPN.odp Loeng 06 VPN]

[http://enos.itcollege.ee/~mernits/infrastruktuur/arhiiv/loeng07%20-%20iptables.odp Loeng 07 Tulemüürid]

[http://enos.itcollege.ee/~mernits/infrastruktuur/arhiiv/loeng08%20-%20SAN%20-%20NAS%20-%20CAS.odp Loeng 08 SAN NAS CAS]

[http://enos.itcollege.ee/~mernits/infrastruktuur/arhiiv/loeng09%20-%20Virtualiseerimine.odp Loeng 09 Virtualiseerimine]

[http://enos.itcollege.ee/~mernits/infrastruktuur/arhiiv/loeng10%20-%20DHCP.odp Loeng 10 DHCP]

Abimaterjal:
* [http://tools.ietf.org/html/rfc2131 RFC2131]
* [http://kuutorvaja.eenet.ee/wiki/Isc-dhcpd_server Kuutõrvaja DHCP materjal]

Abimaterjal laboriks:
* Maskeraad [[Ufw]]
* DHCP serveri seadistamine [[DHCP]]
* [http://www.debian-administration.org/article/343/Configuring_Dynamic_DNS__DHCP_on_Debian_Stable Dünaamiline DNS kirjete uuendamine DHCP poolt]
* [http://debianclusters.org/index.php/Troubleshooting_DHCP DHCP probleemide lahendamine]

[http://enos.itcollege.ee/~mernits/infrastruktuur/arhiiv/loeng11%20-%20Monitooring.odp Loeng 11 Monitooring]

[http://enos.itcollege.ee/~mernits/infrastruktuur/arhiiv/loeng12%20-%20LDAP.odp Loeng 12 LDAP]

=Praktilised tööd=

==Sissejuhatav praktikum==

Paigaldage Ubuntu Linux Server süsteem VirtualBox abil

'''NB! Pange kasutajanimeks mõlema süsteemi puhul student ja parool ka student'''

* RAM 512MB
* HDD dynamicly allocated 8GB
* 2 Võrgukaarti NIC1 - NAT (eth0 - Ubuntus) ja NIC2 - HostOnly (eth1 - Ubuntus)
Logige serverisse sisse ja seadistage võrk failis /etc/network/interfaces (liidese eth1 ip aadress 192.168.56.200).
Abiinfo Ubuntu server võrgu seadistamine ja VirtualBoxi võrgud

<pre>
auto eth1
iface eth1 inet static
address 192.168.56.200
netmask 255.255.255.0
</pre>

Paigaldage openssh server, kui te seda installi käigus ei teinud (apt-get update && apt-get install ssh)
ISO: Ubuntu Server 12.04.1 LTS ISO (64bit) http://elab.itcollege.ee:8000/ubuntu-12.04.1-server-amd64.iso

Lisaks paigaldage ka Ubuntu Linux Desktop süsteem VirtualBox abil

ISO: Ubuntu Desktop 12.04.1 LTS ISO (64bit) http://elab.itcollege.ee:8000/ubuntu-12.04.1-desktop-amd64.iso

Pärast installi lõppu pange peale ka kõik vajalik uuendused ning paigaldage VirtualBox-i enda additionid, mis on leitavad VirtualBox-i üldiste seadete alt

Seadistage ka võtmetepõhine autentimine [[OpenSSH: võtmetega autentimine]]

Eelnevalt seadistatud [http://elab.itcollege.ee:8000/infra_server.ova server] ja [http://elab.itcollege.ee:8000/infra_klient.ova klient]. User student parool on sama ja seadistatud on ka ssh key autentimine. Võtme parool on samuti student.

==Praktiline töö 1 NTP/DNS/DHCP (9p/15%)==
Esimese praktilise töö eesmärgiks on omandada oskused ja algteadmised levinumate infrastruktuuri teenuste seadistamiseks.

Selleks on tarvis teostada kolm laborit teemadel:

* NTP paigaldamine ja seadistamine (3p)

Konfigureerige NTP teenus serveris ja seadistage kliendiarvuti seda teenust kasutama.

Uurige mida teevad järgnevad korraldused juurkasutajana.

<source lang="bash">
date
hwclock -r
TZ=UTC date
date
echo $TZ
hwclock --set --date="9/22/99 12:00:00"
hwclock --systohc
hwclock --hctosys
</source>

Kuna VirtualBox sünkroniseerib "pisikese" aja tagant oma kella sinu operatsioonisüsteemi vastu, siis järgmisteks testideks on see soovituslik ära keelata.

Järgneb õpetus: '''Kuidas keelata VirtualBoxi'l guest OS kellaaja sünkroniseerimine host OS vastu.'''

Selleks on vaja avada

Windowsi operatsioonisüsteemis administraatoriõigustes Command Prompt

Mac OS X operatsioonisüsteemis Terminal

Linuxi mõnes distributsioonis Terminal

'''1) Navigeeri ennast VirtualBox installeerimiskohvrisse'''

Windows:
cd C:\Program Files(x86)\Oracle\VirtualBox\

Linux: Linuxis on see tee juba PATH muutujas olemas, seega - võid käsud käivitada ükskõik kus olles. :)

Mac OS X: Mac OS X all on see tee juba samuti PATH muutujas olemas.

'''2) Sisesta käsk'''

Windows:
VBoxManage.exe setextradata "Soovitud Masina Nimi" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" "1"
Linux:
VBoxManage setextradata "Soovitud Masina Nimi" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" "1"
Mac OS X:
VBoxManage setextradata "Soovitud Masina Nimi" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" "1"

'''3) Kui soovid ühel hetkel, et siiski sünkroniseeriks, siis toimi samamoodi, aga käsk, mida sisestama pead on'''
Windows:
VBoxManage.exe setextradata "Soovitud Masina Nimi" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" "0"
Linux:
VBoxManage setextradata "Soovitud Masina Nimi" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" "0"
Mac OS X:
VBoxManage setextradata "Soovitud Masina Nimi" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" "0"

Ajage kliendiarvuti kell väga valeks ja mõelge, kuidas seda õigeks saada.

Muutke kleindiarvuti kell 30 sekundit valeks ja uurige, kas aeg läheb täpsemaks.

Millal saab NTP abil aega seada?

Mida teevad korraldused

<source lang="bash">
ntpdate
ntptrace -n
ntpsweep --host localhost
ntpq -pn
service ntp stop
ntpdate ntp.ubuntu.com
service ntp start
</source>

Leia meie võrgule sobivam(ad) ntp serverid, mille abil oma võrgu ntp serveri kella sünkroniseerida.

Kuidas toimib NTP turvamudel?

'''Küsimused, mida õppejõud võib küsida NTP kaitsmisel:'''

*Miks on ntp konfis vaja sellist ip-d nagu 127.0.0.1 seoses ntp ja Internetiga?
*Mida näitab fudge ja stratum 10?
*Mida kirjeldavad ntp.conf failis restrict read?
*Mida tähendavad tärn, pluss ja miinus remote serverite ees?

'''Soovitused:'''

*Kindlasti osata seletada ntpq -p käsu parameetrite tähendusi (refid, st, jitter jne).
*Suur osa küsitavast infost on olemas ntp esitluses ning ülejäänud asjad tuleb leida Google'i abiga.

====NTP sünkroniseerimise kiirendamine====
Kui NTP server käima tõmmata, võib minna tüütult palju aega, et meie server sünkroniseeriks end mõne konfis oleva referents-serveri vastu.

NTP deemoni konfifail <tt>/etc/ntp.conf</tt> toetab võtmesõna <tt>iburst</tt>, mis lisatakse vajadusel <tt>server</tt> ridade lõppu, näiteks:

<pre>
server 0.pool.ntp.org iburst
</pre>

Võtmesõna <tt>iburst</tt> ütleb, et kui antud server on kättesaamatu, siis saadetakse välja 8 paketist koosnev pakettide "purse", vaikimisi 2-sekundiliste vahedega. Mõte selles, et näiteks ebastabiilse võrgu korral, kui esimesele paketile vastust ei saada, üritataks väikese vahega uuesti, mitte ei oodataks, kuni pollimise intervall täis tiksub. Vaikimisi minimaalne pollimise intervall nimelt on 64 sekundit.

Kui kombineerida võtmesõnu <tt>burst</tt>, <tt>iburst</tt>, <tt>minpoll</tt> ja <tt>maxpoll</tt>, saab sünkroniseerimise sagedust märkimisväärselt tõsta, kuid neid võtmesõnu tuleb eriti avalike serverite vastu sünkroniseerides kasutada ettevaatlikult, sest need tekitavad tavapärasest palju tihedamat NTP liiklust. Samas <tt>iburst</tt> üksinda peaks mõjuma ainult siis, kui võrk parasjagu kättesaamatu on.

Loe lisa:
* [http://doc.ntp.org/4.1.2/confopt.htm NTP konfiparameetrid]
* [http://voltdb.com/docs/PerfGuide/ntpSvcIntro.php Veel üks juhend kellade sünkimisega seotud probleemide teemal]

===DNS paigaldamine ja seadistamine (3p)===

*Mõtle välja endale domeeninimi
*Loo domeeninimele tsoonifail ja seadiste nimeserver
*Luba rekursiivne lahendus oma sisevõrgust
*Loo reevers tsoon
*Loo A kirjed e-posti, nimeserveri jaoks
*Loo CNAME kirjed www, samba ja oma severi jaoks

http://enos.itcollege.ee/~mernits/infrastruktuur/dns/DNS_BIND.html

Näitelahendus [[Nimeserveri labor V.2]]

Kaitsmisel pead oskama luua uut tsooni, lisama kirjeid, oskama kasutada rndc, dig, nslookup vahendeid.

* DHCP paigaldamine ja seadistamine (3p)

==Praktiline töö 2==

Teise praktilise töö eesmärgiks on omandada oskused ja algteadmised levinumate juurteenuste seadistamiseks.

Selleks on tarvis teostada kolm laborit teemadel:

* Apache2 paigaldamine ja virtualhostide seadistamine [[Virtualhost apache2 näitel]]
* Wordpress paigaldamine ja jõudluse testimine (varnish)
[[WordPress turvamine]]

[[Varnish]] - vaata
http://www.howtoforge.com/putting-varnish-in-front-of-apache-on-ubuntu-debian
* DVWA paigaldamine ja OWASP testimine

==Praktiline töö 3==

Kolmanda praktilise töö eesmärgiks on omandada teadmised varasemates praktilistes töödes katmata jäänud oluliste infrastruktuuri teenuste kohta.

Selleks on tarvis paigaldada samba failiserver Zentyal keskkonnas.

==Questid, millede eest saab punkte==

Quest 1 - https://docs.google.com/document/d/1oRt9JLF6lcf_Z-ReHCfbZXnSoc-EOBzGprxvIyhq4qk/edit?usp=sharing

=Kaugõppele=

Info lisandub...

=Arvestus ja hindamine=

Aine on jagatud praktilisteks ja teoreetilisteks töödeks. Seitsmeks (7) laboriks ning kaheks (2) teoreetiliseks kontrolltööks.

Lisaks on tarvis teha eraldi dokumentatsiooni ehk ühe kaitstud labori kohta '''viki artikkel'''.

'''Praktiliste tööde''' hulka kuuluvad erinevate teenuste paigaldamine ning seadistamine. Ühe labori eest on võimalik saada maksimaalselt 3 punkti.

* 1 punkt on võimalik saada teenuse seadistamise, paigaldamise ning suulise kaitsmise eest. (Õppejõud võib seadistust muuta ning paluda paranduste kohta selgitust)
* 2 punkti on võimalik saada, kui kaitsta oskuslikult konkreetse labori kohta käivad teoreetilised teadmised suuliselt õppejõule. (Küsimused esitab õppejõud)
* 3 punkti on võimalik saada, kui parandada konkreetse teema kohta käivat juhendit ning esitada tulemuse õppejõule. (Mõeldud ambitsioonikamatele tudengitele)

Lävendiks on 1 punkt, mis tähendab praktilise osa teostust. Kui iga labori eest on ainult 1 punkt, tuleb teoreetilised teadmised kaitsta kontrolltöö käigus, aga kui iga labori eest on vähemalt 2 punkti, ei ole kontrolltööd tarvis teha.

'''Lõpparvestus''', neile, kes ei saa tähtajaks laboreid, kontrolltöid ja dokumentatsiooni kaitstud, toimub samuti kahes osas ning annab kokku 20% kogu hindest. Arvestusel peab koguma vähemalt pooled punktid läbi saamiseks (Tasub semestri jooksul pingutada!)
Arvestusel tuleb 10% ulatuses parandada õppejõu poolt "katki tehtud" teenust ja 10% ulatuses vastata 5-10-le teoreetilisele küsimusele.

==Tähtajad==

===Päevaõppele===

Praktilise töö laborite kaitsmised (laborid 1-3): 18. märts

Praktilise töö laborite kaitsmised (Laborid 4-6): 13. mai

Praktilise töö labori kaitsmised (Labor 7): ~21. mai

Dokumentatsioon (viki artikkel): 13. mai

Kontrolltöö 1: 25. märts

Kontrolltöö 2: 13. mai

Arvestus: Arvestuse päeval mai lõpus. ~27. mail

=Juurteenuste kursus=
[http://enos.itcollege.ee/~mernits/skriptimine/bash/src/juurteenused.html Interneti juurteenused]