Переполнения буфера всегда актуальны. А так же:
1. Целочисленные переполнения
2. Ошибки знаково-беззнаковых преобразований
3. Проблемы с аутентификацией и авторизацией, в т.ч. возможность подмены клиента или сервера, возможность релеинга данных авторизации, недостаточная или слабая аутентификация, повышение привилегий.
4. Передача незашифрованных данных или слабая криптография, replay-атаки
5. Различные DoS-атаки (исчерпание ресурсов одним запросом, флуд, установка большого числа параллельных соединений, установка «вечно живущих» соединений, блокировка ресурсов по запросу клиента и т.п.).
6. Доступ к потенциально опасным серверным или клиентским функциям (например перезаписать любой файл, выполнить код и т.п.)
спамхауз абузов от пользователей не принимает, абузы принимает, например, спамкоп. При этом там требуется регистрация. Защита в спамкоп (помимо защиты от автоматической регистрации) — во-первых в черный список можно попасть только по нескольким неразрешенным жалобам, во-вторых о каждой жалобе сообщается администраторам сетей с возможностью фидбека. Если будет много фидбека на ложные репорты, то соответственно закроют эккаунт того, кто их шлет.
Если хостер не захочет анонсировать сеть — то тут никуда не попрешь, только менять хостера. Лучше изначально ориентироваться на хостеров, которые предлагают услуги PI — они и клиента со своим PI взять всегда смогут, можно не меняя адресов переползти с одного хостинга на другой. Своего BGP с блекджеком и шлюхами поднять нельзя, для этого должен быть пиринг с теми провайдерами, через которых трафик пойдет.
У меня были аналогичные проблемы с 64-битной убунтой в качестве гвеста, сделал для себя вывод, что есть бага VirtualBox когда файл одновременно открыт в гостевой и хостовой системе. А возникать такая ситуация может, когда есть что-то отслеживающее изменение файла, в частности антивирус.
Ну это видимо спаморассыльщики экспериментировали с обратным адресом, при каком адресе больше процент доставки. Было в шаблоне что-то типа
%random%@%reverse%
при нем процент доставки будет небольшой, захотели сделать
%random%@%MX_domain_2ndlevel%
но пару раз промахнулись или редактор шаблонов криво реализован, или правили шаблон в шеле с криво выставленным TERM — поэтому в одном месте Reply-To прилип к X-Priority, а в остальных новый домен в обратном адресе добавили к старому вместо того, чтобы заменить его. В общем не удивляйтесь на спам — там может быть все что угодно.
«Слот на всякий случай» и три планки — не вариант, у вас двухканальная память, в двухканальном режиме она работает только тогда, когда в связанных слотах стоит память с одинаковыми характеристиками.
Но вообще-то не так это дорого. Если вы в хороших отношениях с провайдером, имеющим собственный LIR — то может быть и вообще бесплатно. Если через посредников, на этом специализирующихся — порядка $200/год за блок адресов.
А тогда не парьтесь и делайте проще — берите любую приватную сетку, например 10ю, назначайте оттуда диапазон, документируйте и давайте возможность поменять — так поступают даже достаточно крупные производители, тот же Microsoft для настроек удаленного доступа в отсутствии DHCP. А вот 169.254 для таких целей не годится, не должно быть двух сегментов где используются эти адреса.
Судя по описанному, это скорее готовая писишная платформа, у которой мак-адрес физического интерфейса будет или от производителя материнки или от broadcom/marvel. Решение без регистрации OUI есть — купить две сетевых карты, взять их MACи после чего торжественно запереть в сейф. Но как-то это не по-промышленному, использовать чужой OUI.
169.254 можно использовать только при выполнении всех условий:
1. «внешний» интерфейс всегда подключен или при его переподключении сбрасывается внутренний интерфейс
2. на внешнем интерфейсе имеется возможность поднять ARP-прокси, которая будет отвечать адресом внутреннего интерфейса, чтобы ни одно другое устройство не село на тот же адрес.
3. для адреса назначаемому внутреннему интерфейсу будут производиться проверки предусмотренные RFC 3927, чтобы убедиться, что он не занят.
И все равно это не гарантирует ничего, т.к. amazon используется эту сеть для своих серверов, например.
Знаю несколько крупных интернет-провайдеров, использующих 10.0.0.0/8 для клиентов, 192.168.0.0/16 для оборудования и 172.22.16.0/20 для собственной внутренней сети.
LGPL позволяет создать коммерческий проект с закрытым кодом, если весь лицензированный код вынести в отдельные библиотеки. Скорее, подходит просто GPL.
Так а причем тут блокирование ACK или RST? Нет там никакого блокирования, просто никто их не отправляет. ACK со стороны сервера не отправляется, т.к. данные из буффера не считываются, принимающая сторона не хочет получать новых данных. RST тоже никто не отправляет, для этого нет никаких причин — все идет строго по протоколу, ретрансмиты полученных ранее пакетов молча отбрасывается.
If the peer calls close() or exits, without having messed with
SO_LINGER, then our calls to read() should return 0. It is less clear
what happens to write() calls in this case; I would expect EPIPE, not
on the next call, but the one after.
If the peer reboots, or sets l_onoff = 1, l_linger = 0 and then
closes, then we should get ECONNRESET (eventually) from read(), or
EPIPE from write().
1. Целочисленные переполнения
2. Ошибки знаково-беззнаковых преобразований
3. Проблемы с аутентификацией и авторизацией, в т.ч. возможность подмены клиента или сервера, возможность релеинга данных авторизации, недостаточная или слабая аутентификация, повышение привилегий.
4. Передача незашифрованных данных или слабая криптография, replay-атаки
5. Различные DoS-атаки (исчерпание ресурсов одним запросом, флуд, установка большого числа параллельных соединений, установка «вечно живущих» соединений, блокировка ресурсов по запросу клиента и т.п.).
6. Доступ к потенциально опасным серверным или клиентским функциям (например перезаписать любой файл, выполнить код и т.п.)