Seeking clarification of behaviour with authRequired set to false

[Matt Pryor <pr...@international-presence.com>]

Hi there

In our smtpserver.xml config we have relaying to outside domains restricted
to two IP addresses with the authorizedAddresses tag. The authRequired tag
is still commented out as per the default, which from reading the comments
means that it's set to true (I think).

Last week someone managed to guess the password for one of our mail
accounts on James (admittedly the password wasn't very secure, so lesson
learned there). After that they were able to use our mail server to relay
thousands and thousands of spam emails. Reinstalling everything and setting
the password to something more secure has stopped this for the time being
but it's not a long term solution.

I wanted to check before going ahead that if I explicitly set authRequired
to false, will this prevent anyone from logging in using AUTH LOGIN? I am
hoping this will mean that only the IPs specified in authorizedAddresses
will be able to relay to the outside world and AUTH LOGIN will always fail
- I noticed that if I set it to false it still sends the prompt for a
username so wanted to check.

A bit more explanation of how these two work together would be really
great. It would also be nice to find a way to get rid of these persistent
attempts to log in:

Id='-1423500801' User='' AUTH method LOGIN failed from birds@xxxxxx.com@
92.118.38.50

(We get these about every 4 seconds, always from different IP addresses and
always trying different usernames).

Thanks in advance!

Matt


-- 
Matt Pryor
Software Developer

The International Presence Group of Companies
EMAIL: pryor@presencebpm.com
URL: www.International-presence.com

Re: Seeking clarification of behaviour with authRequired set to false

[Tellier Benoit <bt...@apache.org>]

Hi!

Coming back from vacations, thus catch up is slow...

On 05/08/2019 20:54, Matt Pryor wrote:
> Hi there
> 
> In our smtpserver.xml config we have relaying to outside domains restricted
> to two IP addresses with the authorizedAddresses tag. The authRequired tag
> is still commented out as per the default, which from reading the comments
> means that it's set to true (I think).

The default is 'false': do not require authentication in order to
receive other people emails.

If setting this to false you will (for instance) no longer receive GMail
mails.
http://james.apache.org/server/config-smtp-lmtp.html contains a
(lengthy?) explanation of this setting, which is also relatively
explicit with
https://github.com/apache/james-project/blob/master/server/app/src/main/resources/smtpserver.xml
default configuration.

Anyway, we may need to specify explicitly default value (what we do for
newly written conf).

> 
> Last week someone managed to guess the password for one of our mail
> accounts on James (admittedly the password wasn't very secure, so lesson
> learned there). After that they were able to use our mail server to relay
> thousands and thousands of spam emails. Reinstalling everything and setting
> the password to something more secure has stopped this for the time being
> but it's not a long term solution.
> 
> I wanted to check before going ahead that if I explicitly set authRequired
> to false, will this prevent anyone from logging in using AUTH LOGIN? I am
> hoping this will mean that only the IPs specified in authorizedAddresses
> will be able to relay to the outside world and AUTH LOGIN will always fail
> - I noticed that if I set it to false it still sends the prompt for a
> username so wanted to check.

To prevent logging, you can write a handler chain that do not contain
the "AuthCmdHandler", which would of course be a good choice for a MX
(dropping MTA capability)

Look at "CoreCmdHandlerLoader" commodity handler for the exhaustive list.

> 
> A bit more explanation of how these two work together would be really
> great. It would also be nice to find a way to get rid of these persistent
> attempts to log in:
> 
> Id='-1423500801' User='' AUTH method LOGIN failed from birds@xxxxxx.com@
> 92.118.38.50
> 
> (We get these about every 4 seconds, always from different IP addresses and
> always trying different usernames).

cryptearth suggestions are good for securing a MTA, nothing to add.

> 
> Thanks in advance!
> 
> Matt
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

Re: Seeking clarification of behaviour with authRequired set to false

[cryptearth <cr...@cryptearth.de>]

Hey Matt,

I can't tell if setting authRequired = false does what you want. As far 
from what the docs in smtpserver.xml and mailetcontainer.xml say: You 
would generally use one (authorizedAddresses in smtpserver.xml) OR the 
other (RemoteAddrNotInNetwork in mailetcontainer.xml) approach, but I 
can't tell wich is preferred neither.

Matt

Am 05.08.2019 um 19:08 schrieb Matt Pryor:
> Hi Matt, thanks very much for the reply and the useful information.
>
> It's not possible to close port 25 as we do accept inbound mail for our
> domain, but only want to relay mail to the outside world if it's generated
> by our own servers inside the firewall (from the IPs specified in the
> authorizedAddresses tag).
>
> If setting authRequired to false does the job of preventing AUTH LOGIN
> relay from outside and only allowing relay from our IPs then that will do
> what I need, but I just wanted confirmation that's how it works.
>
> I will also take your advice and start blocking IPs on our firewall!
>
> Many thanks
> Matt
>
>
>
>
> On Mon, 5 Aug 2019 at 16:14, cryptearth <cr...@cryptearth.de> wrote:
>
>> Hey Matt,
>>
>> I have to ask as it isn't clear: Do you use James also to receive mails
>> from outside, so TCP/25 has to be open to the world, or is it possible
>> to just close TCP/25 to the public and make it only accible inside your
>> net/vpn?
>> Also: If you experience attacks, that's daily work for the admin: check
>> logs and block access from each unwanted source. Here's a list I have so
>> far:
>>
>> 5.188.52.254
>> 37.49.230.135
>> 37.49.224.149
>> 45.13.39.56
>> 45.13.39.19
>> 45.125.65.77
>> 45.125.65.84
>> 45.125.65.91
>> 45.125.65.96
>> 60.249.1.169
>> 61.2.214.38
>> 80.82.70.118
>> 92.118.161.33
>> 100.2.39.101
>> 103.231.139.3
>> 103.231.139.130
>> 112.213.99.105
>> 113.160.132.15
>> 116.92.233.140
>> 141.98.9.2
>> 141.98.10.41
>> 141.98.10.42
>> 141.98.10.52
>> 141.98.10.53
>> 177.53.107.131
>> 185.36.81.40
>> 185.36.81.55
>> 185.36.81.58
>> 185.36.81.61
>> 185.36.81.64
>> 185.36.81.145
>> 185.36.81.164
>> 185.36.81.165
>> 185.36.81.166
>> 185.36.81.168
>> 185.36.81.169
>> 185.36.81.173
>> 185.36.81.175
>> 185.36.81.176
>> 185.36.81.180
>> 185.36.81.182
>> 185.137.111.22
>> 185.137.111.77
>> 185.137.111.96
>> 185.137.111.123
>> 185.137.111.125
>> 185.137.111.129
>> 185.137.111.136
>> 185.137.111.188
>> 185.222.209.97
>> 185.222.209.99
>> 185.234.216.144
>> 185.234.216.153
>> 185.234.216.164
>> 185.234.216.189
>> 185.234.216.220
>> 185.234.218.120
>> 185.234.218.129
>> 185.234.218.237
>> 185.234.218.238
>> 185.234.218.251
>> 185.234.219.101
>> 190.119.186.57
>> 190.223.51.130
>> 193.56.28.33
>> 193.169.252.212
>> 202.158.27.51
>>
>> So, each day I check the logs for those failed auth lines and add them
>> to the block list. How to do this depends on your firewall. iptables on
>> linux for example works with a "match first" way: you have to add an IP
>> to block before the overall accept any. That's just how iptables work.
>> On my windows systems I use kaspersky - it works in a "most specific"
>> way: So if I add a rule for a specific IP or IP-block it overrides any
>> less specific, but is overridden by any more specific. Like: 5.0.0.0/8
>> overrides the 0.0.0.0/0 but is overridden by any more specific
>> 5.x.0.0/16. That's how kaspersky firewall works. If you don't know how
>> to use the firewall installed on your server, look up manual. I can't
>> tell about Windows firewall as I never used it since its added back in
>> XP SP2.
>>
>> And of course: have strong passwords should be obvious. There is a
>> reason why mail provider in specific require and enforce strict rules
>> about password security. The main accounts like webmaster, postmaster,
>> admin, root, abuse, etc should be secured by high secure passwords as
>> those are main attack targets. All other lower priority are mostly
>> dictonary attacks.
>>
>> In addtion, auto block filters like fail2ban are helpful as most of
>> attacking servers try more than one time - and as a real user mostly use
>> a MUA and sets the password instead of directly connect to a smtp server
>> with telnet it's unlikely a legit user tries to login with a wrong
>> password multiple times. In addition most attacks run on servers - legit
>> users mostly come from dail-up ranges. So it's also easy to scan for
>> connections from specific blocks. Sure, users of VPN services are also
>> come from those IPs, but as a admin you should know your users and how
>> they use your mail server.
>>
>> Matt
>>
>> Am 05.08.2019 um 15:54 schrieb Matt Pryor:
>>> Hi there
>>>
>>> In our smtpserver.xml config we have relaying to outside domains
>> restricted
>>> to two IP addresses with the authorizedAddresses tag. The authRequired
>> tag
>>> is still commented out as per the default, which from reading the
>> comments
>>> means that it's set to true (I think).
>>>
>>> Last week someone managed to guess the password for one of our mail
>>> accounts on James (admittedly the password wasn't very secure, so lesson
>>> learned there). After that they were able to use our mail server to relay
>>> thousands and thousands of spam emails. Reinstalling everything and
>> setting
>>> the password to something more secure has stopped this for the time being
>>> but it's not a long term solution.
>>>
>>> I wanted to check before going ahead that if I explicitly set
>> authRequired
>>> to false, will this prevent anyone from logging in using AUTH LOGIN? I am
>>> hoping this will mean that only the IPs specified in authorizedAddresses
>>> will be able to relay to the outside world and AUTH LOGIN will always
>> fail
>>> - I noticed that if I set it to false it still sends the prompt for a
>>> username so wanted to check.
>>>
>>> A bit more explanation of how these two work together would be really
>>> great. It would also be nice to find a way to get rid of these persistent
>>> attempts to log in:
>>>
>>> Id='-1423500801' User='' AUTH method LOGIN failed from birds@xxxxxx.com@
>>> 92.118.38.50
>>>
>>> (We get these about every 4 seconds, always from different IP addresses
>> and
>>> always trying different usernames).
>>>
>>> Thanks in advance!
>>>
>>> Matt
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

Re: Seeking clarification of behaviour with authRequired set to false

[Matt Pryor <pr...@international-presence.com>]

Hi Matt, thanks very much for the reply and the useful information.

It's not possible to close port 25 as we do accept inbound mail for our
domain, but only want to relay mail to the outside world if it's generated
by our own servers inside the firewall (from the IPs specified in the
authorizedAddresses tag).

If setting authRequired to false does the job of preventing AUTH LOGIN
relay from outside and only allowing relay from our IPs then that will do
what I need, but I just wanted confirmation that's how it works.

I will also take your advice and start blocking IPs on our firewall!

Many thanks
Matt




On Mon, 5 Aug 2019 at 16:14, cryptearth <cr...@cryptearth.de> wrote:

> Hey Matt,
>
> I have to ask as it isn't clear: Do you use James also to receive mails
> from outside, so TCP/25 has to be open to the world, or is it possible
> to just close TCP/25 to the public and make it only accible inside your
> net/vpn?
> Also: If you experience attacks, that's daily work for the admin: check
> logs and block access from each unwanted source. Here's a list I have so
> far:
>
> 5.188.52.254
> 37.49.230.135
> 37.49.224.149
> 45.13.39.56
> 45.13.39.19
> 45.125.65.77
> 45.125.65.84
> 45.125.65.91
> 45.125.65.96
> 60.249.1.169
> 61.2.214.38
> 80.82.70.118
> 92.118.161.33
> 100.2.39.101
> 103.231.139.3
> 103.231.139.130
> 112.213.99.105
> 113.160.132.15
> 116.92.233.140
> 141.98.9.2
> 141.98.10.41
> 141.98.10.42
> 141.98.10.52
> 141.98.10.53
> 177.53.107.131
> 185.36.81.40
> 185.36.81.55
> 185.36.81.58
> 185.36.81.61
> 185.36.81.64
> 185.36.81.145
> 185.36.81.164
> 185.36.81.165
> 185.36.81.166
> 185.36.81.168
> 185.36.81.169
> 185.36.81.173
> 185.36.81.175
> 185.36.81.176
> 185.36.81.180
> 185.36.81.182
> 185.137.111.22
> 185.137.111.77
> 185.137.111.96
> 185.137.111.123
> 185.137.111.125
> 185.137.111.129
> 185.137.111.136
> 185.137.111.188
> 185.222.209.97
> 185.222.209.99
> 185.234.216.144
> 185.234.216.153
> 185.234.216.164
> 185.234.216.189
> 185.234.216.220
> 185.234.218.120
> 185.234.218.129
> 185.234.218.237
> 185.234.218.238
> 185.234.218.251
> 185.234.219.101
> 190.119.186.57
> 190.223.51.130
> 193.56.28.33
> 193.169.252.212
> 202.158.27.51
>
> So, each day I check the logs for those failed auth lines and add them
> to the block list. How to do this depends on your firewall. iptables on
> linux for example works with a "match first" way: you have to add an IP
> to block before the overall accept any. That's just how iptables work.
> On my windows systems I use kaspersky - it works in a "most specific"
> way: So if I add a rule for a specific IP or IP-block it overrides any
> less specific, but is overridden by any more specific. Like: 5.0.0.0/8
> overrides the 0.0.0.0/0 but is overridden by any more specific
> 5.x.0.0/16. That's how kaspersky firewall works. If you don't know how
> to use the firewall installed on your server, look up manual. I can't
> tell about Windows firewall as I never used it since its added back in
> XP SP2.
>
> And of course: have strong passwords should be obvious. There is a
> reason why mail provider in specific require and enforce strict rules
> about password security. The main accounts like webmaster, postmaster,
> admin, root, abuse, etc should be secured by high secure passwords as
> those are main attack targets. All other lower priority are mostly
> dictonary attacks.
>
> In addtion, auto block filters like fail2ban are helpful as most of
> attacking servers try more than one time - and as a real user mostly use
> a MUA and sets the password instead of directly connect to a smtp server
> with telnet it's unlikely a legit user tries to login with a wrong
> password multiple times. In addition most attacks run on servers - legit
> users mostly come from dail-up ranges. So it's also easy to scan for
> connections from specific blocks. Sure, users of VPN services are also
> come from those IPs, but as a admin you should know your users and how
> they use your mail server.
>
> Matt
>
> Am 05.08.2019 um 15:54 schrieb Matt Pryor:
> > Hi there
> >
> > In our smtpserver.xml config we have relaying to outside domains
> restricted
> > to two IP addresses with the authorizedAddresses tag. The authRequired
> tag
> > is still commented out as per the default, which from reading the
> comments
> > means that it's set to true (I think).
> >
> > Last week someone managed to guess the password for one of our mail
> > accounts on James (admittedly the password wasn't very secure, so lesson
> > learned there). After that they were able to use our mail server to relay
> > thousands and thousands of spam emails. Reinstalling everything and
> setting
> > the password to something more secure has stopped this for the time being
> > but it's not a long term solution.
> >
> > I wanted to check before going ahead that if I explicitly set
> authRequired
> > to false, will this prevent anyone from logging in using AUTH LOGIN? I am
> > hoping this will mean that only the IPs specified in authorizedAddresses
> > will be able to relay to the outside world and AUTH LOGIN will always
> fail
> > - I noticed that if I set it to false it still sends the prompt for a
> > username so wanted to check.
> >
> > A bit more explanation of how these two work together would be really
> > great. It would also be nice to find a way to get rid of these persistent
> > attempts to log in:
> >
> > Id='-1423500801' User='' AUTH method LOGIN failed from birds@xxxxxx.com@
> > 92.118.38.50
> >
> > (We get these about every 4 seconds, always from different IP addresses
> and
> > always trying different usernames).
> >
> > Thanks in advance!
> >
> > Matt
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
>

-- 
Matt Pryor
Software Developer

The International Presence Group of Companies
EMAIL: pryor@presencebpm.com
URL: www.International-presence.com

Re: Seeking clarification of behaviour with authRequired set to false

[cryptearth <cr...@cryptearth.de>]

Hey Matt,

I have to ask as it isn't clear: Do you use James also to receive mails 
from outside, so TCP/25 has to be open to the world, or is it possible 
to just close TCP/25 to the public and make it only accible inside your 
net/vpn?
Also: If you experience attacks, that's daily work for the admin: check 
logs and block access from each unwanted source. Here's a list I have so 
far:

5.188.52.254
37.49.230.135
37.49.224.149
45.13.39.56
45.13.39.19
45.125.65.77
45.125.65.84
45.125.65.91
45.125.65.96
60.249.1.169
61.2.214.38
80.82.70.118
92.118.161.33
100.2.39.101
103.231.139.3
103.231.139.130
112.213.99.105
113.160.132.15
116.92.233.140
141.98.9.2
141.98.10.41
141.98.10.42
141.98.10.52
141.98.10.53
177.53.107.131
185.36.81.40
185.36.81.55
185.36.81.58
185.36.81.61
185.36.81.64
185.36.81.145
185.36.81.164
185.36.81.165
185.36.81.166
185.36.81.168
185.36.81.169
185.36.81.173
185.36.81.175
185.36.81.176
185.36.81.180
185.36.81.182
185.137.111.22
185.137.111.77
185.137.111.96
185.137.111.123
185.137.111.125
185.137.111.129
185.137.111.136
185.137.111.188
185.222.209.97
185.222.209.99
185.234.216.144
185.234.216.153
185.234.216.164
185.234.216.189
185.234.216.220
185.234.218.120
185.234.218.129
185.234.218.237
185.234.218.238
185.234.218.251
185.234.219.101
190.119.186.57
190.223.51.130
193.56.28.33
193.169.252.212
202.158.27.51

So, each day I check the logs for those failed auth lines and add them 
to the block list. How to do this depends on your firewall. iptables on 
linux for example works with a "match first" way: you have to add an IP 
to block before the overall accept any. That's just how iptables work. 
On my windows systems I use kaspersky - it works in a "most specific" 
way: So if I add a rule for a specific IP or IP-block it overrides any 
less specific, but is overridden by any more specific. Like: 5.0.0.0/8 
overrides the 0.0.0.0/0 but is overridden by any more specific 
5.x.0.0/16. That's how kaspersky firewall works. If you don't know how 
to use the firewall installed on your server, look up manual. I can't 
tell about Windows firewall as I never used it since its added back in 
XP SP2.

And of course: have strong passwords should be obvious. There is a 
reason why mail provider in specific require and enforce strict rules 
about password security. The main accounts like webmaster, postmaster, 
admin, root, abuse, etc should be secured by high secure passwords as 
those are main attack targets. All other lower priority are mostly 
dictonary attacks.

In addtion, auto block filters like fail2ban are helpful as most of 
attacking servers try more than one time - and as a real user mostly use 
a MUA and sets the password instead of directly connect to a smtp server 
with telnet it's unlikely a legit user tries to login with a wrong 
password multiple times. In addition most attacks run on servers - legit 
users mostly come from dail-up ranges. So it's also easy to scan for 
connections from specific blocks. Sure, users of VPN services are also 
come from those IPs, but as a admin you should know your users and how 
they use your mail server.

Matt

Am 05.08.2019 um 15:54 schrieb Matt Pryor:
> Hi there
>
> In our smtpserver.xml config we have relaying to outside domains restricted
> to two IP addresses with the authorizedAddresses tag. The authRequired tag
> is still commented out as per the default, which from reading the comments
> means that it's set to true (I think).
>
> Last week someone managed to guess the password for one of our mail
> accounts on James (admittedly the password wasn't very secure, so lesson
> learned there). After that they were able to use our mail server to relay
> thousands and thousands of spam emails. Reinstalling everything and setting
> the password to something more secure has stopped this for the time being
> but it's not a long term solution.
>
> I wanted to check before going ahead that if I explicitly set authRequired
> to false, will this prevent anyone from logging in using AUTH LOGIN? I am
> hoping this will mean that only the IPs specified in authorizedAddresses
> will be able to relay to the outside world and AUTH LOGIN will always fail
> - I noticed that if I set it to false it still sends the prompt for a
> username so wanted to check.
>
> A bit more explanation of how these two work together would be really
> great. It would also be nice to find a way to get rid of these persistent
> attempts to log in:
>
> Id='-1423500801' User='' AUTH method LOGIN failed from birds@xxxxxx.com@
> 92.118.38.50
>
> (We get these about every 4 seconds, always from different IP addresses and
> always trying different usernames).
>
> Thanks in advance!
>
> Matt
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org