Како утврдити коју адресу FTP сервер заиста бележи

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

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

1. Утврдите о којој вези питате

FTP користи две везе. Контролна веза преноси команде и одговоре, а веза података преноси саму датотеку. Догађај пријаве припада првој, догађај преноса другој, па једна сесија у дневнику може садржати запажања са два различита мрежна пута. Запишите којем догађају припада поље адресе пре него што из њега изведете закључке.

Та подела има практичну последицу. Линија пријаве и линија преноса из исте сесије могу носити две различите изворне адресе, па навођење било које као „адреса клијента” јесте нагађање о томе коју везу читате. Проверите тип догађаја пре него што адресу упарите са било чим.

2. Пратите контролну везу

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

Ако клијент заобилази тунел, сервер види приступну адресу, а сопствена адреса VPN интерфејса никада се не појављује на мрежи. Зато је адреса тунела лаптопа обично најмање корисна вредност на слици: постоји само унутар тунела. Користите ss или снимање пакета да потврдите извор који клијент представља, уместо да га читате са екрана конфигурације.

Две команде покривају већину:

ss -tnp state established "( sport = :21 or dport = :21 )"
tcpdump -ni any tcp port 21

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

3. Проверите да ли се веза података поклапа

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

Пренос забележен са друге адресе од пријаве је стварно запажање, а не оштећен запис, и обично говори нешто о путу.

4. Затражите од оператера узак запис

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

Прочитајте стварну шему тог сервера уместо да претпостављате да сваки производ одвојено бележи оригиналног клијента, контролног партнера и партнера података, јер неки сажимају целу сесију у једну линију. Држите и протокол јасним: SFTP је протокол заснован на SSH, а не FTP на другом порту, а FTPS додаје TLS на FTP, па идентитет услуге у дневнику зависи од тога шта сте распоредили.

5. Проверите пре него што припишете

Излазна адреса може служити многим клијентима, а један налог може се користити са неколико дозвољених извора, па адреса и корисничко име не означавају исту јединицу. Евидентирање је политика сервера: VPN мења извор који веза представља, али не брише назив налога, назив датотеке или операцију коју је услуга прималац обрадила. Припишите само оно што запис показује, а остало означите као непознато. Опис FTP-а у WinSCP-у је сажет референс за модел две везе ако то треба некоме објаснити.

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