Pull to refresh
1
0
Send message
необходимо расположить ТД разъёмами вверх или вбок (зависит от конструкции)

А как зависит? Как обывателю узнать вверх или вбок?

Схемы «Хорошее/Плохое расположение» плохо читаема (обывателем). Уберте всю технику, оставьте только роутер (да, и поменяйте «ТД» на «роутер», как выше предлагали)

… необходимо обеспечить расстояние [роутера] от стен на уровне, 20–30 см, исключение составляют лишь те устройства, которые рассчитаны на такую работу, и имеют штатную возможность крепления к стене

Нифига. В бытовых моделях монтажные отверстия появились не от того, что инженеры-проектировщики разрешили, а потому что маркетинг сказал «пиплу надо на стену вешать». К тому же есть вендоры, которые в разных корпусах продают одну начинку, соотв., один корпус будет с возможностью крепления на стену, а другой — допустим, tower.

Текст очень сухой, канцелярский, что-ли.

Картинку с каналами надо перевести. Не потому что импортозамещение, а потому что для обывателей.

Если уж заговорили про каналы, то надо сразу ссылку кинуть на приложения типа WiFi Analyzer, в которых можно посмотреть каналы.

Всё оформить в виде списка (чек-лист). Сейчас это, считай, один большой абзац, люди обычно такое не любят читать.

При наличии у ТД возможности конфигурации Basic Rates отключение поддержки наиболее медленных скоростей и старых стандартов значительно увеличит скорость работы сети

Вы попробуйте зайти в интерфейс своего роутера. Там есть регулятор скорости? Ну хотя бы галочка «В[ы]ключить поддержку медленных скоростей»? А переключатель стандартов (не «b/g/n/...», а «старые/новые»)?

Ну и в конце
Подробности, связанные с особенностями работы WI-FI можно прочитать по ссылке: habr.com/ru/post/509514

Нет, нельзя это прочитать по этой ссылке. По указанной ссылке статья, в которой больше написано "почему я сделал такую памятку и выложил её на хабр", чем "особенности работы Wi-Fi".

Версию и email лучше в конце, отделить пустым пространством и шрифт помельче. Этот текст не нужен обывателю. Сейчас он визуально так же важен, как и всё остальное
И? Вы хотите этой success story доказать, что перепады температуры, влажности, скачки напряжения, бытовая пыль, вибрации — вот это всё совсем никак не влияет на технику? А чего тогда в ЦОДах запариваются по этому поводу?

Я тоже видел сервак в кладовке. Он умер через 6 лет (не помню, материнка или бп, но заменить тогда было не так легко). А ещё видел самосбор, который пашет уже лет 12. Буду ли я на основании этих двух случаев всем рекомендовать самосборы? Нет, конечно.

Никто не говорил, что сервера менее надёжные, чем бытовые. Я писал, что в условиях серверной техника проживёт дольше.
Да, в курсе.
Я писал про то, что «атмосфера в офисе» не способствует длительной жизни любых компонентов.
И сервер, стоящий в кабинете рядом с обычным ПК, проживет значительно меньше своего аналога в серверной.
И ПК из «корпоративного сегмента» тоже дохнут быстрее, если допустить до них юзеров )
На самом деле, статью надо было бы назвать «Как НЕ надо собирать сервер...».
С самого начала у меня не было уверенности, что это 100% рабочее решение, так как на любом этапе, начиная со сборки заканчивая установкой, запуском и корректной работой приложений можно было застрять без возможности продолжить, поэтому про сервер я договорился, что его в течении пару дней можно будет вернуть, а другие компоненты можно использовать в альтернативном решении.

Отличная идея — сначала что-то купить, а потом проверять совместимость.
Посмотреть на сайте характеристики, compatibility list, спросить у вендора? Не, у нас так не принято. Давайте просто купим, если «не взлетит», то часть вернём (бухгалтерия такое любит, да), а оставшееся — используем в другом решении. Хаем игровые самосборы, потом покупаем не самое подходящее оборудование, «подгибаем что-то на сервере»…
В вашем случае — взлетело, но подход в целом — эникейский. Абзац про проблему с soft-режимом это только подтверждает.

Ладно хоть, программную часть как бы проверили перед покупкой (хотя, учитывая выделение жирным соответствующего упоминания в статье, есть сомнения):
Но проверить, что нужное нам ПО работает по RDP нужно в самом начале и сделать это просто: пробуем зайти по RDP — если программа запустилась и работают все базовые программные функции, то и проблем с лицензиями скорее всего не будет. А если выдает ошибку, то перед реализацией проекта с графическим терминальным сервером, ищем удовлетворительное для нас решение проблемы.

Если не было технических проблем при запуске, это ещё не значит, что «проблем с лицензиями не будет», впрочем, как и других проблем:
— Лицензии могут быть привязаны к кол-ву пользователей — тогда вы нарушаете лицензию.
— Софт может некорректно работать при нескольких запущенных инстансах — стоит ему хоть в одном месте писать мусор или настройки не в пользовательский профиль/%temp%, а в что-то общеедоступное — вам потом будет очень весело отлавливать проблему; сюда же озвученную выше проблему безопасности

Операционную систему (желательно Windows server 2019 — там качественный RDP) устанавливаем вначале в Trial режиме, но ни в коем случае не evaluate (нужно потом переустанавливать с нуля). И только после успешного запуска решаем вопросы с лицензиями и активируем ОС.

Вот тут я бы предложил другой вариант: после всех экспериментов с настройками — всё снести и поставить с нуля. Вот так:
— во время экспериментов надо документировать все критичные настройки
— во время установки с нуля вы повторно выполняете минимально необходимые настройки (которые задокументировали на предыдущем этапе)

Это решает несколько проблем. После чистой установки:
— вы точно знаете, что «оно работает» не из-за того, что вы перебрали несколько версий драйверов и какие-то из них «наследили» в системе (было, например, такое — в одной версии была галка в настройках, в следующей её убрали из интерфейса — но, поскольку предыдущая версия записала значение в реестр, то настройка применялась, хотя через интерфейс её отключить было невозможно )
— вы не забудете о какой-то настройке, которую включили в ходе экспериментов, но потом оставили (пример — решение проблемы soft-режима)
— вам не надо будет заново искать нестандартные решения (Clover)
Спустя какое-то время или сервер умрёт или надо будет мигрировать на новую версию ПО или развернуть ещё один сервер — у вас будет чёткий алгоритм, что надо сделать для восстановления (да, быстрее восстановить из бэкапа, но он не всегда применим).

Мне нередко приходилось принимать работу после эникейшиков, поверьте, это будет очень весело (на самом деле нет) — разбираться, почему не загрузился сервер после смерти флешки с Clover'ом, если не знать об этом костыле.
Сейчас у вас есть эта статья, неплохо бы оставить где-то рядом с сервером ссылку на неё, чтобы те, кому потом это обслуживать, знали хотя бы о назначении этой флешки или об отредактированных политиках.
А игровые мамки от силы работают 3-5 лет и даже процент поломки во время гарантийного срока у некоторых превышает 5%. А наш сервер от супернадежного бренда CISCO

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

Более того, если игровой (да любой, на самом деле) ПК убрать из офисного угла и поместить в серверную, где стабильные параметры окружающей среды (температура, влажность), гарантированное стабильное питание, да и просто более трепетное отношение к оборудованию — он вполне себе проживёт десятки лет.

Кстати, а какого года выпуска ваш сервер?
Извлечь, сграбить, рипнуть, спарсить, скрапить...

веб-лутинг
Так google как раз таки хранит реквизиты реальной карты. Но магазинам этот номер не отдает, а генерирует виртуальный номер для каждого платежа в магазине.

Да поправят меня более опытные хабраюзеры, ежели не прав, но это не совсем так. Номер виртуальной карты генерируется один раз при привязке карты, его должно быть видно в интерфейсе приложения и в чеках (в виде «номер карты ******1234»).
Если я правильно помню процесс, виртуальную карту генерирует тоже не гугл, а банк.
В момент привязки приложение «знает», что только что сгенерированную карту ****1234 надо привязать к физической карте ****5678, поэтому в приложении вы можете видеть часть номера физической карты, думая, что её данные хранятся в телефоне.

Но, возможно, это относится не к GooglePay, а к какому-то другому *Pay
Всё, что вы написали про карты — регулируется платежными системами, стандартами PCI DSS, банками. Например, Google не должен хранить реквизиты вашей реальной карты (но можно навыпускать виртуальных; или получить от банка-эмитента кучку одноразовых токенов для оплаты).

Авторизация пользователей — не регулируется никем. Сейчас мы можем только писать в комментариях «хотелось бы вот такую фишку...», но никто не обязан её реализовывать. Но если у кого-то это уже будет и все будут об этом говорить, тогда «отстающие» тоже реализуют (как это случилось с e2e шифрованием в мессенджерах).
Но всё равно останется необходимость передавать какие-то данные о вас (см. постскриптум предыдущего комментария)
могу сказать, что мне легче и соответственно предпочтительнее регистрироваться на сервисе, который поддерживает аутентификацию от внешних сервисов: Google, MS, FB и т.д. Регистрироваться каждый раз с нуля просто лениво.

Меня несколько напрягает, когда моя реальная учетная запись уходит в какой-то левый магазин, в котором я регистрируюсь через свой аккаунт в соц сетях.

Это расплата за лень. За то, что вы перекладываете труд по регистрации на плечи интернет-магазина и стороннего сервиса авторизации — вы расплачиваетесь своими данными (магазин получает данные о вас, соцсеть — данные о том, что вы пользуетесь этим магазином).
Пока вы считаете, что это адекватная плата за «труд» ввести свой email и пароль (это минимум, конечно, некоторые сайты требуют ещё кучу данных, но их можно заполнить фейками) — пользуйтесь авторизацией через сторонние сервисы.

Приведу аналогию:
вы в оффлайн магазине покупаете холодильник. Вам нужна доставка, т.е., надо сообщить продавцу адрес и имя получателя. Вы можете:
1) самому написать ему адрес и имя
2) дать ему папку, в которой лежат: свидетельство о рождении, фото «с уголком», диплом, школьный альбом, записная книжка со списком друзей, дневник с записями о значимых событиях (поездки, праздники, мероприятия), фотки из отпуска, справка из ЖЭКа, телефон любовницы, копия трудовой… Продавец берёт это всё, выбирает среди этого то, что ему нужно (напомню, ему нужны адрес и имя; если речь не о холодильнике, а о продукции 18+, то ещё может глянуть на св-во о рождении). Вам ничего делать не надо (ну только таскать в магазины эту папку)

P.s. пример выдуманный, специально гипертрофирован и подогнан под ваши два комментария. Ни капли не против того, чтобы сторонние сервисы выдавали токены, которые нельзя было бы связать с основным аккаунтом, но:
— сайту обычно нужен не только токен, но ещё и имя; некоторым — возраст; ещё может понадобиться email для связи; кто-то подтягивает фото из соцсети; и т.д. Хотелось бы это контролировать, но полный контроль — это огромная простыня галочек, какие данные предоставлять сайту, она неудобна, поэтому, у кого это есть, отдают данные более-менее связными блоками (например, показать общую информацию / показать друзей / показать подписки / дать возможность писать друзьям / и т.д.), т.е., чтобы показать только имя — нужно разрешить ещё доступ к городу/дате рождения и т.д. В деталях могу ошибаться, поскольку стараюсь не пользоваться такими сервисами.
— я, как пользователь, не хочу знать, какая соцсеть сегодня выдаёт обезличенные токены, а какая — предоставляет доступ ко всем данным, да ещё и разрешает постить друзьям от моего имени. Мне не интересно в этом разбираться, я просто хочу зарегистрироваться на сайте «и чтобы без последствий».

А в организации, поскольку у нас… AD
Тут можно не продолжать )
Вы правы. Спасибо, что напомнили про приватный режим, совсем про него забыл.
Он действительно убирает проблему «хозяин компьютера уже зашел в свой аккаунт».

Осталась только проблема «Чтобы зайти на example.com, надо сначала авторизоваться в (условно) фейсбуке».
Дополню, почему это проблема для меня — поскольку к аккаунту соцсети или того же гугла уже привязано много других сервисов, то и пароли там немного сложнее, чем qwerty12345, и включена 2FA везде, где это возможно. Это обычно означает, что мне надо вспоминать сложный пароль или перепечатывать его из менеджера паролей (если он есть под рукой) и также тащиться за смартфоном (для 2FA).
Если смартфон уже есть поблизости, то обычно нет нужды заходить на example.com с чужого устройства, проще зайти сразу со смартфона.
Плюс тревожности добавляет тот факт, что я не могу гарантировать корректную работу приватного режима на чужом устройстве (необновлённый браузер, кривая реализация приватного режима, кастомные настройки, кастомная сборка браузера, фейковый браузер, прокси, кейлогеры, камера, направленная на клавиатуру и т.д.) и при этом должен вводить пароль от своего важного фейсбучного аккаунта только для того, чтобы попасть на какой-то левый example.com (доступ к которому мне может быть не жаль, пускай перехватывают)
Особенно весело пользоваться сайтами с авторизацией через сторонние сервисы на чужом компьютере.
Чтобы зайти на example.com, надо сначала авторизоваться в (условно) фейсбуке. Перед этим, наверняка, придётся деавторизовать хозяина этого компа, а после — выйти из фейсбука, выйти из example.com, да ещё и куки и кеш браузера потереть, если это не очень доверенный компьютер.
Как-то вы выборочно читали комментарий, если увидели в нём только авторизацию через соцсети. Например, первый абзац вы явно не заметили
Как и на любом сайте, контент для которого генерируют пользователи.
Вы же знаете, как переводятся последние два слова в названии домена githubusercontent?
Как насчёт статьи по мотивам исследования файла с какого-нибудь googleusercontent.com?
А пользователя хоть кто-нибудь спрашивал?
Захожу на западные сайты — мне предлагают авторизоваться через, например, facebook/google.
Захожу на отечественные — предлагают вк/ок.
Мне придётся во всех (ну ладно, в некоторых) соцсетях регистрироваться для того. чтобы зайти на левый сайт?
Разработчикам для моего удобства приходится поддерживать авторизацию через десяток разных сервисов (или терять аудиторию, если юзер не пользуется нужным сервисом).

Если у меня iOS и нет гуглоучётки? Не сижу в фейсбуке? Если РКН «заблокировал» Телеграм, задев и «Телеграм паспорт»? Если ВК заблокировали вна Украине? Что будет?
Я не смогу зайти на ваш сайт.

А если я не хочу, чтобы в инете сохранилась связь сайт-мой аккаунт в соцсети? Например, при входе со смартфона pornhub просит авторизоваться через ВК. Что-то типа Сбербанк ID / Paypal вообще нет желания привязывать ни к одному сервису, на котором есть возможность оплаты/подписки/покупки (а сейчас, считай, что и нет сервисов, у которых нет платных возможностей или их нельзя было бы прикрутить).

Из-за этого везде, где можно — выбираю «Зарегистрироваться через email». А это значит, что разработчикам, помимо сторонних сервисов, все равно приходится пилить свои велосипеды.
Само собой, пример не показательный, но я не встречал ни одного сайта, на котором была бы нужда зарегистрироваться и не было бы возможности сделать это «по старинке» через email или, хотя бы, номер телефона.
Вот тут есть неплохой обзор обмена данными с терминалом, включая некоторые тонкости
Думаете, злоумышленники о ней не знают/не догадываются?
В тексте по ссылке из последнего абзаца статьи как раз типичный взгляд НЕ со стороны злоумышленников, вот краткий пересказ:
RFID-защитные кошельки — пустая трата денег.
Автор не смог найти crime reports о кражах через RFID (я не уверен, что это вообще должно попадать в полицию, вроде банки, МПС и мерчант между собой разруливают такую мелочевку).
Но в финансовом отчёте нашел упоминания о 6.9 млн бесконтактного фрода за 2016 год только в UK (при обороте в 25 млрд). Ему никто не смог пояснить, что это за фрод, но предположили, что это, скорее всего, не связано именно с RFID, потому что есть более простые способы (mobile device fraud) и в статистике они все учитываются одной общей цифрой.
Далее он пытается объяснить, что нельзя просто считать данные с карты и сделать фейковую транзакцию или не получится прикладывать свой терминал к карманам прохожих и не спалиться перед банком.

Концовка тоже порадовала:
Even if we assume that all £6.9 million of 2016 RFID crime reported in the UK Finance report was committed by credit cards and not mobile devices, it means RFID crime is still, at best 1.1 percent of overall credit card fraud, and it’s falling. If you are worried about a potential 1.1 percent crime rate while also using non-RFID credit cards which are responsible for 98.9 percent of credit card fraud, aren’t you focusing on the wrong threat? Why use any credit card? As far as I can tell, if you are worried about credit card fraud, you’d be about 90 times safer (and getting safer) to only use RFID credit cards. You shouldn’t run away from or even worry about RFID credit cards, you should embrace them

Не стоит париться, процент бесконтактного фрода очень мал (1,1%) по сравнению с контактным фродом.

После такого все сразу почувствовали себя Неуловимыми Джо, что их то это точно не коснётся. Дадада, конечно.

Т.е., журналисты и маркетологи пребывают в уверенности, что злодеи будут пытаться «взломать шифры», сделать фейковые карты, фейковый терминал и т.д., на эту уязвимость пока мало обращают внимания. И вендоры могут продолжать ставить большие таймауты на ожидание ответа от карты «для удобства пользователей» (у которых карта не срабатывает с первого раза)
Сколько именно времени терминал «ждёт» ответа от карты?
Из всех упомянутых возражений по невозможности такой атаки — единственное серьезное — это таймауты. Но никто не говорит, сколько эти таймауты (
Можете как-то гарантировать, что злоумышленникам не хватит времени?

Например, вот тут есть «Book A: Architecture and General Requirements», в главе «10 Performance Requirements» написано:
The primary requirement is the maximum time that a card must be present in the reader field when presented for a single presentment. This is a maximum of 500ms (0.5 seconds) and is for successful transactions with no transmission errors

The time utilised by a reader shall be a maximum of 100ms.
This implies a card tariff of 400ms. This is outside the scope of EMV contactless
reader requirements

т.е., на вся операция должна занять максимум 500мс, при этом на ридеру отдаётся только 100мс, а на работу карты и передачу от карты к ридеру остаётся 400мс.

Поправьте, если это не о тех «строгих задержках».

В этом же документе упоминаются и другие таймауты, но без конкретных значений, видимо, каждый вендор может устанавливать свои.
Всё-таки попробовал.
Положил 4 карты в одно отделение кошелька. Все одинаково ориентированные, без посторонних прослоек между картами. К терминалу подносил со скоростью обычного покупателя. Подносил до касания, чтобы все 4 карты гарантированно были в зоне действия ридера (учитывая ещё толщину «внешней обшивки» кошелька).

Ошибок не было, деньги списались с ближней к терминалу карты.

Модель Verifone Vx820. В эксперименте с двумя картами был пин-пад Ingenico, скорее всего, IPP220
добавлю ещё:
4) терминалы могут выходить в интернет через gprs (особо весело такие ставить в металлические ангары или подвальные помещения) или Wifi, которые также вносят свои задержки
5) если терминал работает через ПК (не обязательно через USB, можно и через COM, так даже стабильнее) — то свои задержки вносит и ПО на компьютере.
Ну вот, хоть какая-то конкретика — «меньше миллисекунды». Осталось выяснить, сколько из этого времени реально нужно карте для работы, а сколько остаётся на обмен через удлинитель.
предъявляет высокие требования в конструкции антенны. Иначе даже прикладывание карты прям на антенну может не помочь с ней пообщаться.

Но терминал карты нормально считывает? У тех моделей, над которыми у меня была возможность поэкспериментировать, область стабильного считывания — параллелепипед с высотой 2-3 см и площадью основания, условно, со спичечный коробок. Карту можно подносить под любым углом (ну или почти под любым). В чём сложность сделать такую же антенну? Или даже мощнее, злоумышленникам же не надо сертификацию проходить.
Но собственно попытки найти уязвимости происходят уже лет 7 минимум

Пытаются найти уязвимость в протоколе обмена. amarao же начал тред с варианта, когда протокол не взламывается, данные так и передаются зашифрованными.
Т.е., не классический MitM, а простое proxy, если угодно.

Information

Rating
Does not participate
Registered
Activity