 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
11 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Saturation DDoS| From | Sent On | Attachments |
|---|---|---|
| Zenon Panoussis | Oct 22, 2007 5:50 am | |
| Enda Cronnolly | Oct 22, 2007 6:25 am | |
| Leigh S. Jones | Oct 22, 2007 7:29 am | |
| Gordon Messmer | Oct 22, 2007 7:48 am | |
| Zenon Panoussis | Oct 22, 2007 8:25 am | |
| Gordon Messmer | Oct 22, 2007 9:50 am | |
| Zenon Panoussis | Oct 22, 2007 10:34 am | |
| Gordon Messmer | Oct 22, 2007 12:48 pm | |
| Sam Varshavchik | Oct 22, 2007 3:36 pm | |
| Zenon Panoussis | Oct 23, 2007 12:27 am | |
| Daniel | Oct 23, 2007 11:29 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [courier-users] Saturation DDoS | Actions... |
|---|---|---|
| From: | Gordon Messmer (yiny...@eburg.com) | |
| Date: | Oct 22, 2007 9:50:16 am | |
| List: | net.sourceforge.lists.courier-users | |
Zenon Panoussis wrote:
Enda Cronnolly wrote:
I would hazard a guess that you have either ran out of pre-configured available threads for esmtpd to listen on (in which case increasing the limits will help) or your system has run out of available resources to provide esmtpd with new threads. Its the only logical reason why esmtpd can't answer requests.
You might be right, but there's something with this reasoning that I don't grasp. Whatever resources courier has, small or big, it should be using and re-using. So let's say it can only start five threads; it would then do so, accept five connections, deal with them, close them down and then accept the next five.
Yes, it will do that. However, when mail servers connect to courier's smtpd and send RCPT commands with invalid users (or any other error), smtpd starts tarpitting them -- after each failed command, it waits for an increasingly long period of time before it replies and reads more commands. This feature of courier prevents dictionary attacks against your system. In your case, the mail servers sending you backscatter continue to send commands for a long period, which means that it takes a long time for courier to free up slots for new connections. What you're seeing is not a bug in courier.
This is not the case though. What happens is that courier accepts n connections, deals with whatever is coming in on them (accepts it or bounces it), and then stops accepting new connections indefinitely, until restarted. This would suggest that the processes started are not properly terminated, because new ones should be started when the old ones finish, but are not. So either something is wrong with courier, or my understanding of how new processes are respawned is flawed.
You're simply wrong about what's happening. You can see open connections with either 'netstat' or 'ps'. Use 'tcpdump -A' or 'ethereal' to watch traffic on those connections.
Gordon Messmer wrote:
You don't need more authdaemons, just more esmtpd processes. Increase MAXDAEMONS, but not MAXPERC or MAXPERIP.
I've already been there. They are now 40, 5 and 5 respectively. The 40 seem to roughly correspond at the number of accepted connections after each restart. But with the behaviour I see, increasing the daemons only leads to a higher number of initial connections before courier stops responding.
40 is the default -- pretty low. I use 120 for low-traffic servers.