Sendmail should not be running

[bdharrington7]

OS / Environment

OSX 10.13.1

Deployed from algo: master@e01521bbf493d04dd5ffc7942b558d50674b414f

Ansible version

ansible 2.2.0.0

Version of components from requirements.txt

Name: msrestazure Version: 0.4.16

Summary of the problem

Algo server has sendmail running and accepting connections

Steps to reproduce the behavior

Run ./algo in the normal fashion

The way of deployment (cloud or local)

cloud (digital ocean Ubuntu 16.04)

Expected behavior

only the require VPN services should be running

Actual behavior

ps aux shows sendmail as running and accepting connections

Full log

I closed the window

[dguido]

Steps to reproduce the behavior

Run ./algo in the normal fashion

What options did you choose? We ask these questions because we need them to properly troubleshot.

[bdharrington7]

Which ones were specific to what you needed? I closed the window so I don't know what the logs and options were exactly, but from memory I chose yes to some of the options for connect on demand

[dguido]

I need all of them, thanks.

[davidemyers]

I see sendmail running on my droplets but the iptables rules prevent it from accepting external connections. I create my droplets like this:

ansible-playbook deploy.yml -t digitalocean,vpn,cloud,dns,security \
        -e "do_access_token=$DO_ACCESS_TOKEN do_server_name=$DO_SERVER_NAME do_region=$DO_REGION OnDemandEnabled_WIFI=Y"

[bdharrington7]

I hadn’t checked the Ip tables but I did notice when ssh’ing into the instance for the first time that I was prompted that I had new mail. I haven’t read it (the mail client isn’t installed on the machine and I haven’t had time to dig into the raw file) On Mon, Nov 20, 2017 at 4:11 AM David Myers notifications@github.com wrote:

I see sendmail running on my droplets but the iptables rules prevent it from accepting external connections. I create my droplets like this:

ansible-playbook deploy.yml -t digitalocean,vpn,cloud,dns,security \ -e "do_access_token=$DO_ACCESS_TOKEN do_server_name=$DO_SERVER_NAME do_region=$DO_REGION OnDemandEnabled_WIFI=Y"

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/trailofbits/algo/issues/731#issuecomment-345545585, or mute the thread https://github.com/notifications/unsubscribe-auth/AEV8Q0OTU6Hkh35DRpgE_inwd6aT-QC2ks5s4ItXgaJpZM4Qjeb5 .

[davidemyers]

If you try telnet <ip_address> smtp it should fail. If you log in to the droplet then telnet localhost smtp will succeed. netstat -plunt will tell you which processes are listening to which ports.

Your mail will be in /var/mail/root. I don't think I've ever gotten any mail on any of the 20 or so Algo droplets I've created.

[bdharrington7]

@davidemyers thanks for the tips! looks like it is indeed blocked externally, but there is the sendmail MTA listening on standard smtp ports.

I took a look at the mail file, and it seems like something happened that prevented the adblock script from being installed properly:

From root@algo.local  Mon Nov 20 02:10:11 2017
Return-Path: <root@algo.local>
Received: from algo.local (localhost [127.0.0.1])
        by algo.local (8.15.2/8.15.2/Debian-3) with ESMTP id vAK2ABQj029782
        for <root@algo.local>; Mon, 20 Nov 2017 02:10:11 GMT
Received: (from root@localhost)
        by algo.local (8.15.2/8.15.2/Submit) id vAK2ABdf029781
        for root; Mon, 20 Nov 2017 02:10:11 GMT
Date: Mon, 20 Nov 2017 02:10:11 GMT
Message-Id: <201711200210.vAK2ABdf029781@algo.local>
From: root@algo.local (Cron Daemon)
To: root@algo.local
Subject: Cron <root@algo> /usr/local/sbin/adblock.sh
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>

Downloading hosts lists...
/usr/local/sbin/adblock.sh: 41: /usr/local/sbin/adblock.sh: service: not found

[davidemyers]

Looks to me like a bug in adblock.sh. That script should set its own PATH, but since it doesn't it's not finding /usr/sbin/service when it tries to restart dnsmasq to have the block list reloaded.

The reason I've never seen this mail message myself even though I install the Algo DNS Adblocking feature is because I install the feature only to use it as a caching nameserver, so I disable the running of adblock.sh from cron.

Looks like having sendmail running is a good thing in order to catch problems like this.

[melizeche]

@davidemyers @bdharrington7 adblock script issue solved in #736