[atlas] RIPE Atlas SMTP Measurement

>  but has had the greatly beneficial effect of cutting down on the
absolutely incredible volume of virus/worm/trojan compromised hosts out on
the internet that are probing for open relays or trying repeated
login/password combinations, which does nothing but clutter up log files.

Great to hear it works for you, but the potential unfortunate collateral
from such a blanket action is not really RIPE Atlas' problem. There are
more fine-grained methods against bruteforce attempts and open relay
probes, than triggering on a few connections.

Some webmasters ban IP's for simply visiting a domain, I know one that even
dispatches an email to your ISP's abuse@ address upon visit. Should RIPE
Atlas probes then not probe any HTTP servers? The answer is obviously
no, they shouldn't care.

On Tue, Sep 20, 2022 at 8:39 PM Eric Kuhnke <eric.kuhnke at gmail.com> wrote:

> I have the various postfix smtpd that I control set to be what you would
> call "trigger happy" and it has had absolutely **zero** impact blocking
> legitimate incoming smtp traffic from other domains' legitimate MX, but has
> had the greatly beneficial effect of cutting down on the absolutely
> incredible volume of virus/worm/trojan compromised hosts out on the
> internet that are probing for open relays or trying repeated login/password
> combinations, which does nothing but clutter up log files.
>
> A single connection to check that my MX answers and exists on ports 25 or
> other is not enough to trigger it but multiple repeated same attempts
> coming from the same origin IP in a span of multiple hours will.
>
>
>
>
>
> On Tue, 20 Sept 2022 at 10:29, Avamander <avamander at gmail.com> wrote:
>
>> > a probe of smtpd will look not much different from the many things out
>> there on the internet already maliciously probing smtpd trying to find open
>> relays.
>>
>> It would look very different though, there's a large difference between
>> trying to probe for an open relay and just making a connection without any
>> specific commands being issued.
>>
>> > because common configurations of fail2ban used with postfix and others
>> absolutely will ban your IP at the host operating system level (iptables or
>> other) after multiple connection attempts and no successful mail transfer
>> or authentication.
>>
>> If a few connections are sufficient to trigger that, then such
>> configurations are simply too trigger-happy. Checking the existence and
>> availability of a domain's MX is a very common operation. Things like
>> rspamd have such functionality built-in and I'm sure there are many others.
>>
>> On Tue, Sep 20, 2022 at 8:23 PM Eric Kuhnke <eric.kuhnke at gmail.com>
>> wrote:
>>
>>> I would discourage anyone from relying upon the data from "probing" the
>>> MX and SMTP daemons for a domain name no matter what port they run on,
>>> because common configurations of fail2ban used with postfix and others
>>> absolutely will ban your IP at the host operating system level (iptables or
>>> other) after multiple connection attempts and no successful mail transfer
>>> or authentication.
>>>
>>> a probe of smtpd will look not much different from the many things out
>>> there on the internet already maliciously probing smtpd trying to find open
>>> relays.
>>>
>>>
>>>
>>>
>>> On Tue, 20 Sept 2022 at 09:22, Simon Brandt via ripe-atlas <
>>> ripe-atlas at ripe.net> wrote:
>>>
>>>> Hi Michel,
>>>>
>>>> Currently, HTTP and SSL are separate measurements. But for SMTP it will
>>>> probably not work this way... Encryption is not mandatory for SMTP and thus
>>>> negotiated between client and server every time on port 25. Ports 465 and
>>>> 587 are used for Client Email Submission. You could run some measurements
>>>> for these ports as well, but for the beginning, i would focus on
>>>> server2server communication.
>>>>
>>>> So here's what i think:
>>>>
>>>> What we could measure:
>>>> - General reachability/availability of the e-mail service
>>>> - Response time of the remote server: time between connection establish
>>>> and first SMTP response (220 service ready)
>>>> - Which enhanced status codes are offered by the server?
>>>> - Forward/Reverse DNS matching?
>>>> - SMTP banner matching the DNS name?
>>>>     - if not: what is it?
>>>> - Does the remote server offer encryption (250-STARTTLS)
>>>> - Which cipher settings are offered by the server (SSL/TLS Version, Key
>>>> Exchange Algorithms, Encryption Algorithms, Hashing Algorithms)
>>>>     - alternatively: Which cipher setting has been negotiated between
>>>> probe and server?
>>>> - Can we successfully establish a TLS connection?
>>>> - Certificate Check: is the server-certificate valid and does it match
>>>> the hostname?
>>>> - Forced Encryption: MTA-STS available and 'enforced' or 'testing' or
>>>> 'report'?
>>>> - Forced Authentication: DANE available and check successfull?
>>>>
>>>>
>>>> What we should not do:
>>>> - send MAIL FROM: command
>>>> - send RCPT TO: command
>>>> - send DATA command
>>>> - measure e-mail delivery/roundtrip time, etc.
>>>> - Sending e-mails at all
>>>>
>>>> The Atlas probe should quit the connection after the data is collected.
>>>> An actual e-mail should not be send. The target mailserver would count this
>>>> session as "incomplete" or "aborted" which is totally fine. If someone
>>>> would want to monitor what happens after a mailserver has successfully
>>>> accepted a testmail, he should better use a monitoring service/solution. We
>>>> measure the INTERnet, not what comes after (Intra) :)
>>>>
>>>> I don't expect any "spam" problems. Since the Atlas probes wouldn't
>>>> send e-mails, there's nothing a spamfilter could analyze. The only thing
>>>> that could theoretically happen, is that the probes ip addresses are
>>>> flagged as bad by services like Spamhaus etc. and thus be listed on
>>>> DNSBL/IPBL, but i really don't see a reason why that should happen. There
>>>> wouldn't be any activity originating from the probes which could be
>>>> classified as bad. IP addresses are normally only blacklisted, if they send
>>>> unwanted mails like spam. Also: there are a lot of "check you mailserver"
>>>> or "check your SSL/TLS" websites. The RIPE Atlas probes would behave the
>>>> same way. No big deal.
>>>>
>>>> Maybe we can think of an "extended" SMTP measurement where RIPE Atlas
>>>> sends actual e-mails, but that would require (in my opinion), that the
>>>> person who is creating the measurement somehow provides proof, to be the
>>>> owner of the target mailserver.
>>>>
>>>>
>>>> BR,
>>>> Simon
>>>>
>>>>
>>>> On 15.09.22 12:03, Michel Stam wrote:
>>>>
>>>> Hello Simon,
>>>>
>>>> Thank you for the suggestion.
>>>>
>>>> I have a couple of questions to get a better idea:
>>>>
>>>>    - Can you maybe describe what a SMTP measurement would look like?
>>>>       - Simple EHLO/HELO
>>>>       - Sending an email to a designated address (which would then
>>>>       validate that the SMTP server is capable of relaying etc.)
>>>>    - How would DNSBL or other spam prevention techniques fit into
>>>>    this?
>>>>    - What would the result be?
>>>>       - Delay until mail received
>>>>       - Response time by the actual mail server
>>>>       - Using the Received: headers to get a “traceroute” like result.
>>>>    - What about the more uncommon ports such as 565 (SMTP+SSL/TLS) or
>>>>    587 (mail submission port).
>>>>    - How can we prevent this implementation from having RIPE Atlas be
>>>>    identified as a spam bot network?
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Michel
>>>>
>>>> On 3 Sep 2022, at 14:48, Simon Brandt via ripe-atlas <
>>>> ripe-atlas at ripe.net> wrote:
>>>>
>>>> Hello,
>>>>
>>>> i'd like to start a discussion about having a RIPE Atlas SMTP
>>>> measurements.
>>>> First of all: yes, i know there's a big obstacle for such a measurement
>>>> type. A lot of probes are deployed using enduser internet-connections like
>>>> dsl, cable, etc. with dynamic/eyeball IP addresses. Those IP spaces are
>>>> usually blocked by SMTP servers as approach to reduce spam mails. For
>>>> Example: by using blocklists like Spamhaus PBL. So a proper SMTP
>>>> measurement wouldn't work.
>>>>
>>>> BUT we could have an easy way for RIPE Atlas probe hosters to
>>>> signalize, that their probe is eligible for SMTP measurements:
>>>>
>>>> Step 1: enable "Simple DNS Entry"
>>>> Step 2: create a matching reverse DNS record for the probes IP address
>>>>
>>>> Everybody who is able so configure a reverse DNS record for his probes
>>>> IP address, is most likely using a non-dynamic/non-home ip address space
>>>> e.g. a datacenter or office network. If an ISP provides the option for his
>>>> customers to configure a reverse DNS record, it's most likely a
>>>> "business-customer" subnet which can be used to run mailservers. After Step
>>>> 1+2 are done, the RIPE Atlas platform would easily be able to verify if
>>>> forward-confirmed reverse DNS is successful, and if so, automatically
>>>> enable that probe for SMTP measurements. Alternatively: probe hosters
>>>> choose their own Forward-confirmed reverse DNS name and submit it on the
>>>> RIPE Atlas website.
>>>>
>>>> Also: if we would have STMP measurements, forward-confirmed reverse DNS
>>>> should be mandatory for anchors, or is it already?
>>>>
>>>> Why should we have SMTP measurements?
>>>>
>>>> Besides general reachability checks, we could also evaluate SMTP
>>>> response codes. But the most important thing for me is this: the SMTP
>>>> protocol is old. Very old. From a security point of view, it's absolutely
>>>> outdated. Most security features have been added years after the initial
>>>> RfC. Thus, those security features are optional. Mandatory SMTP encryption
>>>> is not provided by the SMTP RfC. So both sides have to signalize, that they
>>>> are capable of encryption using the STARTTLS command. An attacker
>>>> (man-in-the-middle) can perform a downgrade attack by suppressing the
>>>> STARTTLS command. So both sides are forced to fallback and communicate
>>>> unencrypted. RIPE Atlas would be a really good tool to identify such
>>>> attacks, by monitor/measure the (enhanced) status codes of a target.
>>>>
>>>> But there's more!
>>>> I see a two-sided model here. Either use the RIPE Atlas SMTP
>>>> measurements to monitor/measure your own mailserver by alot of other RIPE
>>>> probes out there, OR probe hosters could run SMTP measurements originating
>>>> from their own probe to find out, if their own IP address is currently
>>>> blocked by other mailservers.
>>>>
>>>>
>>>> What do you think?
>>>>
>>>>
>>>> BR,
>>>> Simon
>>>> --
>>>> ripe-atlas mailing list
>>>> ripe-atlas at ripe.net
>>>> https://mailman.ripe.net/
>>>>
>>>>
>>>>
>>>> --
>>>> ripe-atlas mailing list
>>>> ripe-atlas at ripe.net
>>>> https://mailman.ripe.net/
>>>>
>>> --
>>> ripe-atlas mailing list
>>> ripe-atlas at ripe.net
>>> https://mailman.ripe.net/
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ripe-atlas/attachments/20220920/059917c0/attachment.html>