> 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.kuh...@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 <avaman...@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.kuh...@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@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@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@ripe.net >>>> https://lists.ripe.net/mailman/listinfo/ripe-atlas >>>> >>>> >>>> >>>> -- >>>> ripe-atlas mailing list >>>> ripe-atlas@ripe.net >>>> https://lists.ripe.net/mailman/listinfo/ripe-atlas >>>> >>> -- >>> ripe-atlas mailing list >>> ripe-atlas@ripe.net >>> https://lists.ripe.net/mailman/listinfo/ripe-atlas >>> >>
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
