22.10.2019 13:37
OlegON
 
Цитата:
FinSoft !<ip адрес>, <порт>, <имя каталога на удаленном компьютере>
Я бы категорически отсоветовал бы использовать в протоколе загрузки имя каталога. Первое, что пришло в голову - кто-то обязательно проверит что-нибудь вроде
Код:
<ip адрес>, <порт>, <%WINDIR%\>
или просто
Код:
<ip адрес>, <порт>, <..\..\>
на мой взгляд куда правильнее передавать какой-нибудь индекс уже заданного в конфиге на удаленной стороне каталога.
22.10.2019 13:49
FinSoft
 
Олег, не совсем понял, что значит "проверит"?
22.10.2019 19:49
OlegON
 
Я имею ввиду, что кто-то обнаружит точку входа для протокола и попробует это взломать. Т.е. проверит вариант с такими директориями, а именно - попробует через права того сервиса, который уже работает на машине, достать до чувствительных для системы данных.
22.10.2019 20:44
FinSoft
 
Ммм... У этого сервиса есть только копирование файлов и вызов некоторых функций, зашитых в специально прилагаемой dll. Копирует прикладное приложение через специальную библиотеку. Формат обмена не стандартный. Настройка каталогов обмена на сервере с ограниченными правами.

Я сейчас попробовал ради интереса в системные каталоги удаленно записать файлики, винда блокирует. Да нет, там все так построено, что что-то сломать (не говоря уж о взломать) настолько маловероятно, что можно принебречь.
22.10.2019 20:55
OlegON
 
Вот мы так навскидку и блокирует, а кто-то посидит, подумает, и "ой"... Смотри сам, конечно... Я всегда исхожу из того, что если есть подозрение на дырку, то надо подлатать...
22.10.2019 21:27
FinSoft
 
Копирование файлов в данном случае функция системной библиотеки. Я и при желании не могу передавать ей что-то, кроме имени файла.

Чтобы запустить процесс копирования, надо специфическими знаниями обладать. Это не стандартная утилита с известными ключиками, типа curl. Копирование инициируется прикладной системой и закрыто от конечного пользователя.
22.10.2019 21:36
OlegON
 
Цитата:
FinSoft надо специфическими знаниями обладать
Боюсь, что если системная библиотека, то это самба какая-нибудь... или что-то другое, что на просвет раскрывается каким-то сниффером.
Просто, как факт, у меня тут десяток раз в минуту что-то ищут и подбирают, нельзя недооценивать.
Спорить не буду, если интересно - можем подумать, как спрятать, если хочешь оставить, как есть - твой выбор.
22.10.2019 22:11
FinSoft
 
Нет, это разработка одной забугорной конторы, которая использует напрямую сокеты (win api).

Ты хочешь сказать, что можно чем-то перехватить передаваемые сообщения и имитировать их каким-то внешнем софтом? Теоретически это возможно, но опять таки, настолько маловероятно... Я когда-то пробовал обмениваться с этим удаленным сервисом в обход библиотеки (читая порт из php), потом забил. Там не просто строки передаются, а какой-то специфичный формат со служебными символами.

В принципе, там еще можно штатно openSSL задействовать. Или фильтрацию по ip адресам на роутере. Или vpn. Или сильно зажать права доступа на удаленном компе. Если по безопасности очень заморачиваться. Но это уже не мои вопросы.
23.10.2019 07:32
OlegON
 
Цитата:
FinSoft перехватить передаваемые сообщения и имитировать их каким-то внешнем софтом
да, просто подключить ту же библиотеку, что и ты. и openssl тут не спасет. фильтрация по адресам и прочее подразумевает достаточно грамотных спецов на месте, чего, я полагаю, по факту не случается. а, как факт, дырка есть... и закрывается она очень легко (должна по крайней мере).
сейчас шлется типа <директория><данные> -> <удаленный узел>-‎∞ (пишу, куда хочу)
а надо сделать <индекс><данные> -> <удаленный узел>-‎<индекс>-<заранее заданная директория>
т.е., получается, снаружи в принципе нельзя выбирать, куда писать данные.
23.10.2019 08:59
FinSoft
 
Имя файла явно передается библиотеке, работающей на локальном компьютере. В каком виде она передает его сервису на удаленном компьютере, вопрос другой. Разумно, что не в виде открытой строки, а применяет какой-либо алгоритм шифрации. Я не проверял за ненадобностью.

Если библиотека используется, то там возможность копирования файлов встроенная и мы не можем обойти логику ее работы.

Чтобы причинить вред удаленному компьютеру, предполагается:
1. На удаленном компьютере можно читать и писать критичные для работы системные файлы. Что, в общем, не соответствует действительности.
2. Не организована защита канала внешними средствами.
3. Найти специалиста, который обладает специфическими знаниями и имеет нужную версию библиотеки и компилятора.
4. Получить каким-то способом реквизиты подключения.

Даже если чисто теоретически предположить, что удалось убить удаленный компьютер, восстановить его работоспособность несопоставимо менее затратно, серьезных проблем бизнесу это не создаст (речь не про сервер), а хакер получит разве что моральное удовлетворение.

Вероятность того, что сдохнет железо на удаленном компьютере, похоронив локальные данные о текущей кассовой смене (которые есть в офд), гораздо выше.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.