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 <cryptea...@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 bi...@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-unsubscr...@james.apache.org > For additional commands, e-mail: server-user-h...@james.apache.org > > -- Matt Pryor Software Developer The International Presence Group of Companies EMAIL: pr...@presencebpm.com URL: www.International-presence.com
