Кстати, мне нравится концепция порт-кнокинга. Правда, она древняя до невозможности. Я бы ее улучшил так:
Есть некий веб-интерфейс, туда заходит пользователь, авторизуется. Веб-интерфейс берет его ип адрес и разрешает соединение к сервисам.
Относительно порткнокинга — не имеем ложных срабатываний от скана портов, не нужно ставить «ярлыки» на комп пользователя, можно настроить персонально сервисы для каждого пользователя (не всем все открывать).
Я в своем софте использую лишь пессимизацию, если нашлось несколько атакующих из той же подсети /24. Т.е. условно, для атакующих доступно намного меньше неудачных попыток входа до бана. По формуле:
Целое( 20 / (ЧислоЗаблокированныхРядом + 1) )
20 — базовое число неудачных попыток входа до бана.
ЧислоЗаблокированныхРядом — другие заблокированные ип адреса из той же подсети /24.
Т.е. если это первый атакующий — то у него 20 попыток. Если второй — то у него 10 попыток. Если третий — то 6 попыток. И т.д.
Списки пухнут, потому что подход неправильный. Сейчас многие ип адреса динамические.
Если это более менее профессиональный подход: атакующий купил их штук 100, недельку пароли подбирал и эти отдает обратно, покупает другие.
Если не проф подход: то это условный школьник из сети провайдера с динамическим внешним — у него каждый день новый ип.
Поэтому все меньше смысла в статичном списке — он устаревает и лишь бесполезно нагружает оборудование.
Вырезать сетями — занятие опасное. Что делать, если в сети домашнего провайдера одного из ваших пользователей завелось 3 школьника-хакера? Забанить их подсетью?
В VPN есть только одна проблема — пользователи. Это дополнительная точка отказа, которая раскидана по всем конечным пользователям. У кого-то vpn клиент не установится, у кого-то провайдер блокирует vpn трафик (я такое встречал и не раз), а еще бывает кривое сетевое оборудование, которое часто рвет vpn сессию — все это для обслуживания и техподдержки пользователей требует постоянного админа.
P.S. И почему-то часто забывают, что к впн также подбирают пароли. И также торгуют доступом в корпоративные сети, подобрав пароль. И его также нужно защищать — и примерно теми же мерами.
Идея классная, но не взлетит. Просто потому что после создания это приложение начнет отображать плачевное состояние медицины, а поэтому будет в контрах с властью всегда. Поэтому, думаю, врачам запретят им пользоваться. Гласно или негласно — не важно.
Вторая сторона — как правильно заметили, врачам выгодно продавать одни вещи вместо других (откаты, говоря проще) — и хоть в последние годы эта ситуация сильно улучшилась, но все равно пока осталась.
Третья сторона — врачам проще назначать дорогие препараты, потому что в них можно ожидать лучшую очистку действующий веществ от примесей, а значит меньше побочных эффектов и меньше ответственности врача.
Не думаю, что это для автопрома обуза.
Они довольно легко могли бы свести к минимуму рынок запчастей, используя детали с большИм сроком службы. Сейчас, имхо, все строго наоборот — используются детали с минимальным сроком службы (т.е., в идеале, чтобы по окончании гарантийного периода она и сломалась).
Второй вариант, как снизить рынок запчастей — использовать стандартизацию и модульность и как результат получить взаимозаменяемые детали сквозь все марки авто. Сейчас же все строго наоборот — запчасти приходится искать аж по VIN (т.е. не только внутри марки, но еще и внутри конкретной партии). Согласен, что тут есть исключения — и некоторые блоки действительно подходят на несколько марок, но в целом ситуация все же без стандартизации.
4) И все же, я думаю, что лучше в облако. Просто из соображений управления бизнесом. Смотрите, вы на оптимизацию сети потратили немало человекочасов, причем в статье явно описан «удачный вариант», а за кадром, наверное, было еще штук 5 неудачных гипотез, на них тоже ресурсы потрачены — вот это все надо записать в циферку затрат (и она выйдет немаленькая). Как результат вы получили конкурентное преимущество — работа в оффлайне.
Покрытие и качество интернет увеличиваются с каждым годом — тут и моб сети улучшаются, и wimax покрытия встречаются, и спутники как магистральный провайдер дают возможность провести инет туда, где раньше и не думали. Рост этого рынка будет каждый год снижать пользу от «работы в оффлайне» и, думаю, по истечению следующей пятилетки сведет пользу к нулю.
Вы приводите пример — и в нем уже в конце процесса покупка билета — т.е. действие уже в онлайне. Поэтому польза от «работы в оффлайне» уже снижается до вопроса стабильности канала. Передачу данных на нестабильном канале тоже можно программно улучшить (убрать принцип «канал кратковременно упал => вся работа потерялась») — эта задача уже довольно хорошо изучена и не представляет большой сложности (говоря проще, не требует проверки гипотез — сразу можно написать рабочий вариант). Что еще снизит пользу от «работы в оффлайне».
От облака есть еще дополнительные преимущества: возможность сбора больших данных. А значит вы сможете улучшить свой алгоритм методом композиции нейросетей — т.е. выбрать те примеры, где ваша нейросеть справилась неудачно и построить еще одну, которая дораспознает эти ошибки. Из оффлайна делать это невозможно, из полу-оффлайна делать это сложнее.
А я думаю, что рынок 3D печати некоторым образом угрожает автопрому в части запчастей. Т.к. весь автопром сейчас перешел на модульную замену: когда меняется весь блок, а не только вышедшая из строя деталь. При этом стоимость блока может на порядки превышать стоимость сломанной детали. А еще (это чисто мое мнение) используется идея контролируемого устаревания деталей, когда они сознательно делаются со сроком службы 5 лет. А тут выходят на свет 3d принтеры с их возможностью создать любую пластиковую деталь. 3D печать дороже заводского изготовления детали (той же горячей формовки), но существенно дешевле замены модуля целиком. Поэтому массовое распространение чертежей и 3D принтеров может существенно сократить отрасль запчастей от производителя.
1с крайне сложно будет на этих рынках.
1) Основное преимущество 1с: это поддержка вечно меняющегося регламентированного учета в РФ. Оно сходит на ноль в других странах, т.к. в них нет столько изменений в регл учете. И тогда 1с придется конкурировать даже с чем-нибудь древним, 20 лет назад написанным. Проще говоря: конкуренция выйдет на порядки больше (даже не в разы).
2) В некоторых странах у малого бизнеса допускается вообще отсутствие регл учета. И поэтому 1с тут сможет конкурировать только в сфере управленческого учета, а значит придется конкурировать и с CRM.
3) У 1с тяжеловато с разделением продуктов по сложности. Больше 1с делит их по отраслям. А вот так, чтобы у «Управление торговлей» появилось 3 компоновки по функционалу/сложности/стоимости — такого нет. И механизмов скрытия от пользователя (функциональные опции) недостаточно, т.к. сложность всей конфигурации остается на высоком уровне (а значит теряет в производительности и выше стоимость доработки).
4) Зато у конкурентов много не-технических преимуществ: например, у них есть уже доля рынка и репутация. У некоторых (SAP) репутация такая, что внедрившие ее компании автоматически повышают свою капитализацию.
5) Про SAP отдельный разговор. У них с 1с концептуально противоположный подход к автоматизации.
Подход SAP: процессы должны быть такими, учет всегда таким. Перестраивайте фирму под них. Зато любой может посмотреть «отчет по продажам» и однообразно увидеть состояние фирмы.
Подход 1с: вот вам конструктор, там заложены пара базовых принципов, а дальше меняйте как хотите. Процессы и учет меняют под фирму. Поэтому тот же «отчет по продажам» может как угодно различаться и показывать разное в зависимости от фирмы и ее желаний.
Отсюда внедрение SAP повышает капитализацию (т.к. в фирму внедрили пусть не идеально работающие, но работающие процессы), а внедрение 1с никак не влияет на капитализацию (т.к. процессы могли остаться на любом пещерном уровне).
Не думаю. Обычно узкое место либо в пуле соединений (старт платформы внутри апача довольно затратный), либо в БД. Парсинг json проявится только на больших пакетах данных, а в приведенном примере, думаю, запросы по HTTP были штук на 5 полей.
1) Я бы задрал контраст в максимум. Это привело бы картинки к ч/б. А это ускорило бы обучение нейросети на порядки.
2) Использовал бы на картинках аугментацию поворотом и перспективой. Т.к. врятли вам в боевых условиях предоставят столь хорошо выровненные фотки.
3) Не уверен, что хорошо понимаю «метрическую сеть», но имхо
По выходу классифицирующей сети нельзя сказать, как сильно отличаются классы исходного алфавита, в то время как это хорошо видно по кластерам выходного пространства метрической сети.
Вроде на выходе классификатора имеем набор вероятностей, что объект относится к каждому классу. Если дельта между ними высокая => классы сильно отличаются. Дельта низкая => классы слабо отличаются. Не вижу особых различий с результатом-вектором из метрической сети.
4) Имхо, не имеет большого смысла оптимизировать нейросети для смартфонов. Т.к. чаще всего распознанные данные нужно куда-то после этого «загрузить», а значит все равно интернет доступен, а значит можно вынести распознавание на нормальное железо.
Бегло в код посмотрел, поэтому могу ошибаться:
1) Имхо, лучше бы использовать обертку над базой данных с функцией плейсхолдеров вместо конкатенации запроса с параметрами, т.к. обычно это прям напрашиваться на уязвимости. Чуть вы где-то забыли очистить переменную и можно легко стереть полбазы, вставив в параметры что-то вроде topic_id=7;delete from topics
2) Пароли в таблице users хранятся в md5 — это хорошо. Еще лучше добавить случайный salt — так вы получите разные хеши, если у 2х пользователей совпадают пароли.
3) executer.php->REPLY($args). Вы используете независимые запросы к базе: сначала для получения code, затем делаете инкремент, а затем пишете это в базу. Думаю, под нагрузкой получите баги в виде 2х смешавшихся потоков выполнения и там значение code буду задваиваться.
Я бы даже добавил, что в таких сферах, как банки, где собрана масса крайне важной личной информации (движения финансов) и способность распоряжаться деньгами клиентов — должен быть обязательный периодический независимый аудит безопасности с открытыми для всех результатами, чтобы клиенты понимали риск относительно своих денег и информации.
Вот и я присоединяюсь к вопросу. Если сотрудники могут перебрасывать деньги без уведомлений клиента и отражений в его истории операций — то в банковской сфере может творится что угодно. А «по умолчанию» ответственным за операции является таки клиент.
Так что, если это правда, то ситуация могла случиться плачевная: и деньги обналичены и клиент посажен за чужие действия.
Почти все эти пункты происходят из-за усиления конкуренции. То, что раньше работало в с подходом «тяп-ляп» и 5% эффективности (и давало достаточно преимуществ перед конкурентами) — теперь требует вдумчивого подхода.
Любовь к клиенту — не панацея, совсем. Вот пример из моей жизни: заказал в озоне 5 тарелок (последние. скидка, потому что «некомплект»). Вечером смотрю в ЛК: в заказе осталось 2 тарелки, 3 молча выкинули. Пишу в поддержку: «ребята, мне нужны либо 5, либо 0 (уберите их из заказа совсем)». Отвечают: хорошо-хорошо. И на следующий день привозят 2 тарелки…
Вот скажите, какая мне разница, как любят меня сотрудники поддержки, если они не могут договориться друг с другом?
Уверен, что процессы определяют качество и с каждым годом все больше. Нет процесса — все остальное бессмысленно: и любовь, и crm, и умение «продавать», и лидогенерация — они все упрутся в невозможность обработки заказа.
Направление интересное. Но, имхо, тут есть одна крайне сложная проблема: ваш метод базируется условно на «классификации». Нейросети вы при этом должны предоставить все варианты «правильного» трафика приложения (а неправильный, допустим, можно нагенерировать). Так вот сложность этой задачи схожа с методикой конечных автоматов — когда нужно описать все возможные ветвления программы. Боюсь, что в современном софте это крайне сложно. А без этого мы получаем, что чуть пользователь стал использовать ПО нестандартным способом — и технология пытается его отправить в категорию вредоносного и заблокировать.
А те методы, что вы в статье описываете — они не подходят чиновникам. Думаю, потому, что у них мера «выполненной работы» заключается в полностью заблокированном телеграме. А вы предлагаете скорее способы подгадить одной категории пользователей, другой — оно имеет место быть, но никак не приводит чиновника к «выполненной работе», т.е. вознаграждению.
Есть некий веб-интерфейс, туда заходит пользователь, авторизуется. Веб-интерфейс берет его ип адрес и разрешает соединение к сервисам.
Относительно порткнокинга — не имеем ложных срабатываний от скана портов, не нужно ставить «ярлыки» на комп пользователя, можно настроить персонально сервисы для каждого пользователя (не всем все открывать).
Целое( 20 / (ЧислоЗаблокированныхРядом + 1) )
20 — базовое число неудачных попыток входа до бана.
ЧислоЗаблокированныхРядом — другие заблокированные ип адреса из той же подсети /24.
Т.е. если это первый атакующий — то у него 20 попыток. Если второй — то у него 10 попыток. Если третий — то 6 попыток. И т.д.
Если это более менее профессиональный подход: атакующий купил их штук 100, недельку пароли подбирал и эти отдает обратно, покупает другие.
Если не проф подход: то это условный школьник из сети провайдера с динамическим внешним — у него каждый день новый ип.
Поэтому все меньше смысла в статичном списке — он устаревает и лишь бесполезно нагружает оборудование.
Вырезать сетями — занятие опасное. Что делать, если в сети домашнего провайдера одного из ваших пользователей завелось 3 школьника-хакера? Забанить их подсетью?
P.S. И почему-то часто забывают, что к впн также подбирают пароли. И также торгуют доступом в корпоративные сети, подобрав пароль. И его также нужно защищать — и примерно теми же мерами.
Вторая сторона — как правильно заметили, врачам выгодно продавать одни вещи вместо других (откаты, говоря проще) — и хоть в последние годы эта ситуация сильно улучшилась, но все равно пока осталась.
Третья сторона — врачам проще назначать дорогие препараты, потому что в них можно ожидать лучшую очистку действующий веществ от примесей, а значит меньше побочных эффектов и меньше ответственности врача.
Они довольно легко могли бы свести к минимуму рынок запчастей, используя детали с большИм сроком службы. Сейчас, имхо, все строго наоборот — используются детали с минимальным сроком службы (т.е., в идеале, чтобы по окончании гарантийного периода она и сломалась).
Второй вариант, как снизить рынок запчастей — использовать стандартизацию и модульность и как результат получить взаимозаменяемые детали сквозь все марки авто. Сейчас же все строго наоборот — запчасти приходится искать аж по VIN (т.е. не только внутри марки, но еще и внутри конкретной партии). Согласен, что тут есть исключения — и некоторые блоки действительно подходят на несколько марок, но в целом ситуация все же без стандартизации.
Покрытие и качество интернет увеличиваются с каждым годом — тут и моб сети улучшаются, и wimax покрытия встречаются, и спутники как магистральный провайдер дают возможность провести инет туда, где раньше и не думали. Рост этого рынка будет каждый год снижать пользу от «работы в оффлайне» и, думаю, по истечению следующей пятилетки сведет пользу к нулю.
Вы приводите пример — и в нем уже в конце процесса покупка билета — т.е. действие уже в онлайне. Поэтому польза от «работы в оффлайне» уже снижается до вопроса стабильности канала. Передачу данных на нестабильном канале тоже можно программно улучшить (убрать принцип «канал кратковременно упал => вся работа потерялась») — эта задача уже довольно хорошо изучена и не представляет большой сложности (говоря проще, не требует проверки гипотез — сразу можно написать рабочий вариант). Что еще снизит пользу от «работы в оффлайне».
От облака есть еще дополнительные преимущества: возможность сбора больших данных. А значит вы сможете улучшить свой алгоритм методом композиции нейросетей — т.е. выбрать те примеры, где ваша нейросеть справилась неудачно и построить еще одну, которая дораспознает эти ошибки. Из оффлайна делать это невозможно, из полу-оффлайна делать это сложнее.
1) Основное преимущество 1с: это поддержка вечно меняющегося регламентированного учета в РФ. Оно сходит на ноль в других странах, т.к. в них нет столько изменений в регл учете. И тогда 1с придется конкурировать даже с чем-нибудь древним, 20 лет назад написанным. Проще говоря: конкуренция выйдет на порядки больше (даже не в разы).
2) В некоторых странах у малого бизнеса допускается вообще отсутствие регл учета. И поэтому 1с тут сможет конкурировать только в сфере управленческого учета, а значит придется конкурировать и с CRM.
3) У 1с тяжеловато с разделением продуктов по сложности. Больше 1с делит их по отраслям. А вот так, чтобы у «Управление торговлей» появилось 3 компоновки по функционалу/сложности/стоимости — такого нет. И механизмов скрытия от пользователя (функциональные опции) недостаточно, т.к. сложность всей конфигурации остается на высоком уровне (а значит теряет в производительности и выше стоимость доработки).
4) Зато у конкурентов много не-технических преимуществ: например, у них есть уже доля рынка и репутация. У некоторых (SAP) репутация такая, что внедрившие ее компании автоматически повышают свою капитализацию.
5) Про SAP отдельный разговор. У них с 1с концептуально противоположный подход к автоматизации.
Подход SAP: процессы должны быть такими, учет всегда таким. Перестраивайте фирму под них. Зато любой может посмотреть «отчет по продажам» и однообразно увидеть состояние фирмы.
Подход 1с: вот вам конструктор, там заложены пара базовых принципов, а дальше меняйте как хотите. Процессы и учет меняют под фирму. Поэтому тот же «отчет по продажам» может как угодно различаться и показывать разное в зависимости от фирмы и ее желаний.
Отсюда внедрение SAP повышает капитализацию (т.к. в фирму внедрили пусть не идеально работающие, но работающие процессы), а внедрение 1с никак не влияет на капитализацию (т.к. процессы могли остаться на любом пещерном уровне).
2) Использовал бы на картинках аугментацию поворотом и перспективой. Т.к. врятли вам в боевых условиях предоставят столь хорошо выровненные фотки.
3) Не уверен, что хорошо понимаю «метрическую сеть», но имхо
Вроде на выходе классификатора имеем набор вероятностей, что объект относится к каждому классу. Если дельта между ними высокая => классы сильно отличаются. Дельта низкая => классы слабо отличаются. Не вижу особых различий с результатом-вектором из метрической сети.
4) Имхо, не имеет большого смысла оптимизировать нейросети для смартфонов. Т.к. чаще всего распознанные данные нужно куда-то после этого «загрузить», а значит все равно интернет доступен, а значит можно вынести распознавание на нормальное железо.
1) Имхо, лучше бы использовать обертку над базой данных с функцией плейсхолдеров вместо конкатенации запроса с параметрами, т.к. обычно это прям напрашиваться на уязвимости. Чуть вы где-то забыли очистить переменную и можно легко стереть полбазы, вставив в параметры что-то вроде topic_id=7;delete from topics
2) Пароли в таблице users хранятся в md5 — это хорошо. Еще лучше добавить случайный salt — так вы получите разные хеши, если у 2х пользователей совпадают пароли.
3) executer.php->REPLY($args). Вы используете независимые запросы к базе: сначала для получения code, затем делаете инкремент, а затем пишете это в базу. Думаю, под нагрузкой получите баги в виде 2х смешавшихся потоков выполнения и там значение code буду задваиваться.
Странно, вот даже обзоры библиотек по генетическим алгоритмам есть:
www.kaggle.com/getting-started/112297
Хороший подход. Схожий применяется в оптимизации градиентным спуском в нейросетях. Там «параметр» называется learning_rate.
Пример: www.pyimagesearch.com/2019/07/22/keras-learning-rate-schedules-and-decay (можно особо не вчитываться — на первом же графике понятен результат).
Так что, если это правда, то ситуация могла случиться плачевная: и деньги обналичены и клиент посажен за чужие действия.
Любовь к клиенту — не панацея, совсем. Вот пример из моей жизни: заказал в озоне 5 тарелок (последние. скидка, потому что «некомплект»). Вечером смотрю в ЛК: в заказе осталось 2 тарелки, 3 молча выкинули. Пишу в поддержку: «ребята, мне нужны либо 5, либо 0 (уберите их из заказа совсем)». Отвечают: хорошо-хорошо. И на следующий день привозят 2 тарелки…
Вот скажите, какая мне разница, как любят меня сотрудники поддержки, если они не могут договориться друг с другом?
Уверен, что процессы определяют качество и с каждым годом все больше. Нет процесса — все остальное бессмысленно: и любовь, и crm, и умение «продавать», и лидогенерация — они все упрутся в невозможность обработки заказа.
Поправьте, если я не прав.