Недорогой способ защиты от HTTP-флуда

    Случилась на днях, как всегда, не в самый подходящий момент, DDoS-атака на один из сайтов, размещенных на моем сервере. DDoS-атаки бывают разные, в этот раз злоумышленники запустили HTTP флуд.

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

    Железные решения я считаю правильным выбором, но доступны они не всем и не всегда, а многие атаки, как показала моя практика, успешно отбиваются правильным использованием доступных программных средств. К тому же, захотелось немного поэкспериментировать.



    После детального изучения возможностей давно и вполне успешно используемой мною связки nginx + Apache и документации к nginx родилось решение на базе модуля ngx_http_limit_req_module.

    Этот модуль позволяет ограничить число запросов для заданной сессии или с одного адреса. Я не буду детально описывать его возможности, документация доступна всем желающим.

    Что я сделал



    Я проверил, собран ли nginx с модулем ngx_http_limit_req_module и внес в конфигурационный файл сервера следующие строки:

    http {<br>    # Директива описывает зону, в которой хранятся состояния сессий. <br>    # Значения сессий определяется заданной переменной. <br>    <br>    limit_req_zone $binary_remote_addr zone=one:10m  rate=2r/s;<br>    <br>    # В данном случае состояния сессий хранятся в зоне "one" размером <br>    # 10 мегабайт и средняя скорость запросов для этой зоны не может <br>    # более 2 запросов в секунду. <br>    <br>    # Данный случай частный лично для моей <br>    # ситуации и подбирается индивидуально.<br>    <br>    ...<br>    <br>    # Атакуемый домен.<br>    server {<br><br>        ...<br><br>        location / {<br>            # Директива задаёт зону (zone) и максимально возможные всплески<br>            # запросов (burst). Если скорость запросов превышает описанную <br>            # в зоне, то их обработка запроса задерживается так, чтобы запросы <br>            # обрабатывались с заданной скоростью. Избыточные запросы задерживаются<br>            # до тех пор, пока их число не превысит <br>            # заданное число всплесков. В этом случае запрос завершается кодом <br>            # "Service unavailable" (503).<br>            <br>            limit_req  zone=one burst=4;<br>        }<br><br>* This source code was highlighted with Source Code Highlighter.


    * пример конфигурации и пояснения со страницы документации по модулю


    Что я получил



    Все боты, которые с неистовой частотой «долбили» сервер, начали получать в ответ http- ошибку 503. А выбрать с логов IP ботов например так:

    tail -1000 /var/log/nginx-access.log | grep " 503 " | cut -f1 -d" " | sort -u


    И после этого занести их в таблицу фаервола (у меня FreeBSD и IPFW) проще некуда, равно как и поставить это все в crontab.

    Вот, собственно, и все. На оригинальность идеи я не претендую, спасибо Игорю Сысоеву за реализацию nginx и данного модуля к нему.

    Надеюсь, этот вполне доступный способ защиты от динамичного и интенсивного по частоте запросов HTTP-флуда будет вам полезен.

    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 100
    • +1
      Конфиг уже был использован в бою, я так понял? Какие результаты по сравнению с железкой? Железку примерно какого уровня стоимости он может заменить?
      • 0
        Да, он уже более двух недель помогает мне бороться с флудом суммарной мощностью ~ 34 Mb/s. Сравнивать с железками трудно — так как задачи у них немного, но все же разные. На уровне атакуемого сервера не совсем верно решать вопросы с атаками, но когда другого выбора нет — то очень даже вполне. Касаемо ценового вопроса, то 34 — 40 Mb/s. способны «переживать» железки стоимостью не более 400 — 500$ + цена за размещение этой железки в дата-центре.
        • 0
          Но я так понимаю, что в железных решениях тоже крутится какая-то специализированная ось и какие-то конфиги, так? В тех же цисках?
          • 0
            Само собой, любая железка, будь то решение от Cisco, D-link и т.п. — это всего лишь куча микросхем в красивой обертке. Без грамотной конфигурации сего железа это и дальше будет грудой «железа».
            • 0
              интересно было бы увидеть конфиг циски для общего ознакомления.
              • 0
                Вряд ли Вы найдете человека который вот так выкинет в паблик рабочий конфигурационный файл от любой Cisco. А в качестве примеров ничего лучше нет эмуляторов работы с Cisco — там и IOS пообновляете, и конфигурации посмотрите, даже сети построите.
                • 0
                  Ну, вот вполне рабочий конфиг от Cisco Anomaly Guard, вот — конфиг от Cisco Anomaly Detector.

                  Никакого особого секрета в них нет. Ключи-пароли, конечно, я поудалял. Адреса там приватные.
              • +1
                Ага, в линейке cisco это cisco guard xt, плюс к ней нужно cisco PIX firewall…
                первая весь трафик смотрит и в случае аномалии отправляет сигнал PIX и тот блокирует траф…
                цены конечно кусаются от 30к зеленых =)
                • +1
                  У вас устаревшие сведения, оба продукта уже не продаются.
                  • 0
                    Guard продается, но в виде модуля для 6500. PIX заменен линейкой ASA.
                    • 0
                      Причем линейка ASA более продвинутая чем PIX, и модульность пошла только на пользу.
            • 0
              При обычном флуде — до уровня мгновенной заливки канала. А дальше в любом случае конец. :)

              Если прикрутить еще и проверку по cookie + кэширование + грамотно настроенный firewall, то продавить «это» обычным HTTP-flood/SYN-flood практически невозможно, за исключением опять-таки заливки каналов десятками\сотнями\гигабитами, в зависимости от ширины канала и железа. При условии, что железо — не celeron/512RAM/IDE HDD и не VDSка.

              Другое дело, что боты сейчас стали умными, и в тупую долбят «HTTP 1.1 /» уже единицы. Нормальные боты и страницы меняют, и user agent, и referrer. А самые умные уже даже cookie сохранять научились.
            • НЛО прилетело и опубликовало эту надпись здесь
              • +1
                Когда как, на самом деле
                • –1
                  Канал забить, особенно хороший, нужен нормальный такой ботнет. Например, серверный :-) Чаще на каком-нибудь хилом хостинге тупо тормозит или падает сервак.
                  • 0
                    Сейчас пожалуй не сколько канал ( учитывая сейчашнюю их ширину), а подвесить сайт забив всё процессорное время нагрузив по максимуму серверный софт
                    • 0
                      Бывают и такие атаки, которые именно канал забивают. Например, мощные сервера стоят, балансировка, циски — тут проще нанять большой ботнет и забить канал.
                      • 0
                        Совершенно верно. При сегодняшних возможностях магистральных каналов, узким местом на мой взгляд является серверный софт, вернее даже не серверный, а клиентский.
                        • 0
                          Когда нас досили, то до забивки канала было ещё очень далеко, софтом дос распознавался и резался тоже довольно хорошо, а вот всякие буфера ОС и лимиты числа сетевых соединений кончались довольно быстро. И машика падала…
                          • 0
                            В большинстве OS все буферы и тайминги довольно хорошо поддаются подкрутке. У меня была атака на один из наших DNS серверов — просто шли «кривые» запросы которые вводили bind и вместе с ним сервер в дикий ступор, долго ничего не мог поделать пока не разобрался в том, что все сокеты заняты — подкрутил на горячую через sysctl и смог нормально разобраться с вредоносным трафиком.
                            • 0
                              Ну вот у нас не вышло, как только ни крутили, всё равно забивалось. К сожалению, в деталях сказать не могу, не я админил всё это…
                        • +1
                          У нас «труба» 1 Gbit/s. Забить её простыми http — запросами…. это какой же ботнет надо содержать… У меня не размещено проектов, на которые экономически целесообразно было бы проводить атаки такого уровня.
                          • 0
                            А сколько, кстати, стоит атака, забивающая 100 мегабит и 1 гигабит?
                            • 0
                              Тут я Вам, Алексей, не помощник — цен не знаю. Тут простая математика — один запрос в моем случае «весит» 62 байта, вот и подсчитайте сколько надо таких запросов отправить в единицу времени что бы суммарный поток трафика достиг предела моего канала, разделите к примеру на 7 (число запросов с одного зомби в момент времени) и получится приблизительное количество зомби в ботнете. Вряд ли содержание такого ботнета стоит дешево.
                              • 0
                                Хм, интересно, а какие расходы на содержание ботнета? Какие составляющие там в расходах?
                                • 0
                                  Могу ответить основываясь лишь на предположениях и логике — для того, что бы все это функционировало, нужно «доставить» вирус или что там, на уязвимую машину, связать все воедино с центром управления, и следить за работоспособностью этого хозяйства, и это параллельно постоянному процессу детектирования и распознаванию антивирусами этих программ. Исходя из того, что написание программы которая и реализует функционал ботнета вряд ли занятие для энтузиастов, то это скорее всего так же несет некие затраты.
                                  • 0
                                    Была ведь ссылка на статью Экономика ботнетов
                                    >> средняя цена составляет $0,5 за один бот
                                    Конечно цены варьируются сильно от задач и т.д.
                                    Вот и считайте.
                                • 0
                                  Если верить людям, которые нас досили, то 100Мбит стоит около $350-400/сутки (цены 2007 года).
                                  • 0
                                    таким людям нет веры ((:
                                    • +1
                                      Это они нам сообщали в контексте «нам [вырезано цензурой] 400 баксов в день не жалко чтобы вас, [вырезано цензурой], завалить [вырезано цензурой]» :)
                              • 0
                                Это если пингуют. Сейчас в моде TCP SYN-Flood атаки, когда веб-серверу отсылается большое количество запросов, а ответ никто на забирает уже. В результате веб-сервер жрет процессорное время и память, как безумный, плюс ядро тоже начинает откушивать ресурсы на поддержание толпы коннектов.
                                • 0
                                  нжинкс фронтендом в общемто решает эту проблему. даже без файрвольных хитростей
                                  • 0
                                    Ну я и не отрицаю этого :) Нам, правда, приходилось отбиваться самописным шелл-скриптом и pf, ибо нгинкс никак не получалось поставить.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                      • 0
                                        Тоже удивился, когда прочитал… Причем здесь SYN-Flood к Nginx?
                                        • 0
                                          Они про slowlory, наверное.
                                      • +1
                                        Use syncookies, Luke ;)

                                        У Сысоева на highload был хороший доклад о настройке FreeBSD на обработку большого числа соединений — вполне применимо к ДДОСу.
                                        • 0
                                          Мы это делали в 2006 году первый раз, про Сысоева тогда близко не знали ничего :)
                                        • 0
                                          accept() срабатывает только после завершения tcp-handshake, так что флуд SYN-пакетами до прикладных программ не доходит
                                      • +2
                                        Можно еще добавить автоматическое разбанивание по прошествии определенного срока — недели, например, или месяца, если атака затяжная. Ведь среди атакующих большинство компьютеров — ваши потенциальные пользователи.

                                        Плюс туда могли попасть и случайные пользователи, которые, например, пытались стянуть сайт телепортом, или еще каким пауком. И, самое интересное, что туда же могли попасть и админы сайта, которые с постороннего ip, например, сливают файлы по FTP. (меня так мой хостер регулярно банит, я знаю о чем говорю :)
                                        • 0
                                          Можно еще добавить автоматическое разбанивание по прошествии определенного срока — недели, например, или месяца, если атака затяжная. Ведь среди атакующих большинство компьютеров — ваши потенциальные пользователи.

                                          Конечно можно, даже более того, нужно. Но это уже явно не задача nginx, как минимум тех скриптов, которые парсят логи, в моем случае это 5 скриптов на perl.

                                          И, самое интересное, что туда же могли попасть и админы сайта, которые с постороннего ip, например, сливают файлы по FTP.


                                          Для этого существует «белые списки» адресов, которые каждый администратор имеет возможность дополнить через web- морду.
                                          • 0
                                            Белые списки… так у вас же админы попадают в блеки :) нафиг таких админов, они по белому задосят :D
                                            • +1
                                              Сегодня только модератор жаловался что не может из дома попасть на сайт, из под 1 IP выходят 4000 пользователей, какая то машина из числа этих 4000 пользователей была заражена и скрипты забанили на фаерволе этот грешный 1 IP… Вот свежайший пример из жизни. 

                                              В итоге сам модератор решал вопрос со своим провайдером в части поиска того, кто флудит наш сайт. Так как открывать этот IP пока с него идет флуд я отказался.
                                              • 0
                                                Ну вощем-то его это проблемы, так вот они и решаются :)

                                                Я бы не пожалел копеечку на свой собственный белый адрес.
                                          • 0
                                            Разбанить можно будет всех как атака прекратится. Обычно это не особо затяжное действо.
                                            • 0
                                              нуну… у меня есть сайты которые чаще ддосят чем наоборот…
                                              • +1
                                                что же вы хостите, если вас так часто ддосят?
                                            • 0
                                              Я думаю, все китайские и индийские айпи, а также подсетки абузоустойчивых хостингов можно нафиг и не разбанивать.
                                              • –1
                                                а как определит ип абузоустойчивых хостингов?
                                                а всякие spamhouse и «aggregate list combines Harvesters, Spammers and SMTP Dictionary attacks from the PHP IP Data » листы у меня APF режет и так
                                            • +1
                                              Метод действенный для небольших атак, но увы часть запросов всё-равно сначала поступит к серверу, прежде чем начнут блокироваться, а если ставить слишком маленький лимит то это начнёт доставлять неудобства пользователям. У себя например мы фильтруем запросы по определённым параметрам — в данный момент это user-agent'ы браузеров атакующих компьютеров. Конечно, это не всегда эффективно но спасает от большинства атак из-за бугра. Сначала nginx отдаёт ботам код 444, затем по крону IP достаются из лога и отправляются в фаерволл. В итоге 99% недействительных запросов фильтруются и не достигают бекэнда. Правда, для начала необходимо достать эти самые user-agent'ы, их может быть до 20-40. На практике удавалось смягчать атаки до 15к запросов/сек при 10-15к ботнете. Замечу, что боты часто и не делают больше нескольких запросов в секунду — и остановить такие атаки описанным выше методом невозможно. Экспериментируйте :) нет одного простого решения которое остановит любую атаку.
                                              • +1
                                                Абсолютно согласен с Вами — универсального способа не существует. Для каждой новой атаки я вот и «сочиняю» новые софтовые решения, не по тому что нет аппаратных возможностей для фильтрации вредоносного трафика, а потому что интересно побороть атаку не стандартным методом.

                                                Особенностью же этой атаки были вполне легитимные рандомные запросы и user-agent`ы — никаких отличий от действий нормального пользователя за исключением частоты запросов. Как вариант пробовал анализировать состояния соединений с помощью netstat, смотрел трафик на предмет выделения одной сигнатуры, но ничего более эффективного, чем описанное мною решение из софтовых вариантов у меня не вышло.
                                                • 0
                                                  есть основной подход — частотный анализ запросов. а юзерагенты конечно давно неактуальный
                                              • +2
                                                Нечто подобно пару лет уже использую (ранее только с limit_conn в nginx) + более сложный перловый скрипт, анализирующий с какого ип пришло более чем разрешено одинаковых запросов в еденицу времени.

                                                Отбивал атаки порядка 15к ботов в час. на core2duo 2.4

                                                но, на линухе. там есть особенно полезный патч ядра (оформляется модулем без пересборки ядра) — ipset
                                                удобство в возможности задания времени жизни включения в сет
                                                и в том что сет имея до 65к /32 включений ни разу не тормозит.

                                                Кстати, както было особенно настырная атака, держали адреса по неделе в сете, так 65к исчерпали,
                                                ничего, завели 10 сетов и небольшой баш скрипт проверки прежде чем добавлять… и все было ок
                                                • 0
                                                  я имел ввиду что такой поход с ограничением рейто в нжинксе недостаточен для отражения более-менее серьезных атак без отлова и фильтрации (временно) ддосящих ип.
                                                  • 0
                                                    Я упомянул в заметке, что извлечь из логов nginx IP атакующих не проблема — у меня это делают перловые скрипты, которые и добавляют записи в таблицу фаервола сервера.
                                                • +2
                                                  интересный топик, причем интересный поднятой темой и обсуждением. + в ..(ну вы поняли куда)… однозначно.
                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                    • +1
                                                      Испорченный IP так же просто определяется как и подделывается, а далее кто мешает запретить принимать пакеты от таких IP ? Antispoof — фильтры есть практически в каждом нормальном фаерволе, я не говорю про серьезные «железные» решения.

                                                      Или я ошибаюсь?
                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                      • –1
                                                        Обычно досеры детей не обижают таким флудом
                                                        • 0
                                                          От SYN Flood легко защититься, используя механизм SYN Cookies.

                                                          В Linux достаточно просто их включить: sysctl -w net.ipv4.tcp_syncookies = 1. Работать они начинают после того, как TCP backlog достигнет определенной величины, по умолчанию 1024. Изменить размер TCP backlog можно так: sysctl -w net.ipv4.tcp_max_syn_backlog=2048. Обычно, для не черезвычайно нагруженных серверов значения по умолчанию достаточно.

                                                          В FreeBSD помимо SYN cookies есть еще SYN cache — это, грубо говоря, дополнительный буфер, где хранится информация о неподтвержденных SYN. Его существование улучшает (во всяком случае — должно) производительность обработки кратковременных всплесков SYN-запросов (навроде, как раз Opera, которой может в голову придти открыть несколько соединений одновременно). Там настройки более хитрые, здесь пересказывать я не буду, посмотрите подробное описание, если интересно.

                                                          В винде есть некое подобие SYN Cache, насколько мне известно, но нет SYN Cookies. Но поскольку, КМК, никто в здравом уме винду все равно не использует для нагруженных веб-хостов (и, пожалуйста, не раздувайте флейм про майкрософт.ком и другие их проекты, ясно, что это дело чести), это не очень страшно. Кроме того, можно поставить перед виндой какой-нибудь файвол, который будет уметь SYN cookie.
                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                            • 0
                                                              Дефинируйте, пожалуйста, «серьезное».
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                            • 0
                                                              «икто в здравом уме винду все равно не использует для нагруженных веб-хостов»

                                                              мсье, а как же windows хостинг? тот же хостер «1GB» сервера которго по большей части виндовые.
                                                            • +1
                                                              SYN-flood очень легко и непринужденно обрезается включением SYN-cookies.
                                                            • +2
                                                              DDoS атаки режим ооочень просто. Главное выявить ip реального пользователя от бота. Как? очень просто. На примере: висит програмулька, мониторит нагрузку канала. Возрастает до 80% загрузка канала, активируем panicMode, на всех сайтах автоматом догружается скрытый iframe. Боты не используют бровзер, соотвественно этот скрытый iframe не видят, а реальный клиеты грузят. IP реальных клиентов поподают в белый список(через запрос этого iframe, все остальный в бан на iptables.
                                                              Нагрузка канала спадает до 70% iptables сбрасывается, panicMode выключается и всё ок.

                                                              SYN атаки нормально настроенной системой режутся в разы.
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                • 0
                                                                  Уважаемый, очередь пакетов? или вы о чём? растолкуйте пожалуйста.
                                                                  • +1
                                                                    Про syncookies вам не рассказали, да ведь?

                                                                    Про то, что число и периодичность SYN можно лимитировать файрволом, можно блочить тех, кто посылает больше N в T времени, тоже, правда?
                                                                    • 0
                                                                      видимо про net.ipv4.tcp_syncookies=1 мало кто знает =:)
                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                        • 0
                                                                          Подбираете net.ipv4.tcp_max_syn_backlog, в iptables ограничиваете количество syn пакетов с --limit.
                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                            • 0
                                                                              фейковые запросы очень быстро залитают в бан к iptables, собственно да в момент атаки есть небольшие трудности с работой обычных пользователей, но достучавшись впервый раз до ifram´а вы в белом листе и syn лимит вам не страшен =)
                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                • 0
                                                                                  такой нагрузки небыло… до 30к пакетов было =) а больше как себя поведет нужно пробывать… у вас есть чем попробывать? с удовольствием =)
                                                                                  • 0
                                                                                    200к пакетов в секунду вам уже не backlog, а interrupt queue забьют, там уже не важно какие это будут пакеты, против таких DDoS'ов отбиться простым софтварным способом практически нереально
                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                      • 0
                                                                                        да кто будет гнать на вас по несколько миллионов пакетов в секунду? никто не спорит для большых проэктов обезательно иметь железку с модными наклейками по 40к. Для пар проэктов на wordpress'e что тоже будете тратить от 40к на защиту от DDoS?
                                                                                        Да с такой нагрузкой первое что сделает датацентр выключит нахрен ваш сервер, нафига ему эти пар миллионов пакетов по роутерам… что нибудь дельное лучше бы предложили, чем с мат частью разглогольствовать.
                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                      • 0
                                                                        хм, инетерсный подход! надо обдумать-попробовать
                                                                        • 0
                                                                          как базу для анализа трафика мы взяли cnupm pdp-11.org.ru/~form/cnupm/
                                                                      • 0
                                                                        2 запроса в секунлу — мало, у меня Опера их штук 6 делат параллельно, а если на странице много картинко то запросы авообще дождем будут литься!
                                                                        • 0
                                                                          Я специально сделал в примере конфигурации пояснение:
                                                                          # Данный случай частный лично для моей
                                                                          # ситуации и подбирается индивидуально.

                                                                          По моим тестам и отзывам пользователей, было довольно комфортно и с таким ограничением. По крайней мере, даже если были проблемы, то лучше что бы сайт хоть как то работал, чем не работал вообще.
                                                                          • 0
                                                                            из практики, для реальных сайов с кучей картинкой — 50-60 запросов в секунду надо ставит порог.

                                                                            а вот если там нет картинок, то и 20 порог реальен…
                                                                            • 0
                                                                              Нормальные браузеры не генерируют по 50 запросов никогда. Даже 20 — вполне нормально и хватит всем.
                                                                              • 0
                                                                                раскажите это «варезным» и «новостным» сайтостроителям с кучей рекламы на сайты и всзяким JS подгрзками…
                                                                                • 0
                                                                                  ССЗБ :)
                                                                                  • 0
                                                                                    грамотные варёзные сайтостроители сначала рекламу грузять, а потом сайт)))))
                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                              • 0
                                                                                А зачем nginx-то?

                                                                                Если дело под линуксом, то можно статистику по соединениям собирать в netstat и злобствующих ботов отправлять в iptables -I INPUT -j DROP одним маленьким скриптом, ну вот как этот:

                                                                                BEGIN {
                                                                                pipe = «netstat -n|gawk '{print $5}'|gawk 'BEGIN{FS=\»:\"}{print $1}'|sort|uniq -c |sort -n"
                                                                                while (( pipe| getline) > 0 ) {
                                                                                if ($1 > 29 && $2 != "") {
                                                                                command="/sbin/iptables -I INPUT -s " $2 " -j DROP"
                                                                                date=«date»
                                                                                command | getline result
                                                                                date | getline dateresult
                                                                                print dateresult " — command: " command ", result: " result >>"/var/log/firewall.log"
                                                                                }
                                                                                }
                                                                                close(pipe)
                                                                                }

                                                                                • 0
                                                                                  есть предложение на линуксе плохих дядек отправлять в tarpit
                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                  • 0
                                                                                    мне кажется все же проще обрабатывать логи nginxа, с теми же целями
                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                    • 0
                                                                                      Очень интересно. Можно ли попросить Вас опубликовать этот обработчик?
                                                                                      • 0
                                                                                        Могу в качестве продолжения опубликовать пару решений на perl, которые парсят логи nginx — если интересно конечно.
                                                                                    • 0
                                                                                      oggy
                                                                                      • +1
                                                                                        спасибо
                                                                                        а я то думал почему 503

                                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                        Самое читаемое