Шта је ССХ и како функционише?

Шта је ССХ шифрирање и како то функционише

Сецуре Схелл (ССХ) је заједнички имплементирани сигурносни протокол са низом различитих употреба. Његова најпознатија апликација омогућава корисницима да сигуран приступ удаљеним рачунарима и серверима, али може се користити и за тунелирање, прослеђивање портова, безбедан пренос датотека и још много тога.

У овом водичу ћемо описати шта је ССХ, за шта се користи, историја протокола, његови технички детаљи, као и сигурносна питања које треба узети у обзир.

ССХ чине три одвојена протокола: транспортни слој, слој за потврду идентитета и слој везе. Заједно, они служе за аутентификацију друге стране у вези, пружају поверљивост шифровањем и проверавају интегритет података. ССХ се сада најчешће имплементира као власнички ССХ-2 или као итерација отвореног кода, ОпенССХ.

Примене ССХ

ССХ је свестран протокол. Његова структура и сигурносне карактеристике омогућавају да се користи на бројне начине, као што су даљински приступ, просљеђивање портова, тунелирање и сигурни пријенос датотека.

Даљински приступ

Удаљени приступ корисницима омогућава начин пријавите се на други рачунар или сервер са сопствене машине. Користи се за приступ локалним датотекама циљане машине или обављање услуга на њему, а све без физичког физичког боравка.

Програми попут Телнета и рлогина такође имају ову функцију, али им недостају безбедносне карактеристике ССХ-а. Мере шифровања и аутентификације укључене у ССХ омогућавају корисницима да се заштите на други сервер или рачунар на заштићен начин, чак и преко потенцијално опасне посредничке мреже.

Удаљени приступ са ССХ обично се спроводи тако да запослени могу радити на даљину или да би ИТ одељењу омогућили да обављају задатке, а да не морају физички да иду до машине. Може се користити за даљинску администрацију, управљање мрежном инфраструктуром, за подешавање аутоматизације, прављење резервних копија и још много тога.

Порт форвардинг

Прослеђивање порта користи се за преношење захтева са једне адресе и броја порта у други скуп. Примјењује превођење мрежне адресе (НАТ) на преусмјеравање портова између локалне мреже и удаљеног рачунара, омогућујући вам приступ уређају изван мреже.

Прослеђивање порта може се извршити на три различита начина:

  • Локално прослеђивање порта - Преусмеравање локалних портова омогућава вам да повежете локалног клијента и спољну мрежу. Може бити ефикасно за радње попут приступа веб локацијама које су локално блокиране или за повезивање са базом података која се налази иза фиревалл-а..
  • Даљинско прослеђивање портова - Ова врста прослеђивања омогућава апликацијама на страни сервера приступ услугама на страни клијента. ССХ даљинско прослеђивање портова омогућава корисницима да се сигурно повезују на удаљене сервере преко локалног рачунара преусмеравањем локалног порта на удаљени ССХ сервер.
  • Динамично прослеђивање порта - Ово омогућава корисницима да своје податке преко одређеног порта шаљу на удаљени рачунар или сервер помоћу одређеног броја ССХ сервера који делују као посредници.

Тунелинг

ссх-2

Протоколи за тунелирање користе енкапсулацију за премјештање података између мрежа. Тунели се могу распоредити како би се дозволило да се нетични протоколи крећу кроз мреже које их обично не подржавају. Друга уобичајена употреба је за обезбеђивање сигурности преко несигурне мреже.

Протоколи тунелирања критичне пакете омотавају унутар корисног оптерећења другог пакета. ССХ тунелирање омогућава корисницима да заобиђу мрежну безбедност, повежу уређаје који користе протокол не-матичне мреже и заштите податке који се преносе. Они се често користе за повезивање удаљених корисника са мрежним ресурсима њихове организације на сигуран начин.

СФТП

ССХ протокол преноса датотека (ФТП), понекад познат и као протокол сигурног преноса датотека, пружа сигуран начин приступа, преноса и управљања датотекама. То је сигурна алтернатива ФТП-у и користи ССХ протокол да безбедно шаље, прима и администрира датотеке.

СЦП

Протокол сигурне копије (СЦП) је сличан СФТП-у, али је ограничен у свом обиму. Омогућава само безбедан пренос датотека, а не читав низ функција које омогућавају СФТП да делује као протокол удаљеног датотечног система.

Платформе & апликације које користе ССХ

Власнички ССХ или ОпенССХ могу се користити на свим главним оперативним системима. Доступан је на Уник платформама попут ОпенБСД, мацОС, Линук и Соларис, док Виндовс корисници могу да користе ССХ путем ПоверСхелл-а.

Историја ССХ

ССХ је развијен на Техничком универзитету у Хелсинкију 1995. године Тату Илонен као одговор на напад њушкања лозинком на мрежу универзитета. Желео је да обезбеди алтернативу протоколима попут ФТП, ТЕЛНЕТ, рсх и рлогин, који није осигурао поверљивост или потврдио аутентичност корисника на сигуран начин.

ССХ је пуштен у јавност 1995. године и био је добро прихваћен. Усред свог брзог усвајања, Илонен је крајем исте године основао ССХ Цоммуницатионс Сецурити како би наставио развој и комерцијализовао ССХ.

Илонен је 1995. године такође објавио Интернет нацрт Интернет Инжењерске радне групе (ИЕТФ) документовао ССХ-1 протокол. Ограничења су убрзо пронађена у протоколу и њих није било могуће решити без утицаја на компатибилност уназад. Решење је била нова верзија протокола, а ССХ-2 је лансирала Илоненова компанија 1996. године.

ССХ-2 је представио нове алгоритме, због чега је ИЕТФ основао радну групу која је имала за циљ стандардизацију протокола. Група је добила надимак СЕЦСХ, због Сецуре Схелл, а свој први интернет нацрт за ССХ-2 објавио је 1997. године.

Софтвер за ССХ-2 објављен је 1998. године, али није одмах усвојен на широко распрострањен начин због рестриктивнијег лиценцирања. ИЕТФ је 2006. године измијенио верзију протокола као стандард. Ово је било сигурније, коришћењем кодова за потврду идентитета порука за проверу интегритета и разменом кључева Диффие-Хеллман за аутентификацију.

Године 1999. пројекат ОпенБСД објавио је ОпенССХ. ОпенССХ је бесплатна верзија протокола која се заснива на модификацијама које је Бјорн Гронвалл направио у ССХ 1.1.12. Програмери су се вратили на ову старију верзију и увелико су је изменили јер је последња верзија ССХ-а била потпуно отворени извор. ОпенССХ је сада најчешће коришћена опција и од тада се имплементира у низ оперативних система, као што су Виндовс, мацОС, Линук, Соларис и други.

ССХ-1 вс ССХ-2 вс ОпенССХ

Као што је горе поменуто, ССХ-1 је прва верзија протокола, која је првобитно објављена под лиценца отвореног кода. Сматра се несигурним и не би га требало проводити. Власничка верзија, ССХ-2, и слободно доступна верзија, ОпенССХ, остају као одрживе алтернативе.

ССХ-2 и ОпенССХ су у основи исти када је реч о њиховој архитектури и начину на који раде. Главна разлика је у томе што власничка верзија долази са широким опцијама подршке, док се оне које користе ОпенССХ морају ослонити на ресурсе које заједница ствара слободно..

ССХ: Технички детаљи

ССХ-1 је функционисао као један протокол, али овде нећемо улазити у њега јер је застарео. Уместо тога, фокусираћемо се на ССХ-2 и ОпенССХ, који се састоје од три одвојена протокола:

  • Транспортни протокол - Ово успоставља везу и пружа основну сигурност.
  • Протокол аутентификације - Овај слој се користи за аутентификацију клијента.
  • Протокол веза - Овај протокол обрађује канале преко којих се подаци преносе.

Сваки од ових протокола служи јединствену улогу која делује на успостављању и обезбеђивању везе, аутентификацији друге стране и преносу података. Подразумевани прикључак ТЦП везе је 22, а везе су постављене између ССХ клијента и ССХ сервера дуж модел клијент-сервер.

Процес даљинског пријављивања ССХ одвија се према следећој основној структури (са варијацијама зависно од конфигурације), о чему ћемо детаљније говорити касније:

  • Клијент контактира ССХ сервер да би започео везу.
  • Затим сервер шаље свој јавни кључ клијенту да потврди његов идентитет.
  • Двије стране договарају параметре за везу, а затим успостављају сигуран канал дуж тих линија.
  • Тада се корисник пријављује у оперативни систем послужитеља и сада може даљинско администрирати своје задатке.

Транспортни протокол

Транспортни слој је протокол ниског нивоа који води рачуна о следећим задацима.

  • Провјера идентитета главног рачунала
  • Размена кључева
  • Шифрирање за поверљивост података
  • Провера интегритета ради провере да подаци нису измењени
  • Успостављање ИД-а сесије који се може користити у осталим протоколима

Тхе транспортни протокол потврђује само сервер, а не клијента (аутентификација клијента се врши у протоколу за аутентификацију ако је неопходан).

У транспортном слоју, клијент покреће везу, а затим две стране договарају како ће се кључеви размењивати, који алгоритам јавног кључа ће се користити, који шифри са симетричним кључем ће шифровати податке, који алгоритам провере идентитета поруке ће се користити да бисте проверили податке и која метода компресије (ако постоји) ће се применити.

Једном када веза крене, и сервер и клијент морају послати идентификациони низ, који укључује верзију протокола (2.0).

Преговарање о алгоритму

Да бисте поставили параметре везе, обе стране шаљу кроз пакет који садржи листу са следећим опцијама:

бајт ССХ_МСГ_КЕКСИНИТ

бите [16] колачић (случајни бајтови)
списак имена кек_алгоритхмс
списак имена сервер_хост_кеи_алгоритхмс
списак имена енцриптион_алгоритхмс_цлиент_то_сервер
наме-лист енцриптион_алгоритхмс_сервер_то_цлиент
списак имена мац_алгоритхмс_цлиент_то_сервер
списак имена мац_алгоритхмс_сервер_то_цлиент
списак имена цомпрессион_алгоритхмс_цлиент_то_сервер
списак имена цомпрессион_алгоритхмс_сервер_то_цлиент
списак имена лангуагес_цлиент_то_сервер
списак имена лангуагес_сервер_то_цлиент
боолеан фирст_кек_пацкет_фоллов
уинт32 0 (резервисано за будуће проширење)

Свака страна наводи параметре које су спремни да прихвате у вези, одвојене зарезима. Преферирани алгоритам треба прво навести.

За размена кључева (кек_алгоритхмс), први алгоритам који обе стране подржавају ће бити изабран за везу (могу бити и други фактори које је потребно испунити, у зависности од тога који је алгоритам изабран). Ако две стране не могу наћи међусобно подржани алгоритам који удовољава овим захтевима, тада веза не успева.

Алгоритми кључа главног сервера јесу подржани алгоритми за кључ главног сервера. Сервер поставља алгоритме за које има кључеве хоста, док клијент одређује алгоритме које је спреман да прихвати. Избор ће овисити о томе да ли метода размјене кључева која је ријешена захтијева кључ хоста који може да шифрира или дигитални потпис

Обе стране су на листи алгоритми симетричних кључева да су спремни да прихвате, са пожељним методама на врху. Прва опција која се појављује на листи клијента која се такође налази на листи сервера мора се користити. Ако се не може постићи никакав договор, веза не успева.

Оба МАЦ алгоритам и тхе алгоритам компресије преговарају се на исти начин.

Размена кључева

Одговорна је размена кључева аутентификација сервера, и то поставља кључеве који ће се користити за осигурање везе у следећим корацима. Обично започиње са странама које међусобно шаљу листе подржаних алгоритама. Алтернативно, свака страна може погодити жељени алгоритам друге стране и на почетку послати пакет који одговара параметрима тог алгоритма..

Ако је погодак једне стране тачан, тај се пакет користи као први пакет за размену кључева. Ако ниједно претпостављање није тачно, свака страна мора да направи корак унапред и пошаље своје листе пожељних алгоритама. Ако порука о размени кључа укључује дигитални потпис сервера као доказ легитимности сервера, сматра се експлицитна аутентификација сервера. Ако умјесто тога користи заједничку тајну, помиње се као имплицитна аутентификација сервера.

Размјена кључева одговорна је и за успостављање заједничке тајне и хасх-а. Хасх вредност из иницијалне размене кључева постаје јединствени идентификатор сесије, а користи се и као део дигиталних потписа који доказују да је странка прави власник свог приватног кључа.

Хасх функција која ће се користити зависи од начина размене кључева за који се одлучи у преговорима. Када се размена кључева заврши, све будуће комуникације користиће нови сет кључева и алгоритама.

Према нацрту Интернета Интернет Инжењерске радне групе (ИЕТФ), следеће кључне методе размене сматрају се сигурним:

  • цурве25519-сха256
  • цурве448-сха512
  • диффие-хеллман-гроуп-екцханге-сха256
  • диффие-хеллман-гроуп14-сха256
  • диффие-хеллман-гроуп15-сха512
  • диффие-хеллман-гроуп16-сха512
  • диффие-хеллман-гроуп17-сха512
  • диффие-хеллман-гроуп18-сха512
  • ецдх-сха2-нистп256
  • ецдх-сха2-нистп384
  • гсс-гроуп14-сха256
  • гсс-гроуп15-сха512
  • гсс-гроуп16-сха512
  • гсс-гроуп17-сха512
  • гсс-група18-сха512
  • гсс-нистп256-сха256
  • гсс-нистп384-сха384
  • гсс-нистп521-сха512
  • гсс-цурве25519-сха256
  • гсс-цурве448-сха512
  • рса2048-сха256

Алгоритам кључа главног сервера

Ови алгоритми јавних кључева се користе за аутентификација сервера као и сигурно успостављање ИД-а дељене сесије. Такође се могу опционално користити за аутентификацију домаћина. ССХ је дизајниран за рад са низом алгоритама јавних кључева, типова и формата кодирања:

  • Користи алгоритме јавног кључа за шифровање и / или дигитални потпис.
  • Може се имплементирати низ метода кодирања, омогућавајући конфигурацију с различитим форматима података, редослиједом подметања и бајтова.
  • Различити формати тастера омогућавају кодирање кључева на различите начине, као и низ представки цертификата.

Подразумевани алгоритми укључују следеће, међутим постоје и неке друге варијације које се такође могу применити:

  • ссх-рса
  • ссх-рса-сха256
  • ссх-дсс
  • ссх-дсс-сха256
  • к509в3-сигн-дсс
  • к509в3-сигн-дсс-сха256
  • к509в3-сигн-рса
  • к509в3-знак-рса-сха256

Алгоритми за шифровање

Алгоритми симетричних кључева се користе за шифрирају податке и пружају поверљивост. Параметри и заједнички кључ који се користе у процесу шифрирања утврђују се у ранијим фазама везе. Одабрани алгоритам шифрира корисни терет, дужину пакета, дужину паддинга и поља за облагање.

Распон различитих алгоритама за шифровање прихваћен је у ССХ-у, али из безбедносних разлога најбоље је држати се АЕС-а. Кључеви требају да буду најмање 128-битни, али преферирају се већи тастери.

МАЦ алгоритми

Транспортни протокол потврђује интегритет података додавањем кода за потврду идентитета поруке (МАЦ) у пакет. Овај МАЦ заснован је на заједничкој тајни (која је успостављена у размени кључева), редном броју пакета и садржају пакета. Израчунава се пре него што се изврши шифровање.

Имплементације морају понудити независни алгоритам за покретање у сваком смјеру, иако је идеално ако се исти користи на обје стране. Може се имплементирати широк спектар алгоритама за потврђивање идентитета порука, међутим СХА-256 и новије верзије треба користити у већини ситуација да би се осигурао висок ниво сигурности.

Компресија

Компримирање није обавезно у ССХ протоколу и његове имплементације морају дозволити да се везе наставе без компресије. Компресија се може спровести само као опција, користећи схеме попут злиб. Ако се користи компресија, она утиче само на корисни терет. МАЦ и поље дужине пакета се затим израчунавају на основу компримованог корисног оптерећења.

Пакет протокола за транспорт

Пакет протокола за транспорт је форматиран тако да садржи следеће информације (као и неке мање релевантне детаље који су изостављени):

  • Дужина пакета
  • Дужина облоге
  • Корисни терет
  • Паддинг
  • Код за потврду идентитета поруке (МАЦ)

ссх-3

Протокол аутентификације

Овај протокол сервер користи за овери клијента. То може учинити са различитим механизмима, од којих се многи ослањају на ИД сесије утврђен у протоколу превоза. Неки користе провере шифрирања и интегритета из транспортног протокола заједно са ИД сесије, док други користе ове алгоритме сами.

Сервер користи своју локалну политику да одлучи које методе аутентификације прихвата од појединог корисника. Пошто је сервер већ проверен у протоколу транспорта, нема потребе да аутентификујете сервер још једном.

Сигурност протокола за потврду идентитета зависи од транспортног протокола преко којег се покреће. Ако протокол превоза не може гарантовати поверљивост или проверити интегритет података, то ограничава начин на који се протокол за оверу може сигурно користити.

На пример, ако се протоколом транспорта не примењује заштита интегритета, захтеви попут промене лозинке не смеју бити дозвољени, јер би то нападачима оставило могућност да варају податке без да се примете.

Протокол за провјеру аутентичности користи провјеру јавног кључа под претпоставком да ни приватни кључ главног рачунала, ни кључ клијентског рачунала нису угрожени.. Ако је сервер угрожен, то може довести до тога да се корисничко име и лозинка клијента ослободе нападачу.

Да би аутентификација на бази домаћина била сигурна, клијент не сме бити угрожен. Ако је то могућност, онда треба додати и друге методе аутентификације. Важно је то приметити процес аутентификације је само толико јак колико и најслабија метода размене коју сервер прихвата.

Процес протокола за потврду идентитета

Протокол провјере аутентичности започиње када сервер пошаље клијенту листу његових прихваћених метода провјере аутентичности. Клијент може изабрати између ових метода било којим редоследом. Овај процес даје контролу серверу, али исто тако омогућава довољну флексибилност тако да се клијент може договорити да користи најповољнију методу.

Најчешћи методи за аутентификацију клијента укључују:

  • Јавни кључ - Ова метода користи алгоритме као што су РСА, ДСА и ЕЦДСА за аутентификацију клијента путем криптографије јавног кључа. Неке имплементације такође користе к.509 цертификате. Сервер проверава дигитални потпис клијента на њиховом јавном кључу како би потврдио идентитет клијента.
  • Лозинка - Лозинке се такође могу користити за аутентификацију клијента. Клијент шаље своју лозинку (која би требало да буде шифрована транспортним протоколом). Ако се лозинка подудара са похрањеном вриједношћу сервера, она се прихвата и провјеравање идентитета се помиче напријед.
  • ГССАПИ - Према овој методи, спољне шеме као што је Керберос могу се користити за једнократну пријаву.
  • Типковница интерактивна - Ова техника омогућава једнократну аутентификацију лозинке тако што сервер тражи клијента за информације.

Протокол веза

Поставља се протокол за везу како ће се више канала канала комбиновати преко сигурног транспортног слоја. Такође се бави параметрима који се користе за приступ безбедним подсистемима на хост серверу, као и прослеђивањем проки-а и приступом шкољкама..

Протокол повезивања налази се на врху транспортног слоја и протокола за потврду идентитета. Омогућава даљинско извршавање наредби, као и прослеђене Кс11 и ТЦП / ИП везе. Ако је послужитељ или клијент угрожен, протокол везе није сигуран.

Канали

Канали су основне комуникацијске стазе и може их отворити било која страна. Канали могу да укључују терминалне сесије, прослеђене везе и друге видове комуникације. Када постоји више канала, они се мултиплексирају у једну везу.

Отварање канала

Сваки је канал означен са оба краја, мада се бројеви могу разликовати на обе стране. Када једна страна затражи отварање канала, шаље његов број канала као део поруке, као и информације о почетна величина прозора и тхе максимална величина пакета.

Почетна величина прозора показује колико података може примити странка која отвара канал. Ако треба послати више података, прозор се прво мора прилагодити. Исто тако, максимална величина пакета одређује колико велики пакет може да се прими.

Када једна страна захтева да се канал отвори, друга страна ће отворити канал ако може да га прими. Ако није, послаће се путем поруке о грешци. Канали се не могу отворити из следећих разлога:

  • Забрањена од стране администрације
  • Веза није успела
  • Непознат тип канала
  • Мањак ресурса

Ако било која страна везе жели да пошаље више података него што прозор тренутно дозвољава, могу послати поруку са захтевом за додавање више бајтова.

Затварање канала

Након што једна страна везе заврши пренос података, требала би послати поруку која означава да је завршила са коришћењем канала. Упркос томе, канал је и даље отворен, а податке и даље може слати друга страна. Ако странка жели у потпуности да прекине канал, то чини са засебном поруком о раскиду.

ССХ обезбеђење

Различите верзије ССХ-а имале су свака своја сигурносна питања, иако постојеће конфигурације ССХ-2 и ОпенССХ сматрају се далеко сигурнијима од ССХ-1.

ССХ-1

ССХ-1 се опћенито сматра мањкавим, с низом различитих рањивости. Они укључују грешку у ССХ 1.5 који је омогућио неовлашћеним корисницима да убаце садржај у ССХ ток података. Овај напад искористио је минималну заштиту интегритета података алгоритма ЦРЦ-32.

Овај напад је ублажен ССХ компензацијским нападачем који је интегрисан у већину новијих имплементација. До овог поправка је стигла нова рањивост, која је имала моћ извршавања произвољног кода са роот привилегијама.

Постоји и рањивост која омогућава противницима да измене последњи блок у сесији који користи ИДЕА-енкрипцију, као и онај који омогућава компромитованом серверу да проследи процес аутентификације клијента на други сервер.

Због ових безбедносних проблема требало би уместо њега користити ССХ-2. Да бисте имплементирали сигурност, требали бисте и ви онемогући поновно преговарање на ССХ-1, јер напади могу то искористити за приступ подацима путем слабијег нивоа заштите ССХ-1.

ССХ-2

ССХ-2 је рањив на теоријски напад на његов подразумевани начин шифровања, ЦБЦ. Омогућује нападачу да поврати до 32 бита отвореног текста из шифрованог блока. Ово се може ублажити коришћењем бројача (ЦТР) и претворбе блок шифре у шифру тока.

На крају 2014. Дер Спиегел је објавио документе НСА који су наговештавали да НСА понекад може сломити ССХ. Овај процуривани НСА ПоверПоинт каже да НСА може „Потенцијално опоравите корисничка имена и лозинке“, Мада нису дати даљњи детаљи. Није познато којим је методама агенција то радила, али мало је вероватно да ће се о својим могућностима лагати у сопственој интерној документацији.

У 2017. години је дошло до цурења Ваулт 7, то је откривено ЦИА је имала два алата која су могла да се користе за пресретање и крађу ССХ пријава и лозинки. БотханСпи је циљао Виндовс Кссхелл клијенте, док је Гирфалцон коришћен против ОпенССХ клијента на више различитих Линук дистрибуција.

Ови алати могу украсти акредитиве и потом их вратити на ЦИА сервер. Ниједан од ових напада не може прекршити сам протокол; они само користе друге нападе бочних канала који их могу заобићи у одређеним имплементацијама.

Упркос овим нападима, ССХ-2 се сматра сигурним у већини ситуација, под условом да се примени на одговарајући начин. Циљеви велике вредности или они који користе застареле или лоше имплементације требало би да размотре друге опције.

ОпенССХ

У ОпенССХ верзији 2, откривен је напад који је искористио слабост у ССХ бинарном пакету. Напад је омогућио истраживачима са Лондонског универзитета да поврате 14 бита отвореног текста из шифрованог блока. Ово је ублажено у издању 5.2 тако што је протокол прочитао неисправну дужину пакета или код за потврду поруке, уместо да прекине везу.

У верзијама 6.8 и 6.9, Линук би се могао користити за извршавање произвољних наредби на терминалима других корисника. То је постигнуто рањивошћу ескалације привилегија која је омогућила нападачима да убризгавају ликове помоћу ТИОЦСТИ контроле улаза / излаза.

Да ли је ССХ безбедан?

Иако се може чинити да ССХ има пуно сигурносних проблема, то је релативнои нормално да се у различитим имплементацијама протокола може наћи низ рањивости. То не значи да ССХ протокол није безбедан. Уместо тога, то само значи треба га правилно спровести.

Све док употребљавате било једно ССХ-2 или ОпенССХ и конфигуриран је на начин који је погодан за вашу употребу, требали бисте се осјећати поуздано у заштиту коју ССХ пружа вашој вези. Због тога је то и даље тако често кориштен протокол, посебно у сврху даљинског приступа и тунелирања.

Погледајте такође: Објашњени су уобичајени типови шифрирања

Позадина технологије цибер мреже аутор: ТхеДигиталАртист под лиценцом под ЦЦ0

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 *

67 − 57 =

Adblock
detector