Cât de ușor este să detectați o VPN folosită?

Rețelele private virtuale (VPN) rezolvă o mulțime de probleme de confidențialitate. Deoarece de obicei o VPN criptează traficul dvs. între computer și furnizorul VPN, este foarte dificil pentru un observator să vadă traficul dvs. pentru a vedea ce faceți. Cu toate acestea, există multe persoane care doresc să poată ascunde faptul că folosesc VPN-uri; cum ar fi persoanele din țările care interzic VPN-urile sau alte situații în care utilizarea VPN nu este în general permisă sau blocată prin mijloace tehnice. În acest articol, ne concentrăm pe tipul de date pe care un observator le poate colecta din capturile de pachete de rețea și modul în care aceste date pot fi utilizate pentru a detecta utilizarea VPN.

Istoric despre problemă

Întrebarea arzătoare este „de ce”? Cui îi pasă dacă cineva descoperă că executați un VPN? Dacă oricum traficul este criptat intens, care este problema?

Este adevărat că, în multe situații și în multe țări, nu contează deloc dacă un observator detectează utilizarea unei VPN. Cu toate acestea, există multe țări care interzic utilizarea VPN-urilor și, prin urmare, este important ca utilizatorii VPN din aceste țări să știe cum pot fi descoperite..

Pentru a determina dacă este utilizat un VPN, un observator trebuie să aibă acces la un router prin care trece traficul țintă. În cazul unei victime vizate, un atacator poate cheltui resurse mari pentru a identifica un mod de a prelua un router pe care îl folosește o anumită victimă. În cazul supravegherii statelor naționale, detectarea eficientă ar necesita controlul multor routere. Când combinați aceste două lucruri - o organizație care îi pasă dacă utilizați și VPN Si deasemenea are capacitatea de a controla un număr mare de routere - ceea ce indică de obicei un actor la nivel național.

Rețineți că acest articol tratează modalități prin care utilizatorii VPN pot fi descoperiți de observatori. Nu înseamnă neapărat că datele criptate în tunelul VPN sunt mai ușor de exploatat.

Metodologia testării

Fără acces la resurse la nivel de stat, platforma și metodologia mea de testare sunt puțin mai mici. Am creat o mică rețea internă folosind trei mașini virtuale (VM) cu VirtualBox. Topologia rețelei este astfel:

Configurare rețea de test VPN

Am instalat software de adulmecare a pachetelor pe routerul OpenWRT VM și apoi am testat diverse configurații VPN pe celelalte două mașini virtuale. Software-ul de adulmecare a pachetelor, tcpdump, mi-a permis să surprind traficul de rețea VM pentru analiză. Într-o configurare mai realistă, software-ul de captare a pachetelor va fi probabil instalat pe routere de pe Internet sau cel puțin în rețeaua ISP. Amplasarea strategică a software-ului de analiză ar necesita unele cunoștințe despre punctele de interes de convergență pe internet unde este probabil să circule traficul țintă. În rețeaua de testare, știu cu 100% siguranță că tot traficul către și către mașinile mele virtuale va trece prin routerul OpenWRT. Prin urmare, este cel mai bun loc pentru mine să plasez instrumentele de colectare.

Surse non-tehnice ale indicatorilor VPN

Nu toate sursele de date care indică utilizarea VPN sunt tehnice. În timp ce unele sunt foarte tehnice, cum ar fi analiza pachetelor, unele sunt foarte non-tehnice, cum ar fi eroarea umană și rutina zilnică.

Traficul de rețea neintenționat

Majoritatea utilizatorilor VPN au software de client care trebuie lansat pentru a putea fi stabilit VPN. Este foarte dificil să vă asigurați că niciun trafic nu trece pe internet înainte ca VPN-ul să fie stabilit când computerul începe. Este posibil ca chiar și VPN-urile cu switch-uri să nu poată face nimic în privința traficului care trece în timpul pornirii sistemului.

vypr-vpn-AutoConnect-mode

vypr-vpn-Killswitch-mode

Pentru a testa acest lucru, am setat opțiunile de comutare auto-conectare și omorâre ale VyprVPN în mașina virtuală Windows. Am oprit apoi aparatul Windows, am pornit o captare de pachete pe routerul OpenWRT și am pornit mașina Windows. Acestea au generat o mulțime de pachete și sunt de interes aceste două secvențe.

În primul rând, putem vedea o mulțime de pings pentru o gamă similară de IP-uri. Nu am grupat intenționat aceste pachete - așa au fost trimise organic:

vypr-RVP-ferestre-boot-ICMP-pachete

Acest lucru sugerează că ceva încearcă să enumere servere. O cauză foarte frecventă a acestui tip de trafic într-un scenariu VPN este un client VPN care încearcă să determine cel mai rapid server. O metodă pentru a face acest lucru este să trimiteți un pachet ICMP (cunoscut sub numele de ping) la un set de servere pentru a vedea care dintre acestea revin cel mai rapid.

Putem vedea din prima captură de ecran că 209.99.63.34 a returnat cel mai rapid în 99 de milisecunde. Mai jos în captura de pachete, observăm brusc că cea mai mare parte a traficului din acel moment este criptată și este destinată 209.99.63.34

vypr-RVP-ferestre-boot-QUIC-pachete

Următoarea piesă a puzzle-ului este să descoperi ce se află la aceste IP-uri. Folosind IP WHOIS care afirmă proprietarul înregistrat al unui IP, putem vedea că toate aceste IP-uri, cu excepția unuia, aparțin YHC Corporation și se rezolvă la serverele din centrul de date Data Foundry:

209.99.108.46
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
209.99.109.167
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
209.99.113.70
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
209-99-115-97
209.99.117.82
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
209.99.21.36
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
OrgTechEmail: [email protected]
209.99.22.46
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
209.99.60.34
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
209.99.61.42
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
209.99.62.34
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
OrgName: Powerhouse Management, Inc.
OrgTechEmail: [email protected]
209.99.63.34
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
209.99.63.34
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
209.99.67.41
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
209.99.72.70
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
209.99.75.70
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
209.99.93.34
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
209.99.94.37
Nume Org: YHC Corporation
OrgTechEmail: [email protected]
209.99.95.40
Nume Org: YHC Corporation
OrgTechEmail: [email protected]

Un pas logic logic ar fi scanarea IP-urilor pentru a vedea ce servicii rulează. Nu am furnizat detalii despre cum să faceți asta, dar testarea mea arată că bannerele de conexiune implicite pe care majoritatea serverelor afișate au fost eliminate din serverele VyprVPN, astfel încât nu există o poveste evidentă că aceste IP-uri rulează un server VPN.

Nu puteți face multe despre modul în care computerul dvs. acționează înainte de a fi pornit. Prin urmare, dacă doriți să desconsiderați acest tip de secvență de configurare, va trebui să rulați o VPN „în fața” computerului. Rularea clientului VPN pe routerul dvs. în loc să rulați un client pe computer este o modalitate de a face acest lucru. Vei rula în continuare aceleași secvențe de pornire atunci când routerul repornește, dar acesta este de obicei mai puțin frecvent decât computerul tău.

Nu există pachete necriptate

După cum am menționat mai sus, odată ce pings-ul a fost complet, captura de pachete arată traficul criptat către cel mai rapid IP. Dacă un observator vede doar pachete criptate și nu un singur pachet necriptat, acesta poate fi un semn că există un VPN în uz. În timp ce lumea se îndreaptă rapid către criptarea cât mai multor date pe web, există încă unele solicitări care nu sunt de obicei criptate. Printre acestea se numără interogări de căutare DNS, interogări NNTP (serverul de timp) și o prezentare a altor solicitări de protocol, cum ar fi FTP și Telnet, care sunt uneori utilizate în unele dintre aplicațiile noastre, dar nu acceptă deloc criptarea..

Scurgeri de la securitatea operațională umană sloppy (OpSec)

O mulțime de date semnificative pot fi obținute dintr-o țintă folosind informații aparent banale. Mulți oameni petrec mult timp și eforturi pentru a atenua ceea ce ei consideră drept „lucruri importante” doar pentru a fi identificați prin informații banale la care nu s-au gândit. Unele exemple includ memoria lungă a internetului care a dezvăluit că administratorul de e-mail al lui Hillary Clinton era cel mai probabil un tip pe nume Paul Combetta; Dread Pirate Roberts, AKA Ross Ulbricht, pretinsul director al pieței ilegale a internetului Silk Road, a fost urmărit în mare măsură din cauza datelor de pe laptopul său care au fost luate fizic de la el în timp ce erau distrase la o bibliotecă publică..

Mai puțin dramatic, observatorii pot folosi frecvent lucruri precum ciclurile de activitate pentru a fixa fusul orar al unei ținte sau prezența unor caractere speciale într-un mesaj pentru a identifica o dispunere a limbii corespunzătoare țării vizate. Nu există o listă completă de lucruri care trebuie luate în considerare atunci când se ia în considerare securitatea operațională, deoarece furnizarea de noi modalități de referință încrucișată este în mare parte un exercițiu în imaginație și resurse.

Cu toate acestea, există unele lucruri specifice care se referă la captarea pachetelor care pot identifica utilizarea VPN.

Semne de poveste din metadate de pachete

Re-tastele PFS sunt previzibile

Întrucât traficul VPN este de obicei criptat, acesta este, în general, ascuns de privirile indurerate Criptarea funcționează deoarece este foarte greu să „brute forța” datele criptate pentru a expune conținutul clar al textului. De fapt, ruperea criptării este atât de grea încât proiectele de supraveghere la scară largă colectează uneori doar toate datele pe care le pot, în speranța că vor putea sparge criptarea la o dată viitoare, când puterea computerului va crește, sau vor putea obține cheile. care au fost utilizate pentru criptarea datelor. Perfect Forward Secrecy (PFS) este o metodă care poate fi utilizată pentru a preveni acest din urmă scenariu.

Perfect Forward Secrecy generează cheile de criptare utilizate pentru a cripta traficul VPN periodic. Când este generată o nouă pereche de chei, perechea anterioară este distrusă. Aceasta înseamnă că orice pachete criptate colectate nu pot fi decriptate la o dată ulterioară, deoarece cheia folosită pentru criptarea lor nu mai există.

OpenVPN acceptă PFS. În timp ce captez date pentru acest articol, am scăzut viteza de ciclare a cheii până la 10 secunde pentru a surprinde acest proces. Am constatat că atunci când a avut loc regenerarea cheii, a fost generată următoarea secvență de pachete:

09: 01: 48.461276 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lungime 94
09: 01: 54.749114 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lungime 65
09: 01: 58.895381 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lungimea 86
09: 01: 58.951091 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lungime 94
09: 01: 58.951614 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lungime 259
09: 01: 59.007916 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lungime 94
09: 01: 59.008027 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lungime 94
09: 01: 59.008265 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lungime 94
09: 01: 59.008300 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lungime 94
09: 01: 59.062927 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lungime 256
09: 01: 59.106521 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lungime 575

Lucrul notabil despre această secvență este că dimensiunile pachetului sunt identice de fiecare dată când are loc regenerarea cheii. Prin urmare, de fiecare dată când vedeam o secvență de pachete cu aceste dimensiuni în captura mea de pachete, știam că ciclul cheie avea loc:

94
65
86
94
259
94
94
94
94
256
575

În mod evident, orice proces de repetare ar genera teoretic o secvență repetată de pachete de acest fel, dar poate fi utilizat în continuare ca indicator că poate fi în joc PFS. Împreună cu alte date, aceste informații ar putea fi suficiente pentru a confirma o conexiune VPN.

Toate pachetele destinate aceluiași IP

În timpul desfășurării normale a internetului, oamenii și computerele solicită date de pe mai multe site-uri diferite. Fiecare dintre aceste site-uri are o adresă IP diferită. Când utilizați un VPN, fiecare pachet este destinat serverului VPN. Serverul VPN scoate stratul de criptare VPN de pe fiecare pachet pentru a dezvălui pachetul real și apoi îl trimite în drum spre destinația sa reală. Serverul VPN face același lucru cu răspunsurile. Acesta primește pachete de răspuns, le înfășoară într-un strat de criptare și apoi trimite pachetul la computerul utilizatorului.

O captura de pachete care arată un computer care trimite 100% din traficul său către un singur IP este un indicator bun că este folosit un VPN sau un proxy.

Psifhon este un instrument de eludare a cenzurii pe internet. Are o funcție interesantă care poate combate acest lucru într-o oarecare măsură. Are modul de tunel divizat, care utilizează în esență doar tunelul Psifhon pentru traficul care părăsește propria țară.

comparitech-psiphon-splittunnel-mode

Pentru a vedea cum arată acest lucru la nivelul pachetelor, am lansat Psiphon și am testat două site-uri. Sunt în Canada și iată un eșantion de trafic care este destinat registrului nostru de domeniu .CA. În acest caz, destinația mea este clar vizibilă în captura de pachete.

8: 30: 14.213668 IP 192.168.1.210.58787 > www.cira.ca.https: Steaguri [.], ack 1026833, câștigă 64240, lungime 0
08: 30: 14.229178 IP www.cira.ca.https > 192.168.1.210.58787: Steaguri [.], Urm. 1026833: 1028293, ack 715, câștig 5094, lungime 1460
08: 30: 14.229427 IP www.cira.ca.https > 192.168.1.210.58787: Steaguri [.], Urm. 1028293: 1031213, ack 715, câștig 5094, lungime 2920
08: 30: 14.229781 IP 192.168.1.210.58787 > www.cira.ca.https: Steaguri [.], ack 1031213, câștigă 64240, lungimea 0

Am vizitat apoi site-ul web Comparitech, care este găzduit în Statele Unite:

8: 29: 48.028789 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Steaguri [P.], urm 107809: 108277, ACK 19080, câștig 1392, lungime 468
08: 29: 48.029101 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Steaguri [.], ack 108277, câștig 856, lungime 0
08: 29: 48.029306 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Steaguri [P.], urm 19080: 19132, ack 108277, câștig 856, lungime 52
08: 29: 48.108658 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Steaguri [.], Ack 19132, câștig 1392, lungime 0

Rețineți cum traficul destinat SUA este trimis către un server Linode în loc de a comparaitech.com. Linode este o companie de server foarte mare și nu este deloc neobișnuit să vezi traficul destinat unui server Linode. În plus, Psifhon profită de traficul acesta folosind un tunel SSH pentru a ascunde orice urmă de VPN. De asemenea, DNS invers (rDNS) pentru serverul Psiphon de la Linode nu trădează asocierea acestuia cu Psifhon; rDNS arată doar Linode deține IP-ul, care este de așteptat. Mai multe despre rDNS în secțiunea de ofuscitare mai târziu în acest articol.

Incoerențe în sistemul de operare și în pachetul de date despre amprentă

Deși rețeaua TCP este un sistem de operare agnostic, diferite sisteme de operare creează pachete cu valori diferite. De exemplu, valoarea de pachet implicită Time-To-Live (TTL) variază în pachetele create pe diferite sisteme. Majoritatea sistemului Windows va seta pachetul TTL la 128 în mod implicit, în timp ce majoritatea sistemelor Linux îl vor seta la 64. Deoarece TTL este o parte vizibilă a pachetului capturat, este posibil să se stabilească ce sistem de operare cel mai probabil a creat acel pachet. Există, de asemenea, alte semne în construcția de pachete, cum ar fi lungimea și dimensiunea maximă a segmentului (MSS), care diferă, de asemenea, de la sistemul de operare la sistemul de operare.

Snippet de mai jos face parte dintr-un pachet generat de un sistem Windows. Rețineți ttl 127 valoarea pe ultima linie este setată la 127. Acest lucru se datorează faptului că TTL este exprimat în număr de „hamei”. De fiecare dată când un pachet traversează un dispozitiv, cum ar fi un router, TTL-ul său este decrementat de unul. În acest caz, TTL a început de la 128, dar de când l-am capturat pe router - după un hop - acum este 127. Cu toate acestea, pot încă să spun că nu a fost niciodată 64, deci este probabil un pachet creat pe un sistem Windows.

08: 08: 51.657495 IP (tos 0x0, ttl 64, id 32150, offset 0, steaguri [DF], proto UDP (17), lungime 177)
google-public-dns-a.google.com.domain > 192.168.2.139.59414: 40501 3/0/0 cdn-3.convertexperiments.com. CNAME cdn-3.convertexperiments.com.edgekey.net., Cdn-3.convertexperiments.com.edgekey.net. CNAME e5289.g.akamaiedge.net., E5289.g.akamaiedge.net. A 104.94.35.212 (149)
08: 08: 51.659278 IP (tos 0x0, ttl 127, id 3890, offset 0, steaguri [DF], proto TCP (6), lungime 52)

Un pachet capturat de pe o mașină Linux are un TTL de 63 după primul salt. Acest lucru se datorează faptului că majoritatea aparatelor Linux setează valoarea inițială a pachetului TTL pe 64.

08: 15: 55.913493 IP (tos 0x0, ttl 63, id 41443, offset 0, steaguri [DF], proto UDP (17), lungime 56)
192.168.2.139.48635 > rezolvare1.ihgip.net.domain: 47200+ A? google.com. (28)

Dar, ce? De ce poate fi important să știm ce sistem de operare a creat un pachet?

Dacă un observator are cunoștințe de specialitate despre o țintă, aceasta poate conta foarte mult. Dacă se știe că ținta folosește Windows - poate ca membru al organizației mari care folosește Windows în tot -, dar pachetele capturate din acea țintă arată că probabil au fost create pe o mașină Linux, acesta este un indicator bun că VPN sau proxy al unora genul este folosit. Merită menționat că practic toate serverele VPN sunt rulate pe servere Linux sau Unix.

Este posibil să ajustați parametrii pachetului pe majoritatea sistemelor, dar foarte puțini utilizează această lungime.

Tehnici insuficiente de obstrucție de la furnizorii de VPN

Analiza rețelei este mai multă decât colectarea de pachete. Procesele auxiliare precum DNS pot juca un rol. Mulți utilizatori VPN sunt conștienți de DNS, deoarece trimiterea de întrebări DNS în mod clar este o modalitate prin care un observator poate determina unde vizitați sau urmează să îl vizitați. Cu toate acestea, mai puțini utilizatori sunt conștienți de DNS invers (rDNS). La fel ca DNS asociază un nume de domeniu la o adresă IP, rDNS asociază o adresă IP la un nume gazdă, iar numele de gazdă identifică de obicei proprietarul IP-ului. În plus, majoritatea bibliotecilor de programare și sistemelor de operare sunt livrate cu o versiune a funcțiilor standard gethostnameby * (), care extind capacitatea unui sistem de a asocia IP-uri și nume de gazdă.

DNS invers nu este la fel de critic ca DNS „normal”, deoarece rDNS nu joacă niciun rol în rutarea traficului. Mai degrabă, este utilizat în principal ca mijloc de identificare a proprietății IP. Doar proprietarul unei adrese IP îi poate asocia o înregistrare rDNS. Prin urmare, verificarea înregistrării rDNS a unei adrese IP oferă o asigurare rezonabilă cu privire la cine o deține, sau cel puțin, cine este proprietarul care vrea să crezi că o deține. Rețineți că rDNS nu este necesar și multe adrese IP nu au deloc intrări rDNS.

Să ne uităm la exemplul domeniului facebook.com. DNS O înregistrare furnizată de o interogare DNS standard arată această adresă IP:

$ dig + scurt facebook.com
31.13.67.35

Acum să folosim o interogare DNS inversă sau funcția gethostnamebyaddr () pentru a vedea cine deține acel IP:

$ gazdă -n 31.13.67.35
35.67.13.31.in-addr.arpa nume de domeniu pointer edge-star-mini-shv-01-mia3.facebook.com

Putem vedea de aici că Facebook deține de fapt acea adresă IP. Cu toate acestea, majoritatea site-urilor nu dețin propriile IP; acestea sunt închiriate și aparțin unor organizații arbitrare sau poate deținute de entități mai puțin evidente. Amazon este un exemplu de mare furnizor de calcul care este folosit de multe companii. O interogare rDNS pentru adresa IP a multor servicii de internet arată pur și simplu că Amazon deține IP-ul și, prin urmare, informațiile sunt de mică utilitate pentru a determina cine operează IP-ul. Un alt exemplu este Google. Google este ceva mai subtil în intrările sale rDNS, dar păstrează în continuare informații despre proprietate. Iată cum arată DNS invers pentru un IP Google:

$ dig + google.com scurt
216.58.207.46

$ gazdă -n 216.58.207.46
46.207.58.216.in-addr.arpa pointer nume de domeniu fra16s24-in-f14.1e100.net.

Google deține domeniul 1e100.net, astfel încât putem vedea că acest IP aparține de fapt Google.

În lumea VPN-urilor, instrumentele de rezoluție a adreselor pot fi utilizate pentru a vedea dacă IP-ul pentru care traficul dvs. este destinat aparține unei VPN. De exemplu, o comandă implicită tcpdump pe routerul OpenWRT va încerca să rezolve IP-urile pe care le vede în pachetele TCP. Pare să folosească în primul rând gethostbyaddress () pentru a face acest lucru și, prin urmare, este posibil, uneori, să vedem unde sunt destinate pachetele. O captură tcpdump implicită a unei sesiuni IPVanish ilustrează acest lucru:

08: 23: 14.485768 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, lungime 1441
08: 23: 14.485847 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, lungime 1441
08: 23: 14.486144 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, lungime 1441
08: 23: 14.486186 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, lungime 385

Clientul IPVanish pentru Windows oferă trei configurații: o conexiune standard OpenVPN, o conexiune OpenVPN folosind HTTPS și o conexiune nefuscată.

ipvanish-vpn-OpenVPN-mode

Pachetele de mai sus au fost capturate în timpul unei sesiuni folosind setarea de conexiune OpenVPN ofuscată, cu toate acestea, WireShark este încă capabil să furnizeze informații despre destinație.

În concluzie

La determinarea utilizării VPN, există foarte puține „gloanțe de argint”. De obicei, este nevoie de o serie de tehnici sau observații pentru a compila suficienți indicatori care indică faptul că un VPN este în uz și chiar atunci poate fi greu să fie 100% sigur. Companiile care au un interes de a nu permite utilizarea VPN, cum ar fi Netflix și alte servicii de streaming, au echipe cu normă întreagă dedicate doar acestei probleme. În alte cazuri, multe țări din Europa de Est și Orientul Mijlociu) interzic utilizarea VPN și au echipe similare pentru a elimina utilizatorii VPN.

Brayan Jackson
Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me

About the author

Leave a Reply

Your email address will not be published. Required fields are marked *

83 − = 78

Adblock
detector