@qmailtoaster.com>>
*Subject: *Re: [qmailtoaster] SMTPS Port - Who is Failing ?
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 s
; David,
>>>
>>>
>>>
>>> You might try the suggestions here:
>>> https://www.taverner-rich.com/mitigating-brute-force-attacks/
>>>
>>>
>>>
>>> I put them in place on my server and it definitely helped.
>>&
;>
*Date: *Wednesday, April 22, 2020 at 9:40 AM
*To: *mailto:qmailtoaster-list@qmailtoaster.com>>
*Subject: *Re: [qmailtoaster] SMTPS Port - Who is Failing ?
__ __
Hi David,
I think you're on to something with fail2ban (keying
#!/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
;> 0418 745334
>> 2 ∞ & <
>>
>>
>> On Thu, 23 Apr 2020 at 00:06, Jaime Lerner
>
>> wrote:
>>
>>> David,
>>>
>>>
>>>
>>> You might try the suggestions here:
>>> https://www.taverner-rich.com/mitigat
t;> I put them in place on my server and it definitely helped.
>>
>>
>>
>> Jaime
>>
>>
>>
>> *From: *Eric Broch
>> *Reply-To: *
>> *Date: *Wednesday, April 22, 2020 at 9:40 AM
>> *To: *
>> *Subject: *Re: [qmailtoaster] SMTPS Port - Who
server and it definitely helped.
>>
>>
>>
>> Jaime
>>
>>
>>
>> From: Eric Broch
>> Reply-To:
>> Date: Wednesday, April 22, 2020 at 9:40 AM
>> To:
>> Subject: Re: [qmailtoaster] SMTPS Port - Who is Failing ?
>>
>&
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 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
on my server and it definitely helped.
>
>
>
> Jaime
>
>
>
> *From: *Eric Broch
> *Reply-To: *
> *Date: *Wednesday, April 22, 2020 at 9:40 AM
> *To: *
> *Subject: *Re: [qmailtoaster] SMTPS Port - Who is Failing ?
>
>
>
> Hi David,
>
> I think you're on
Hi Eric / David.
My vpopmail.conf from fail2ban :
failregex = vchkpw-smtp: vpopmail user not found .*:$
vchkpw-smtps: vpopmail user not found .*:$
vchkpw-smtp: null password given .*:$
vchkpw-smtps: null password given .*:$
vchkpw-submission: null
, April 22, 2020 at 9:40 AM
*To: *
*Subject: *Re: [qmailtoaster] SMTPS Port - Who is Failing ?
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
Port - Who is Failing ?
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
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:
HI David, you can use TCPDump with source IP example
tcpdump src 1.1.1.1
And or with ports if you want. Like this
tcpdump -nnvvS src thebadguyipaddress and dst port 25
> On Apr 21, 2020, at 17:15, David Bray wrote:
>
> Hey Remo, just looking at Andy's suggestion though
>
> tcpdump -
Hey Remo, just looking at Andy's suggestion though
tcpdump - that only copies the data from the port ?
So if if I were to use Andy's idea - it would be an interference in the
port and the data would have to be proxied to the correct port (or lost)
tcpdump - can I use that on an existing
Thankfully CentOS 7 using 1.0.2k so not affected - thanks for the tip though
David Bray
0418 745334
2 ∞ & <
On Wed, 22 Apr 2020 at 09:40, Andrew Swartz wrote:
> David,
>
> I just received this OpenSSL security advisory which may be describing
> your problem. It describes a vulnerability
The other is to leverage some of Andy’s suggestions and use tcpdump on that
port and see
> Il giorno 21 apr 2020, alle ore 16:40, Andrew Swartz
> ha scritto:
>
> David,
>
> I have no idea where (or even if) incoming TLS sessions are logged.
>
> I've used "openssl s_client" numerous times
David,
I have no idea where (or even if) incoming TLS sessions are logged.
I've used "openssl s_client" numerous times to see the details of a
connection, but only from the client perspective.
Openssl does have the "s_server" complement of s_client, but I've never
used it:
David,
I just received this OpenSSL security advisory which may be describing
your problem. It describes a vulnerability which allows a DOS attack by
submitting an invalid certificate.
https://www.openssl.org/news/secadv/20200421.txt
-Andy
On 4/20/2020 8:15 PM, David Bray wrote:
Hi
Hi Eric - was that for Andy or me
I'm on
- qmail-1.03-3.1.1.qt.el7.x86_64
- qmailadmin-1.2.16-2.qt.el7.x86_64
- qmailmrtg-4.2-3.qt.el7.x86_64
David Bray
0418 745334
2 ∞ & <
On Tue, 21 Apr 2020 at 23:34, Eric Broch wrote:
> Andy,
>
> May I ask what version of qmail you're on?
>
>
Andy,
May I ask what version of qmail you're on?
Eric
On 4/20/2020 10:15 PM, David Bray wrote:
Hi Andy - you have grasped the problem accurately
As I understand it, the transaction does not leave a great deal of
scope - negotiate the encryption, send a password successfully or
Hi Andy - you have grasped the problem accurately
As I understand it, the transaction does not leave a great deal of scope -
negotiate the encryption, send a password successfully or unsuccessfully -
(at that point it's logged)
So it has to be the negotiation phase ...
but:
- I've only just
Port 465 should be SMTP over SSL/TLS. Therefore the sequence of events is:
1. Establish TCP connection
2. Negotiate SSL/TLS session
3. Begin SMTP session
Of these, the SSL/TLS negotiation is by far the most CPU-intensive.
Consider trying to see what is happening with the SSL/TLS
I will give more suggestions in the morning time for bed.
> Il giorno 19 apr 2020, alle ore 23:13, David Bray ha
> scritto:
>
>
> Hey thanks Remo
> smtps is an inbound port, they are contacting me - this IP is in Russia
> somewhere - so do I want to engage (perhaps, probably not but ..)
>
Hey thanks Remo
smtps is an inbound port, they are contacting me - this IP is in Russia
somewhere - so do I want to engage (perhaps, probably not but ..)
I could of course block that IP - but that doesn't help, I'd have to block
endless IPs
I'd like to know what's taking the CPU load, in theory
Hi,
Can you reach the server? It maybe blocking you. So what does your queue looks
like?
Here is mine for example:
# qmHandle -L
Messages in local queue: 0
Messages in remote queue: 0
My other server
# qmHandle -L
10355792 (19, L)
Return-path: r...@qmailx.com
From: Anacron
To:
Ok - but after all the investigation etc, this is actually the trigger
which caught my eye in the first place
How this comes about is:
1. User say hey I can't send
2. I look and see this high CPU load and intermittent failures for
client to send
Any thoughts on where to start looking
Thanks Eric
It's hard to track things but I think I have had success monitoring the
/var/log/maillog
I'm not sure why I didn't pick this up earlier, I'm already using the
fail2ban suggestion of the older qmailtoaster wiki (
http://wiki.qmailtoaster.com/index.php/Fail2Ban), actually had a rule to
I don't know if anyone use csf firewall. It have many options to prevent
such issues.
--
--
Best Regards
Muhammad Tahnan Al Anas
On Sat, Apr 18, 2020 at 9:12 PM Eric Broch wrote:
> It looks like a connect and disconnect. If there was authentication you'd
> see it. I don't think you have
I stopped iptables and moved to pfsense for my front end firewall. Way more
options and easier to deal with.
> Il giorno 18 apr 2020, alle ore 08:11, Eric Broch
> ha scritto:
>
>
> It looks like a connect and disconnect. If there was authentication you'd see
> it. I don't think you have
It looks like a connect and disconnect. If there was authentication
you'd see it. I don't think you have anything to worry about here. I'm
not saying there's not some jerk out there messing with your
smtps...just saying it may be harmless. That said, do you have a good
firewall in place that
Hi David, I don't know if this can help you but I use iptables with
xrecent module to limit 10 connections per minute on each port on my
server:
iptables -A INPUT -p tcp --dport 25 -m state --state NEW -m recent --set
--name SMTP --rsource
iptables -A INPUT -p tcp --dport 25 -m state --state NEW
Hi David,
The ip you are having issues with returns (NXDOMAIN) so try
using this or a variant on the search string to find what
you are looking for.
-- snip --
#!/bin/bash
mdate=`date +%c`
mip=$1
### must be root ###
if [ `whoami` != "root" ]; then
echo ""
echo "$0 must be run as
Hi Tony, thanks
But not so much looking for a solution to block ips.
I’m needing to identify which ips to block
On Sat, 18 Apr 2020 at 8:19 pm, Tony White wrote:
> Or this...
>
> -- snip --
> #!/bin/bash
> logf="/var/log/blockip.log"
> mdate=`date +%c`
> mip=$1
> ### must be root ###
> if [
Or this...
-- snip --
#!/bin/bash
logf="/var/log/blockip.log"
mdate=`date +%c`
mip=$1
### must be root ###
if [ `whoami` != "root" ]; then
echo ""
echo "$0 must be run as root"
echo ""
exit 1
fi;
if [ $mip == "--help" ]; then
echo
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
Hi David,
Sorry try this instead...
-- snip --
#!/bin/sh
logf="/var/log/blacklist_ip.log"
mdate=`date +%c`
### must be root ###
if [ `whoami` != "root" ]; then
echo ""
echo "$0 must be ran as root"
echo ""
exit 1
fi
export
Hi David,
Try using this little script...
-- snip --
#!/bin/bash
logf="/var/log/blockip.log"
mdate=`date +%c`
mip=$1
### must be root ###
if [ `whoami` != "root" ]; then
echo ""
echo "$0 must be run as root"
echo ""
exit 1
fi;
if [ $mip == "--help" ]; then
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 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
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 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
42 matches
Mail list logo
