thanks for sharing this. after a gazillion years had no idea this was there.
BUT.....
when i opened this and went to advanced, none of the ssl ports are shown
in the config, yet surgemail was listening on them when we did a netstat.
?????
david camm
advanced wbe systems
keller, tx
On 3/18/2016 4:31 PM, Ed wrote:
> under global settings | mail services you set ports .. Simply blank
> out the ones you don't want surge to answer on and it won't.
>
> you will have to restart surge to make the changes take effect.
>
> #2) it is normal for a lot of MTA's to try and connect SSL on the
> standard ports (25, 110), we see this all the time ... if it doesn't
> work then they just revert to non-secure communications.
>
> --Ed
>
> On 03/18/2016 05:28 PM, David Camm wrote:
>> we found that surgemail was listening on ports 993, 995 and 465 and
>> could not see a way to turn that off, which is why we put in the
>> iptables rules.
>>
>> we're still seeing some of these:
>>
>> pop: ssl failed SSL error gave up after 6 seconds (20 attempts) (from IP
>> 157.56.111.101)
>>
>> which i fail to understand. seems they're trying to connect using ssl on
>> the standard pop port (110). which makes no sense to me. looking at the
>> ip addresses involved, they all appear to be registered to microsoft,
>> which makes even less sense :-)
>>
>> there was, however, some minor fallout from implementing the rules.....
>>
>> customer using phones and setting them up themselves, have sometimes
>> failed to turn off ssl and have, as a result, been blocked. when they
>> turn of ssl, they're fine.
>>
>> of course, when a customer asks me how to set up their phone, i tell
>> them explicitly to turn ssl off.
>>
>> i think we'll just let this one ride.
>>
>> david camm
>> advanced web systems
>> keller, tx
>>
>>
>> On 3/18/2016 4:08 PM, surgemail-support wrote:
>>> Nothing currently would block that, you could disable ssl on the non
>>> ssl ports but that strikes me as a bad idea.
>>> We could add a black listing feature for these attempts, but I'm
>>> reluctant to do that without being sure it's causing some
>>> problem other than log entries as it might knock out real users in
>>> some situations.
>>>
>>> Can you send me a bigger log section from mail.err and mail.log and
>>> imap.log and pop.log so I can see more context.
>>>
>>> ChrisP.
>>>
>>>
>>> On 19/03/2016 6:18 a.m., David Camm wrote:
>>>> over the past week or so, we been getting a tremendous number of
>>>> attempted logins that generate error messages like this:
>>>>
>>>> pop: ssl failed SSL error gave up after 6 seconds (20 attempts) (from
>>>> IP 208.95.135.96)
>>>>
>>>> and
>>>>
>>>> smtp: ssl failed SSL error gave up after 6 seconds (20 attempts)
>>>> (from IP 208.95.135.96)
>>>>
>>>> we added iptables rules to drop any traffic attempting to connect to
>>>> the secure ports (993, 995 and 465) as we don't support that, but
>>>> that didn't help.
>>>>
>>>> so, clearly the attackers are attempting to connect using the
>>>> non-secure ports with ssl protocol.
>>>>
>>>> is there any way, rather than allowing them 20 attempts to either ban
>>>> the ip or cut them off after a fewer number of attempts?
>>>>
>>>> this has become REALLY annoying.
>>>>
>>>> david camm
>>>> advanced web systems
>>>> keller, tx
>>>>
>>>
>>>
>>>
>>
>>
>>
>
|
