Блог вопиющего в пустыне
Наступил 2020 год и с ним в наш реальный мир пришла очередная виртуальная "пандемия", связанная с усилением защиты передачи данных в сети Интернет. Так как у меня уже года три как на платформе Windows Server 2008 R2 работает мой сайт, поддался и я этому психозу, и решил включить на сервере протокол TLS 1.2, а заодно проверить, какие у меня на сервере есть устаревшие протоколы передачи данных (SSL), от которых в обозримом будущем, продвинутые в этом направлении браузеры, будут шарахаться как "черти от ладана".
Как-то обратился ко мне за помощью сотрудник одного ООО (очень малого предприятия), которое выиграло конкурс и последующие торги, проводимые одним довольно солидным, в их представлении, ПАО. Суть обращения была такова: заказчик прислал им письмо с просьбой предоставить в адрес организатора закупки документы, которые по совершенно аналогичной прошлогодней выигранной закупке не требовались, в связи с чем они проштудировали закупочную документацию, но так и не смогли уяснить, на чем основано это довольно неожиданное требование. Поэтому необходимо было ещё раз очень скрупулёзно проанализировать все документы, входящие в закупочную документацию и дать юридическую оценку обоснованности этих требований. Ну что-ж, проанализировал. И вот какая "картина маслом"получилась...
Или сказ о том, как упрямый абонент пытался объяснить "специалистам" «Скорой абонентской» Tele2 очевидные вещи и вернуть незаконно "уведенные" с его счета деньги
Краткая предыстория. В августе 2018 года ко мне обратился знакомый пенсионер с просьбой помочь разобраться по поводу исчезновения с его мобильного счета денег (80 руб.) и последующего появления за этим непонятного долга в размере 340 руб. По данному случаю им уже было написано заявление в офисе Теле2, но т.к. ответ там обещали дать не ранее чем через 30 дней, то мы решили обратиться в техподдержку Теле2.
По просьбе пользователя стал настраивать синхронизацию рабочей папки, находящейся на его компьютере в конторе, с её копией, залитой предварительно ко мне на сервер. Пользователь хотел, чтобы все действия, которые он производил в течение дня у себя на компьютере в рабочих папках (удалял, добавлял, редактировал файлы), соответственно вносились в их копии у меня на сервере. Синхронизацию запустил через Планировщик заданий. Но, когда стал проверять, то оказалось, что результат последнего запуска - (0x1)
Перенос контейнера закрытого ключа из RuToken в реестр
По решению данной проблемы «нарыл» в сети две рекомендации: 1) подключить Rutoken к той машине, с которой пытаются по RDP зайти на удаленный компьютер, и 2) на удалённой машине скопировать контейнер закрытого ключа из RuToken в реестр. Решил апробировать второй вариант, так как постоянно таскать токен туда-сюда не представлялось возможным.
По просьбе пользователя, который не хотел хранить разработанный им контент на офисном компьютере, сделал для него на своем сервере "облако": на базе IIS добавил FTP-сайт, закачал указанные папки, организовал доступ. Но в процессе работы пользователь попросил сменить логин и пароль на более удобные для его восприятия. Сделал, но...
В первых числах февраля в логах файрвола стали пачками сыпаться странные запросы к веб-серверу, на котором установлен мой сайт. Необычным в этих запросах было то, что в корне сайта искали zip-архивы, а обращение к сайту шло не по ip-адресу, который традиционные "дыроискатели", как правило, использовали для подключения, а по его доменному имени.
При заходе на электронную торговую площадку (ЭТП) браузер выдал: "У вас нет действующих сертификатов"
Ситуация сложилась таким образом, что участнику торгов на электронной площадке необходимо было подать своё ценовое предложение как можно ближе к окончанию торгов. Но, так как рабочий день был сокращенный и контора закрывалась намного раньше, то решено было подключиться к рабочему компьютеру удаленно (из дома), благо обе машины были предварительно введены в VPN-сеть через мой VPN-сервер.