Maximus43

Nodeca

Могу только предположить, что 94.242.7.157 резолвится как mail.da.am, а письма идут от имени bannerd.ru. Это хоть и один и тот же IP, но обратный ДНС тоже принимается во внимание. Пропишите обратную зону для 94.242.7.157 как bannerd.ru и посмотрите на результат.

Мой вариант, возможно не самый оптимальный, так как RDP не копал глубоко.
Если клиентская часть Windows 7 и выше, то берется USB token с сертификатом (EKU Client Auth, UPN содержит какое-то значение), настраивается IPSec VPN c авторизацией по EAP-SSL. Автоматом ничего подниматься не будет, но можно создать ярлык на рабочем столе пользователя.

Похоже на рекламу, а не на вопрос.
Мой личный опыт: закрытые репозитарии на GitHub, на кластере сервера Jenkins с развертыванием на тестовые и боевые сервера из разных веток гитхаба. 7 баксов в месяц — адекватная цена для создания закрытых репозитариев на гитхабе.

Если у вас есть цель написать собственные процедуры подписи данных и проверки подписи, тогда вы сами решаете, в каком формате вам хранить ключи. PEM это BASE64. Можно спокойно передавать по сети.
Обычно из публичного ключа все-таки делают сертификат, хотя-бы самоподписанный. И далее включают в проект необходимые PKI библиотеки.

Честно говоря, я так и не понял суть. :-)
Понял, что вы собираетесь создать корневой ЦС в режиме Off-line root. Потом вы создаете промежуточный ЦС, подписанный корневым, и этим ЦС будете подписывать сертификаты конечных устройств. Или вы просто загрузите сертификат (публичный ключ) промежуточного ЦС на свои устройства, чтобы они, видимо, проверяли сертификаты конечных пользователей.
А вот дальше я совсем ничего не понял. Кто должен подписывать сертификаты? Сертификаты для кого? Что значит предыдущий УЦ?

Поставьте Soekris net6501 (http://soekris.com/products/net6501/net6501-30-board-case.html) и к нему точку доступа Wi-Fi. Можно воткнуть в виде платы mini-PCI, можно прикупить отдельное устройство и включить в Ethernet порт.
В коробочке 4 гигабитных порта, два USB (можно воткнуть 3G модем), операционная система pfSense на базе FreeBSD. Все ваши потребности покрываются с лихвой.
Если наличие гигабитных портов не принципиально, то берите решение ALIX.2D13 (http://www.pcengines.ch/alix2d13.htm)

>> Коммуникация с базой (Linux; Qt) осуществляется через радио. Требуемое растояние — 1200 м.

>Ого. Есть смысл подумать о ДВС, аккумулятор такое долго не потянет.

Не слушайте этот совет.
ДВС квадрокоптеров не бывает. Летать FPV на ДВС вертолете — это жесть и экстрим.
1200 метров отлететь от базы на квадрике вполне реально, это пара минут в одну сторону. Хорошо сбалансированный по всем параметрам квадрокоптер спокойно летает 10 минут с полной нагрузкой.

>> Система авто-балансировки не дает квадрокоптеру перевернуться и упасть в штопор.
Вот такие штуки программировать будет интересно.

Эти штуки уже реализованы в прошивках. Называется «система стабилизации». Без нее квадрокоптер не полетит.

По теме: посмотрите в сторону проекта OpenPilot. Там есть все, что требуется.

У нас есть специально обученный человек, в должности офицера по безопасности (Security Officer), который регулярно проходит по рабочим местам и смотрит на незакрытые сессии, пароли на бумажках и т.д. Если найдет компьютер без надзора с отрытым доступом или бумажки с паролями, то он открывает почту с компьютера сотрудника и пишет что-либо от его имени. На первый раз это может быть рассылка всем сотрудникам сообщения типа: «Я самый крутой, а вы все лохи». Типа шутка такая, но действует на 99%. Если же человек попался во второй раз (у нас было всего один раз), то безопасник пишет с компьютера сотрудника письмо в отдел кадров с просьбой перенести отпуск на конец ноября. Третьего раза у нас не было. :-)

Один таймслот в E1 — это 64 кБит/с. Вы можете по нему пустить голос, а можете испрользовать для сигнального трафика. В идеале 1 тайм-слот — это одно соединение, не важно в какую сторону.

Вам нужен собственный NS. Можно купить такую услугу у того же hetzner. Прописываете все свои домены на собственном NS и потом меняете адрес NS у регистратора на свой. Надеюсь, доступ к панели регистратора у вас остался.
При грамотном подходе все делается за полчаса.

У вас уже состояние такое, что кроме операции ничего не поможет. Если вы, конечно, хотите вернуть нормальное зрение, а не изменить -6 на -5. Упражнения и отдых при таком сильном минусе уже не помогут, увы.
Я в 32 года сделал операцию по техноогии cTEN. Было -1 и -1.5. Сейчас уже три года стабильная единица на оба глаза. Нагрузка по 10 часов в день за компьютером. Об операции не жалею и вам советую.

Как я понял, все упирается в дисковую подсистему, так? Тогда сам сервер менять особого смысла нет, дайте SQL серверу больше ОЗУ для работы и ставьте быстрый RAID10 из SAS 15k или SSD. Держать базу в продакшене на одном диске — это нонсенс. Вообще желательно ставить два сервера баз данных в режиме репликации.
Если есть бюджет 15к, то я бы на вашем месте купил подержанный HP DL380 G5 с контроллером 405162-B21 и процессорами E5460 или выше, 32GB RAM, плюс шесть новых SAS 300G 15k, поставил бы его вторым сервером в режиме репликации, перенес бы базу, переключил на нее пользователей и потом поставил бы такие же SAS диски на основной сервер. Потом все переключил бы обратно, а купленный сервер настроил бы на stand-by.

Ответ написан каким-то недоучившимся школяром, и по грамматике, и по содержанию. Серьезные люди с реальными адвокатами совсем иначе пишут. Вывод: просто забыть, все последующие письма с этого адреса отправлять в спам.

Немножко покоробила терминология в ТЗ, а именно:
п.2. — серверный сертификат, как и любой сертификат, не может содержать закрытый ключ, так что извлекать там нечего. Пара ключей может содержаться в файлах p12, pfx или в отдельных файлах в формате PEM или DER. Сертификат — это всего навсего отрытый ключ плюс метадата и все это подписано закрытым ключом центра сертификации. Или может речь идет о брутфорсе закрытого ключа по открытому ключу? :-)
п. 3. — В HTTPS сертификаты используются для создания симметричного сессионного ключа, далее весь трафик шифруется этим ключом. Сессионный ключ может меняться несколько раз за время сессии. Поэтому требование использовать предоставленные сертификаты для вычленения HTTP из HTTPS для меня звучит странно. Тут надо слушать процесс генерации сессионного ключа и уже потом дешифровать трафик этим ключом.

ТЗ писал какой-то дилетант, IMHO

Может провайдер проксирует трафик хитрым способом и их настройки не поддерживают TLS 1.1? Насколько я знаю, Гугл один из немногих, кто включил поддержку TLS 1.1 для защищенного трафика, и ограниченное количество браузеров используют его. Safari и Chrome в этом списке.