Атака на вордпресс-сайт

  • Alex Voronin

    (@alex-voronin)


    8 лет, 12 месяцев назад

    Всем привет.

    У меня виртуальный сервер на Ubuntu 14 (Nginx+Apache+MySql) Сайты на WordPress

    В error.log сервера apache появляется такая хрень. После, чего сервер становится перегруженым и падает.

    Объясните новичку что это такое?
    Я на гуглил, что это атака в ввиде SQL -инъекции. Это так? Как с этим бороться?

    Буду Вам благодарен за любой совет?

    [Mon Dec 19 10:43:17.992197 2016] [:error] [pid 25428] [client 37.232.180.93:40030] \xd0\x91\xd0\xb0\xd0\xb7\xd0\xb0 \xd0\xb4\xd0\xb0\xd0\xbd\xd0\xbd\xd1\x8b\xd1\x85 WordPress \xd0\xb2\xd0\xbe\xd0\xb7\xd0\xb2\xd1\x80\xd0\xb0\xd1\x82\xd0\xb8\xd0\xbb\xd0\xb0 \xd0\xbe\xd1\x88\xd0\xb8\xd0\xb1\xd0\xba\xd1\x83 Lost connection to MySQL server during query \xd0\xb2 \xd0\xbe\xd1\x82\xd0\xb2\xd0\xb5\xd1\x82 \xd0\xbd\xd0\xb0 \xd0\xb7\xd0\xb0\xd0\xbf\xd1\x80\xd0\xbe\xd1\x81 SELECT * FROM my_posts WHERE ID = 245 LIMIT 1, \xd0\xb2\xd1\x8b\xd0\xbf\xd0\xbe\xd0\xbb\xd0\xbd\xd0\xb5\xd0\xbd\xd0\xbd\xd1\x8b\xd0\xb9 require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), do_action('template_redirect'), WP_Hook->do_action, WP_Hook->apply_filters, call_user_func_array, twentytwelve_content_width, is_page_template, get_page_template_slug, get_post, WP_Post::get_instance

[Mon Dec 19 10:43:17.992445 2016] [:error] [pid 29003] [client 46.163.173.103:40111] \xd0\x91\xd0\xb0\xd0\xb7\xd0\xb0 \xd0\xb4\xd0\xb0\xd0\xbd\xd0\xbd\xd1\x8b\xd1\x85 WordPress \xd0\xb2\xd0\xbe\xd0\xb7\xd0\xb2\xd1\x80\xd0\xb0\xd1\x82\xd0\xb8\xd0\xbb\xd0\xb0 \xd0\xbe\xd1\x88\xd0\xb8\xd0\xb1\xd0\xba\xd1\x83 Lost connection to MySQL server during query \xd0\xb2 \xd0\xbe\xd1\x82\xd0\xb2\xd0\xb5\xd1\x82 \xd0\xbd\xd0\xb0 \xd0\xb7\xd0\xb0\xd0\xbf\xd1\x80\xd0\xbe\xd1\x81 SELECT DISTINCT(label) FROM my_wp_rp_tags WHERE post_id=14549 ORDER BY weight desc;, \xd0\xb2\xd1\x8b\xd0\xbf\xd0\xbe\xd0\xbb\xd0\xbd\xd0\xb5\xd0\xbd\xd0\xbd\xd1\x8b\xd0\xb9 require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('/themes/iconic-one/single.php'), get_header, locate_template, load_template, require_once('/themes/iconic-one/header.php'), wp_head, do_action('wp_head'), call_user_func_array, wp_rp_head_resources
Просмотр 6 ответов — с 1 по 6 (всего 6)
  • Модератор Юрій

    (@yube)

    8 лет, 12 месяцев назад

    то атака в ввиде SQL -инъекции. Это так?

    Нет.

    Если mysqld на простеньком запросе SELECT * FROM my_posts WHERE ID = 245 LIMIT 1 теряет connection, то, ВОЗМОЖНО, Ваш виртуальный сервер на Ubuntu 14 слишком слаб и/или не оптимизирован. Какая конфигурация?

    Модератор Yui

    (@fierevere)

    永子

    8 лет, 12 месяцев назад

    возможно также повреждены таблицы, стоит начать с их проверки и ремонта
    CHECK, REPAIR, OPTIMIZE (можно в phpmyadmin это все сделать)

    Автор Alex Voronin

    (@alex-voronin)

    8 лет, 12 месяцев назад

    Смотрел логи syslog. И понял, что это не инъекция. И ворд пресс не причем.

    Нашел такую закономерность. Если в 6:30 утра возникли такие ошибки. То MySQL умирает или сервер становится недоступным. Если же таких ошибок не было. То сервер работает без проблем.

    Dec 16 06:30:33 slovarik kernel: [68362.962956] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik kernel: [68362.962988] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik kernel: [68362.963027] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik kernel: [68362.963062] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik kernel: [68362.963094] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik kernel: [68362.963126] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik kernel: [68362.963158] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik kernel: [68362.963188] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik kernel: [68362.963220] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik kernel: [68362.963251] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik kernel: [68362.963282] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik kernel: [68362.963314] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik kernel: [68362.963345] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik kernel: [68362.963378] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik kernel: [68362.963409] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik kernel: [68362.963440] sd 2:0:0:0: [sda] abort
Dec 16 06:30:33 slovarik CRON[13277]: (www-data) CMD ([ -x /usr/share/awstats/tools/update.sh ] && /usr/share/awstats/tools/update.sh)
Dec 16 06:30:43 slovarik dovecot: pop3-login: Fatal: Error reading configuration: Timeout reading config from /var/run/dovecot/config
Dec 16 06:30:43 slovarik dovecot: master: Error: service(pop3-login): command startup failed, throttling for 2 secs
Dec 16 06:31:01 slovarik CRON[13300]: (root) CMD (/usr/local/mgr5/sbin/cron-ispmgr sbin/mgrctl -m ispmgr periodic >/dev/null 2>&1)
Dec 16 06:31:11 slovarik kernel: [68400.544086] INFO: task jbd2/sda3-8:147 blocked for more than 120 seconds.
Dec 16 06:31:11 slovarik kernel: [68400.544196] Not tainted 3.13.0-74-generic #118-Ubuntu
Dec 16 06:31:11 slovarik kernel: [68400.544283] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 16 06:31:11 slovarik kernel: [68400.544386] jbd2/sda3-8 D ffff88007fc13180 0 147 2 0x00000000
Dec 16 06:31:11 slovarik kernel: [68400.544395] ffff880036713bd8 0000000000000046 ffff8800369fe000 ffff880036713fd8
Dec 16 06:31:11 slovarik kernel: [68400.544401] 0000000000013180 0000000000013180 ffff8800369fe000 ffff88007fc13a18
Dec 16 06:31:11 slovarik kernel: [68400.544406] ffff88007ffd01e8 0000000000000002 ffffffff811efe60 ffff880036713c50
Dec 16 06:31:11 slovarik kernel: [68400.544412] Call Trace:
Dec 16 06:31:11 slovarik kernel: [68400.544427] [<ffffffff811efe60>] ? generic_block_bmap+0x50/0x50
Dec 16 06:31:11 slovarik kernel: [68400.544434] [<ffffffff8172929d>] io_schedule+0x9d/0x140
Dec 16 06:31:11 slovarik kernel: [68400.544440] [<ffffffff811efe6e>] sleep_on_buffer+0xe/0x20
Dec 16 06:31:11 slovarik kernel: [68400.544445] [<ffffffff81729722>] __wait_on_bit+0x62/0x90
Dec 16 06:31:11 slovarik kernel: [68400.544451] [<ffffffff811efe60>] ? generic_block_bmap+0x50/0x50
Dec 16 06:31:11 slovarik kernel: [68400.544455] [<ffffffff817297c7>] out_of_line_wait_on_bit+0x77/0x90
Dec 16 06:31:11 slovarik kernel: [68400.544481] [<ffffffff810ab4a0>] ? autoremove_wake_function+0x40/0x40
Dec 16 06:31:11 slovarik kernel: [68400.544490] [<ffffffff811f119a>] __wait_on_buffer+0x2a/0x30
Dec 16 06:31:11 slovarik kernel: [68400.544498] [<ffffffff8128c63d>] jbd2_journal_commit_transaction+0x185d/0x1ab0
Dec 16 06:31:11 slovarik kernel: [68400.544506] [<ffffffff810757df>] ? try_to_del_timer_sync+0x4f/0x70
Dec 16 06:31:11 slovarik kernel: [68400.544511] [<ffffffff81290a9d>] kjournald2+0xbd/0x250
Dec 16 06:31:11 slovarik kernel: [68400.544517] [<ffffffff810ab460>] ? prepare_to_wait_event+0x100/0x100
Dec 16 06:31:11 slovarik kernel: [68400.544522] [<ffffffff812909e0>] ? commit_timeout+0x10/0x10
Dec 16 06:31:11 slovarik kernel: [68400.544529] [<ffffffff8108b8a2>] kthread+0xd2/0xf0
Dec 16 06:31:11 slovarik kernel: [68400.544534] [<ffffffff8108b7d0>] ? kthread_create_on_node+0x1c0/0x1c0
Dec 16 06:31:11 slovarik kernel: [68400.544541] [<ffffffff817356a8>] ret_from_fork+0x58/0x90
Dec 16 06:31:11 slovarik kernel: [68400.544545] [<ffffffff8108b7d0>] ? kthread_create_on_node+0x1c0/0x1c0
Dec 16 06:31:11 slovarik kernel: [68400.544574] INFO: task apache2:13173 blocked for more than 120 seconds.
Dec 16 06:31:11 slovarik kernel: [68400.544667] Not tainted 3.13.0-74-generic #118-Ubuntu
Dec 16 06:31:11 slovarik kernel: [68400.544760] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 16 06:31:11 slovarik kernel: [68400.544935] apache2 D ffff88007fd13180 0 13173 2531 0x00000000
Dec 16 06:31:11 slovarik kernel: [68400.544942] ffff88007ab63c20 0000000000000082 ffff88007a76e000 ffff88007ab63fd8
Dec 16 06:31:11 slovarik kernel: [68400.544948] 0000000000013180 0000000000013180 ffff88007a76e000 ffff880066af9868
Dec 16 06:31:11 slovarik kernel: [68400.544954] ffff880066af986c ffff88007a76e000 00000000ffffffff ffff880066af9870
Dec 16 06:31:11 slovarik kernel: [68400.544960] Call Trace:
Dec 16 06:31:11 slovarik kernel: [68400.544968] [<ffffffff81729499>] schedule_preempt_disabled+0x29/0x70
Dec 16 06:31:11 slovarik kernel: [68400.544974] [<ffffffff8172b305>] __mutex_lock_slowpath+0x135/0x1b0
Dec 16 06:31:11 slovarik kernel: [68400.544979] [<ffffffff8172b39f>] mutex_lock+0x1f/0x2f
Dec 16 06:31:11 slovarik kernel: [68400.544987] [<ffffffff81321506>] ima_file_check+0x86/0x180
Dec 16 06:31:11 slovarik kernel: [68400.544995] [<ffffffff8123b990>] ? ext4_htree_store_dirent+0x120/0x120
Dec 16 06:31:11 slovarik kernel: [68400.545002] [<ffffffff811cac80>] do_last+0x570/0x1200
Dec 16 06:31:11 slovarik kernel: [68400.545008] [<ffffffff8131666b>] ? apparmor_file_alloc_security+0x5b/0x180
Dec 16 06:31:11 slovarik kernel: [68400.545014] [<ffffffff811cde8b>] path_openat+0xbb/0x640
Dec 16 06:31:11 slovarik kernel: [68400.545020] [<ffffffff811ce639>] ? putname+0x29/0x40
Dec 16 06:31:11 slovarik kernel: [68400.545026] [<ffffffff811cf18f>] ? user_path_at_empty+0x5f/0x90
Dec 16 06:31:11 slovarik kernel: [68400.545031] [<ffffffff811cf27a>] do_filp_open+0x3a/0x90
Dec 16 06:31:11 slovarik kernel: [68400.545037] [<ffffffff811dc0d7>] ? __alloc_fd+0xa7/0x130
Dec 16 06:31:11 slovarik kernel: [68400.545045] [<ffffffff811bd839>] do_sys_open+0x129/0x280
Dec 16 06:31:11 slovarik kernel: [68400.545050] [<ffffffff811bd9ae>] SyS_open+0x1e/0x20
Dec 16 06:31:11 slovarik kernel: [68400.545056] [<ffffffff8173575d>] system_call_fastpath+0x1a/0x1f
Dec 16 06:31:16 slovarik kernel: [68405.746830] sd 2:0:0:0: [sda] abort
Dec 16 06:31:16 slovarik kernel: [68405.746906] sd 2:0:0:0: [sda] abort
Dec 16 06:31:16 slovarik kernel: [68405.746975] sd 2:0:0:0: [sda] abort
Dec 16 06:31:16 slovarik kernel: [68405.747019] sd 2:0:0:0: [sda] abort
Dec 16 06:31:16 slovarik kernel: [68405.747055] sd 2:0:0:0: [sda] abort
Dec 16 06:31:16 slovarik kernel: [68405.747087] sd 2:0:0:0: [sda] abort
Dec 16 06:31:16 slovarik kernel: [68405.747119] sd 2:0:0:0: [sda] abort
Dec 16 06:31:16 slovarik kernel: [68405.747150] sd 2:0:0:0: [sda] abort
Dec 16 06:31:16 slovarik kernel: [68405.747190] sd 2:0:0:0: [sda] abort
Dec 16 06:31:16 slovarik kernel: [68405.747231] sd 2:0:0:0: [sda] abort
Dec 16 06:31:16 slovarik kernel: [68405.747262] sd 2:0:0:0: [sda] abort
Dec 16 06:31:16 slovarik kernel: [68405.747294] sd 2:0:0:0: [sda] abort
Dec 16 06:31:16 slovarik kernel: [68405.747326] sd 2:0:0:0: [sda] abort
Dec 16 06:31:16 slovarik kernel: [68405.747357] sd 2:0:0:0: [sda] abort
Dec 16 06:31:16 slovarik kernel: [68405.747394] sd 2:0:0:0: [sda] abort
Dec 16 06:31:16 slovarik kernel: [68405.747426] sd 2:0:0:0: [sda] abort
    Модератор Yui

    (@fierevere)

    永子

    8 лет, 12 месяцев назад

    Dec 16 06:30:33 slovarik kernel: [68362.963409] sd 2:0:0:0: [sda] abort
    Dec 16 06:30:33 slovarik kernel: [68362.963440] sd 2:0:0:0: [sda] abort
    INFO: task jbd2/sda3-8:147 blocked for more than 120 seconds.
    у вас проблемы с жестким диском

    раз это VPS, то проблема на хостовой системе, вашей виртуалке практически не достается IOPS в течении 2 минут. Лучше заменить виртуалку на тариф с SSD, там таких проблем меньше

    PS: таблицы БД от этого тоже могут портиться
    если проблема возникает в конкретное время — вероятно у многих ( у вас и/или ваших соседей по физ хосту ) в это время выполняются какие-то тяжелые задания с нагрузкой на диск IO

    • Ответ изменён 8 лет, 12 месяцев назад пользователем Yui.
    Автор Alex Voronin

    (@alex-voronin)

    8 лет, 12 месяцев назад

    если проблема возникает в конкретное время — вероятно у многих ( у вас и/или ваших соседей по физ хосту ) в это время выполняются какие-то тяжелые задания с нагрузкой на диск IO

    Дело в том, что у меня виртуализация KVM. Хостинг сказал, что она не зависит от соседей. Но может быть Вы правы.

    Лучше заменить виртуалку на тариф с SSD, там таких проблем меньше
    Дело в том, что у меня должен быть SSD. По крайней мере я плачу за SSD. Вот мой (tfox = Alex Voronin) топик http://forum.ubuntu.ru/index.php?topic=285174.0 Ребята сказали, что у меня SSD и хостинг не обманывает.

    раз это VPS, то проблема на хостовой системе, вашей виртуалке практически не достается IOPS в течении 2 минут.

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

    Могу ли я попросить хостинг перенести мой виртуальный сервер на другую физическую машину?
    Поможет ли мне эта операция?

    Что вообще можно сделать в этой ситуации?

    Модератор Yui

    (@fierevere)

    永子

    8 лет, 11 месяцев назад

    Дело в том, что у меня виртуализация KVM. Хостинг сказал, что она не зависит от соседей. Но может быть Вы правы.

    если у всех стоит на 6-30 утра задача по бэкапу допустим ежедневному
    а ведь многие пользуются ispmgr, то соседи в любом случае будут влиять.
    KVM виртуализация вам гарантирует только память. По процессору в любом случае идет оверселл, ну и диск — самое узкое место, особенно если это механический диск, где поиск осуществляется перемещением головок. Также вы делите с соседями сеть. Но диск всегда самое узкое место.

    Дело в том, что у меня должен быть SSD

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

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

    возможно есть ошибки файловой системы приводящие к подвисам VFS, попробуйте загрузить виртуалку в rescue (режим восстановления), обычно у хостеров есть
    и сделать

    fsck -v -f -y /dev/sda3

    или хостера попросите помочь вам с этим

    Могу ли я попросить хостинг перенести мой виртуальный сервер на другую физическую машину?
    Поможет ли мне эта операция?

    да, возможно

Просмотр 6 ответов — с 1 по 6 (всего 6)

Тема «Атака на вордпресс-сайт» закрыта для новых ответов.