[SOLVED] sudo message in webserver error log

cmgeo · 10-22-2017, 12:03 AM

Hello,

I am receinving the following in errorlog of my website.

Code:

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.
sudo: no tty present and no askpass program specified

I know that first time sudo users get this message but this message shouldn't appear on my webserver error log.

can anyone give any clues as to what is happening here.

Thanks

CMG

Turbocapitalist · 10-22-2017, 01:29 AM

Something on your web site has a script that is calling sudo. You need to be concerned about why and how that is happening. How did the script get there and what exact line in /etc/sudoers is it aiming to exploit?

cmgeo · 10-22-2017, 04:26 AM

Thanks for information, and now i am really concerned. The server is deb 9 vm instance on google cloud, i have the default sudoers file. i have two cron jobs running for certbot and awstats. i cannot find anything unusual other than the fact that error.log is updated with these entries 1 minute before an unsual request in access.log.

they are as follows:

Code:

66.70.218.228 - - [22/Oct/2017:13:46:23 +0530] "GET / HTTP/1.1" 302 207 "-" "Go-http-client/1.1"
221.231.140.171 - - [22/Oct/2017:13:47:07 +0530] "GET / HTTP/1.1" 302 188 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36"
221.231.140.171 - - [22/Oct/2017:13:47:08 +0530] "GET /Struts2XMLHelloWorld/User/home.action HTTP/1.1" 404 476 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Geck
o) Chrome/56.0.2924.87 Safari/537.36"
221.231.140.171 - - [22/Oct/2017:13:47:08 +0530] "GET /struts2-showcase/showcase.action HTTP/1.1" 404 471 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Ch
rome/56.0.2924.87 Safari/537.36"
221.231.140.171 - - [22/Oct/2017:13:47:09 +0530] "GET / HTTP/1.1" 302 188 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36"
221.231.140.171 - - [22/Oct/2017:13:47:09 +0530] "GET /Struts2XMLHelloWorld/User/home.action HTTP/1.1" 404 476 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Geck
o) Chrome/56.0.2924.87 Safari/537.36"
221.231.140.171 - - [22/Oct/2017:13:47:10 +0530] "GET /struts2-showcase/showcase.action HTTP/1.1" 404 471 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Ch
rome/56.0.2924.87 Safari/537.36"
221.231.140.171 - - [22/Oct/2017:13:47:10 +0530] "GET /struts2-showcase/titles/index.action HTTP/1.1" 404 475 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko
) Chrome/56.0.2924.87 Safari/537.36"
221.231.140.171 - - [22/Oct/2017:13:47:14 +0530] "GET /struts2-bootstrap-showcase/ HTTP/1.1" 404 466 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/
56.0.2924.87 Safari/537.36"
221.231.140.171 - - [22/Oct/2017:13:47:14 +0530] "GET /struts2-showcase/index.action HTTP/1.1" 404 468 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrom
e/56.0.2924.87 Safari/537.36"
221.231.140.171 - - [22/Oct/2017:13:47:15 +0530] "GET /struts2-bootstrap-showcase/index.action HTTP/1.1" 404 478 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Ge
cko) Chrome/56.0.2924.87 Safari/537.36"

In the above, the error log was updated at 13.46 and these entries are the only stuff that i can make out as unsual in access.log. And then there was this following entry also in logs which i believe is a port scanner. but only ssh and http and https are enabled right now on google cloud. so should i worry?

Code:

155.94.88.58 - - [21/Oct/2017:19:17:58 +0530] "GET / HTTP/1.0" 302 207 "-" "sysscan/1.0 (https://github.com/robertdavidgraham/sysscan)"

I am new to website server administration, so that makes a nervous newbie in this field. The project is being under taken on personal level in google cloud trial before shifting from cpanel on paid hosting providers to google. I know that debian on gcloud is generally protected but noob me could have some misconfiguration and all hell may break loose. So if i could just find the where and how to trace this problem, it would be helpful for me.

Thanks

CMG

Turbocapitalist · 10-22-2017, 04:30 AM

What does the error log indicate is causing that message?

Turbocapitalist · 10-22-2017, 04:34 AM

By the way, the HTTP response 404 means that those files or scripts are not present and those particular requests thus had no effect.

You should also be able to find something in the system's auth.log regarding what was tried against sudo.

cmgeo · 10-22-2017, 04:49 AM

The auth log for for the relevant period is as under:

Quote:

Oct 22 14:29:09 localhost sshd[1915]: Received disconnect from 121.18.238.125 port 40655:11: [preauth]
Oct 22 14:29:09 localhost sshd[1915]: Disconnected from 121.18.238.125 port 40655 [preauth]
Oct 22 14:30:01 localhost CRON[1918]: pam_unix(cron:session): session opened for user www-data by (uid=0)
Oct 22 14:30:01 localhost CRON[1918]: pam_unix(cron:session): session closed for user www-data
Oct 22 14:34:59 localhost sudo: myusername : TTY=pts/0 ; PWD=/var/log/apache2 ; USER=root ; COMMAND=/usr/bin/crontab -e
Oct 22 14:34:59 localhost sudo: pam_unix(sudo:session): session opened for user root by myusername(uid=0)
Oct 22 14:35:06 localhost sudo: pam_unix(sudo:session): session closed for user root
Oct 22 14:35:28 localhost sudo: myusername : TTY=pts/0 ; PWD=/var/log/apache2 ; USER=root ; COMMAND=/usr/bin/crontab -e
Oct 22 14:35:28 localhost sudo: pam_unix(sudo:session): session opened for user root by myusername(uid=0)
Oct 22 14:35:43 localhost sudo: pam_unix(sudo:session): session closed for user root
Oct 22 14:36:39 localhost sshd[1970]: Received disconnect from 121.18.238.123 port 33419:11: [preauth]
Oct 22 14:36:39 localhost sshd[1970]: Disconnected from 121.18.238.123 port 33419 [preauth]
Oct 22 14:39:01 localhost CRON[1975]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 14:39:01 localhost CRON[1975]: pam_unix(cron:session): session closed for user root
Oct 22 14:40:01 localhost CRON[2033]: pam_unix(cron:session): session opened for user www-data by (uid=0)
Oct 22 14:40:02 localhost CRON[2033]: pam_unix(cron:session): session closed for user www-data
Oct 22 14:43:56 localhost sudo: pam_unix(sudo:auth): conversation failed
Oct 22 14:43:56 localhost sudo: pam_unix(sudo:auth): auth could not identify password for [www-data]
Oct 22 14:43:56 localhost sudo: www-data : user NOT in sudoers ; TTY=unknown ; PWD=/var/www ; USER=root ; COMMAND=/bin/chmod -R 775 mywebsite.in
Oct 22 14:43:56 localhost sudo: pam_unix(sudo:auth): conversation failed
Oct 22 14:43:56 localhost sudo: pam_unix(sudo:auth): auth could not identify password for [www-data]
Oct 22 14:43:56 localhost sudo: www-data : user NOT in sudoers ; TTY=unknown ; PWD=/var/www ; USER=root ; COMMAND=/bin/chown -R myusername:www-data mywebsite.in
Oct 22 14:45:23 localhost sshd[2056]: Received disconnect from 121.18.238.123 port 48379:11: [preauth]
Oct 22 14:45:23 localhost sshd[2056]: Disconnected from 121.18.238.123 port 48379 [preauth]
Oct 22 14:50:01 localhost CRON[2062]: pam_unix(cron:session): session opened for user www-data by (uid=0)
Oct 22 14:50:02 localhost CRON[2062]: pam_unix(cron:session): session closed for user www-data
Oct 22 14:51:33 localhost sshd[1595]: pam_unix(sshd:session): session closed for user myusername

The error log displays like this

Quote:

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
sudo: no tty present and no askpass program specified
[Sun Oct 22 11:03:08.012395 2017] [mpm_prefork:notice] [pid 29496] AH00169: caught SIGTERM, shutting down
[Sun Oct 22 11:05:59.037710 2017] [mpm_prefork:notice] [pid 789] AH00163: Apache/2.4.25 (Debian) OpenSSL/1.0.2l configured -- resuming normal operations
[Sun Oct 22 11:05:59.038895 2017] [core:notice] [pid 789] AH00094: Command line: '/usr/sbin/apache2'
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
sudo: no tty present and no askpass program specified
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
sudo: no tty present and no askpass program specified
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
sudo: no tty present and no askpass program specified
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
sudo: no tty present and no askpass program specified
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

sudo: no tty present and no askpass program specified

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
sudo: no tty present and no askpass program specified

Again thanks for looking into it. I think it is the cron job but not all of those entries are producing the error.log so i am not able to decipher the exact job. right now only two jobs for awstats and certbot are the ones that i can really say are running and doing what they need to do.

CMG

Turbocapitalist · 10-22-2017, 04:55 AM

I presume the crontab editing at 14:34:59 was you.

However, these are the peculiar ones:

Code:

Oct 22 14:43:56 localhost sudo: pam_unix(sudo:auth): conversation failed
Oct 22 14:43:56 localhost sudo: pam_unix(sudo:auth): auth could not identify password for [www-data]
Oct 22 14:43:56 localhost sudo: www-data : user NOT in sudoers ; TTY=unknown ; PWD=/var/www ; USER=root ; COMMAND=/bin/chmod -R 775 mywebsite.in
Oct 22 14:43:56 localhost sudo: pam_unix(sudo:auth): conversation failed
Oct 22 14:43:56 localhost sudo: pam_unix(sudo:auth): auth could not identify password for [www-data]
Oct 22 14:43:56 localhost sudo: www-data : user NOT in sudoers ; TTY=unknown ; PWD=/var/www ;

What was going on in the web server's access log and error log at 14:43:56?
Did you make a script that tries to call sudo?

cmgeo · 10-22-2017, 05:22 AM

Thank you, i got to the root of the problem. Actually i had some sample data on my website which is being resetted by my scripts(using sh with sudo inside the script) on new session visit by users. A php script running sh scripts in var/wwww.

So as u have guessed by now that i didn't knew how to read those log files correctly. Can i do it such a way that the above error log entry is not generated.

Heartfelt thanks again.

CMG

Turbocapitalist · 10-22-2017, 05:27 AM

No problem.

The question is can the scripts be run safely? There are a lot of things to check regarding that question. One is to ensure that no data is being passed to the script as it runs sudo. The other is to ensure that sudoers constrains your script to the exact command with the exact parameters it needs.

If it's not too nosy to ask, a) what do you have in sudoers to allow your script to run and b) how is PHP calling sudo?

cmgeo · 10-22-2017, 05:36 AM

I am just copying a default data dir to the site data dir and changing permissions for them so that they are accessible and modifiable by apache. i am achieving this by shell_exec(cmd_path_to_script) and has no relation to what is passed to the php script.

So is there a way to avoid those error log entries.

CMG

Turbocapitalist · 10-22-2017, 05:43 AM

Quote:

Originally Posted by cmgeo

I am just copying a default data dir to the site data dir and changing permissions for them so that they are accessible and modifiable by apache. i am achieving this by shell_exec(cmd_path_to_script) and has no relation to what is passed to the php script.

So is there a way to avoid those error log entries.

CMG

Well, as long as "cmd_path_to_script" is not on the receiving any parameters and it is being run by www-data, you could do it like this:

Code:

%www-data ALL=(root:root) NOPASSWD: cmd_path_to_script ""

The trailing "" means that cmd_path_to_script will refuse to run if the PHP script tries to pass any parameters or modifiers.

For background, I'd recommend these three:

Using sudoers to adjust sudo is not hard, but it is dealing with high stakes, especially when doing something on the behalf of a public web server.

Or is sudo being called from within cmd_path_to_script ?

cmgeo · 10-22-2017, 05:49 AM

From within the cmd_path_to_script and a generated argument like next "sample no" without any requirement from any other script or input.

Turbocapitalist · 10-22-2017, 05:57 AM

It might be easier to put cmd_path_to_script off somewhere safe in the file system where it cannot be modified. Then call it with sudo

cmgeo · 10-22-2017, 05:59 AM

Thank you,

This solves my problem.

CMG