Mailing List Archive

Blocking a Class C
Just going over my spam and I find this IP 195.133.39.99

sending a lot of junk. How can you block such a class C?

--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
27 years of Internet Service since 1/6/1995 ! Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On 06/06/2022 23:18, The Doctor via Exim-users wrote:
> Just going over my spam and I find this IP 195.133.39.99
>
> sending a lot of junk. How can you block such a class C?
>

Multiple possible ways.

One would be a
deny hosts= 195.133.39.0/24
acl verb (assuming you really want the class-C).
You get to choose at what stage of processing you want this.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
It's best to use DNSBL /(DNS Block Lists)/ for this, because then you
don't need to update these yourself: e.g. that particular IP address is
already listed on all three block lists at uceprotect.net.  These work
in the same way as a DNS reverse look-up but instead of returning a
domain name, the result is a value depending on whether or not that
particular DNSBL is listing the originating IP address as a suspected
source of spam.

Use the following in your exim.conf, in the acl_check_rcpt section:

deny    message       = GOODBYE!!! $sender_host_address is in a black
list at $dnslist_domain\n$dnslist_text
        dnslists      = dnsbl-1.uceprotect.net : dnsbl-2.uceprotect.net
: dnsbl-3.uceprotect.net

I also use other DNSBLs, just add the ones you want to use to the
dnslists entry.

On 06/06/2022 23:18, The Doctor via Exim-users wrote:
> Just going over my spam and I find this IP 195.133.39.99
>
> sending a lot of junk. How can you block such a class C?
--
footer
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
Me: *"These work in the same way as a DNS reverse look-up but instead of
returning a domain name, the result is a value depending on whether or
not that particular DNSBL is listing the originating IP address as a
suspected source of spam."*

Time I was in bed, asleep... it's not like an rDNS look-up at all...
more like a DNS look-up, but the advice is still good...

And don't block the whole /24 unless you're absolutely certain that you
don't want to accept mail from *any* IP address in that sub-net, e.g.
because of the country of origin.

On 06/06/2022 23:18, The Doctor via Exim-users wrote:
> Just going over my spam and I find this IP 195.133.39.99
>
> sending a lot of junk. How can you block such a class C?

footer
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On Mon, Jun 06, 2022 at 11:33:17PM +0100, Jeremy Harris via Exim-users wrote:
> On 06/06/2022 23:18, The Doctor via Exim-users wrote:
> > Just going over my spam and I find this IP 195.133.39.99
> >
> > sending a lot of junk. How can you block such a class C?
> >
>
> Multiple possible ways.
>
> One would be a
> deny hosts= 195.133.39.0/24
> acl verb (assuming you really want the class-C).
> You get to choose at what stage of processing you want this.

I wonder if Reject IP can be class C based.

> --
> Cheers,
> Jeremy
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/

--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
27 years of Internet Service since 1/6/1995 ! Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
are those 3 not supposed to resolve in DNS? None of them does in my end..


> deny message       = GOODBYE!!! $sender_host_address is in a black
> list at $dnslist_domain\n$dnslist_text
>         dnslists      = dnsbl-1.uceprotect.net :
> dnsbl-2.uceprotect.net : dnsbl-3.uceprotect.net

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
They only have NS records, because they're name servers(!)... specify
that you want NS records, like this:

dig dnsbl-1.uceprotect.net ns

On 07/06/2022 07:37, Laura Williamson via Exim-users wrote:
> are those 3 not supposed to resolve in DNS? None of them does in my end..
--
footer
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On 6/7/22 14:37, Laura Williamson via Exim-users wrote:
> are those 3 not supposed to resolve in DNS? None of them does in my end..

You prefix the IP address in reverse order to the domain. The query is e.g.

99.39.133.195.dnsbl-1.uceprotect.net. IN A

to look up 195.133.39.99

If listed. the A record would be 127.0.0.{1,2,3, ...}

And the meaning of the last octet is locally defined by the specific DNSBL.

You can often get additional details by also getting a TXT record.



--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
of course, my mistake.

On 07/06/2022 10:39, R M Crorie via Exim-users wrote:
> They only have NS records, because they're name servers(!)... specify
> that you want NS records, like this:
>
> dig dnsbl-1.uceprotect.net ns
>
> On 07/06/2022 07:37, Laura Williamson via Exim-users wrote:
>> are those 3 not supposed to resolve in DNS? None of them does in my
>> end..

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On 2022-06-06, The Doctor via Exim-users <exim-users@exim.org> wrote:
> On Mon, Jun 06, 2022 at 11:33:17PM +0100, Jeremy Harris via Exim-users wrote:
>> On 06/06/2022 23:18, The Doctor via Exim-users wrote:
>> > Just going over my spam and I find this IP 195.133.39.99
>> >
>> > sending a lot of junk. How can you block such a class C?
>> >
>>
>> Multiple possible ways.
>>
>> One would be a
>> deny hosts= 195.133.39.0/24
>> acl verb (assuming you really want the class-C).
>> You get to choose at what stage of processing you want this.
>
> I wonder if Reject IP can be class C based.

well, yeah, a network-layer firewall is another solution.
>


--
Jasen.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On Thu, Dec 08, 2022 at 11:35:15AM +0300, Odhiambo Washington wrote:
> Define this in the global section:
>
> hostlist blocked_hosts = 5.34.207.0/24
>
> Then in acl_smtp_connect:
> drop
> message = You are banned here
> log_message = Blocked host from 5.34.207.0/24 subnet
> ($sender_host_address)
> hosts = +blocked_hosts
>

Still getting

tcp4 0 0 midwest.ab.ca.smtps 5.34.207.58.62078 SYN_RCVD
tcp4 0 0 204.209.81.122.smtps 5.34.207.77.62962 SYN_RCVD
tcp4 0 0 204.209.81.102.smtps 5.34.207.195.9246 ESTABLISHED
tcp4 0 0 stagehypnotistco.smtps 5.34.207.114.55268 ESTABLISHED
tcp4 0 0 204.209.81.97.smtps 5.34.207.198.63598 ESTABLISHED
tcp4 0 6153 204.209.81.174.smtps 5.34.207.114.4726 ESTABLISHED
tcp4 0 6153 dwellmodern.ca.smtps 5.34.207.190.48444 ESTABLISHED
tcp4 0 0 204.209.81.110.smtps 5.34.207.198.63764 ESTABLISHED
tcp4 0 0 204.209.81.51.smtps 5.34.207.198.38686 ESTABLISHED
tcp4 0 0 204.209.81.87.smtps 5.34.207.77.43412 ESTABLISHED
tcp4 0 0 environmental-so.smtps 5.34.207.49.53302 ESTABLISHED
tcp4 0 0 204.209.81.51.smtps 5.34.207.153.61228 ESTABLISHED
tcp4 0 0 lpeser.ca.smtps 5.34.207.198.43508 ESTABLISHED
tcp4 0 0 204.209.81.142.smtps 5.34.207.198.4664 ESTABLISHED
tcp4 0 0 gibb.ab.ca.smtps 5.34.207.189.8904 ESTABLISHED
tcp4 0 0 robertsonsplumbi.smtps 5.34.207.189.1834 ESTABLISHED
tcp4 0 151 attilahypnotist..smtps 5.34.207.198.5432 ESTABLISHED
tcp4 0 0 techsupplies.ca.smtps 5.34.207.58.62492 ESTABLISHED
tcp4 0 0 proflamefireplac.smtps 5.34.207.198.56078 ESTABLISHED
tcp4 0 0 204.209.81.97.smtps 5.34.207.191.21406 ESTABLISHED
tcp4 0 0 204.209.81.151.smtps 5.34.207.95.43326 ESTABLISHED
tcp4 0 0 unityintegration.smtps 5.34.207.191.29918 ESTABLISHED
tcp4 0 47 albertadogs.com.smtps 5.34.207.77.59246 ESTABLISHED
tcp4 0 0 lpeser.ca.smtps 5.34.207.153.16136 ESTABLISHED
tcp4 0 0 valpy.com.smtps 5.34.207.153.7492 ESTABLISHED
tcp4 0 0 travelersfirstch.smtps 5.34.207.153.45748 ESTABLISHED
tcp4 0 43 massageresultsco.smtps 5.34.207.185.20282 ESTABLISHED
tcp4 0 0 204.209.81.102.smtps 5.34.207.186.47794 ESTABLISHED
tcp4 0 0 204.209.81.110.smtps 5.34.207.193.51362 ESTABLISHED
tcp4 0 0 valpy.com.smtps 5.34.207.198.50486 ESTABLISHED
tcp4 0 64 204.209.81.167.smtps 5.34.207.198.34662 ESTABLISHED
tcp4 0 64 stage-hypnosis-c.smtps 5.34.207.198.64002 ESTABLISHED
tcp4 0 64 204.209.81.102.smtps 5.34.207.198.23784 ESTABLISHED
tcp4 0 64 promoteyourbusin.smtps 5.34.207.198.51544 ESTABLISHED
tcp4 0 64 fortchipewyanlod.smtps 5.34.207.198.21030 ESTABLISHED

I am using exim-4.95 from FreeBSD ports.

Etierh the port is in question or the IP block is being faked.


> On Thu, Dec 8, 2022 at 10:31 AM Andreas Metzler via Exim-users <
> exim-users@exim.org> wrote:
>
> > On 2022-12-08 The Doctor via Exim-users <exim-users@exim.org> wrote:
> > > On Wed, Dec 07, 2022 at 04:02:55PM -0700, The Doctor via Exim-users
> > wrote:
> > > > On Wed, Dec 07, 2022 at 04:08:34PM +0000, Jeremy Harris via Exim-users
> > wrote:
> > > > > On 07/12/2022 15:34, The Doctor via Exim-users wrote:
> > > > > > How do you block a whole Class C like
> > > > > > 5.34.207.0/24 using the configuration file?
> > > > >
> > > > > Make a start by reading the manual, about ACLs
> > > > > and hostlists.
> >
> > > > Already did that.
> >
> > > For clarification, here is what I am seeing when I go
> > > netstat -a | egrep smtp
> >
> > > tcp4 0 0 204.209.81.116.smtps 5.34.207.189.11238
> > ESTABLISHED
> > [...]
> >
> > I am missing some sign of "I tried this but it did not work because I
> > failed
> > to understand that specific detail there ...". This looks more like "Phew
> > that is lot to read, let's simply ask."
> >
> > cu Andreas
> > --
> > `What a good friend you are to him, Dr. Maturin. His other friends are
> > so grateful to you.'
> > `I sew his ears on from time to time, sure'
> >
> > --
> > ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> > ## Exim details at http://www.exim.org/
> > ## Please use the Wiki with this list - http://wiki.exim.org/
> >
>
>
> --
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", egrep -v '^$|^.*#' ??\_(???)_/?? :-)

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Happy Christmas 2022 and Merry New Year 2023 Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On 08/12/2022 13:26, The Doctor via Exim-users wrote:
> tcp4 0 0 midwest.ab.ca.smtps 5.34.207.58.62078 SYN_RCVD
> tcp4 0 0 204.209.81.122.smtps 5.34.207.77.62962 SYN_RCVD
> tcp4 0 0 204.209.81.102.smtps 5.34.207.195.9246 ESTABLISHED
> tcp4 0 0 stagehypnotistco.smtps 5.34.207.114.55268 ESTABLISHED
> tcp4 0 0 204.209.81.97.smtps 5.34.207.198.63598 ESTABLISHED
> tcp4 0 6153 204.209.81.174.smtps 5.34.207.114.4726 ESTABLISHED
> tcp4 0 6153 dwellmodern.ca.smtps 5.34.207.190.48444 ESTABLISHED
> tcp4 0 0 204.209.81.110.smtps 5.34.207.198.63764 ESTABLISHED
> tcp4 0 0 204.209.81.51.smtps 5.34.207.198.38686 ESTABLISHED
> tcp4 0 0 204.209.81.87.smtps 5.34.207.77.43412 ESTABLISHED
> tcp4 0 0 environmental-so.smtps 5.34.207.49.53302 ESTABLISHED
> tcp4 0 0 204.209.81.51.smtps 5.34.207.153.61228 ESTABLISHED
> tcp4 0 0 lpeser.ca.smtps 5.34.207.198.43508 ESTABLISHED
> tcp4 0 0 204.209.81.142.smtps 5.34.207.198.4664 ESTABLISHED
> tcp4 0 0 gibb.ab.ca.smtps 5.34.207.189.8904 ESTABLISHED
> tcp4 0 0 robertsonsplumbi.smtps 5.34.207.189.1834 ESTABLISHED
> tcp4 0 151 attilahypnotist..smtps 5.34.207.198.5432 ESTABLISHED
> tcp4 0 0 techsupplies.ca.smtps 5.34.207.58.62492 ESTABLISHED
> tcp4 0 0 proflamefireplac.smtps 5.34.207.198.56078 ESTABLISHED
> tcp4 0 0 204.209.81.97.smtps 5.34.207.191.21406 ESTABLISHED
> tcp4 0 0 204.209.81.151.smtps 5.34.207.95.43326 ESTABLISHED
> tcp4 0 0 unityintegration.smtps 5.34.207.191.29918 ESTABLISHED
> tcp4 0 47 albertadogs.com.smtps 5.34.207.77.59246 ESTABLISHED
> tcp4 0 0 lpeser.ca.smtps 5.34.207.153.16136 ESTABLISHED
> tcp4 0 0 valpy.com.smtps 5.34.207.153.7492 ESTABLISHED
> tcp4 0 0 travelersfirstch.smtps 5.34.207.153.45748 ESTABLISHED
> tcp4 0 43 massageresultsco.smtps 5.34.207.185.20282 ESTABLISHED
> tcp4 0 0 204.209.81.102.smtps 5.34.207.186.47794 ESTABLISHED
> tcp4 0 0 204.209.81.110.smtps 5.34.207.193.51362 ESTABLISHED
> tcp4 0 0 valpy.com.smtps 5.34.207.198.50486 ESTABLISHED
> tcp4 0 64 204.209.81.167.smtps 5.34.207.198.34662 ESTABLISHED
> tcp4 0 64 stage-hypnosis-c.smtps 5.34.207.198.64002 ESTABLISHED
> tcp4 0 64 204.209.81.102.smtps 5.34.207.198.23784 ESTABLISHED
> tcp4 0 64 promoteyourbusin.smtps 5.34.207.198.51544 ESTABLISHED
> tcp4 0 64 fortchipewyanlod.smtps 5.34.207.198.21030 ESTABLISHED
>
> I am using exim-4.95 from FreeBSD ports.


Ah, those are all ".smtps" - I suspect netstat on FreeBSD means "port 465" there.
If those are hung waiting to complete TLS negotiation, you'd see that.

For those, use the main-config option "host_reject_connection" rather than the
connect ACL - it operates before the TLS startup for TLS-on-connect ports,
while the ACL is run after.


I'm considering changing that, even though it's an incompatible change.
Having the ACL operate before TLS startup (for TLS-on-connect) would align
with the operation for STARTTLS, and possibly cause less surprise.
Anybody want to comment?
--
Cheers,
Jeremy


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On Thu, Dec 08, 2022 at 02:33:01PM +0000, Jeremy Harris via Exim-users wrote:
> On 08/12/2022 13:26, The Doctor via Exim-users wrote:
> > tcp4 0 0 midwest.ab.ca.smtps 5.34.207.58.62078 SYN_RCVD
> > tcp4 0 0 204.209.81.122.smtps 5.34.207.77.62962 SYN_RCVD
> > tcp4 0 0 204.209.81.102.smtps 5.34.207.195.9246 ESTABLISHED
> > tcp4 0 0 stagehypnotistco.smtps 5.34.207.114.55268 ESTABLISHED
> > tcp4 0 0 204.209.81.97.smtps 5.34.207.198.63598 ESTABLISHED
> > tcp4 0 6153 204.209.81.174.smtps 5.34.207.114.4726 ESTABLISHED
> > tcp4 0 6153 dwellmodern.ca.smtps 5.34.207.190.48444 ESTABLISHED
> > tcp4 0 0 204.209.81.110.smtps 5.34.207.198.63764 ESTABLISHED
> > tcp4 0 0 204.209.81.51.smtps 5.34.207.198.38686 ESTABLISHED
> > tcp4 0 0 204.209.81.87.smtps 5.34.207.77.43412 ESTABLISHED
> > tcp4 0 0 environmental-so.smtps 5.34.207.49.53302 ESTABLISHED
> > tcp4 0 0 204.209.81.51.smtps 5.34.207.153.61228 ESTABLISHED
> > tcp4 0 0 lpeser.ca.smtps 5.34.207.198.43508 ESTABLISHED
> > tcp4 0 0 204.209.81.142.smtps 5.34.207.198.4664 ESTABLISHED
> > tcp4 0 0 gibb.ab.ca.smtps 5.34.207.189.8904 ESTABLISHED
> > tcp4 0 0 robertsonsplumbi.smtps 5.34.207.189.1834 ESTABLISHED
> > tcp4 0 151 attilahypnotist..smtps 5.34.207.198.5432 ESTABLISHED
> > tcp4 0 0 techsupplies.ca.smtps 5.34.207.58.62492 ESTABLISHED
> > tcp4 0 0 proflamefireplac.smtps 5.34.207.198.56078 ESTABLISHED
> > tcp4 0 0 204.209.81.97.smtps 5.34.207.191.21406 ESTABLISHED
> > tcp4 0 0 204.209.81.151.smtps 5.34.207.95.43326 ESTABLISHED
> > tcp4 0 0 unityintegration.smtps 5.34.207.191.29918 ESTABLISHED
> > tcp4 0 47 albertadogs.com.smtps 5.34.207.77.59246 ESTABLISHED
> > tcp4 0 0 lpeser.ca.smtps 5.34.207.153.16136 ESTABLISHED
> > tcp4 0 0 valpy.com.smtps 5.34.207.153.7492 ESTABLISHED
> > tcp4 0 0 travelersfirstch.smtps 5.34.207.153.45748 ESTABLISHED
> > tcp4 0 43 massageresultsco.smtps 5.34.207.185.20282 ESTABLISHED
> > tcp4 0 0 204.209.81.102.smtps 5.34.207.186.47794 ESTABLISHED
> > tcp4 0 0 204.209.81.110.smtps 5.34.207.193.51362 ESTABLISHED
> > tcp4 0 0 valpy.com.smtps 5.34.207.198.50486 ESTABLISHED
> > tcp4 0 64 204.209.81.167.smtps 5.34.207.198.34662 ESTABLISHED
> > tcp4 0 64 stage-hypnosis-c.smtps 5.34.207.198.64002 ESTABLISHED
> > tcp4 0 64 204.209.81.102.smtps 5.34.207.198.23784 ESTABLISHED
> > tcp4 0 64 promoteyourbusin.smtps 5.34.207.198.51544 ESTABLISHED
> > tcp4 0 64 fortchipewyanlod.smtps 5.34.207.198.21030 ESTABLISHED
> >
> > I am using exim-4.95 from FreeBSD ports.
>
>
> Ah, those are all ".smtps" - I suspect netstat on FreeBSD means "port 465" there.
> If those are hung waiting to complete TLS negotiation, you'd see that.
>
> For those, use the main-config option "host_reject_connection" rather than the
> connect ACL - it operates before the TLS startup for TLS-on-connect ports,
> while the ACL is run after.
>
>
> I'm considering changing that, even though it's an incompatible change.
> Having the ACL operate before TLS startup (for TLS-on-connect) would align
> with the operation for STARTTLS, and possibly cause less surprise.
> Anybody want to comment?

Just reading this.

Tried

host_reject_connection = 5.34.207.*

Still not doing the rejection job.

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Happy Christmas 2022 and Merry New Year 2023 Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On Thu, Dec 08, 2022 at 10:30:05AM -0700, The Doctor via Exim-users wrote:
> Tried
>
> host_reject_connection = 5.34.207.*
>
> Still not doing the rejection job.

Use CIDR instead of pattern.
--
Eugene Berdnikov

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
Jeremy Harris via Exim-users schreef op 2022-12-08 15:33:
> On 08/12/2022 13:26, The Doctor via Exim-users wrote:
>> tcp4 0 0 midwest.ab.ca.smtps 5.34.207.58.62078
>> SYN_RCVD
(...)
>> tcp4 0 64 fortchipewyanlod.smtps 5.34.207.198.21030
>> ESTABLISHED
>>
>> I am using exim-4.95 from FreeBSD ports.
>
>
> Ah, those are all ".smtps" - I suspect netstat on FreeBSD means "port
> 465" there.
> If those are hung waiting to complete TLS negotiation, you'd see that.
>
> For those, use the main-config option "host_reject_connection" rather
> than the
> connect ACL - it operates before the TLS startup for TLS-on-connect
> ports,
> while the ACL is run after.
>
>
> I'm considering changing that, even though it's an incompatible change.
> Having the ACL operate before TLS startup (for TLS-on-connect) would
> align
> with the operation for STARTTLS, and possibly cause less surprise.
> Anybody want to comment?
> --
> Cheers,
> Jeremy

Port 465 is indeed smtps on FreeBSD.

As a FreeBSD user myself I commit suspicious or caught addresses like
these to a table in PF (either as a single address or a CIDR range) so
they can't reach Exim at all anymore.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On Thu, Dec 8, 2022 at 8:47 PM The Doctor via Exim-users <
exim-users@exim.org> wrote:

> On Thu, Dec 08, 2022 at 02:33:01PM +0000, Jeremy Harris via Exim-users
> wrote:
> > On 08/12/2022 13:26, The Doctor via Exim-users wrote:
> > > tcp4 0 0 midwest.ab.ca.smtps 5.34.207.58.62078
> SYN_RCVD
> > > tcp4 0 0 204.209.81.122.smtps 5.34.207.77.62962
> SYN_RCVD
> > > tcp4 0 0 204.209.81.102.smtps 5.34.207.195.9246
> ESTABLISHED
> > > tcp4 0 0 stagehypnotistco.smtps 5.34.207.114.55268
> ESTABLISHED
> > > tcp4 0 0 204.209.81.97.smtps 5.34.207.198.63598
> ESTABLISHED
> > > tcp4 0 6153 204.209.81.174.smtps 5.34.207.114.4726
> ESTABLISHED
> > > tcp4 0 6153 dwellmodern.ca.smtps 5.34.207.190.48444
> ESTABLISHED
> > > tcp4 0 0 204.209.81.110.smtps 5.34.207.198.63764
> ESTABLISHED
> > > tcp4 0 0 204.209.81.51.smtps 5.34.207.198.38686
> ESTABLISHED
> > > tcp4 0 0 204.209.81.87.smtps 5.34.207.77.43412
> ESTABLISHED
> > > tcp4 0 0 environmental-so.smtps 5.34.207.49.53302
> ESTABLISHED
> > > tcp4 0 0 204.209.81.51.smtps 5.34.207.153.61228
> ESTABLISHED
> > > tcp4 0 0 lpeser.ca.smtps 5.34.207.198.43508
> ESTABLISHED
> > > tcp4 0 0 204.209.81.142.smtps 5.34.207.198.4664
> ESTABLISHED
> > > tcp4 0 0 gibb.ab.ca.smtps 5.34.207.189.8904
> ESTABLISHED
> > > tcp4 0 0 robertsonsplumbi.smtps 5.34.207.189.1834
> ESTABLISHED
> > > tcp4 0 151 attilahypnotist..smtps 5.34.207.198.5432
> ESTABLISHED
> > > tcp4 0 0 techsupplies.ca.smtps 5.34.207.58.62492
> ESTABLISHED
> > > tcp4 0 0 proflamefireplac.smtps 5.34.207.198.56078
> ESTABLISHED
> > > tcp4 0 0 204.209.81.97.smtps 5.34.207.191.21406
> ESTABLISHED
> > > tcp4 0 0 204.209.81.151.smtps 5.34.207.95.43326
> ESTABLISHED
> > > tcp4 0 0 unityintegration.smtps 5.34.207.191.29918
> ESTABLISHED
> > > tcp4 0 47 albertadogs.com.smtps 5.34.207.77.59246
> ESTABLISHED
> > > tcp4 0 0 lpeser.ca.smtps 5.34.207.153.16136
> ESTABLISHED
> > > tcp4 0 0 valpy.com.smtps 5.34.207.153.7492
> ESTABLISHED
> > > tcp4 0 0 travelersfirstch.smtps 5.34.207.153.45748
> ESTABLISHED
> > > tcp4 0 43 massageresultsco.smtps 5.34.207.185.20282
> ESTABLISHED
> > > tcp4 0 0 204.209.81.102.smtps 5.34.207.186.47794
> ESTABLISHED
> > > tcp4 0 0 204.209.81.110.smtps 5.34.207.193.51362
> ESTABLISHED
> > > tcp4 0 0 valpy.com.smtps 5.34.207.198.50486
> ESTABLISHED
> > > tcp4 0 64 204.209.81.167.smtps 5.34.207.198.34662
> ESTABLISHED
> > > tcp4 0 64 stage-hypnosis-c.smtps 5.34.207.198.64002
> ESTABLISHED
> > > tcp4 0 64 204.209.81.102.smtps 5.34.207.198.23784
> ESTABLISHED
> > > tcp4 0 64 promoteyourbusin.smtps 5.34.207.198.51544
> ESTABLISHED
> > > tcp4 0 64 fortchipewyanlod.smtps 5.34.207.198.21030
> ESTABLISHED
> > >
> > > I am using exim-4.95 from FreeBSD ports.
> >
> >
> > Ah, those are all ".smtps" - I suspect netstat on FreeBSD means "port
> 465" there.
> > If those are hung waiting to complete TLS negotiation, you'd see that.
> >
> > For those, use the main-config option "host_reject_connection" rather
> than the
> > connect ACL - it operates before the TLS startup for TLS-on-connect
> ports,
> > while the ACL is run after.
> >
> >
> > I'm considering changing that, even though it's an incompatible change.
> > Having the ACL operate before TLS startup (for TLS-on-connect) would
> align
> > with the operation for STARTTLS, and possibly cause less surprise.
> > Anybody want to comment?
>
> Just reading this.
>
> Tried
>
> host_reject_connection = 5.34.207.*
>
> Still not doing the rejection job.
>

hostlist host_rejects = 5.34.207.0/24
host_reject_connection = +host_rejects

host_reject_connection = +host_reject

root@gw:/usr/home/wash # exim -bh 5.34.207.3

**** SMTP testing session as if from host 5.34.207.3
**** but without any ident (RFC 1413) callback.
**** This is not for real!

>>> host in hosts_connection_nolog? no (option unset)
LOG: SMTP connection from [5.34.207.3]
>>> host in host_lookup? yes (matched "*")
>>> looking up host name for 5.34.207.3
>>> IP address lookup using gethostbyaddr()
>>> IP address lookup failed: h_errno=1
>>> host in "5.34.207.0/24"? yes (matched "5.34.207.0/24")
>>> host in host_reject_connection? yes (matched "+host_rejects")
LOG: refused connection from [5.34.207.3] (host_reject_connection)
554 SMTP service not available
root@gw:/usr/home/wash #



--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(?)_/¯ :-)
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On Thu, Dec 08, 2022 at 09:24:19PM +0300, Odhiambo Washington via Exim-users wrote:
> On Thu, Dec 8, 2022 at 8:47 PM The Doctor via Exim-users <
> exim-users@exim.org> wrote:
>
> > On Thu, Dec 08, 2022 at 02:33:01PM +0000, Jeremy Harris via Exim-users
> > wrote:
> > > On 08/12/2022 13:26, The Doctor via Exim-users wrote:
> > > > tcp4 0 0 midwest.ab.ca.smtps 5.34.207.58.62078
> > SYN_RCVD
> > > > tcp4 0 0 204.209.81.122.smtps 5.34.207.77.62962
> > SYN_RCVD
> > > > tcp4 0 0 204.209.81.102.smtps 5.34.207.195.9246
> > ESTABLISHED
> > > > tcp4 0 0 stagehypnotistco.smtps 5.34.207.114.55268
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.97.smtps 5.34.207.198.63598
> > ESTABLISHED
> > > > tcp4 0 6153 204.209.81.174.smtps 5.34.207.114.4726
> > ESTABLISHED
> > > > tcp4 0 6153 dwellmodern.ca.smtps 5.34.207.190.48444
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.110.smtps 5.34.207.198.63764
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.51.smtps 5.34.207.198.38686
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.87.smtps 5.34.207.77.43412
> > ESTABLISHED
> > > > tcp4 0 0 environmental-so.smtps 5.34.207.49.53302
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.51.smtps 5.34.207.153.61228
> > ESTABLISHED
> > > > tcp4 0 0 lpeser.ca.smtps 5.34.207.198.43508
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.142.smtps 5.34.207.198.4664
> > ESTABLISHED
> > > > tcp4 0 0 gibb.ab.ca.smtps 5.34.207.189.8904
> > ESTABLISHED
> > > > tcp4 0 0 robertsonsplumbi.smtps 5.34.207.189.1834
> > ESTABLISHED
> > > > tcp4 0 151 attilahypnotist..smtps 5.34.207.198.5432
> > ESTABLISHED
> > > > tcp4 0 0 techsupplies.ca.smtps 5.34.207.58.62492
> > ESTABLISHED
> > > > tcp4 0 0 proflamefireplac.smtps 5.34.207.198.56078
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.97.smtps 5.34.207.191.21406
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.151.smtps 5.34.207.95.43326
> > ESTABLISHED
> > > > tcp4 0 0 unityintegration.smtps 5.34.207.191.29918
> > ESTABLISHED
> > > > tcp4 0 47 albertadogs.com.smtps 5.34.207.77.59246
> > ESTABLISHED
> > > > tcp4 0 0 lpeser.ca.smtps 5.34.207.153.16136
> > ESTABLISHED
> > > > tcp4 0 0 valpy.com.smtps 5.34.207.153.7492
> > ESTABLISHED
> > > > tcp4 0 0 travelersfirstch.smtps 5.34.207.153.45748
> > ESTABLISHED
> > > > tcp4 0 43 massageresultsco.smtps 5.34.207.185.20282
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.102.smtps 5.34.207.186.47794
> > ESTABLISHED
> > > > tcp4 0 0 204.209.81.110.smtps 5.34.207.193.51362
> > ESTABLISHED
> > > > tcp4 0 0 valpy.com.smtps 5.34.207.198.50486
> > ESTABLISHED
> > > > tcp4 0 64 204.209.81.167.smtps 5.34.207.198.34662
> > ESTABLISHED
> > > > tcp4 0 64 stage-hypnosis-c.smtps 5.34.207.198.64002
> > ESTABLISHED
> > > > tcp4 0 64 204.209.81.102.smtps 5.34.207.198.23784
> > ESTABLISHED
> > > > tcp4 0 64 promoteyourbusin.smtps 5.34.207.198.51544
> > ESTABLISHED
> > > > tcp4 0 64 fortchipewyanlod.smtps 5.34.207.198.21030
> > ESTABLISHED
> > > >
> > > > I am using exim-4.95 from FreeBSD ports.
> > >
> > >
> > > Ah, those are all ".smtps" - I suspect netstat on FreeBSD means "port
> > 465" there.
> > > If those are hung waiting to complete TLS negotiation, you'd see that.
> > >
> > > For those, use the main-config option "host_reject_connection" rather
> > than the
> > > connect ACL - it operates before the TLS startup for TLS-on-connect
> > ports,
> > > while the ACL is run after.
> > >
> > >
> > > I'm considering changing that, even though it's an incompatible change.
> > > Having the ACL operate before TLS startup (for TLS-on-connect) would
> > align
> > > with the operation for STARTTLS, and possibly cause less surprise.
> > > Anybody want to comment?
> >
> > Just reading this.
> >
> > Tried
> >
> > host_reject_connection = 5.34.207.*
> >
> > Still not doing the rejection job.
> >
>
> hostlist host_rejects = 5.34.207.0/24
> host_reject_connection = +host_rejects
>
> host_reject_connection = +host_reject
>
> root@gw:/usr/home/wash # exim -bh 5.34.207.3
>
> **** SMTP testing session as if from host 5.34.207.3
> **** but without any ident (RFC 1413) callback.
> **** This is not for real!
>
> >>> host in hosts_connection_nolog? no (option unset)
> LOG: SMTP connection from [5.34.207.3]
> >>> host in host_lookup? yes (matched "*")
> >>> looking up host name for 5.34.207.3
> >>> IP address lookup using gethostbyaddr()
> >>> IP address lookup failed: h_errno=1
> >>> host in "5.34.207.0/24"? yes (matched "5.34.207.0/24")
> >>> host in host_reject_connection? yes (matched "+host_rejects")
> LOG: refused connection from [5.34.207.3] (host_reject_connection)
> 554 SMTP service not available
> root@gw:/usr/home/wash #
>
>
>

Still seeing

netstat -a | egrep smtp
tcp4 0 0 exploreedmonton..smtps 5.34.207.189.26526 SYN_RCVD
tcp4 0 0 comparealbertapo.smtps 5.34.207.190.30872 FIN_WAIT_2
tcp4 0 0 204.209.81.148.smtps 5.34.207.114.57546 FIN_WAIT_2




Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Happy Christmas 2022 and Merry New Year 2023 Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On Thu, Dec 08, 2022 at 12:22:13PM -0700, The Doctor via Exim-users wrote:
> On Thu, Dec 08, 2022 at 09:24:19PM +0300, Odhiambo Washington via Exim-users wrote:
[...]
> > >>> host in "5.34.207.0/24"? yes (matched "5.34.207.0/24")
> > >>> host in host_reject_connection? yes (matched "+host_rejects")
> > LOG: refused connection from [5.34.207.3] (host_reject_connection)
> > 554 SMTP service not available
> > root@gw:/usr/home/wash #
>
> Still seeing
>
> netstat -a | egrep smtp
> tcp4 0 0 exploreedmonton..smtps 5.34.207.189.26526 SYN_RCVD
> tcp4 0 0 comparealbertapo.smtps 5.34.207.190.30872 FIN_WAIT_2
> tcp4 0 0 204.209.81.148.smtps 5.34.207.114.57546 FIN_WAIT_2

Rejection with status code 554 requires established TCP connection.
Study mainlog to check whether connections are rejected.

However, absense of numerous connections in ESTABLISHED state is a hint
that rejection works.

If you don't want TCP connections, use packet filtering on kernel level
instead of Exim's configuration options.
--
Eugene Berdnikov

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On Thu, Dec 08, 2022 at 10:47:18PM +0300, Evgeniy Berdnikov via Exim-users wrote:
> On Thu, Dec 08, 2022 at 12:22:13PM -0700, The Doctor via Exim-users wrote:
> > On Thu, Dec 08, 2022 at 09:24:19PM +0300, Odhiambo Washington via Exim-users wrote:
> [...]
> > > >>> host in "5.34.207.0/24"? yes (matched "5.34.207.0/24")
> > > >>> host in host_reject_connection? yes (matched "+host_rejects")
> > > LOG: refused connection from [5.34.207.3] (host_reject_connection)
> > > 554 SMTP service not available
> > > root@gw:/usr/home/wash #
> >
> > Still seeing
> >
> > netstat -a | egrep smtp
> > tcp4 0 0 exploreedmonton..smtps 5.34.207.189.26526 SYN_RCVD
> > tcp4 0 0 comparealbertapo.smtps 5.34.207.190.30872 FIN_WAIT_2
> > tcp4 0 0 204.209.81.148.smtps 5.34.207.114.57546 FIN_WAIT_2
>
> Rejection with status code 554 requires established TCP connection.
> Study mainlog to check whether connections are rejected.
>
> However, absense of numerous connections in ESTABLISHED state is a hint
> that rejection works.
>
> If you don't want TCP connections, use packet filtering on kernel level
> instead of Exim's configuration options.

I am surprised that my firewall ACL is not getting this
in a switch!

> --
> Eugene Berdnikov
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Happy Christmas 2022 and Merry New Year 2023 Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
D?a 8. decembra 2022 14:33:01 UTC používate? Jeremy Harris via Exim-users <exim-users@exim.org> napísal:

>For those, use the main-config option "host_reject_connection" rather than the
>connect ACL - it operates before the TLS startup for TLS-on-connect ports,
>while the ACL is run after.
>
>I'm considering changing that, even though it's an incompatible change.
>Having the ACL operate before TLS startup (for TLS-on-connect) would align
>with the operation for STARTTLS, and possibly cause less surprise.

>Anybody want to comment?

Yes, i want, if i can, as i know nothing about exim's internals and very
little about TLS, and if my English allow me it ;-)

If i properly understand you, you want to move current "connect" ACL
to be handled before TLS handshake happens. I see that problematic,
not by implementation (i know nothing about it), but with results:

We was talk about this some time ago on IRC, if you remember... You
mentioned, that currently the "host_reject_connection" returns to client
plaintext response... I understand, that this is "historic", but Ii hope that
you will agree, that this is wrong, at least because clients will not
expect plaintext on encrypted connection. Yes, we can consider
those rejected at connect stage as bad and ignore them. But despite
this, we have to respond correctly, as we have to considef misconfigured
clients rather than malicious. Plain response is OK before STARTTLS
was issued, but with TLS-on-connect connection we have either
silently close connection or issue some TLS error. I do not know what
is proper to reject TLS handshake, but i hope that here are people
who know. Or, we can inspire eg. from nginx's solution of rejecting TLS
handshake (BTW, openssl s_client returns it as "alert number 112").

Thus, we have to distinguish connection type (plain/TLS) to choose
appropriate rejection. IMO, better can be to add separate ACL, which
will be called before current connect ACL, but only on TLS-on-connect
ports. Its semantic have to be simmilar to connect ACL, but with defer
either not allowed or treated the same as deny/drop. Simillar with
the message modiffier (ignore/not allow). If i can, i will vote for
allowing both.

Another reason to separate them is, that eg. SNI name and some
other properties are not available before TLS handshake is finished.
Yes, it can be checked latter, but checking at connect stage can
save some possibly not cheap queries in latter ACLs. Checking
SNI in current connect ACL is very effective...

One thing, which is not clear for me, is what you mean by
"align with the operation for STARTTLS", i hope that it is not
what i understand ;-)

And when we are talking about TLS, i consider as useful to allow
encrypted condition in both, the connect and helo ACLs, to one
can distinguish encrypted connections there (now one have to check
eg. $tls_in_cipher variable). Please, can it be added?

regards


--
Slavko
https://www.slavino.sk/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On Thu, Dec 8, 2022 at 11:38 PM The Doctor via Exim-users <
exim-users@exim.org> wrote:

> On Thu, Dec 08, 2022 at 10:47:18PM +0300, Evgeniy Berdnikov via Exim-users
> wrote:
> > On Thu, Dec 08, 2022 at 12:22:13PM -0700, The Doctor via Exim-users
> wrote:
> > > On Thu, Dec 08, 2022 at 09:24:19PM +0300, Odhiambo Washington via
> Exim-users wrote:
> > [...]
> > > > >>> host in "5.34.207.0/24"? yes (matched "5.34.207.0/24")
> > > > >>> host in host_reject_connection? yes (matched "+host_rejects")
> > > > LOG: refused connection from [5.34.207.3] (host_reject_connection)
> > > > 554 SMTP service not available
> > > > root@gw:/usr/home/wash #
> > >
> > > Still seeing
> > >
> > > netstat -a | egrep smtp
> > > tcp4 0 0 exploreedmonton..smtps 5.34.207.189.26526
> SYN_RCVD
> > > tcp4 0 0 comparealbertapo.smtps 5.34.207.190.30872
> FIN_WAIT_2
> > > tcp4 0 0 204.209.81.148.smtps 5.34.207.114.57546
> FIN_WAIT_2
> >
> > Rejection with status code 554 requires established TCP connection.
> > Study mainlog to check whether connections are rejected.
> >
> > However, absense of numerous connections in ESTABLISHED state is a hint
> > that rejection works.
> >
> > If you don't want TCP connections, use packet filtering on kernel level
> > instead of Exim's configuration options.
>
> I am surprised that my firewall ACL is not getting this
> in a switch!


I shared config snippets that work.
If you wanted to deal with this at the firewall level, you did not need
Exim to do it!

--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(?)_/¯ :-)
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On Thu, Dec 08, 2022 at 11:44:44PM +0300, Odhiambo Washington via Exim-users wrote:
> On Thu, Dec 8, 2022 at 11:38 PM The Doctor via Exim-users <
> exim-users@exim.org> wrote:
>
> > On Thu, Dec 08, 2022 at 10:47:18PM +0300, Evgeniy Berdnikov via Exim-users
> > wrote:
> > > On Thu, Dec 08, 2022 at 12:22:13PM -0700, The Doctor via Exim-users
> > wrote:
> > > > On Thu, Dec 08, 2022 at 09:24:19PM +0300, Odhiambo Washington via
> > Exim-users wrote:
> > > [...]
> > > > > >>> host in "5.34.207.0/24"? yes (matched "5.34.207.0/24")
> > > > > >>> host in host_reject_connection? yes (matched "+host_rejects")
> > > > > LOG: refused connection from [5.34.207.3] (host_reject_connection)
> > > > > 554 SMTP service not available
> > > > > root@gw:/usr/home/wash #
> > > >
> > > > Still seeing
> > > >
> > > > netstat -a | egrep smtp
> > > > tcp4 0 0 exploreedmonton..smtps 5.34.207.189.26526
> > SYN_RCVD
> > > > tcp4 0 0 comparealbertapo.smtps 5.34.207.190.30872
> > FIN_WAIT_2
> > > > tcp4 0 0 204.209.81.148.smtps 5.34.207.114.57546
> > FIN_WAIT_2
> > >
> > > Rejection with status code 554 requires established TCP connection.
> > > Study mainlog to check whether connections are rejected.
> > >
> > > However, absense of numerous connections in ESTABLISHED state is a hint
> > > that rejection works.
> > >
> > > If you don't want TCP connections, use packet filtering on kernel level
> > > instead of Exim's configuration options.
> >
> > I am surprised that my firewall ACL is not getting this
> > in a switch!
>
>
> I shared config snippets that work.
> If you wanted to deal with this at the firewall level, you did not need
> Exim to do it!
>

As I said, the firewall wer not dropping the packets hence the
need to use exim ACL.

By the way,

This looks like a very interesting attack!

Have a look at https://www.nk.ca/~doctor/5.34.207.txt

but be careful!

This file is 113960735 bytes.

> --
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", egrep -v '^$|^.*#' ??\_(???)_/?? :-)
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Happy Christmas 2022 and Merry New Year 2023 Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
Please learn how to write your responses. Either top-post, or post below,
by snipping.

Even without doing anything, my server has been rejecting these IPs because
they are listed on spamhaus.

On Thu, Dec 8, 2022 at 11:58 PM The Doctor <doctor@doctor.nl2k.ab.ca> wrote:

> On Thu, Dec 08, 2022 at 11:44:44PM +0300, Odhiambo Washington via
> Exim-users wrote:
> > On Thu, Dec 8, 2022 at 11:38 PM The Doctor via Exim-users <
> > exim-users@exim.org> wrote:
> >
> > > On Thu, Dec 08, 2022 at 10:47:18PM +0300, Evgeniy Berdnikov via
> Exim-users
> > > wrote:
> > > > On Thu, Dec 08, 2022 at 12:22:13PM -0700, The Doctor via Exim-users
> > > wrote:
> > > > > On Thu, Dec 08, 2022 at 09:24:19PM +0300, Odhiambo Washington via
> > > Exim-users wrote:
> > > > [...]
> > > > > > >>> host in "5.34.207.0/24"? yes (matched "5.34.207.0/24")
> > > > > > >>> host in host_reject_connection? yes (matched "+host_rejects")
> > > > > > LOG: refused connection from [5.34.207.3]
> (host_reject_connection)
> > > > > > 554 SMTP service not available
> > > > > > root@gw:/usr/home/wash #
> > > > >
> > > > > Still seeing
> > > > >
> > > > > netstat -a | egrep smtp
> > > > > tcp4 0 0 exploreedmonton..smtps 5.34.207.189.26526
> > > SYN_RCVD
> > > > > tcp4 0 0 comparealbertapo.smtps 5.34.207.190.30872
> > > FIN_WAIT_2
> > > > > tcp4 0 0 204.209.81.148.smtps 5.34.207.114.57546
> > > FIN_WAIT_2
> > > >
> > > > Rejection with status code 554 requires established TCP connection.
> > > > Study mainlog to check whether connections are rejected.
> > > >
> > > > However, absense of numerous connections in ESTABLISHED state is a
> hint
> > > > that rejection works.
> > > >
> > > > If you don't want TCP connections, use packet filtering on kernel
> level
> > > > instead of Exim's configuration options.
> > >
> > > I am surprised that my firewall ACL is not getting this
> > > in a switch!
> >
> >
> > I shared config snippets that work.
> > If you wanted to deal with this at the firewall level, you did not need
> > Exim to do it!
> >
>
> As I said, the firewall wer not dropping the packets hence the
> need to use exim ACL.
>
> By the way,
>
> This looks like a very interesting attack!
>
> Have a look at https://www.nk.ca/~doctor/5.34.207.txt
>
> but be careful!
>
> This file is 113960735 bytes.
>
> > --
> > Best regards,
> > Odhiambo WASHINGTON,
> > Nairobi,KE
> > +254 7 3200 0004/+254 7 2274 3223
> > "Oh, the cruft.", egrep -v '^$|^.*#' ??\_(???)_/?? :-)
> > --
> > ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> > ## Exim details at http://www.exim.org/
> > ## Please use the Wiki with this list - http://wiki.exim.org/
>
> --
> Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
> Yahweh, King & country!Never Satan President Republic!Beware AntiChrist
> rising!
> Look at Psalms 14 and 53 on Atheism
> https://www.empire.kred/ROOTNK?t=94a1f39b
> Happy Christmas 2022 and Merry New Year 2023 Beware
> https://mindspring.com
>


--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(?)_/¯ :-)
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On 08/12/2022 20:42, Slavko via Exim-users wrote:
> D?a 8. decembra 2022 14:33:01 UTC používate? Jeremy Harris via Exim-users <exim-users@exim.org> napísal:
>
>> For those, use the main-config option "host_reject_connection" rather than the
>> connect ACL - it operates before the TLS startup for TLS-on-connect ports,
>> while the ACL is run after.
>>
>> I'm considering changing that, even though it's an incompatible change.
>> Having the ACL operate before TLS startup (for TLS-on-connect) would align
>> with the operation for STARTTLS, and possibly cause less surprise.
>
>> Anybody want to comment?
>
> Yes, i want, if i can, as i know nothing about exim's internals and very
> little about TLS, and if my English allow me it ;-)
>
> If i properly understand you, you want to move current "connect" ACL
> to be handled before TLS handshake happens. I see that problematic,
> not by implementation (i know nothing about it), but with results:
>
> We was talk about this some time ago on IRC, if you remember... You
> mentioned, that currently the "host_reject_connection" returns to client
> plaintext response... I understand, that this is "historic", but Ii hope that
> you will agree, that this is wrong, at least because clients will not
> expect plaintext on encrypted connection.

That is arguably a matter of semantics and expectations. At the TCP-and-TLS
level, a TLS startup has not bee done yet (so responding with an encrypted
SMTP failure response isn't possible, and doing a TLS startup just in
order to do so is precisely what we're wanting to avoid. At the SMTP level
it could be argued that connection has not yet completed, so an SMTP response
of any kind is bad. At the application-client level, trying to make a
TLS-on-connect connection and get an (encrypted) banner... it won't be managing
to make the TLS-level connection whether we put anything on the wire
(in plaintext) or not.

We could just drop the connection at the TCP level, silently; that wouldn't
be hard to code. I don't think it'd make any difference to a client
that didn't have a human peering at a packet capture of the connection
attempt.

> Yes, we can consider
> those rejected at connect stage as bad and ignore them. But despite
> this, we have to respond correctly, as we have to considef misconfigured
> clients rather than malicious. Plain response is OK before STARTTLS
> was issued, but with TLS-on-connect connection we have either
> silently close connection or issue some TLS error. I do not know what
> is proper to reject TLS handshake, but i hope that here are people
> who know. Or, we can inspire eg. from nginx's solution of rejecting TLS
> handshake (BTW, openssl s_client returns it as "alert number 112").

"unrecognized name" ?
per https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-6
at least. That should be used for an SNI mismatch; I don't see that it should be
used for an administrative denial

[.
49 access_denied sounds nice, but it's apparently, per RFC 8446,
for "A valid certificate or PSK was received, but when
access control was applied, the sender decided not to proceed with
negotiation." - and we've not even assessed any such validity.
71 insufficient_security might work
]

But sending anything complex enough to need the TLS library sounds like
too much hard work. I don't think either supported library provides
a simple way of "start the handshake and intentionally cancel it".

>
> Thus, we have to distinguish connection type (plain/TLS) to choose
> appropriate rejection. IMO, better can be to add separate ACL, which
> will be called before current connect ACL, but only on TLS-on-connect
> ports[...]
> Another reason to separate them is, that eg. SNI name and some
> other properties are not available before TLS handshake is finished.

Not so. It's available early and can be used to select the server cert.
So, selecting a nonexistent cert depending on SNI can be done
and will result in no TLS connection.

What other properties?

> One thing, which is not clear for me, is what you mean by
> "align with the operation for STARTTLS", i hope that it is not
> what i understand ;-)

Since you didn't say, I can't tell...

By "align" I mean "operates before TLS startup".

> And when we are talking about TLS, i consider as useful to allow
> encrypted condition in both, the connect and helo ACLs, to one
> can distinguish encrypted connections there (now one have to check
> eg. $tls_in_cipher variable). Please, can it be added?

There is an "encrypted=" ACL condition. Or you can check $tls_in_cipher,
as you said - it's fully equivalent.
--
Cheers,
Jeremy


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Blocking a Class C [ In reply to ]
On Thu, Dec 08, 2022 at 08:42:46PM +0000, Slavko via Exim-users wrote:
> D??a 8. decembra 2022 14:33:01 UTC pou????vate?? Jeremy Harris via Exim-users <exim-users@exim.org> nap??sal:
>
> >For those, use the main-config option "host_reject_connection" rather than the
> >connect ACL - it operates before the TLS startup for TLS-on-connect ports,
> >while the ACL is run after.
> >
> >I'm considering changing that, even though it's an incompatible change.
> >Having the ACL operate before TLS startup (for TLS-on-connect) would align
> >with the operation for STARTTLS, and possibly cause less surprise.
>
> >Anybody want to comment?
>
> Yes, i want, if i can, as i know nothing about exim's internals and very
> little about TLS, and if my English allow me it ;-)
>
> If i properly understand you, you want to move current "connect" ACL
> to be handled before TLS handshake happens. I see that problematic,
> not by implementation (i know nothing about it), but with results:
>
> We was talk about this some time ago on IRC, if you remember... You
> mentioned, that currently the "host_reject_connection" returns to client
> plaintext response... I understand, that this is "historic", but Ii hope that
> you will agree, that this is wrong, at least because clients will not
> expect plaintext on encrypted connection. Yes, we can consider
> those rejected at connect stage as bad and ignore them. But despite
> this, we have to respond correctly, as we have to considef misconfigured
> clients rather than malicious. Plain response is OK before STARTTLS
> was issued, but with TLS-on-connect connection we have either
> silently close connection or issue some TLS error. I do not know what
> is proper to reject TLS handshake, but i hope that here are people
> who know. Or, we can inspire eg. from nginx's solution of rejecting TLS
> handshake (BTW, openssl s_client returns it as "alert number 112").
>
> Thus, we have to distinguish connection type (plain/TLS) to choose
> appropriate rejection. IMO, better can be to add separate ACL, which
> will be called before current connect ACL, but only on TLS-on-connect
> ports. Its semantic have to be simmilar to connect ACL, but with defer
> either not allowed or treated the same as deny/drop. Simillar with
> the message modiffier (ignore/not allow). If i can, i will vote for
> allowing both.
>
> Another reason to separate them is, that eg. SNI name and some
> other properties are not available before TLS handshake is finished.
> Yes, it can be checked latter, but checking at connect stage can
> save some possibly not cheap queries in latter ACLs. Checking
> SNI in current connect ACL is very effective...
>
> One thing, which is not clear for me, is what you mean by
> "align with the operation for STARTTLS", i hope that it is not
> what i understand ;-)
>
> And when we are talking about TLS, i consider as useful to allow
> encrypted condition in both, the connect and helo ACLs, to one
> can distinguish encrypted connections there (now one have to check
> eg. $tls_in_cipher variable). Please, can it be added?
>
> regards
>

Looks like a fix for 4.97 .

I still wonder why the FReeBSD porters never went up to 4.96?

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Happy Christmas 2022 and Merry New Year 2023 Beware https://mindspring.com

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

1 2  View All