Ted Cooper wrote:
> On 15/06/11 11:42, W B Hacker wrote:
>>
>> 'Obliterated'?
>>
>> You must have one Helluva good backbone for things to degenerate to that
>> sad sate of affairs.
>>
>> ;-)
>
> You'd be surprised how many logs you get from millions of connections
> when you're only set for maybe a thousand a day, of which 50 are real
> emails.
Not 'surprised' at all. I've had something on the order of 869 million
connections logged in 26 hours on FreeBSD.
That's when I learned not to blackhole. Makes 'bots think you are an
open-relay and pile-on!
Also when I learned that I didn't really have to FW the CIDR/8 of the
upstream networks of a University in PRC and another University in
Taiwan trying to beat the daylights out of each other via ... Korea and
Hong Kong.
Nowadays, a limit of 2 or 3 simultaneous connections per source IP, an
rDNS check, limit to one message for one recipient at a time ..
End of problem. Doesn't even need ratelimiting.
>
> We're not talking about a massive system here, just a single domain at a
> small business that was somehow lucky enough to be picked to the source
> address for **** knows how many emails. How I managed to get TWO
> different client domains picked within a month of each other, I do not
> know*. Both had strict SPF records too.
I don't even look at DKIM or SPF. KISS. Pass the rDNS check and be taken
as honest until proven otherwise. BE proven otherwise, and become LBL'ed
with no second chance, even with perfect DNS, SPF, DKIM creds.
>
> Cutting a long story short, the /var drive ran out of room and services
> started dying off because of it.
As did ours. 110% full. Syslog bailed. Mail was slow but not terribly
so, but when the /periodic/daily cron reports failed to appear, ssh'ed
in for a recce, found and fixed the cause, analyzed the source of the
problem later.
That also gave us religion as to auto-rotated logs.
> The machine was running (no smoke
> pouring out of it), but wasn't really doing anything but printing
> messages to the console about how upset it was.
>
ACK. Saving grace in my case was a limited number of PostgreSQL
connections. Once consumed, at around 135 active connections, Exim sent
'temporary local problem..' defers, after which logging was the primary
consumer of resources. In those days I did not auto-rotate logs, relied
on huge multiple RAID1. AND used 'too long' progressive delay =
Bad move. Better to keep delay = short, apply seldom, simply toss the
rascals 'soonest' to make room for legit arrivals.
> I don't really have any idea how many connections it was, but it was
> enough to fill the drive overnight with a combination of log files.
>
Probably take several weeks if not months for that to happen now...
256MB used since 28 April 2011 on 39.4GB mount of a 2TB HDD with over
1TB held in flexible reserve.
Filesystem Size Used Avail Capacity Mounted on
/dev/sd0e 39.4G 256M 37.1G 1% /var
I tend to pay attention only if/as/when a mount hits 25% utilization OR
shows a spike of a full percent in one day.
> I also don't do these any more.
>
>
> * Ok, I _do_ have an idea but no way to check it. My reject messages
> used to be slightly confrontational when there was zero chance of it
> being a legitimate connection - like HELO with my hostname or IP
> address. Perhaps remove the slightly.
> That was the only thing those
> servers/domains had in common really, but they weren't the only servers
> returning those messages either.
>
I do out-of-session DSN's ONLY to my own authenticated users.
There are also 'strict enough' rules to insure incoming DSN's are not
bogus. Even so, since they are responded to in-session or not at all,
there is very little chance of participating in a backscatter chain
reaction.
Bill
--
韓家標
