What is this?

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

What is this?

Jaroslaw Rafa
My Postfix log is full of repeated connections and disconnections from the
same machine:

Feb 26 11:43:41 rafa postfix/submission/smtpd[13829]: connect from unknown[92.118.38.42]
Feb 26 11:43:52 rafa postfix/submission/smtpd[13829]: disconnect from unknown[92.118.38.42]
Feb 26 11:44:04 rafa postfix/submission/smtpd[13829]: warning: hostname ip-38-42.ZervDNS does not resolve to address 92.118.38.42: Name or service not known

This repeats over and over (I already blocked this IP on firewall). I wonder
what this attacker(?) is trying to do - the client doesn't attempt AUTH or
anything (it would be logged). It just connects and disconnects. And so on
and on...
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: What is this?

wa6vvv

> On 26 February 2020, at 02:54, Jaroslaw Rafa <[hidden email]> wrote:
>
> My Postfix log is full of repeated connections and disconnections from the
> same machine:
>
> Feb 26 11:43:41 rafa postfix/submission/smtpd[13829]: connect from unknown[92.118.38.42]
> Feb 26 11:43:52 rafa postfix/submission/smtpd[13829]: disconnect from unknown[92.118.38.42]
> Feb 26 11:44:04 rafa postfix/submission/smtpd[13829]: warning: hostname ip-38-42.ZervDNS does not resolve to address 92.118.38.42: Name or service not known
>
> This repeats over and over (I already blocked this IP on firewall). I wonder
> what this attacker(?) is trying to do - the client doesn't attempt AUTH or
> anything (it would be logged). It just connects and disconnects. And so on
> and on...

One of my mail servers showed the same thing.  Tcpdump showed they are sending SYN after SYN, nothing else.  You didn't indicate which firewall you are using, but when I went to block them with pf I found that they send often enough that pf's state stays active.  I had to manually remove that state entry to stop the logging.  That won't stop their sending the SYNs though.  It almost appears to be a really poor attempt at a denial of service.  I did find 2 other sites sending the same thing.

-- Doug


Reply | Threaded
Open this post in threaded view
|

Re: What is this?

Viktor Dukhovni
In reply to this post by Jaroslaw Rafa
On Wed, Feb 26, 2020 at 11:54:31AM +0100, Jaroslaw Rafa wrote:

> Feb 26 11:43:41 rafa postfix/submission/smtpd[13829]: connect from unknown[92.118.38.42]
> Feb 26 11:43:52 rafa postfix/submission/smtpd[13829]: disconnect from unknown[92.118.38.42]
> Feb 26 11:44:04 rafa postfix/submission/smtpd[13829]: warning: hostname ip-38-42.ZervDNS does not resolve to address 92.118.38.42: Name or service not known
>
> This repeats over and over (I already blocked this IP on firewall). I wonder
> what this attacker(?) is trying to do - the client doesn't attempt AUTH or
> anything (it would be logged). It just connects and disconnects. And so on
> and on...

This appears to be a network registered in Britain with a yandex.ru
abuse contact: <[hidden email]> and a netblock whose
GeoIP appears to be in Romania:

    92.118.38.42: RO, Romania

If anyone is going to give an answer, the yandex abuse contact be the
first place to ask, but I wouldn't hold out much hope.

    inetnum:        92.118.38.0 - 92.118.38.255
    org:            ORG-IA1699-RIPE
    netname:        INTERNET-HOSTING
    country:        GB
    admin-c:        ACRO26375-RIPE
    tech-c:         ACRO26375-RIPE
    status:         ASSIGNED PA
    mnt-by:         Internet-Hosting
    created:        2019-06-25T12:24:07Z
    last-modified:  2019-11-02T10:34:55Z
    source:         RIPE

    organisation:   ORG-IA1699-RIPE
    phone:          +447501520497
    org-name:       InternetHosting-LTD
    org-type:       OTHER
    address:        26 New kent Road ,SE16TJ
    address:        London
    abuse-c:        ACRO26375-RIPE
    mnt-ref:        Internet-Hosting
    mnt-by:         Internet-Hosting
    mnt-by:         InternetHosting
    created:        2019-08-12T12:49:00Z
    last-modified:  2019-10-27T09:46:20Z
    source:         RIPE # Filtered

    role:           Abuse contact role object
    phone:          +447501520497
    address:        London
    address:        26 New kent Road ,SE16TJ
    abuse-mailbox:  [hidden email]
    c-hdl:          ACRO26375-RIPE
    mnt-by:         InternetHosting
    mnt-by:         Internet-Hosting
    created:        2019-08-12T12:48:42Z
    last-modified:  2019-10-27T09:45:35Z
    source:         RIPE # Filtered

    % Information related to &#39;92.118.38.0/24AS50360&#39;

    route:          92.118.38.0/24
    origin:         AS50360
    mnt-by:         ZervDNS
    created:        2019-06-09T19:03:29Z
    last-modified:  2019-06-09T19:03:29Z
    source:         RIPE

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: What is this?

Matus UHLAR - fantomas
In reply to this post by wa6vvv
>> On 26 February 2020, at 02:54, Jaroslaw Rafa <[hidden email]> wrote:
>>
>> My Postfix log is full of repeated connections and disconnections from the
>> same machine:
>>
>> Feb 26 11:43:41 rafa postfix/submission/smtpd[13829]: connect from unknown[92.118.38.42]
>> Feb 26 11:43:52 rafa postfix/submission/smtpd[13829]: disconnect from unknown[92.118.38.42]
>> Feb 26 11:44:04 rafa postfix/submission/smtpd[13829]: warning: hostname ip-38-42.ZervDNS does not resolve to address 92.118.38.42: Name or service not known
>>
>> This repeats over and over (I already blocked this IP on firewall). I wonder
>> what this attacker(?) is trying to do - the client doesn't attempt AUTH or
>> anything (it would be logged). It just connects and disconnects. And so on
>> and on...

welcome to the internet. Can be misconfigured client, spamware somewhere,
scan, whatever. Firewalling those automatically is the only way to limit
those messages.

On 26.02.20 03:04, Doug Hardie wrote:
>One of my mail servers showed the same thing.  Tcpdump showed they are
> sending SYN after SYN, nothing else.  You didn't indicate which firewall
> you are using, but when I went to block them with pf I found that they
> send often enough that pf's state stays active.  I had to manually remove
> that state entry to stop the logging.  That won't stop their sending the
> SYNs though.  It almost appears to be a really poor attempt at a denial of
> service.  I did find 2 other sites sending the same thing.

SYN after SYN will not cause this error. For this kind of error the
connection must be made by SYN,SYN+ACK,ACK and then FIN.

If you block data/SYN by any firewll, you won't see those messages.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows.   -- Matthew D. Fuller
Reply | Threaded
Open this post in threaded view
|

Re: What is this?

Mark Rousell
In reply to this post by Viktor Dukhovni
On 26/02/2020 11:05, Viktor Dukhovni wrote:

This appears to be a network registered in Britain with a yandex.ru
abuse contact: [hidden email] and a netblock whose
GeoIP appears to be in Romania:

    92.118.38.42: RO, Romania

If anyone is going to give an answer, the yandex abuse contact be the
first place to ask, but I wouldn't hold out much hope.

    inetnum:        92.118.38.0 - 92.118.38.255
    org:            ORG-IA1699-RIPE
    netname:        INTERNET-HOSTING
    country:        GB
    admin-c:        ACRO26375-RIPE
    tech-c:         ACRO26375-RIPE
    status:         ASSIGNED PA
    mnt-by:         Internet-Hosting
    created:        2019-06-25T12:24:07Z
    last-modified:  2019-11-02T10:34:55Z
    source:         RIPE

    organisation:   ORG-IA1699-RIPE
    phone:          +447501520497
    org-name:       InternetHosting-LTD
    org-type:       OTHER
    address:        26 New kent Road ,SE16TJ
    address:        London

Purely out of curiosity, I decided to see what 26 New Kent Road, SE1 6TJ looked like. It's seems to be the blue building here: <https://www.google.com/maps/@51.4950291,-0.0987796,3a,72.8y,195.28h,93.97t/data=!3m6!1e1!3m4!1sE_LhSDAamlHCPvnCSrYYBA!2e0!7i16384!8i8192?hl=en>. Lovely, eh. I think it might be an old (rather small) cinema, but I'm not sure.

The 07501 dialling code is a mobile phone.

A company named "Internet Hosting Ltd" does exist and is in fact registered to this address but it's only existed since June 2019. It has a single company officer named Elliot Carey who is the sole shareholder. Details here: <https://beta.companieshouse.gov.uk/company/12051036>

All for what it's worth.

-- 
Mark Rousell
 
 
 
Reply | Threaded
Open this post in threaded view
|

Re: What is this?

Micah Anderson-2
In reply to this post by Matus UHLAR - fantomas
Matus UHLAR - fantomas <[hidden email]> writes:

> welcome to the internet. Can be misconfigured client, spamware somewhere,
> scan, whatever. Firewalling those automatically is the only way to limit
> those messages.

I'm curious what kind of firewalling rules that people have come up with
to limit these. Are you just doing a fail2ban type reaction, or have
some particular state you are denying? I'd be happy to see some iptables
or even pf examples.

Reply | Threaded
Open this post in threaded view
|

Re: What is this?

Jaroslaw Rafa
Dnia 26.02.2020 o godz. 07:59:04 micah anderson pisze:
> I'm curious what kind of firewalling rules that people have come up with
> to limit these. Are you just doing a fail2ban type reaction, or have
> some particular state you are denying? I'd be happy to see some iptables
> or even pf examples.

I just completely blocked that IP on iptables.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: What is this?

Wietse Venema
In reply to this post by Micah Anderson-2
micah anderson:

> Matus UHLAR - fantomas <[hidden email]> writes:
>
> > welcome to the internet. Can be misconfigured client, spamware somewhere,
> > scan, whatever. Firewalling those automatically is the only way to limit
> > those messages.
>
> I'm curious what kind of firewalling rules that people have come
> up with to limit these. Are you just doing a fail2ban type reaction,
> or have some particular state you are denying? I'd be happy to see
> some iptables or even pf examples.

Why bother? Storage is cheap, and repeated logging compresses
very well. So it is only a proble, if you keep uncompressed logs
forever.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: What is this?

John Gateley


On 2/26/20 9:12 AM, Wietse Venema wrote:

> micah anderson:
>> Matus UHLAR - fantomas <[hidden email]> writes:
>>
>>> welcome to the internet. Can be misconfigured client, spamware somewhere,
>>> scan, whatever. Firewalling those automatically is the only way to limit
>>> those messages.
>> I'm curious what kind of firewalling rules that people have come
>> up with to limit these. Are you just doing a fail2ban type reaction,
>> or have some particular state you are denying? I'd be happy to see
>> some iptables or even pf examples.
> Why bother? Storage is cheap, and repeated logging compresses
> very well. So it is only a proble, if you keep uncompressed logs
> forever.
>
I firewall things like this to prevent that IP address from mounting
other types
of attacks, including non-SMTP attacks. It's not the storage, it's
protection.

For that reason, any time I automatically firewall an IP for something I
read in the logs,
I just block the IP on all TCP and UDP ports. I don't try to be selective.

However, I do NOT firewall in this particular case. There were three
messages reported:
a connect, a disconnect, and a warning. I don't see sufficient info in
these three messages
to warrant labeling the IP address as malicious.

I'm curious to hear about other's experiences. I know I block a lot of
attacks (100,000+
daily ssh probes) on my small servers, though mostly from detecting
http(s)  and
auth anomalies, not SMTP.

John
Reply | Threaded
Open this post in threaded view
|

Re: What is this?

biggsy
In reply to this post by Jaroslaw Rafa
A friend and I experienced this in October last year.

I believe these SYNs have forged source addresses.  The objectives being one or more of:
- a DOS attack on the legit owner of the IP,
- create a state table size issue for you,
- to have you block legitimate sources.  
The last of these certainly happened here.
 
I set up a fail2ban rule to pick these up and, after one day,
nearly 9,500 sources had been blocked at the firewall.  
However, the pf table included addresses that belonged to the likes of MessageLabs.
I dropped the rule and unbanned them after realizing that.

Better not to block them and live with the log spam.

I should mention that my pf firewall is a separate system in front of my postfix
server and postfix never saw any of these bogus connections.  
Eventually, I also turned off logging of TCP/25 connections at the firewall.  

Phil    


Wednesday, February 26, 2020, 9:54:31 PM, you wrote:

> My Postfix log is full of repeated connections and disconnections from the
> same machine:

> Feb 26 11:43:41 rafa postfix/submission/smtpd[13829]: connect from unknown[92.118.38.42]
> Feb 26 11:43:52 rafa postfix/submission/smtpd[13829]: disconnect from unknown[92.118.38.42]
> Feb 26 11:44:04 rafa postfix/submission/smtpd[13829]: warning: hostname ip-38-42.ZervDNS does not resolve to address 92.118.38.42: Name or service not known

> This repeats over and over (I already blocked this IP on firewall). I wonder
> what this attacker(?) is trying to do - the client doesn't attempt AUTH or
> anything (it would be logged). It just connects and disconnects. And so on
> and on...



--
Best regards,
Phil Biggs

Reply | Threaded
Open this post in threaded view
|

Re: What is this?

Jaroslaw Rafa
In reply to this post by John Gateley
Dnia 26.02.2020 o godz. 11:17:00 John Gateley pisze:
>
> However, I do NOT firewall in this particular case. There were three
> messages reported:
> a connect, a disconnect, and a warning. I don't see sufficient info
> in these three messages
> to warrant labeling the IP address as malicious.

You probably missed the part that these connects and disconnects have been
repeating over and over, for several hours. Multiple repeated connection
attempts, without doing anything productive, are a sufficient reason to
firewall for me. Additionally, what I didn't mention in my original post,
it was eating up my resources a bit, and there was a noticeable server
slowdown.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: What is this?

Wietse Venema
Jaroslaw Rafa:

> Dnia 26.02.2020 o godz. 11:17:00 John Gateley pisze:
> >
> > However, I do NOT firewall in this particular case. There were three
> > messages reported:
> > a connect, a disconnect, and a warning. I don't see sufficient info
> > in these three messages
> > to warrant labeling the IP address as malicious.
>
> You probably missed the part that these connects and disconnects have been
> repeating over and over, for several hours. Multiple repeated connection
> attempts, without doing anything productive, are a sufficient reason to
> firewall for me. Additionally, what I didn't mention in my original post,
> it was eating up my resources a bit, and there was a noticeable server
> slowdown.

In what respect? File system (logging), networking, memory, ...?
Is this systemd overhead? I tried to make Postfix "not receiving
email" as inexpensive as possible. I further reduced that cost by
adding postscreen.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: What is this?

Jaroslaw Rafa
Dnia 27.02.2020 o godz. 07:02:10 Wietse Venema pisze:
> > firewall for me. Additionally, what I didn't mention in my original post,
> > it was eating up my resources a bit, and there was a noticeable server
> > slowdown.
>
> In what respect? File system (logging), networking, memory, ...?
> Is this systemd overhead? I tried to make Postfix "not receiving
> email" as inexpensive as possible. I further reduced that cost by
> adding postscreen.

I did not investigate it very much. Definitely it was not a CPU issue, might
be networking.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: What is this?

Micah Anderson-2
Jaroslaw Rafa <[hidden email]> writes:

> Dnia 27.02.2020 o godz. 07:02:10 Wietse Venema pisze:
>> > firewall for me. Additionally, what I didn't mention in my original post,
>> > it was eating up my resources a bit, and there was a noticeable server
>> > slowdown.
>>
>> In what respect? File system (logging), networking, memory, ...?
>> Is this systemd overhead? I tried to make Postfix "not receiving
>> email" as inexpensive as possible. I further reduced that cost by
>> adding postscreen.
>
> I did not investigate it very much. Definitely it was not a CPU issue, might
> be networking.

Better investigate before blaming Postfix! We are using Postfix very
happily, without firewalling these, and without slowdown, on a very busy
set of machines. Postscreen has helped tremendously in this respect.

--
        micah
Reply | Threaded
Open this post in threaded view
|

Re: What is this?

Jaroslaw Rafa
Dnia 27.02.2020 o godz. 09:55:30 micah anderson pisze:
>
> Better investigate before blaming Postfix! We are using Postfix very
> happily, without firewalling these, and without slowdown, on a very busy
> set of machines. Postscreen has helped tremendously in this respect.

Where am I blaming Postfix? I never said anything like this...
I was just curious about this strange type of "attack", that's all.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: What is this?

Bill Cole-3
In reply to this post by Wietse Venema
On 26 Feb 2020, at 10:12, Wietse Venema wrote:

> micah anderson:
>> Matus UHLAR - fantomas <[hidden email]> writes:
>>
>>> welcome to the internet. Can be misconfigured client, spamware
>>> somewhere,
>>> scan, whatever. Firewalling those automatically is the only way to
>>> limit
>>> those messages.
>>
>> I'm curious what kind of firewalling rules that people have come
>> up with to limit these. Are you just doing a fail2ban type reaction,
>> or have some particular state you are denying? I'd be happy to see
>> some iptables or even pf examples.
>
> Why bother? Storage is cheap,

Managing storage is not. Unanticipated growth of logs is a common root
cause of having to do storage management tasks that require
highly-compensated labor.

> and repeated logging compresses
> very well.

True, but log parsing and analysis for extraction of useful information
still has to deal with the uncompressed logs and at least read and
filter every line, whether its content carries interesting data or not.

> So it is only a proble, if you keep uncompressed logs
> forever.

It can be an ongoing nuisance if you try to maximize resource
utilization (a common strategy in the age of easy virtualization) and
guess wrong about how many bots will do pointless broken things in the
lifetime of a system.

There's also a side-issue that I don't believe to be applicable here:
forged packet reflection attacks. I don't suspect that in this case
because there's no amplification but it certainly would work to make a
flooding attack untraceable.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
Reply | Threaded
Open this post in threaded view
|

Re: What is this?

Matus UHLAR - fantomas
In reply to this post by biggsy
On 27.02.20 08:09, Phil Biggs wrote:
>A friend and I experienced this in October last year.
>
>I believe these SYNs have forged source addresses. The objectives being one or more of:
>- a DOS attack on the legit owner of the IP,
>- create a state table size issue for you,
>- to have you block legitimate sources.
>The last of these certainly happened here.

per my last e-mail...
https://marc.info/?l=postfix-users&m=158272022625515&w=2

SYN with forged address can not cause this kind of error.  This error
requires connection be made (until then postfix does not know about it) and
then closed. Thus it requires SYN - SYN+ACK - ACK which does not work with
forged address.

>I set up a fail2ban rule to pick these up and, after one day,
>nearly 9,500 sources had been blocked at the firewall.
>However, the pf table included addresses that belonged to the likes of MessageLabs.
>I dropped the rule and unbanned them after realizing that.

It's more likely that messagelabs scan the internet for open relays,
mailservers features to gather statistics about the internet.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fighting for peace is like fucking for virginity...
Reply | Threaded
Open this post in threaded view
|

Re: What is this?

Viktor Dukhovni
On Fri, Feb 28, 2020 at 10:06:51AM +0100, Matus UHLAR - fantomas wrote:

> It's more likely that MessageLabs scan the internet for open relays,
> mailservers features to gather statistics about the internet.

That's quite plausible.  I also operate a more modest scanner: it
connects once a day to every IP address of DNSSEC-signed MX hosts with
DANE TLSA records (around 13k TCP endpoints), checking whether their
TLSA records match their certificate chains.

A small fraction of users with DANE TLSA records are blocking the survey
connections (currently from 100.2.39.101).  If you are one of them,
please consider dropping the filter.

The DANE survey is for your benefit, you get notified[1] if you ever mess
up, and even if *you* never mess up, others who do, get an opportunity to
fix the reported issues promptly.  This keeps the ecosystem healthy enough
for further adoption (<https://stats.dnssec-tools.org/>).

Just blocking traffic you didn't expect isn't always a win if it is not
doing any harm.

--
    Viktor.

[1] Unless there's no way to find a working contact address for your
domain, but if you're operating an email domain it is best to have a
working postmaster address, a non-hidden WHOIS email contact, or a
working contact in the SOA RR (or RFC 8460 _smtp._tls TXT RR):

    https://tools.ietf.org/html/rfc8460#section-3
Reply | Threaded
Open this post in threaded view
|

Re: What is this?

biggsy
In reply to this post by Matus UHLAR - fantomas
Friday, February 28, 2020, 8:06:51 PM, Matus UHLAR - fantomas  wrote:

> On 27.02.20 08:09, Phil Biggs wrote:
>>A friend and I experienced this in October last year.
>>
>>I believe these SYNs have forged source addresses. The objectives being one or more of:
>>- a DOS attack on the legit owner of the IP,
>>- create a state table size issue for you,
>>- to have you block legitimate sources.
>>The last of these certainly happened here.

> per my last e-mail...
> https://marc.info/?l=postfix-users&m=158272022625515&w=2

> SYN with forged address can not cause this kind of error.  This error
> requires connection be made (until then postfix does not know about it) and
> then closed. Thus it requires SYN - SYN+ACK - ACK which does not work with
> forged address.

You are completely correct, of course.  I mistakenly replied to and quoted the OP instead
of Doug Hardie.  Very careless of me.  My apologies.

>>I set up a fail2ban rule to pick these up and, after one day,
>>nearly 9,500 sources had been blocked at the firewall.
>>However, the pf table included addresses that belonged to the likes of MessageLabs.
>>I dropped the rule and unbanned them after realizing that.

> It's more likely that messagelabs scan the internet for open relays,
> mailservers features to gather statistics about the internet.

The SYN (or SYN+ACK) attack was targeting whole address blocks belonging
to AWS, MessageLabs, a Turkish bank and many others.
   
Phil