Topic: Is this a DDos attack?

[Fumetto]

For about 1 month I think that one of the (few) servers that I have up and running is under a probable DDos attack, or at least that's what I understand.
Through the smeadmin contrib I notice many connections that remain in "CLOSE_WAIT" status from different IP addresses.
I tried to install fail2ban and geoip and I'm gradually blocking the nations that "pain in the ass" but I haven't managed to solve it yet, probably due to my incompetence.
The problem occurs on clients (outlook) with an exasperating slowness in sending messages; sometimes after a while it works, sometimes not. I think it's due to the fact that there are 40 maximum simultaneous connections for qpsmtpd and, remaining in "CLOSE_WAIT" status for the 40 slots, if one of the slots doesn't "free up" first I obviously can't send.
Fail2ban works (I have jailed IPs), geoip works (from qpsmtpd logs I see that "211.57. 111.99 Unknown check_badcountries 901 Country is on Blocked List msg denied before queued"), but I still have a ton of CLOSE_WAIT.

I could move the server to another IP of another operator to try to solve it that way but it doesn't seem like a good solution, and increasing the value of 40 simultaneous slots doesn't seem like a valid solution either, does anyone have an idea of ​​how I could proceed? I don't know where to turn anymore and I can't think of any other ideas.

TIA

[mmccarn]

This is a wild guess, but you may want to check the PMTU between your servers and the remote systems.

Read more here:
qpsmtpd "Connection Timed Out" errors

(I discovered PMTU years ago researching "CLOSE_WAIT" connections as you describe)

[Jean-Philippe Pialasse]

if you are under DOS or DDOS, your CPU load will increase and qpsmtpd will delay incoming mails (both from your client and from remote servers).
by default it will occur after 7% load.  you can increase this in db, but the cure is indeed fail2ban, geoip and sometime manual blocking of a ip range. 
I had recently a ddos on a vm from ip related to alibaba cloud localized in the US.

you can use the riffraff template in wiki for that. but before check whois for the ip causing problem  and think teice what other services could be there (eg google crawler..)

[Fumetto]

Many thanks all.

I proceeded to block the "pain in the ass" nations with GeoIP by analyzing the logs and it seems that I managed to eliminate (or rather mitigate) the problem encountered, but "a new world" opened up to me with the links indicated above.

I seem to have understood that "it would be appropriate" to "pair" the MTU value of the server with that of the gateway used. So, with this values from command line

Code: [Select]

[root@server ~]# config show ExternalInterface
ExternalInterface=interface
    Broadcast=10.10.10.255
    Configuration=static
    Driver=tg3
    Gateway=10.10.10.1
    IPAddress=10.10.10.3
    Name=eno2
    Netmask=255.255.255.0
    Network=10.10.10.0

[root@server ~]# tracepath google.com
 1?: [LOCALHOST]                                         pmtu 1500
 1:  10.10.10.1                                            0.979ms
 1:  10.10.10.1                                            0.805ms
 2:  10.10.10.1                                            1.090ms pmtu 1492
 2:  no reply
^C
[root@server ~]#it would be ideal to align the MTUs with

Code: [Select]

config setprop ExternalInterface MTU 1492
signal-event post-upgrade; signal-event rebootIs this correct?

[Jean-Philippe Pialasse]

MTU is a whole subject on its own.

globaly a MTU* should not be bigger than tue upstream link.
PMTU is not the MTU. You should have a read on how Maximum Transmission Unit and  Path Maximum Transmission Unit work and are used before you try to play with them.

If downstream MTU is greater than upstream MTU then packet get fragmented and this lead to loss of performance. IT could get to the point where a VPN is unusable particularly as we use UDP which does not acknowledge for the packet.


multiple protocoles will use header  bits, eg PPPOE will need a 8 bit leaving 1492. You can try to increase to 1508 to keep your 1500, but this assumes that your ISP is not limiting to 1500 somewhere else upstream.

your PMTU is probably the result of such a substraction. If you reduce your MTU to 1492, tyhen you PMTU will be 1484, and so on

[Fumetto]

Thanks, I actually think I should study this thing thoroughly... it's a very large topic from what little I've seen. Studying... studying... I never end!!!
I'll try to find some free nights for this (studying during the day is impossible with a 3-year-old niece at home). In fact I had already clashed with MSS, MTU and so on when I had problems with a VPN, but "I solved it" and didn't delve any further... thanks again for the input!!!

[Jean-Philippe Pialasse]

usually default is good, unless you try to chain multiple vpn inside one another. then you most probably will reduce the latest mtu to make sur it fits inside the previous.

[Fumetto]

Do I have any chance of being able to use Fail2Ban and/or GeoIP with sqpsmtpd?
They went from 25 to 465...

Code: [Select]

[root@server ~]# config show sqpsmtpd
sqpsmtpd=service
    Authentication=enabled
    Instances=10
    InstancesPerIP=5
    TCPPort=465
    access=public
    status=enabled
[root@server ~]#

[ReetP]

Xt_Geoip

[Fumetto]

Xt_Geoip

I try, ty

But "the spam" is with different tecnique.. I try study...
I've some (rarely) GeoIP lines on spqmtpsd log, so "it's work" (as it was documented somewhere).
The attacked port is 465 (SMTPS) from which the sqpsmtpd logs. "many" connections are made even from single IPs, which remain "halfway" (SYNC_RCV, LAST_ACK...).
What is driving me crazy (a the moment) is "Too many connections: 10 >= 10. Waiting one second."
I try

Code: [Select]

config setprop spqsmtpd Instances 2
signal-event email-updateBut connection is 10 too, after reconfigure and reboot too...

I need to let off steam by destroying grass with the brush cutter for an hour... but first a coffee!!!

[Fumetto]

Grass cut, coffee taken, rest taken.

Geoip and Xt_Geoip seem to "coexist" well but I don't get the functioning of "!==" in Xt-Geoip. But it was probably a wrong configuration on my part. I will check better

However, an analysis of the logs led me to the conclusion that it is a synflood attack; the only valid solution should be to check the various classes (x.x.x.x/20) that "flood" and block them "by hand"... I'll see how to do it tonight (I hope).

[Jean-Philippe Pialasse]

they are both watched by fail2ban.

what vould be hard is even with our current limits they could get up to 100 submission per connexion. fail2ban from memory limits only by number of connexion.

[Fumetto]

Workaround in production: ~ config sqpsmtpd access private

I can only send mail from the lan. But I have a crazy idea...

There are two lines from two different operators; both lines arrive at a firewall, which "manages" a LAN. The server is in server/gateway mode; WAN on Line1, LAN on LAN.
If I "forward" the ports from line2 on the lan, does it work? Does sqpsmtpd see the connections arriving on the internal interface (even if with "outside" IPs) and consider them "private" or "public"?

In this way, when and if I set up Line2 with a type A DNS record, I will be able to understand if it is a targeted attack on the domain, the line and/or "randomly".

[bunkobugsy]

Workaround in production: ~ config sqpsmtpd access private
I can only send mail from the lan.

So your clients need to be on lan side (or vpn in) to reach 465 submission port.
But with access public you could set xt_geoip port 465 to !TLD (your home country) where most/all of your clients are.

[Fumetto]

So your clients need to be on lan side (or vpn in) to reach 465 submission port.
But with access public you could set xt_geoip port 465 to !TLD (your home country) where most/all of your clients are.

...I don't get the functioning of "!==" in Xt-Geoip. But it was probably a wrong configuration on my part. I will check better...

I had time to check and, in fact, the proposed solution is a "better than mine" workaround... and above all it seems to work!!!

Let's see how it goes this weekend... attacks of this type all started from !TLD in the logs... and I read so many logs so many lines... too many...