Re: What is this?

2020-02-26 Thread Phil Biggs 
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

Re: unverified_recipient_tempfail_action

2020-02-26 Thread Wietse Venema 
Wietse Venema:
> Daniel Ry?link:
> > Hello
> > 
> > What are the valid values for this configuration option?
> > 
> > I tried to set it as "PERMIT", and the server failed to stard saying 
> > it's "Bad configuration". 
> 
> RTFM?
> http://www.postfix.org/postconf.5.html#unverified_recipient_reject_code
> http://www.postfix.org/postconf.5.html#reject_unverified_recipient

Ah, this was ..tempfail_action. Documentation sats:

unverified_recipient_tempfail_action (default: $reject_tempfail_action)
   The Postfix SMTP server's action when reject_unverified_recipient fails
   due to a temporary error condition. Specify "defer" to defer the remote
   SMTP  client  request  immediately.  With the default "defer_if_permit"
   action, the Postfix SMTP server continues to look for opportunities  to
   reject  mail,  and defers the client request only if it would otherwise
   be accepted.

And those two, defer and defer_if_permit, are the permitted actions.

> > My aim is to set the server so that it defers mail for recipients
> > that fail permanently during the recipient address verification
> > (for example, the target mailserver answers that the user does not
> > exist. I don't want to accept mail for a non-existent user). On
> > the other hand, I want to accept mail for recipients that fail
> > temporarily (for example, greylisting or full mailbox), because
> > some of me users use this servers as smarthost and I want the
> > server to try several times on their behalf instead of rejecting
> > the mail immediately.
> 
> Use reject_unverified_recipient only for addresses in domains that
> you control, not everything out there on the internets.
> 
> smtpd_recipient_restrictions =
> ...stuff...
> reject_unauth_destination
> ..stuff...
> reject_unverified_recipeint
> ..stuff...
> 
>   Wietse
>

Re: What is this?

2020-02-26 Thread John Gateley 




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

micah anderson:

Matus UHLAR - fantomas  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

Re: unverified_recipient_tempfail_action

2020-02-26 Thread Wietse Venema 
Daniel Ry?link:
> Hello
> 
> What are the valid values for this configuration option?
> 
> I tried to set it as "PERMIT", and the server failed to stard saying 
> it's "Bad configuration". 

RTFM?
http://www.postfix.org/postconf.5.html#unverified_recipient_reject_code
http://www.postfix.org/postconf.5.html#reject_unverified_recipient

> My aim is to set the server so that it defers mail for recipients
> that fail permanently during the recipient address verification
> (for example, the target mailserver answers that the user does not
> exist. I don't want to accept mail for a non-existent user). On
> the other hand, I want to accept mail for recipients that fail
> temporarily (for example, greylisting or full mailbox), because
> some of me users use this servers as smarthost and I want the
> server to try several times on their behalf instead of rejecting
> the mail immediately.

Use reject_unverified_recipient only for addresses in domains that
you control, not everything out there on the internets.

smtpd_recipient_restrictions =
...stuff...
reject_unauth_destination
..stuff...
reject_unverified_recipeint
..stuff...

Wietse

Re: What is this?

2020-02-26 Thread Wietse Venema 
micah anderson:
> Matus UHLAR - fantomas  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

unverified_recipient_tempfail_action

2020-02-26 Thread Daniel Ryšlink 

Hello

What are the valid values for this configuration option?

I tried to set it as "PERMIT", and the server failed to stard saying 
it's "Bad configuration". My aim is to set the server so that it defers 
mail for recipients that fail permanently during the recipient address 
verification (for example, the target mailserver answers that the user 
does not exist. I don't want to accept mail for a non-existent user). On 
the other hand, I want to accept mail for recipients that fail 
temporarily (for example, greylisting or full mailbox), because some of 
me users use this servers as smarthost and I want the server to try 
several times on their behalf instead of rejecting the mail immediately.


Thank you in advance.

--
S pozdravem,
Daniel Ryšlink

Re: What is this?

2020-02-26 Thread 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
   r...@rafa.eu.org
--
"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."

Re: What is this?

2020-02-26 Thread micah anderson 
Matus UHLAR - fantomas  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.

Re: What is this?

2020-02-26 Thread Mark Rousell 
On 26/02/2020 11:05, Viktor Dukhovni wrote:
>
> This appears to be a network registered in Britain with a yandex.ru
> abuse contact:  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:
.
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: 

All for what it's worth.

-- 
Mark Rousell

Re: What is this?

2020-02-26 Thread Matus UHLAR - fantomas 

On 26 February 2020, at 02:54, Jaroslaw Rafa  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, uh...@fantomas.sk ; 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

Re: What is this?

2020-02-26 Thread Viktor Dukhovni 
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:  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:  internethosting-...@yandex.ru
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 '92.118.38.0/24AS50360'

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.

Re: What is this?

2020-02-26 Thread Doug Hardie 


> On 26 February 2020, at 02:54, Jaroslaw Rafa  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

What is this?

2020-02-26 Thread 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
   r...@rafa.eu.org
--
"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."