B>можно вопрос? B>что важнее, защита трафика или защита от подмены айпи? например объект а общается с б, а пакеты у а подменяются на ип адрес какого нибудь левого с
В ситуации когда злоумышленник получил техническую возможность подменять пакеты это уже не имеет значения.
Все проблемы от жадности и глупости
Re[23]: Разумность 16 байтных IP-адресов - ведь глупость сде
Здравствуйте, Stanislaw K, Вы писали:
SK>Здравствуйте, bobby23, Вы писали:
B>>можно вопрос? B>>что важнее, защита трафика или защита от подмены айпи? например объект а общается с б, а пакеты у а подменяются на ип адрес какого нибудь левого с
SK>В ситуации когда злоумышленник получил техническую возможность подменять пакеты это уже не имеет значения.
почему такой вопрос с ип адресами, в "токной ситуации" будут три обьекта, и котму то чтото надо сделать, а дает задание б, но с имея техн возможность меняет пакет и меняет задание.
Такой вопрос связан с гипотетической телепатией, если есть три объекта, кто с кем общается?
Re[24]: Разумность 16 байтных IP-адресов - ведь глупость сде
или такой гемор
Илон вот сделал датацентр со сто пицот тысяч видеокарт, есть крипты, котоыре майнятся на видюхах, и сейчас этот засранцец сделаоет несколько пулов в разных странах и будет дурить хомячков
Re[24]: Разумность 16 байтных IP-адресов - ведь глупость сде
Здравствуйте, bobby23, Вы писали:
B>>>можно вопрос? B>>>что важнее, защита трафика или защита от подмены айпи? например объект а общается с б, а пакеты у а подменяются на ип адрес какого нибудь левого с
SK>>В ситуации когда злоумышленник получил техническую возможность подменять пакеты это уже не имеет значения.
B>почему такой вопрос с ип адресами, в "токной ситуации" будут три обьекта, и котму то чтото надо сделать, а дает задание б, но с имея техн возможность меняет пакет и меняет задание. B>Такой вопрос связан с гипотетической телепатией, если есть три объекта, кто с кем общается?
Прикладная авторизация и аутентификация много выше уровнем над транспортом с IP адресами (которые к тому же могут динамически меняться как время от времени, так и в течении сеанса).
Все проблемы от жадности и глупости
Re[25]: Разумность 16 байтных IP-адресов - ведь глупость сде
Здравствуйте, Stanislaw K, Вы писали:
SK>Здравствуйте, bobby23, Вы писали:
B>>>>можно вопрос? B>>>>что важнее, защита трафика или защита от подмены айпи? например объект а общается с б, а пакеты у а подменяются на ип адрес какого нибудь левого с
SK>>>В ситуации когда злоумышленник получил техническую возможность подменять пакеты это уже не имеет значения.
B>>почему такой вопрос с ип адресами, в "токной ситуации" будут три обьекта, и котму то чтото надо сделать, а дает задание б, но с имея техн возможность меняет пакет и меняет задание. B>>Такой вопрос связан с гипотетической телепатией, если есть три объекта, кто с кем общается?
SK>Прикладная авторизация и аутентификация много выше уровнем над транспортом с IP адресами (которые к тому же могут динамически меняться как время от времени, так и в течении сеанса).
ну, два нюанса, либо привязывать ип по гео коорд либо к личности(но тут можно наплодить мертвых душ)
Re[26]: Разумность 16 байтных IP-адресов - ведь глупость сде
Здравствуйте, bobby23, Вы писали:
SK>>>>В ситуации когда злоумышленник получил техническую возможность подменять пакеты это уже не имеет значения.
B>>>почему такой вопрос с ип адресами, в "токной ситуации" будут три обьекта, и котму то чтото надо сделать, а дает задание б, но с имея техн возможность меняет пакет и меняет задание. B>>>Такой вопрос связан с гипотетической телепатией, если есть три объекта, кто с кем общается?
SK>>Прикладная авторизация и аутентификация много выше уровнем над транспортом с IP адресами (которые к тому же могут динамически меняться как время от времени, так и в течении сеанса).
B>ну, два нюанса, либо привязывать ип по гео коорд либо к личности(но тут можно наплодить мертвых душ)
Потому что можешь? Почему бы тогда не привязать IP к атмосферному давлению?
Ни в каком случае не нужно привязываться к IP в целях аутентификации. Просто забудь. Нет такого параметра.
Решай задачу доверенной связи между "а" и "б" осуществляемую голубиной почтой и аквариумными золотыми рыбками. (ip просто немного более быстрый транспорт чем рыбки).
Все проблемы от жадности и глупости
Re[21]: Разумность 16 байтных IP-адресов - ведь глупость сде
Здравствуйте, netch80, Вы писали:
N>Apple создала структуру ради своей прибыли. А её решила обеспечить ориентацией на выравнивание требований пользователей по линейке имени Джобса. N>Если ты согласился подровняться под неё — это говорит о тебе.
Ну, я не очень хочу участвовать в религиозном споре о том, является ли Apple империей зла. Как продукт менеджер, я вижу её феноменальный успех. Как пользователь — вижу способы, которыми она этого успеха достигла.
И нет, это не "агрессивная реклама".
N>Интернет через спутник есть везде. А вот ближайший СЦ Apple может быть и в другой стране.
Ну, раз интернет через спутник работает, то и перепривязка устройства сработает.
N>А пока добежал до СЦ — напокупали на миллион. При чём тут вообще тогда защита уровня root или не root?
Непонятно, о каком забеге до СЦ идёт речь. Защита уровня root — это очень простая штука: например, в ОС Виллариба встроено ограничение — никакая прикладная программа не может воспользоваться платёжными API, ключи для которых живут внутри TPM. В ОС Виллабаджо тоже есть такое ограничение; вот только в ней любой пользователь может лёгким движением руки войти в майнтенанс моду и поставить прошивку от левого поставщика. В которой этого ограничения уже не будет. Для нормальной эксплуатации нет никакой нужды получать root access.
Он обычно нужен как раз для того, чтобы обходить "идиотские ограничения".
Вопрос только в том — сколько из ограничений являются идиотскими, а сколько — весьма и весьма осмысленными. И насколько обход ограничений нужен лично вам, а насколько — социальному инженеру, который уговаривает вас дать root access "невинному приложению", которое вот-вот сделает вас миллионером.
N>Три года — это вы по какой стране судите? N>IP телефоны даже в условиях США спокойно жили и по 10 лет. А у индийских клиентов жило и по 15, если повезёт (плесенью изнутри не покроется). Могло быть при этом 20 раз перепродано — всё равно в статистике маячили древние модели.
Речь об РФ. У нас официальные рекомендации по амортизации для примерно любой цифровой техники — от 1 до 3 лет. Понятно, что в быту можно и 25 лет её эксплуатировать; но речь не о технической прочности, а о периоде полезного использования, на который рассчитывает бизнес.
N>Нет.
N>Его не используют без DHCP. Используют тогда уже полноценный FTP, или HTTP.
Ну, вот я сейчас не помню, был ли там FTP или всё же TFTP. В обоих сценариях хрен редьки не слаще — потому что никакого DHCP, а просто предпрошитый в конфиге фиксированный адрес хоста, с которого девайс запрашивает файл с именем равным собственному MAC-адресу.
N>Не я смешиваю, а они. Я констатирую факт.
Непонятно, на чём этот факт основан.
N>Тут согласен. Но история IT показывает, что продукт-менеджеры, или бизнес-аналитики, или кто там вместо них будет — промахиваются всегда. Реальную информацию они могут получить только от фидбэка. А фидбэк в плане секьюрити им получить и осознать ещё сложнее. N>Тех, кто параноик в душе, слишком мало.
+1.
N>Но всё ещё хуже. Инженеры тоже... мнэээ... лажают. За то, как спроектирован SIP, я регулярно хотел взять автомат и перестрелять всех. Сделать разумно было тривиально, только чуть-чуть подумать. Часть я описал тут, за вторую (где сессия) и дальше пока не брался, там не меньше кошмаров.
Немного сумбурно написано, но глубина освоения впечатляет.
N>В 2024 я таки да жду от всех секьюрных решений.
+1 N>Что, возвращаясь к предыдущей теме, не означает необходимость открытия внутренних сетей всем ветрам. Потому что даже если будут верно проектировать в принципе, CVE никто не отменял.
Да, я склонен с вами согласиться. N>Почему вы думаете, что не по опросам участников рынка?
Скажем, это просто смелая гипотеза. N>Или у вас какие-то особо дуболомные инженеры-проектировщики, или одно из двух. Потому что сколь-нибудь нормальные знают, что пароли это как раз то, что у всех должно различаться.
И тем не менее, админский пароль на жопе моего роутера таки напечатан, и я сомневаюсь, что он случайный и именно мне достался единственный на всю галактику пароль "password".
N>И это не голые слова. В одном из недавних проектов я как раз с таким имел дело. Там не SIP, другое, но тоже есть M центральных железяк и N (N≫M) юзерских, но жёстко руководимых из центра (клиент имеет право только втыкать-вытыкать шнурки). С завода приходят железяки с заводским паролем. Отдел эксплуатации ставит в сеть и меняет на один пароль и один SSH ключ на всех. Вариант персонального пароля на каждый не рассматривается.
Ну, это как раз примерно и есть идея "давайте зашьём в каждый девайс публичный ключ сервера, которым будет управляться устройство".
N>С принципом согласен. И всё равно, повторюсь, это не причина после того выставлять все устройста голым задом в интернет, сколь бы этот зад ни казался бронированным.
Ок, да, вы правы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Разумность 16 байтных IP-адресов - ведь глупость сделали
Ну давай померяем ужасы, вот программка засекающая время выборки из std::set в котором содержатся 10000000 64битных или 128битных рандомных значений. Вектор значений которые искать надо содержит каждое 32е из исходных значений + в 8 раз больше рандомных значений которых нету в set-е. Собирал gcc v 11.4.0 с -O2 Время засекается точным таймером, на моей системе получилось 677 msec для 128битных значений и 643 msec для 64хбитных. Пять процентов, Карл! И это без спецоптимизаций которые очень даже возможны и сделают разницу еще меньше.
#include <set>
#include <vector>
#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#define USE128
static void randfill(void *p, size_t l)
{
for (;l >= 2; l-= 2) {
*(unsigned short *)p = rand();
p = (char *)p + 2;
}
for (;l >= 1; l--) {
*(unsigned char *)p = rand();
p = (char *)p + 1;
}
}
#ifdef USE128
struct Value
{
uint64_t v1;
uint64_t v2;
Value()
{
randfill(&v1, sizeof(v1));
randfill(&v2, sizeof(v2));
}
bool operator <(const Value &other) const
{
if (v1 != other.v1)
return v1 < other.v1;
return v2 < other.v2;
}
};
#else
struct Value
{
uint64_t v;
Value()
{
randfill(&v, sizeof(v));
}
bool operator <(const Value &other) const
{
return v < other.v;
}
};
#endif
int main(int argc, char **argv)
{
srand(123);
std::set<Value> values;
std::vector<Value> lookup;
// generating addresses out of time measurements scopefor (unsigned long i = 0; i < 10000000; ++i) {
auto ir = values.emplace();
if ((i % 32) == 0) {
lookup.emplace_back(*ir.first);
if ((i % 4) == 0) {
lookup.emplace_back();
}
}
}
unsigned long found = 0;
struct timespec ts1 = {0};
clock_gettime(CLOCK_MONOTONIC, &ts1);
for (const auto &v : lookup) {
if (values.find(v) != values.end()) {
found++;
}
}
struct timespec ts2 = {0};
clock_gettime(CLOCK_MONOTONIC, &ts2);
unsigned long msec = (unsigned long)((ts2.tv_sec - ts1.tv_sec) * 1000);
msec+= (unsigned long)(ts2.tv_nsec / 1000000);
msec-= (unsigned long)(ts1.tv_nsec / 1000000);
printf("found %lu time %lu msec\n", found, msec);
}
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Ну давай померяем ужасы, вот программка засекающая время выборки из std::set в котором содержатся 10000000 64битных или 128битных рандомных значений. Вектор значений которые искать надо содержит каждое 32е из исходных значений + в 8 раз больше рандомных значений которых нету в set-е. Собирал gcc v 11.4.0 с -O2 Время засекается точным таймером, на моей системе получилось 677 msec для 128битных значений и 643 msec для 64хбитных. Пять процентов, Карл! И это без спецоптимизаций которые очень даже возможны и сделают разницу еще меньше.
Это слишком примитивное мышление. Нужно рассмотреть не 1 случай а множество вариантов, в т.ч. создание списка и поиск по хеш-коду. Там нужно сотни разных тестов провести, прежде чем сделать вывод.
=сначала спроси у GPT=
Re[3]: Разумность 16 байтных IP-адресов - ведь глупость сделали
S>Это слишком примитивное мышление. Нужно рассмотреть не 1 случай а множество вариантов, в т.ч. создание списка и поиск по хеш-коду. Там нужно сотни разных тестов провести, прежде чем сделать вывод.
Вариант на хэштаблицах имеет нулевую разницу, 40+-1 миллисекунд:
#include <unordered_set>
#include <vector>
#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#define USE128
static void randfill(void *p, size_t l)
{
for (;l >= 2; l-= 2) {
*(unsigned short *)p = rand();
p = (char *)p + 2;
}
for (;l >= 1; l--) {
*(unsigned char *)p = rand();
p = (char *)p + 1;
}
}
#ifdef USE128
struct Value
{
uint64_t v1;
uint64_t v2;
Value()
{
randfill(&v1, sizeof(v1));
randfill(&v2, sizeof(v2));
}
bool operator <(const Value &other) const
{
if (v1 != other.v1)
return v1 < other.v1;
return v2 < other.v2;
}
bool operator ==(const Value &other) const
{
return v1 == other.v1 && v2 == other.v2;
}
};
struct ValueHash
{
size_t operator()(const Value &v) const
{
return v.v1;
}
};
#else
struct Value
{
uint64_t v;
Value()
{
randfill(&v, sizeof(v));
}
bool operator <(const Value &other) const
{
return v < other.v;
}
bool operator ==(const Value &other) const
{
return v == other.v;
}
};
struct ValueHash
{
size_t operator()(const Value &v) const
{
return v.v;
}
};
#endif
int main(int argc, char **argv)
{
srand(123);
std::unordered_set<Value, ValueHash> values;
std::vector<Value> lookup;
// generating addresses out of time measurements scopefor (unsigned long i = 0; i < 10000000; ++i) {
auto ir = values.emplace();
if ((i % 32) == 0) {
lookup.emplace_back(*ir.first);
if ((i % 4) == 0) {
lookup.emplace_back();
}
}
}
unsigned long found = 0;
struct timespec ts1 = {0};
clock_gettime(CLOCK_MONOTONIC, &ts1);
for (const auto &v : lookup) {
if (values.find(v) != values.end()) {
found++;
}
}
struct timespec ts2 = {0};
clock_gettime(CLOCK_MONOTONIC, &ts2);
unsigned long msec = (unsigned long)((ts2.tv_sec - ts1.tv_sec) * 1000);
msec+= (unsigned long)(ts2.tv_nsec / 1000000);
msec-= (unsigned long)(ts1.tv_nsec / 1000000);
printf("found %lu time %lu msec\n", found, msec);
}
Как много веселых ребят, и все делают велосипед...
Re[4]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, ononim, Вы писали:
S>>Это слишком примитивное мышление. Нужно рассмотреть не 1 случай а множество вариантов, в т.ч. создание списка и поиск по хеш-коду. Там нужно сотни разных тестов провести, прежде чем сделать вывод. O>Вариант на хэштаблицах имеет нулевую разницу, 40+-1 миллисекунд:
А почему вы вставку не измеряете, когда вычисляется хеш? И нужно не в миллисекундах. +- а в процентах.
=сначала спроси у GPT=
Re[5]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, Shmj, Вы писали:
S>>>Это слишком примитивное мышление. Нужно рассмотреть не 1 случай а множество вариантов, в т.ч. создание списка и поиск по хеш-коду. Там нужно сотни разных тестов провести, прежде чем сделать вывод. O>>Вариант на хэштаблицах имеет нулевую разницу, 40+-1 миллисекунд:
S>А почему вы вставку не измеряете, когда вычисляется хеш? И нужно не в миллисекундах. +- а в процентах.
Какую часть времени занимает вставка от чтения? Как правило это небольшой процент.
И что такое вставка при измерении хэша?
и солнце б утром не вставало, когда бы не было меня
Re[5]: Разумность 16 байтных IP-адресов - ведь глупость сдел
S>>>Это слишком примитивное мышление. Нужно рассмотреть не 1 случай а множество вариантов, в т.ч. создание списка и поиск по хеш-коду. Там нужно сотни разных тестов провести, прежде чем сделать вывод. O>>Вариант на хэштаблицах имеет нулевую разницу, 40+-1 миллисекунд: S>А почему вы вставку не измеряете, когда вычисляется хеш?
Вставка будет ожидаемо дважды дольше: генерация рандома + копирование дважды больше объемов в памяти.
Речь шла именно про поиск, я его и померял, потому что:
Да хотя бы поиск по адресам в памяти. 16 байт потребуют введения спец. типа или создавать процессоры в которых есть нейтивный 16-байтный тип
Напиши на C++ поиск по IP-адресам из черного списка. Сначала напиши для 8-байтных адресов (а это делается нейтивным типом), потом для 16 байт. Сравни скорость работы.
Вот я написал, скорость отличается максимум на 5%, и это еще раз — без оптимизаций. Даже если говорить про локальность данных у бинарного поиска, то если это будет проблемой (на уровне 5% да), то адреса банально разбиваются на две части, строится две таблицы, каждая содержащая одну половинку каждого адреса, в первую вносятся максимально вариабельная часть адреса и бинарный поиск будет искать по первой таблице лишь изредка залазя во вторую. Разница скорости между 64 и 128 битными адресами по поиску будет примерно ноль.
S>И нужно не в миллисекундах. +- а в процентах.
Ну так разница если и есть то она на уровне рандомных флуктуаций на моей системе. То есть иногда 128 бит работает за 39 мсек, иногда 64 бит за 40 мсек, а иногда наоборот. Зато наглядно видна польза хэштаблиц — как раз становится окончательно пофиг на длину хранимого ключа.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Вот я написал, скорость отличается максимум на 5%, и это еще раз — без оптимизаций.
У вас хеш-код вычисляется без учета второй части адреса — а это годится не для всех случаев. Мы же условились что Интернет разрастется до размеров, что не хватит и квинтиллионов адресов — по этому таблицу поиска будут многотеррабайтными и хеш очень важен. Иногда важна первая половина адреса а иногда вторая — т.е. и та и та должна участвовать в создании хеш-кода.
Т.е. вы интуитивно понимаете что 10 млн. — это как бы много и что черный список большего размера быть не может, так? А интуитивно не понимаете что квинтиллион — это много и будет достаточно?
Далее. В системе с 16 байтами черный список, как я понимаю, будет включать целые поддиапазоны, т.к. логика формирования адресов другая. Т.е. там не все так просто будет.
S>У вас хеш-код вычисляется без учета второй части адреса — а это годится не для всех случаев. Мы же условились что Интернет разрастется до размеров, что не хватит и квинтиллионов адресов
Ну то есть до размеров когда 64 бит станет не хватать, окей, тогда альтернативы не остается. Не делать же 96 битные адреса.
Ну ладно, сделал return v.v1 ^ v.v2;
~/research/mapspeed$ ./mapspeed64 && ./mapspeed128
found 312500 time 39 msec
found 312500 time 41 msec
==> в итоге ломаем копья о те же 5%
Как много веселых ребят, и все делают велосипед...
Re[12]: Разумность 16 байтных IP-адресов - ведь глупость сдел
Здравствуйте, mrTwister, Вы писали:
T>И еще потом каждому роутеру объясняй, как роутить пакеты для каждого адреса, что вот эти два адреса принадлежат одноу клиенту, им можно друг с другом общаться, а вот другим адресам нельзя. И как только выдаем новый адрес кому-то, то не забыть сходить переконфигурировать роутеры и фаерволы. Спасибо. Чтобы этой голимотьей не заниматься, и придумали IPv6, на нем можно построить гораздо более простую и надежную инфраструктуру. Без центральных реестров адресов, без натов, без переконфигурирования фаерволов и роутеров на каждый чих.
Люди делится на два типа. Те кто восхищаются ipv6 и те кто на самом деле администрирует сети.
Для доступа в интернет ipv6 работает конечно замечательно.
А вот если надо выставить что-то в интернет.... без "not recomended (tm)" костылей не настроишь ни маршрутизацию, ни фаерволы, ни dns.
Re[8]: Разумность 16 байтных IP-адресов - ведь глупость сдел
Здравствуйте, ononim, Вы писали:
S>>У вас хеш-код вычисляется без учета второй части адреса — а это годится не для всех случаев. Мы же условились что Интернет разрастется до размеров, что не хватит и квинтиллионов адресов O>Ну то есть до размеров когда 64 бит станет не хватать, окей, тогда альтернативы не остается. Не делать же 96 битные адреса.
Так вы же уже сделали 128 битные адреса, забыли?
O>Ну ладно, сделал return v.v1 ^ v.v2; O>
O>~/research/mapspeed$ ./mapspeed64 && ./mapspeed128
O>found 312500 time 39 msec
O>found 312500 time 41 msec
O>==> в итоге ломаем копья о те же 5%
А вы учли что IPv6 — отдает на откуп клиенту часть диапазона? В этом же и фишка. Т.е. черный список будет не просто поиск — а вхождение в диапазон.
=сначала спроси у GPT=
Re[9]: Разумность 16 байтных IP-адресов - ведь глупость сдел
Здравствуйте, netch80, Вы писали:
N>И к системам внутри это тоже относится. Передаваемое по PCI или USB обычно не шифруется и не подписывается, эти меры применяются уже снаружи от них. Точно так же поставить внутренние серверы с доступом только через VPN и расслабиться, допуская общие для всех ресурсы видимыми без паролей — нормальная идея.
Не то, чтобы я был готов оспаривать твой тезис, но не могу по случаю не вспомнить про светлую идею подключить через JS к web-у USB и Bluetooth.
Уверен, что по мере внедрения этих дивных технологий мы прочтем еще много интересных новостей из загадочного и увлекательного мира компьютерной безопасности.
N>А теперь скажи мне, как сделать простой и удобный (и межвендорски универсальный) раздатчик https сертификатов для локалки, раз уж ты предлагаешь, чтобы даже поход на местный файловый сервер шифровать. И чтобы все браузеры автоматом подтягивали всё нужное. Q?
Прям даже и задачу могу конкретную подкинуть. Современные принтеры-сканеры общаются с внешним миром по протоколу на основе HTTP (IPP, eSCL), и он, естественно, бывает и в варианте HTTPS. Но только толку от этого HTTPS-а не много, потому, что сертификаты в ентих принтерах самоподписанные и припаянные на фабрике.
Интересно, можно ли получить от этого HTTPS-а больше пользы, чем есть сейчас?
P.S. Кстати, если у CUPS-а на знакомом ему принтере поменяется сертификат, то CUPS встанет в положение "в принтере завелся хакер, требуется вмешательство админа", и больше печатать не будет, пока не придет админ и не починет.
Re[10]: Разумность 16 байтных IP-адресов - ведь глупость сдел
