Is there a way to alter the Logwatch settings such that it stops performing reverse dns name resolution on all the hosts which tried to probe the server or were blocked?

These URLs are causing the emails to be blocked, particularly by Gmail, and thereby making Logwatch unusable as a sysadmin tool.

I'd prefer an answer which uses pre-existing config files on Ubuntu or Debian but I'll take whatever I can get.


2 Answers 2


This answer is heavily inspired by @RedScourge's original answer, but disables LookupIP via config and makes minimally invasive changes to the sshd script only if necessary.

In response to a user asking about the ability to selectively disable hostname hostname lookups for certain services, a patch was committed to logwatch that enables this feature for SSHD. As of this writing, the patch is not part of a tagged release, but it is easy to apply locally. As an added bonus, this speeds up log generation significantly if there are lots of SSH attempts on your server.

Step 1: Make sure flag sshd_ip_lookup is handled by your local version of logwatch.

  1. Open /usr/share/logwatch/scripts/services/sshd and search for sshd_ip_lookup.

  2. If you don't find any references to this flag, then...

    a. Copy sshd script to /etc so that it won't be overwritten if logwatch is updated

    sudo cp /usr/share/logwatch/scripts/services/sshd /etc/logwatch/scripts/services/sshd

    b. Open /etc/logwatch/scripts/services/sshd with your preferred editor

    sudo nano /etc/logwatch/scripts/services/sshd

    c. Modify script with changes from this commit.
    i.e. paste the following, just before my $DebugCounter = 0; (or anywhere near the top):

    $main::DoLookup = $ENV{'sshd_ip_lookup'};   

Step 2: Set flag sshd_ip_lookup to No

  1. Create/Open /etc/logwatch/conf/services/sshd.conf using your preferred editor.
  2. Add the following contents:
    # Set to No to disable IP lookups
    $sshd_ip_lookup = No

Try running logwatch again!

Addendum: Google Mail (GMail) spam detection

I experienced Google blocking logwatch emails as well. They never made it to the recipient's spam folder; Google blocked the email on the way out. @RedScourge's analysis that this is due to the large number of domain names in the logwatch report appears correct. The email must look like it's full of URLs to Google's spam filters.

I believe there is a correlation between IP addresses that Google Mail links when displaying an email and those that its spam filter considers a link before an email is sent. I noticed that Google Mail linked the IP in X Time(s) but it did not link the IP in : X Time(s). With this in mind, I included a space after the IP and before the colon in the "Negotiation failed" and "Illegal users from" sections. Since doing this – a few weeks ago, now – I have not had any logwatch emails blocked by Google Mail.

The changes to /etc/logwatch/scripts/services/sshd include:

  1. Within section if (keys %NegotiationFailed) { ... }, modify:
    print "      $Host: " . timesplural($HostTotal);
    print "      $Host : " . timesplural($HostTotal);
  2. Within section if (keys %IllegalUsers) { ... }, modify:
    print "   $name: " . timesplural($totcount);
    print "   $name : " . timesplural($totcount);

A gist showing these changes is available here.


I've submitted a wishlist request to add the upstream logwatch patch to LTS releases of Ubuntu. I'm not sure that it will be approved, but you can subscribe to it here to track its status: https://bugs.launchpad.net/ubuntu/+source/logwatch/+bug/1904362

  • 1
    It seems to work! However the email still seems to add A HREF links in the SSHD section under the "Failed logins from:" and "Illegal users from:" section. When I do View Original in Gmail, they do not appear, so I must assume that Gmail is adding these in, not Logwatch. Hopefully Gmail will not start blocking these at a future date, as we appear to be unable to prevent this, unless perhaps we add in prefix or suffix characters to prevent Gmail from detecting these as IP addresses and trying to turn them into links.
    – RedScourge
    Nov 17, 2020 at 2:59
  • @RedScourge - One of my daily logs was blocked by Google again. I wonder if there is a correlation between IP addresses that Google Mail linkifies and those that its spam filter considers a link. I notice that Google Mail linkifies X Time(s) but it does not link : X Time(s). With this in mind, I'm going to test inclusion of a space after the IP and before the colon in the "Negotiation failed" and "Illegal users from" sections. You might try the same and report whether it helps.
    – MDMower
    Nov 20, 2020 at 6:35
  • Here is my current diff: gist.github.com/mdmower/f1923a23bd6270792a2362f552a9c464 . If this helps over the next week or two, I'll update this answer with an addendum specific to spam filter avoidance.
    – MDMower
    Nov 20, 2020 at 6:50

Possible solution:

In Ubuntu 18.04 LTS:

#First copy sshd script from default location to /etc location to have 
#LogWatch override the default script even if there is a LogWatch package update
cp /usr/share/logwatch/scripts/services/sshd /etc/logwatch/scripts/services/sshd
#Then replace all occurrences of "my $name = LookupIP($ip);" with "my $name = $ip;"
sed -i "s/my \$name = LookupIP\(\$ip\);/my \$name = \$ip;/g" /etc/logwatch/scripts/services/sshd

Alternatively, you can edit the file by hand:

#vi /etc/logwatch/scripts/services/sshd
  • Find all occurrences of "my $name = LookupIP($ip);"

  • Replace with "my $name = $ip;"

At first I tried simply adding "my $DoLookup = 0;" near the top of the sshd script by hand, as a look at /usr/share/logwatch/lib/Logwatch.pm seemed to indicate that setting this would cause the LookupIP function to skip hostname lookups, but this did not work.

  • Not ideal, but it appears to work.
    – RedScourge
    Aug 2, 2019 at 18:29
  • Gmail still seems to sporadically reject the Logwatch emails despite this fix. May be situational, perhaps Gmail has a list of banned spam URLs that it uses to reject emails with or something.
    – RedScourge
    Nov 17, 2020 at 3:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.