Как стать автором
Обновить

Комментарии 22

А транзистор правда без резистора в базе использован?
Питание лучше брать с джампера переключателя питания USB-портов, там есть Vsb — +5В дежурного питания которые есть всегда и просто +5v — тут 5 вольт есть только когда компьютер включен.
Питание есть всегда, пока есть напряжение на материнской плате.
На 1 картинке после фразы «Питание берется с USB, а проверка...» видно куда подключаются земли (2 коричневых провода) и откуда снимается + 5V (красный провод — его плохо видно он за двумя коричневыми).
Наверное «по феншую» нужен резистор, но полгода после того как последний раз перебрал работает без нареканий.
Ну я и говорю, что лучше подключаться не к USB разъему, там очень легко попутать контакты. И похоже что питание USB у вас стоит в положении «питание от дежурного источника».
Вообще-то резистор там не просто нужен а ОБЯЗАТЕЛЕН. ничего не замечаете только потому что перегрузка достаточно кратковременна — всего 1-2 секунды за сколько то там дней насилуется транзистор, выход ардуины и стабилизатор питания на плате ардуины. В любой момент времени один из компонентов может не выдержать и потянуть за собой остальное. Найдите все-таки резистор, выпаять можно даже где-то на любой номинал — от 500 Ом до 100 кОм. Можно даже SMD-шный.
Хорошо, спасибо за совет. Как полезу внутрь — поставлю.
НЛО прилетело и опубликовало эту надпись здесь
А может, у него белый IP? <зависть>
НЛО прилетело и опубликовало эту надпись здесь
Настроен проброс порта. По статическому IP на определенный порт имеем доступ к Arduino. Получается нужно знать комбинацию из IP +порт и страницы на которую будем отзываться.
Теоретически комбинацию можно нащупать, и можно придраться и сказать, что это не безопасно, но я для себя решил, что так как доступа к информации нет, то для меня это допустимо. Можно придумать ведь и более сложный механизм, скажем с динамически меняющимся мак-адресом, каждые сутки, отправкой его письмом на почту и проверкой при обращении содержится ли в запросе в заголовках этот мак-адрес и сделать к примеру клиент с отправкой таких заголовков и обращением к данной странице по связке IP+порт… Но стоит ли овчинка выделки?.. )
Вот тут описан механизм слежения за действиями пользователей у некоторых провайдеров. Вашу секретную ссылку могут просто посещать вслед за вами.
lleo.me/dnevnik/2015/01/29.html
Спасибо за ссылку, обязательно ознакомлюсь. Но как описано в статье, тут два варианта. Первый — они включат PC, но не получат к нему доступа, второй — они получат сообщение, что PC уже включен, но не получат к нему доступа. Так что ничего критичного не получаем. Как я говорил, возможность передавать данные специально не реализовывалась с целью безопасности. Стоит отметить, что в 99,9% случаев я посылал сигнал на пробуждение, так как при подключении по RDP на рабочем столе лежит ярлык с командной строкой «C:\Windows\System32\rundll32.exe powrprof.dll,SetSuspendState 0,1,0» которая отправляет PC в «sleep».
Я ведь не отрицаю, что можно найти эту ссылку, но не вижу в этом ничего критичного. Опять таки, если для кого-то это критично, можно придумать массу вариантов. Вот с ходу могу предложить такой вариант: добавляем в схему DS1307 для работы с реальным временем, делаем автономное резервное питание, делаем хеш функцию с «солью» из набора символов (то есть берем дату или дату плюс текущее значение часа, прогоняем её через хеш функцию, складываем с нашим набором символов, получаем другой хеш, повторяем n раз и на выходе контрольная сумма или дата для хэша, значение часов плюс скажем сто для числа повторений). Таким образом мы получаем клиент с генерацией заголовков и сервер которые будет проверять на совпадение в заголовках контрольного значения с идентичным вычислением на сервере. Ведь для тех кто ищет с чего начать, как раз тут раздолье вариантов. Я не вижу, что использование данного решения было бы опаснее, чем использование «магических пакетов».
Вы писали, что у вас есть функция принудительного отключения питания для перезагрузки в случае сбоя компа. Вот она-то уже может попортить крови.

Вообще понятно, что ничего особо страшного вроде как не сотворить, но тот факт, что какая-то функция доступна буквально всему интернету оставляет ощущение чего-то неправильного. Защита через незнание самая примитивная. Адрес страницы действительно легко получат роботы поисковиков, даже, если вы им напрямую его не сказали. Они могут просто заходить, пытаясь индексировать ее, и каждый раз будут включать ваш компьютер, когда не надо.

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

В технологии Wake-on-lan изначально функция доступна буквально всему интернету.
Где гарантии, что провайдеры также не «отдают на сторону» UDP-пакеты?
По поводу выключения. Никто не мешает перенастроить систему, что при получении сигнала от кнопки питания уходить в сон.
Но опять таки это не говорит о том, что я с вами не согласен. Теоретически — да, открыт доступ к функции включения всему интернету.
Всё решается гораздо проще. Есть такой алгоритм как KeeLoq который обеспечивает безопасную передачу команды и в настоящее время используется для пультов автосигнализаций. Конкретно с авто происходят фейлы с сильным ослаблением стойкости алгоритма, но сам алгоритм при условии произвольного выбора ключа считается еще не взломаным.
Никогда не думал о применении KeeLoq в такой области? А почему именно этот алгоритм шифрования?
Потому что он простой в реализации. Никаких хеш-функций считать не надо — просто сдвиговый регистр с обратными связями. Нагрузка на микроконтроллер минимальная, лишь бы ключ не светить. Фишка еще в том что пульт передаёт счетчик, и даже если узнаешь ключ приемник может отбросить команду как ложную если переданное значение счетчика будет меньше чем с прошлого сеанса или сильно больше.
Алгоритм специально разрабатывался для противодействия воспроизведению перехваченного сигнала, т.е. точно такой же сигнал воспроизведенный приемнику не приведет к повторному действию.
Не обязательно воспроизводить весь алгоритм один в один по спецификациям, можно ведь взять только идею.
Кстати, раз уж речь внезапно зашла про KeeLoq, предлагаю небольшой офтоп. Вы понимаете, как они хранят ключи? Я сейчас делаю один девайс, который использует такие брелки, и мне просто стало интересно, как шифрование осуществляется. Про сам алгоритм шифрования, про формат посылки, про счетчик синхронизации — я нашел. Не понял только, как брелок и приемник умудряются зашифровать и расшифровать посылку. Откуда они ключ друг друга знают? Он намертво внутри прошит что ли? У всех одинаковый?
Да, ключи вшиты. Там есть постоянная часть и переменная.
Постоянная — одинакова для производителя, а переменная это что-то вроде серийного номера. Ключи соответственно уникальны.
Собственно, поэтому и проблемы с брелками наблюдаются — производители используют константы в ключах и эти константы периодически утекают в паблик. Переменной части кода ключа остается не так много как хотелось бы, поэтому они ломаются за приемлемое время на обычном ПК если известна постоянная часть от производителя.
Поэтому при утере ключей и необходимости иметь дополнительное количество ключей — меняют весь блок сигнализации т.к. чужие брелки в таком случае не подойдут.
Можно использовать один из вариантов реализации KeeLoq алгоритма который обеспечит защиту от несанкционированного использования.
Мне не безынтересны предлагаемые варианты, обязательно почитаю. Просто попытаюсь объяснить свою позицию. Случается так, что забываю у мышки выключить тумблер (on/off), а она с энергосберегающим режимом. При выходе из стендбай она подает какой-то сигнал, который PC воспринимает как сигнал к включению. (И меня это устраивает, так как просто перещелкнув вышеописанный тумблер вывожу PC из сна). Так вот в тех случаях когда тумблер не выключен, жена может просто задеть стол или мышку и запустить PC. И она не будет уверена, она это сделала или я послал сигнал на включение — то есть она не станет его выключать заранее не зная, что именно она его включила. Таким образом вероятность того, что кто-то из интернета включит мне PC ниже чем вероятность, что его физически выведут из сна дома.
Сталкивался с такой фигней, когда компьютер после выключения был доступен для wake-on-LAN только несколько минут после. Это из-за того, что роутер забывает таблицу сопоставления MAC и IP адресов (ARP таблицу)
Роутеры не дают часто сделать проброс внешнего порта на порт внутреннего широковещательного .255 адреса…

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

На D-Linkах выкручивался экзотично — скрипт узнавал адрес роутера по его DYNDNS имени, потом подключался к телнету роутера, вбивал ARP запись, посылал уже WOL пакет…

Ваше решение решает эти проблемы, я же ленился сделать хардварное решение… корпус там искать…

Кстати, ждем решения этой проблемы на ESP8266 с nodeMCU, и провод не потребуется, если есть WIFI…
Это из-за того, что роутер забывает таблицу сопоставления MAC и IP адресов (ARP таблицу)

Спасибо за информацию! Нужно будет почитать, может действительно есть решение для моего роутера и arduino освободиться для других проектов )
Любые попытки заставить стабильно работать wake-on-lan
Аналогично. Ни один из моих компов за 15 лет стабильно не обрабатывал WOL, Удивительно, технологии два десятка лет а её так и не смогли нормально и удобно реализовать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации