Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eP8s6-0008NN-9k for pgsql-performance@arkaria.postgresql.org; Wed, 13 Dec 2017 15:22:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eP8s5-0000vE-LE for pgsql-performance@arkaria.postgresql.org; Wed, 13 Dec 2017 15:22:57 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eP8s5-0000v3-BG for pgsql-performance@lists.postgresql.org; Wed, 13 Dec 2017 15:22:57 +0000 Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eP8s2-0001Xh-QM for pgsql-performance@postgresql.org; Wed, 13 Dec 2017 15:22:56 +0000 Received: by mail-wm0-x22d.google.com with SMTP id 9so5729023wme.4 for ; Wed, 13 Dec 2017 07:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=iLaA9qKhuahgmZqU8KFe+shX19YZ5BI/sPtHml5sz7Q=; b=caZnL4H1jPjz0qx8AzVD3sQxT691zFwySI613o+fG5Rsfj8wj1yYVLjd8VCurOArsx WT0E8jthtL/71DRQnHB/33IzOvK2LmhJAjjMcmoHgegN5kZl95i+jA4DUQDZ3I8tx5Qx ZbKI1WbjRy0KIamoSYl5dwSN5yKPq3CTc4T/pwlQ/G1X+7W4MlKJ/j4rAmZKPBc+zN85 Rp8pEsCidpMD29eTsWupBEaS1Eukm+hLGDcba6UnhwqDD+J5GqzU62ECVztyHDTXGgfF oevI/PV7IRybMwJAywb+uflsdoTAF358PZ4zuk6UAPRK201mHOA1c6Nu5tXyBYxovfal dA0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iLaA9qKhuahgmZqU8KFe+shX19YZ5BI/sPtHml5sz7Q=; b=IiiaMGlLKGJYthUa6pASlgLJjWAwvyZa6iqkEoCp7fe2/mFlDWyiDuQV5sUfEVTFx1 8CeJWBV/bF72Ar2cm/51BulWVoTAEblm/ETe435sMOhCkAY65hp3J/lsP7e9BymFe3Sy 3nnPReSemtEh2JEUZP4gKyeLAG6IuuNlHCqdWHdHwz/haeTttl9Uj2m/H4Ye0PzQ/YjS jKz3WijfpG1zLrE2uX0ZJV/QBliT7onPCqJ/A7h9DsF6ehOopUeKYMKKOZgJuI58QT8s eFhXh8+XWqQ2Fmu1uWrl2OytbclLc3enn2v09jGvt5kjCysAw543RgIKEiHwnZR9WlTT t0AQ== X-Gm-Message-State: AKGB3mKspTqtHrjqbH9OBo4OQ+4ps7LpYA9Sm4tNcrIve+mhhuFeEq1P LMSaYYv70iuB/G0S7JGbD66uaIgkqxdoVzlM45LY8E9XTZ8MdDRROQ+n1YAW7dPs26W6eTsr91n 2PTUi+VaVIARFuYvlOdrav6QHbEfflR9v8DxMGw2706sJilIYjhF9BKZt4ZZ0nIOkEN5wpi4GhR 2wwbB9DjBw4PzFSA== X-Google-Smtp-Source: ACJfBovAQxr2GsIz45IFqG59yhICF/3IZZTeg0Bf++tMH7N1POJVXcohSQZQxBtyMtLFQ9ilOEqmjQ== X-Received: by 10.80.174.2 with SMTP id c2mr8011196edd.93.1513178572130; Wed, 13 Dec 2017 07:22:52 -0800 (PST) Received: from [10.137.2.19] (ip-78-102-97-226.net.upcbroadband.cz. [78.102.97.226]) by smtp.gmail.com with ESMTPSA id m1sm1501472ede.74.2017.12.13.07.22.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 07:22:51 -0800 (PST) Subject: Re: CPU 100% usage caused by unknown postgres process.. To: Justin Pryzby , Laurenz Albe Cc: Dinesh Chandra 12108 , "pgsql-performance@postgresql.org" References: <68dd64b2a09f4fd8afe9582a4e23641e@cyient.com> <1513161371.5128.3.camel@cybertec.at> <20171213121952.GA16691@telsasoft.com> From: Tomas Vondra Message-ID: <96e72d15-7edf-96bd-69e1-59ef562f4ca8@2ndquadrant.com> Date: Wed, 13 Dec 2017 16:22:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171213121952.GA16691@telsasoft.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 12/13/2017 01:19 PM, Justin Pryzby wrote: > On Wed, Dec 13, 2017 at 11:36:11AM +0100, Laurenz Albe wrote: >> Dinesh Chandra 12108 wrote: >>> My CPU utilization is going to 100% in PostgreSQL because of one unknown process /x3303400001 is running from postgres user. >>> >>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >>> 19885 postgres 20 0 192684 3916 1420 S 99.3 0.1 5689:04 x3303400001 >>> >>> The same file is automatically created in Postgres Cluster also. I am using Postgresql-9.3. >>> >>> Kindly suggest how can I resolve this issue. >> >> I don't know, but the same problem has been reported on Stackoverflow: >> https://stackoverflow.com/q/46617329/6464308 >> >> If your queries look similar, then you might indeed be the victim of an attack. >> >> Figure out where the function and the executable come from. >> >> In case of doubt, disconnect the server from the network. > > Looks suspicious; I would look at (and save) things like these: > > ls -l /proc/19885/exe > ls -l /proc/19885/fd > ls -l /proc/19885/cwd > > sudo lsof -n -p 19885 > sudo netstat -anpe |grep 19885 > > Stacktrace with gcore/gdb is a good idea. > Save a copy of your log/postgres logfiles and try to figure out where it came > from. Since an attacker seems to control the postgres process, your data may > have been compromized (leaked or tampered with). > Any details about the x3303400001 file (is it a shell script or some kind of binary)? FWIW the queries (listed in the stackoverflow post) are running under postgres, which I assume is superuser. The backend has full access to the data directory, of course, so it may create extra files (using adminpack extension, for example). If that's the case (and if it's indeed an attack), it either means the attacker likely already has access to all the data. So presumably x3303400001 is doing something else at the OS level. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services