Comments 39
UFO just landed and posted this here
да, так «они» и делали с жж на кануне выборов.
Это под большим вопросом, был ли ДДос.
Носик утверждал, что с американских прокси, ЖЖ был всё время доступен. Равно как и некоторые из России писали, что и у них ЖЖ спокойно открывается.
Так что есть повод задуматься: это происки кровавой гэбни, или неполадки внутри самого ЖЖ.
Носик утверждал, что с американских прокси, ЖЖ был всё время доступен. Равно как и некоторые из России писали, что и у них ЖЖ спокойно открывается.
Так что есть повод задуматься: это происки кровавой гэбни, или неполадки внутри самого ЖЖ.
Может быть через прокси и был доступен, но по крайней мере по трем различным американским ip адресам которыми я пользовался жж был недоступен.
Так точно. Ещё в прошлые случаи «ддос атак на ЖЖ» высказывались сомнения в том, что всё именно так, как они заявляют. Процитирую:
«Прочитал я тут в „Огоньке“ интервью со Светланой Иванниковой, руководителем LiveJournal Russia в компании SUP. Такие слезы, да еще в печатном виде, я видел впервые. И хацкеры нехорошие, и DDoS-ят они ЖЖ, и креста на них нет, и наказывать их надо отрубанием хвоста по самую шею. А потом взял и протестировал время выдачи странички. И получилось у меня слелующее:
А потом еще раз решил взять страничку и вот что увидел:
Когда-то давно, года три назад, времена ЖЖ были порядка 230 мсек. Тоже не сахар, но было терпимо. Но вот читаю интервью и вижу следующее: „Однако атаки, которые происходили 30 марта, 4 апреля и 6 апреля — это атаки очень высокой мощности. Легко понять, о чем я говорю, обратившись к цифрам. Например, 30 марта система, отвечающая за распределение входящей нагрузки по серверам LiveJournal, обрабатывала более миллиона одновременных соединений при средней норме 50 тысяч соединений. ЖЖ пришлось обслуживать в десятки раз больше запросов, чем обычно, и “отдавать» по 2 Гбит трафика в секунду вместо обычных 400 Мбит".
И стало мне смешно. Тут тот самый случай с ЖЖ, когда голова есть, а думай нету. Не буду говорить о том, как расставлены запятые. Это отдельная песня. Сначала стоит разделить 2 Гбит=2048 Мбит на 400 Мбит. Получается примерно 5. Т.е., нагрузка возросла всего-то в ПЯТЬ раз, а не в десятки раз, как это утверждается.
Ну ладно. Пойдем дальше. Посмотрим, что там у нас с миллионами соединений. Миллион соединений в секунду — это как минимум 2 миллиона пакетов с MTU=1500 байт. Или в 15000 бит. Байты стоит умножать на 10 для получения битов по той причине, что всегда в канале есть служебный трафик. Минимально служебный трафик дает прирост не больше 10-15% к полезному трафику. Да, еще не стоит забывать, что каждое соединение — это процедура HandShake (рукопожатие), при которой клиент и сервер обмениваются 4 пакетами — 2 шлет клиент, 2 в ответ шлет сервер, а уже после «рукопожатия» шлется запрос и получается ответ. Запросы и ответы так же упаковываются в пакеты. После окончания соединения происходит процедура «прощания». HTTP-протокол предусматривает упрощенную схему «рукопожатия» и «прощания». Но даже в этом случае для «рукопожатия» клиенту и серверу нужно обменяться по одному пакету, а «прощание» можно не делать, если в ответе указано Connection: close и в последнем пакете установлен флаг FIN. И так, имеем миллион пакетов в секунду, что равно 1000000 * 15000 бит = 15000000000 бит = 15000000 Кбит = 15000 Мбит = 15 Гбит. 15 Гбит в СЕМЬ С ПОЛОВИНОЙ раз превышает заявленную пропускную спосбность канала в 2 Гбит (см. цитату из интервью).
В общем, если был действительно миллион соединений, то это они сами там что-то «наваяли». Вряд ли провайдер, с кем они пирятся, сможет обработать такой поток. Это уже магистральные цифры. Да, чуть не забыл. 50000 соединений в секунду — это 50000 * 15000 бит = 1500000000 бит = 1500000 Кбит = 1500 Мбит = 1.5 Гбит входящего трафика. Исходящий будет 1 + 91849 / 1500 = 62.2 = 63 пакета. Следовательно, 50000 * 63 * 15000 = 47250000000 бит = 47250000 Кбит = 47250 Мбит = 47.25 Гбит. Эта цифра почти в ДВАДЦАТЬ ЧЕТЫРЕ раза больше заявленных 2 Гбит в пике и в СТО ДВАДЦАТЬ раз больше завленных 400 Мбит в штатном режиме. Куда ни кинь, где ни проверь, — везде цифры «не бьют». Это значит, что всем нам лапшу вешают на уши."
— вот такие высказываются сомнения. видимо, небеспочвенные.
«Прочитал я тут в „Огоньке“ интервью со Светланой Иванниковой, руководителем LiveJournal Russia в компании SUP. Такие слезы, да еще в печатном виде, я видел впервые. И хацкеры нехорошие, и DDoS-ят они ЖЖ, и креста на них нет, и наказывать их надо отрубанием хвоста по самую шею. А потом взял и протестировал время выдачи странички. И получилось у меня слелующее:
# ab http://realurix.livejournal.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking realurix.livejournal.com (be patient).....done
Server Software: GoatProxy
Server Hostname: realurix.livejournal.com
Server Port: 80
Document Path: /
Document Length: 91455 bytes
Concurrency Level: 1
Time taken for tests: 5.733 seconds
Complete requests: 1
Failed requests: 0
Write errors: 0
Total transferred: 91849 bytes
HTML transferred: 91455 bytes
Requests per second: 0.17 [#/sec] (mean)
Time per request: 5733.229 [ms] (mean)
Time per request: 5733.229 [ms] (mean, across all concurrent requests)
Transfer rate: 15.64 [Kbytes/sec] received
Connection Times (ms)
min mean[±sd] median max
Connect: 221 221 0.0 221 221
Processing: 5513 5513 0.0 5513 5513
Waiting: 589 589 0.0 589 589
Total: 5733 5733 0.0 5733 5733
А потом еще раз решил взять страничку и вот что увидел:
# ab http://realurix.livejournal.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking realurix.livejournal.com (be patient)...apr_poll: The timeout specified has expired (70007)Когда-то давно, года три назад, времена ЖЖ были порядка 230 мсек. Тоже не сахар, но было терпимо. Но вот читаю интервью и вижу следующее: „Однако атаки, которые происходили 30 марта, 4 апреля и 6 апреля — это атаки очень высокой мощности. Легко понять, о чем я говорю, обратившись к цифрам. Например, 30 марта система, отвечающая за распределение входящей нагрузки по серверам LiveJournal, обрабатывала более миллиона одновременных соединений при средней норме 50 тысяч соединений. ЖЖ пришлось обслуживать в десятки раз больше запросов, чем обычно, и “отдавать» по 2 Гбит трафика в секунду вместо обычных 400 Мбит".
И стало мне смешно. Тут тот самый случай с ЖЖ, когда голова есть, а думай нету. Не буду говорить о том, как расставлены запятые. Это отдельная песня. Сначала стоит разделить 2 Гбит=2048 Мбит на 400 Мбит. Получается примерно 5. Т.е., нагрузка возросла всего-то в ПЯТЬ раз, а не в десятки раз, как это утверждается.
Ну ладно. Пойдем дальше. Посмотрим, что там у нас с миллионами соединений. Миллион соединений в секунду — это как минимум 2 миллиона пакетов с MTU=1500 байт. Или в 15000 бит. Байты стоит умножать на 10 для получения битов по той причине, что всегда в канале есть служебный трафик. Минимально служебный трафик дает прирост не больше 10-15% к полезному трафику. Да, еще не стоит забывать, что каждое соединение — это процедура HandShake (рукопожатие), при которой клиент и сервер обмениваются 4 пакетами — 2 шлет клиент, 2 в ответ шлет сервер, а уже после «рукопожатия» шлется запрос и получается ответ. Запросы и ответы так же упаковываются в пакеты. После окончания соединения происходит процедура «прощания». HTTP-протокол предусматривает упрощенную схему «рукопожатия» и «прощания». Но даже в этом случае для «рукопожатия» клиенту и серверу нужно обменяться по одному пакету, а «прощание» можно не делать, если в ответе указано Connection: close и в последнем пакете установлен флаг FIN. И так, имеем миллион пакетов в секунду, что равно 1000000 * 15000 бит = 15000000000 бит = 15000000 Кбит = 15000 Мбит = 15 Гбит. 15 Гбит в СЕМЬ С ПОЛОВИНОЙ раз превышает заявленную пропускную спосбность канала в 2 Гбит (см. цитату из интервью).
В общем, если был действительно миллион соединений, то это они сами там что-то «наваяли». Вряд ли провайдер, с кем они пирятся, сможет обработать такой поток. Это уже магистральные цифры. Да, чуть не забыл. 50000 соединений в секунду — это 50000 * 15000 бит = 1500000000 бит = 1500000 Кбит = 1500 Мбит = 1.5 Гбит входящего трафика. Исходящий будет 1 + 91849 / 1500 = 62.2 = 63 пакета. Следовательно, 50000 * 63 * 15000 = 47250000000 бит = 47250000 Кбит = 47250 Мбит = 47.25 Гбит. Эта цифра почти в ДВАДЦАТЬ ЧЕТЫРЕ раза больше заявленных 2 Гбит в пике и в СТО ДВАДЦАТЬ раз больше завленных 400 Мбит в штатном режиме. Куда ни кинь, где ни проверь, — везде цифры «не бьют». Это значит, что всем нам лапшу вешают на уши."
— вот такие высказываются сомнения. видимо, небеспочвенные.
Человек интересно, конечно, считает, но пакеты всегда разные. В виду неоднородности сети (пакеты проходят через множество узлов, у которых MTU может значимо различаться) нельзя твёрдо говорить, что MTU = 1500 байт, скорее оно было в районе 1200-1400. Но даже если принять MTU == 1500, то даже в этом случае расчёт в принципе неправильные:
пакет формируется по принципу — заполняем сколько можем, остальное в следующем пакете. пустые данные в пакете не передаются. Таким образом handshake в среднем требует около 300 байт (3 пакета). Далее (не знаю точно протокол http, скорее всего передаётся в 3ем пакете handshake`а) идёт запрос. В запросе передаются различные параметры, урл и ряд заголовков, характеризующих ПО запрашивающее (какие технологии поддерживаются etc). Далее сервер обрабатывая запрос может запросить куки. После получения всех необходимых данных клиенту отдаётся страничка. И тут начинается узкое место — пока данные клиенту не отданы (например картинка 20Мб) соединение не сбрасывается. Если канал перегружен — скорость конкретного соединения проседает, но разорваться оно может только по таймауту молчания (за каждые несколько принятых пакетов клиент отсылает отчёты). Соединения могут висеть больше минуты. Так что по сути — вопрос лишь в том, сколько реальных соединений может выдержать распределяющий сервер LJ (интересно, кстати, сколько их).
Суть — с помощью DDoS`а можно реально перегрузить принимающий сервер и он будет еле отвечать клиентам. И проблема будет не в канале.
пакет формируется по принципу — заполняем сколько можем, остальное в следующем пакете. пустые данные в пакете не передаются. Таким образом handshake в среднем требует около 300 байт (3 пакета). Далее (не знаю точно протокол http, скорее всего передаётся в 3ем пакете handshake`а) идёт запрос. В запросе передаются различные параметры, урл и ряд заголовков, характеризующих ПО запрашивающее (какие технологии поддерживаются etc). Далее сервер обрабатывая запрос может запросить куки. После получения всех необходимых данных клиенту отдаётся страничка. И тут начинается узкое место — пока данные клиенту не отданы (например картинка 20Мб) соединение не сбрасывается. Если канал перегружен — скорость конкретного соединения проседает, но разорваться оно может только по таймауту молчания (за каждые несколько принятых пакетов клиент отсылает отчёты). Соединения могут висеть больше минуты. Так что по сути — вопрос лишь в том, сколько реальных соединений может выдержать распределяющий сервер LJ (интересно, кстати, сколько их).
Суть — с помощью DDoS`а можно реально перегрузить принимающий сервер и он будет еле отвечать клиентам. И проблема будет не в канале.
1200 байт — это уменьшение 1500 на проценты, но не в разы (7.5 раз). Чтобы получилось как у вас в расчётах, длина пакета должна быть всего 200 байт. Только и всего. Кроме того, исходящий трафик в 64 раза больше входящего. Это опять разы, а не проценты.
Да неважно это вообще. Это всё — теоретические измышления. В статье цитата: «Например, 30 марта система, отвечающая за распределение входящей нагрузки по серверам LiveJournal, обрабатывала более миллиона одновременных соединений при средней норме 50 тысяч соединений. ЖЖ пришлось обслуживать в десятки раз больше запросов, чем обычно, и “отдавать» по 2 Гбит трафика в секунду вместо обычных 400 Мбит»
Что у нас тут есть? Есть следующее «более миллиона одновременных соединений» — да легко, если соединения забирающие картинки — не закрылись, а новых навалилась куча. Другой вопрос — как они смогли столько соединений разрулить, но для этого существуют различные high-load механизмы. Скорее всего никак не разрулили — из-за мощного потока соединений сервер просто перегружался. В общем он пытался, но съедал на этом всю мощность и отвечал медленно.
Теперь по поводу счёта — счёт в данном случае бесполезен. Скорее всего сервер успевал обрабатывать только handshake. И соединения висели более чем по секунде. Пока сервер не получал хоть немного времени, чтобы обработать старые.
Далее MTU — максимальный размер пакета мало того, что не фиксированная величина (пакет имеет полное право быть меньше, либо равен MTU), так ещё и не подлежащая к использованию в данном контексте. Объясняю: поставьте на удалённой машине веб-сервер, ограничте к нему канал до 1Мбита/секунду и начните качать файл 20 Мбайта. Скачается файл за ~(20*9/1) = 180 секунд (3 минуты). Угадайте, соединение длилось 1 секунду и заново начиналось, или всё прошло в рамках одного соединения? Таким образом соединение длилось 3 минуты. Если с таким же каналом вы ткнётесь качать 10 таких файлов с сервера — каждый файл будет качаться медленнее, но соединения будет держаться. В конечном итоге ограничением является количество одновременных соединений, которое принимает сервер. Вот ровно по такой простой причине нет необходимости считать абстрактные цифры. Потому что просчитывается совсем другая ситуация, а не описанная.
PS сие была последняя попытка донести данную мысль, за сим прощаюсь.
Что у нас тут есть? Есть следующее «более миллиона одновременных соединений» — да легко, если соединения забирающие картинки — не закрылись, а новых навалилась куча. Другой вопрос — как они смогли столько соединений разрулить, но для этого существуют различные high-load механизмы. Скорее всего никак не разрулили — из-за мощного потока соединений сервер просто перегружался. В общем он пытался, но съедал на этом всю мощность и отвечал медленно.
Теперь по поводу счёта — счёт в данном случае бесполезен. Скорее всего сервер успевал обрабатывать только handshake. И соединения висели более чем по секунде. Пока сервер не получал хоть немного времени, чтобы обработать старые.
Далее MTU — максимальный размер пакета мало того, что не фиксированная величина (пакет имеет полное право быть меньше, либо равен MTU), так ещё и не подлежащая к использованию в данном контексте. Объясняю: поставьте на удалённой машине веб-сервер, ограничте к нему канал до 1Мбита/секунду и начните качать файл 20 Мбайта. Скачается файл за ~(20*9/1) = 180 секунд (3 минуты). Угадайте, соединение длилось 1 секунду и заново начиналось, или всё прошло в рамках одного соединения? Таким образом соединение длилось 3 минуты. Если с таким же каналом вы ткнётесь качать 10 таких файлов с сервера — каждый файл будет качаться медленнее, но соединения будет держаться. В конечном итоге ограничением является количество одновременных соединений, которое принимает сервер. Вот ровно по такой простой причине нет необходимости считать абстрактные цифры. Потому что просчитывается совсем другая ситуация, а не описанная.
PS сие была последняя попытка донести данную мысль, за сим прощаюсь.
У меня на практике было больше 900 тыс pps (соединений в секунду) и поток 500-700 мегабит. MTU не считал, было не до этого.
так ясно-понятно, что пакеты в MTU не упирались — иначе бы поток резко больше был (900 000 * 1400 * 9 ~ 10.7 Гбит/сек).
Я и пытаюсь объяснить — суть ддоса не в перегрузке канала байтами (за редким видом атак), а в перегрузке сервера левыми запросами, которые в канал очень редко упираются.
Ну и особенность http позволяет проводить более изощрённые атаки, ибо коннекты живут некоторое время.
Я и пытаюсь объяснить — суть ддоса не в перегрузке канала байтами (за редким видом атак), а в перегрузке сервера левыми запросами, которые в канал очень редко упираются.
Ну и особенность http позволяет проводить более изощрённые атаки, ибо коннекты живут некоторое время.
>> суть ддоса не в перегрузке канала байтами (за редким видом атак), а в перегрузке сервера левыми запросами, которые в канал очень редко упираются.
не всегда так, меня больше всего в процессе защиты напрягало и пугало именно то, что могли заткнуть канал. Это на самом деле проще сделать, чем собрать многотысячный ботнет.
Достаточно несколько дедиков с руткитами на мощных каналах(а их порой собрать не так тяжело, например среди гореадминов ммпорг серверов на ворованных сборках, которые ставят чтопопало думая, что линукс умный и сам их защитит), чтобы выдать мощный поток. И пока будешь их отстреливать по одному, ругаясь с ДЦ абузами, ваш сервис будет лежать.
Чаще ДЦ предоставляют 1гбит порт на 1 сервер, если нужно больше, уже идет немного другой уровень цен, да и глупо и дорого держать такой канал ради того чтобы тебя пару дней поддосили.
Можно конечно масштабироваться горизонтально по мере надобности, но тут уже задача не для каждого проекта решается с разбегу (а обычно времени резко перестроить инфраструктуру времени нет, ибо обычно все прогнозировалось под другие нагрузки).
Балансировать трафик тоже как-то нужно, при чем так, чтобы балансировщик не заткнулся тем же гигабитом.
не всегда так, меня больше всего в процессе защиты напрягало и пугало именно то, что могли заткнуть канал. Это на самом деле проще сделать, чем собрать многотысячный ботнет.
Достаточно несколько дедиков с руткитами на мощных каналах(а их порой собрать не так тяжело, например среди гореадминов ммпорг серверов на ворованных сборках, которые ставят чтопопало думая, что линукс умный и сам их защитит), чтобы выдать мощный поток. И пока будешь их отстреливать по одному, ругаясь с ДЦ абузами, ваш сервис будет лежать.
Чаще ДЦ предоставляют 1гбит порт на 1 сервер, если нужно больше, уже идет немного другой уровень цен, да и глупо и дорого держать такой канал ради того чтобы тебя пару дней поддосили.
Можно конечно масштабироваться горизонтально по мере надобности, но тут уже задача не для каждого проекта решается с разбегу (а обычно времени резко перестроить инфраструктуру времени нет, ибо обычно все прогнозировалось под другие нагрузки).
Балансировать трафик тоже как-то нужно, при чем так, чтобы балансировщик не заткнулся тем же гигабитом.
Согласен, как вариант — если посмотреть на твиттер за последнюю неделю (по всяким «политическим» запросам), количество ссылок на ЖЖ выросло в несколько раз, не возьмусь конечно оценивать, но думаю, что в период выборов и по текущий момент посещаемость ЖЖ выросла резко и сильно. Хотя бы из-за многочисленных ссылок на статьи про намечающийся митинг, ссылки на которые в том же Вконтакте народ ставит в статус по 50 раз в минуту.
Проблемы были не только у ЖЖ, но так же и у ряда СМИ и организаций. Вероятно, у них действительно у всех разом 4.12 просто сломались сервера, как я раньше не догадался.
Пока у нас оптические компьютеры не распространены, так что в конце концов будет в «форме электрических сигналов». Ну и аренда вредоносного ПО замечательно попадает под «использование», что закрывается законодательством.
Поэтому, если будет желание и воля — закон применят. А если их нет, то и сейчас он не работает.
Поэтому, если будет желание и воля — закон применят. А если их нет, то и сейчас он не работает.
Вы явно блогом промазали…
Извините за занудство, новость конечно актуальная и интересная, но это не повод нарушать правила — весь топик чистой воды копипаст.
«Создание,
использование и распространение...»
Совсем не обязательно в совокупности, просто использование тоже попадает под удар — хоть арендуй, хоть покупай, вроде бы.
использование и распространение...»
Совсем не обязательно в совокупности, просто использование тоже попадает под удар — хоть арендуй, хоть покупай, вроде бы.
> DDoSить можно отныне!)))
Скобки-смайлики? На главной странице Хабра? Нет-нет, это сон, мне причудилось.
Скобки-смайлики? На главной странице Хабра? Нет-нет, это сон, мне причудилось.
UFO just landed and posted this here
Вполне ожидаемо.
Не судить же собственных ДДоСеров.
А на проблемы людей, которые возникнут с принятием этого закона, власти разумеется плевать.
Не судить же собственных ДДоСеров.
А на проблемы людей, которые возникнут с принятием этого закона, власти разумеется плевать.
Судить за такие атаки по статье «Создание, использование и распространение вредоносных компьютерных программ» не всегда можно, поскольку часто киберпреступники не создают, а выкупают или арендуют уже действующие ботнеты для проведения атак.
Не создают, но используют — слово «использование».
С другой стороны, что, если какой-нибудь вконтакт вставит такое на каждой странице?
(new Img).src = "{адрес целевого сайта?}";
Хотя это может попасть под «Создание вредоносных компьютерных программ»
А что, если напишет «перейдите на сайт такой-то» с целью, чтобы количество пользователей сложило сайт.
Очень часто, например, на bash.org.ru появляются предложения ддосить определённые сайты и, иногда, у них это удаётся.
> Создание, использование и распространение вредоносных компьютерных программ.
Умное решение. Зловреды часто создаются в целях образования. Вирусы сами по себе интересны, только payload обычно безвреден. Другое дело, когда человек использует, либо свое, либо чужое для нанесения вреда другой стороне. За это надо наказывать.
Что бы понять всю соль шутки, в 2010 году у меня был курс в универе Information Security. Всю практику можно было проходить только на специально выделенной машине. Писать какие либо зловреды вообще запрещалось. Все почему? Потому, что по нашим законам (Нидерланды) сам факт несанкционированного доступа (попробовал пароль к root'у qweqwe и получилось зайти по ssh, тут же вышел) или написание зловреда уже уголовно наказуемо (20к штрафа + срок по моему) и не важно в каких целях это было. На выделенную машину ломиться было можно, потому, что было письменное разрешение (санкционированный доступ) до нее в форме допускающей не стандартные методы. Для «зловредов» такую уловку не сделать. Просто аудит любой системы (даже купленной) сделать нельзя без письменного разрешения производителя (Microsoft требует перед публикацией результатов все согласовывать с ними). Повторюсь, не важно для каких целей был выполнен анализ/доступ/взлом и на каких машинах (софт у себя на собственной ВМ). Шутки шутками, но скоро может сбыться предсказание RMS, что дебаггер можно будет иметь только сертифицированным программистам, для остальных - это инструмент для анализа и последующего взлома софта.
А в России поняли, что судить надо за зловредные действия, а не инструменты. По DDoS'у все выше написали, на момент ажиотажа трафик растет лавинообразно, если севера были не готовы к этому, они лягут. Сам факт DDoS'a привязать к конкретному человеку сложно, зато это могла бы быть удобная статья сажать нерадивых блоггеров за решетку, а улики притягивать «за уши». Ну а правительству, что бы кого-либо DDoS'ить, закон не нужен.
Умное решение. Зловреды часто создаются в целях образования. Вирусы сами по себе интересны, только payload обычно безвреден. Другое дело, когда человек использует, либо свое, либо чужое для нанесения вреда другой стороне. За это надо наказывать.
Что бы понять всю соль шутки, в 2010 году у меня был курс в универе Information Security. Всю практику можно было проходить только на специально выделенной машине. Писать какие либо зловреды вообще запрещалось. Все почему? Потому, что по нашим законам (Нидерланды) сам факт несанкционированного доступа (попробовал пароль к root'у qweqwe и получилось зайти по ssh, тут же вышел) или написание зловреда уже уголовно наказуемо (20к штрафа + срок по моему) и не важно в каких целях это было. На выделенную машину ломиться было можно, потому, что было письменное разрешение (санкционированный доступ) до нее в форме допускающей не стандартные методы. Для «зловредов» такую уловку не сделать. Просто аудит любой системы (даже купленной) сделать нельзя без письменного разрешения производителя (Microsoft требует перед публикацией результатов все согласовывать с ними). Повторюсь, не важно для каких целей был выполнен анализ/доступ/взлом и на каких машинах (софт у себя на собственной ВМ). Шутки шутками, но скоро может сбыться предсказание RMS, что дебаггер можно будет иметь только сертифицированным программистам, для остальных - это инструмент для анализа и последующего взлома софта.
А в России поняли, что судить надо за зловредные действия, а не инструменты. По DDoS'у все выше написали, на момент ажиотажа трафик растет лавинообразно, если севера были не готовы к этому, они лягут. Сам факт DDoS'a привязать к конкретному человеку сложно, зато это могла бы быть удобная статья сажать нерадивых блоггеров за решетку, а улики притягивать «за уши». Ну а правительству, что бы кого-либо DDoS'ить, закон не нужен.
> информация определяется как «сведения […] представленные в форме электрических сигналов, независимо от средств их хранения, обработки и передачи».
> Однако в данной ситуации возникает неопределенность, поскольку компьютерные сети также используют оптоволокно, в которых данные передаются с помощью света, а не электрических сигналов.
Ну и где здесь неопределённость?
> Однако в данной ситуации возникает неопределенность, поскольку компьютерные сети также используют оптоволокно, в которых данные передаются с помощью света, а не электрических сигналов.
Ну и где здесь неопределённость?
Ждем топика «DDoSить можно доколе!?»
«К примеру, в статье «Неправомерный доступ к компьютерной информации» такая информация определяется как «сведения […] представленные в форме электрических сигналов, независимо от средств их хранения, обработки и передачи». Однако в данной ситуации возникает неопределенность, поскольку компьютерные сети также используют оптоволокно, в которых данные передаются с помощью света, а не электрических сигналов» — всё равно в конечной точке — компьютере — сигналы электрические. Лазейка появится только после создания «оптических» компьютеров, но тогда, наверное, внесут соответствующую поправку.
Можно уточнить, электромагнитные волны оптического диапазона частот электрическими сигналами не считаются?
И тут добрались до корпускулярно-волнового дуализма. Ну что за люди, вместо того, чтобы философствовать что такое свет: волна или поток фотонов, лучше бы писали законы которые реально помогают бороться с преступностью.
UFO just landed and posted this here
«Создание, использование и распространение вредоносных компьютерных программ»
Всегда доставляла эта статья УК. Фактически, человека можно посадить только за то, что у него на компе троян.
Всегда доставляла эта статья УК. Фактически, человека можно посадить только за то, что у него на компе троян.
Нельзя, так как человек его не создавал, не использует, и распространяется он сам без его согласия.
1) Не путайте термин «троян» с термином «червь».
2) Не смотрите на то, что слова через запятую. Если подробнее прочитать закон, то фактически судят за каждый из этих пунктов.
То-есть, Вы скачали пособие по вышиванию со стороннего сайта, а в нём троян. Вы запустили. Результат — использование вредоносной программы.
Другой пример: Вы скачали тот же файл, а в нём файловый червь. Червь мигом залез на флешку, которую Вы в последствии дали кому-нибудь другому, либо вставили в чужой компьютер. Результат — распространение вирусов.
А с вашим согласием это произошло или нет — в суде это будет звучать примерно как про наркотики в багажнике «это не моё! меня подставили!».
В общем, это лазейка в законодательстве, с помощью которой при желании можно посадить практически любого. А всё из-за того, что законы РФ в сфере информационных технологий абсолютно абсурдны, о чём автор статьи лишний раз подтверждает.
2) Не смотрите на то, что слова через запятую. Если подробнее прочитать закон, то фактически судят за каждый из этих пунктов.
То-есть, Вы скачали пособие по вышиванию со стороннего сайта, а в нём троян. Вы запустили. Результат — использование вредоносной программы.
Другой пример: Вы скачали тот же файл, а в нём файловый червь. Червь мигом залез на флешку, которую Вы в последствии дали кому-нибудь другому, либо вставили в чужой компьютер. Результат — распространение вирусов.
А с вашим согласием это произошло или нет — в суде это будет звучать примерно как про наркотики в багажнике «это не моё! меня подставили!».
В общем, это лазейка в законодательстве, с помощью которой при желании можно посадить практически любого. А всё из-за того, что законы РФ в сфере информационных технологий абсолютно абсурдны, о чём автор статьи лишний раз подтверждает.
Вы ошибаетесь. Я так, слегка, юрист поэтому вижу это ясно. Что-то вам доказывать или читать курс лекций я не хочу.
Дальше можете спорить с интернетом по ключевым словам:
«состав преступления»
«субъективная сторона»
«Глава 5 УК РФ 'Вина' „
PS. Напишите другой “не абсурдный» законопроект. Было бы любопытно ознакомиться.
Дальше можете спорить с интернетом по ключевым словам:
«состав преступления»
«субъективная сторона»
«Глава 5 УК РФ 'Вина' „
PS. Напишите другой “не абсурдный» законопроект. Было бы любопытно ознакомиться.
UFO just landed and posted this here
Кодифицированный закон в романо-германской системе права — это попытка ответа на не только существующие, но и принципиально возможные угрозы. Это достигается гибкостью и общностью формулировок. И ничего плохого в этом, вобщем то нет. Другое дело, что недостаточная компетентность законодателей иногда влечёт неточность этих формулировок.
«Называть вещи своими именами», не определяя и не характеризуя их — это вообще тупик. Суд превратится в разгребание узкоспециальных терминологических дебрей. К тому же частность формулировок предполагает радикальное увеличение количества норм.
«Называть вещи своими именами», не определяя и не характеризуя их — это вообще тупик. Суд превратится в разгребание узкоспециальных терминологических дебрей. К тому же частность формулировок предполагает радикальное увеличение количества норм.
Ддос это статья 274, а если ещё и ботнет, то + 273. Как до поправок, так и после.
Теперь насчёт оптики. Полностью оптических компьютеров, насколько мне известно, не сучществует, так что изменяем мы так или иначе «сведения […] представленные в форме электрических сигналов» и именно что «независимо от средств их хранения, обработки и передачи». НЕЗАВИСИМО ОТ СРЕДСТВ ПЕРЕДАЧИ. Будь это хоть оптика, хоть гидравлика, хоть черепашья почта.
Sign up to leave a comment.
DDoSить можно отныне!?