#!/bin/sh
QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming` 
SMTPD="/var/qmail/bin/qmail-smtpd"
TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb"
HOSTNAME=`hostname`
VCHKPW="/home/vpopmail/bin/vchkpw"
RECORDIO=""
RECORDIO="/usr/bin/recordio"
export SMTPS=1
export FORCETLS=0
export SMTPAUTH="!"

exec /usr/bin/softlimit -m 128000000 \
/usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
$RECORDIO \
$SMTPD $VCHKPW /bin/true 2>&1



⁣Get BlueMail for Android ​

On Apr 22, 2020, 6:38 PM, at 6:38 PM, David Bray <da...@brayworth.com.au> wrote:
>Could I ask you command line for recordio
>Thanks in advance
>David Bray
>0418 745334
>2 ∞ & <
>
>
>On Wed, 22 Apr 2020 at 23:40, Eric Broch <ebr...@whitehorsetc.com>
>wrote:
>
>> Hi David,
>>
>> I think you're on to something with fail2ban (keying off maillog). I
>was
>> monitoring my smtps port (watching the certificate and encryption
>scroll
>> by) using /usr/bin/recordio and /var/log/maillog and found that the
>bad
>> guys are trying to login. Here are some failures from maillog:
>>
>> vchkpw-smtps: vpopmail user not found
>> testforu...@whitehorsetc.com:92.118.38.83
>>
>> vchkpw-smtps: password fail (pass: 'somepassword')
>> someu...@whitehorsetc.com:185.50.149.2
>>
>> Maybe a fail2ban rule?!
>>
>> Eric
>>
>>
>> On 4/18/2020 4:12 AM, David Bray wrote:
>>
>> Hi thanks - yes can block that IP
>> But it’s not just one, and the solution is not fine enough
>> I want more of a fail2ban rule, bad use bad pass 3 strikes your out
>>
>> I need to know they are mucking round.
>>
>> I tried sending myself through the port with a bad password- sure it
>> blocks it, but there is no log of the event - it looks like a legit,
>> connection from Ann IP
>>
>> On Sat, 18 Apr 2020 at 7:30 pm, Chris <boh...@gmail.com> wrote:
>>
>>> Here's a great article with instructions on how to implement an IP
>>> blacklist in iptables. Unless you've got a user in Panama, it looks
>like
>>> you's want to block 141.98.80.30
>>>
>>>
>https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/
>>>
>>> On Sat, Apr 18, 2020 at 5:49 PM David Bray <da...@brayworth.com.au>
>>> wrote:
>>>
>>>> sure - thanks for replying, this comes in waves taking the server
>to
>>>> it's maximum at times
>>>>
>>>> as far as I can see this only logs are this:
>>>>
>>>> ==> /var/log/qmail/smtps/current <==
>>>> 2020-04-18 05:04:48.450871500 tcpserver: status: 6/60
>>>> 2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from
>141.98.80.30
>>>> 2020-04-18 05:04:48.480787500 tcpserver: ok 13339
>dev.brayworth.com:172.105.181.18:465
>>>> :141.98.80.30::25638
>>>> 2020-04-18 05:04:52.797644500 tcpserver: status: 7/60
>>>> 2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from
>141.98.80.30
>>>> 2020-04-18 05:04:52.830768500 tcpserver: ok 13340
>dev.brayworth.com:172.105.181.18:465
>>>> :141.98.80.30::14862
>>>> 2020-04-18 05:04:57.248902500 tcpserver: status: 8/60
>>>> 2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from
>141.98.80.30
>>>> 2020-04-18 05:04:57.304006500 tcpserver: ok 13342
>dev.brayworth.com:172.105.181.18:465
>>>> :141.98.80.30::9646
>>>> 2020-04-18 05:05:01.854790500 tcpserver: status: 9/60
>>>> 2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from
>141.98.80.30
>>>> 2020-04-18 05:05:01.902266500 tcpserver: ok 13345
>dev.brayworth.com:172.105.181.18:465
>>>> :141.98.80.30::54058
>>>> 2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256
>>>> 2020-04-18 05:05:09.729713500 tcpserver: status: 8/60
>>>> 2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256
>>>> 2020-04-18 05:06:05.965716500 tcpserver: status: 7/60
>>>> 2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256
>>>> 2020-04-18 05:06:06.141273500 tcpserver: status: 6/60
>>>>
>>>> David Bray
>>>> 0418 745334
>>>> 2 ∞ & <
>>>>
>>>>
>>>> On Sat, 18 Apr 2020 at 15:41, Eric Broch <ebr...@whitehorsetc.com>
>>>> wrote:
>>>>
>>>>> Can you send the log of one of the "bad" connections?
>>>>>
>>>>> On 4/17/2020 10:59 PM, David Bray wrote:
>>>>>
>>>>> I can see I'm getting hammered on my smtps port
>>>>>
>>>>> How can I mitigate this?
>>>>>
>>>>> I can see the IP's in /var/log/qmail/smtps/current
>>>>>
>>>>> *but where do I actually see that the smtp auth actually fails ?*
>>>>>
>>>>> or do I need to increase the logging somewhere ?
>>>>>
>>>>> if I tail -f /var/log/dovecot.log
>>>>>
>>>>> I can see the imap and pop failures
>>>>>
>>>>> thanks in advance
>>>>>
>>>>> David Bray
>>>>> 0418 745334
>>>>> 2 ∞ & <
>>>>>
>>>>> --
>> # David
>>
>>

Reply via email to