On 7/04/2011, at 5:49 PM, Steve Holdoway wrote:
This was my first thought, and I've thought further. I know it's external as if I drop the port forwarding from the firewall, the problem disappears.
Said mail server is a KVM VPS, and the ip address seen by sendmail is that of the physical host, so I now think it's some artefact of the bridging used ( all physical and virtual servers are on the same subnet ). I think I need to read more on this. Any pointers, keywords I should look out for?
The addressing sounds like the VM is doing NAT and can be ignored. Some questions that might help work out what is going on: - What is the SMTP incoming traffic that you are seeing - Are they actually sending an email or connecting and then doing something odd? - Do you run the DNS as well? - What's the domain? If you do run DNS then you can drop the MX TTL to an hour or so (though it will increase traffic so you may not be able to do it) which will give you the ability to move things around later once the current MX TTL has timed out in caches. Finally, below is a general DDoS mitigation guide adapted from one on how to survive LOIC: 1. Get rid of stateful firewalls and 'IPS' in front of their servers and instead enforce network access policies in stateless ACLs on hardware-based routers/switches. Where PCI DSS requirements mandate an 'application-layer firewall', install mod_security on the Apache servers themselves, which will meet this requirement; similar on-server tools exist for IIS and other httpds. 2. Craft ACLs to only allow necessary protocols/ports - for example, a standard Web server only needs TCP/80 and possibly TCP/443. DNS servers need UDP/53 and TCP/53. 4. Implement NetFlow/jflow/cflowd/NetStream/sFlow/etc. telemetry export from routing/switching infrastructure to open-source or commercial flow telemetry collection/analysis systems for detection/classification/traceback. 5. Implement reaction/mitigation tools such as s/RTBH and IDMS. These should be placed northbound of Web, DNS, SMTP, and other servers, as well as Web cache farms; if stateful firewalls and 'IPS' devices can't be quickly removed due to non-technical considerations, these devices and everything behind them must be protection by reaction/mitigation tools. Load-balancers are also stateful DDoS chokepoints, and must be protected by these reaction/mitigation tools, as well. 6. Implement logical separation of DNS authoritative and recursive/caching lookup functions per https://files.me.com/roland.dobbins/m4g34u 8. Read these presos and implement the cited BCPs and other recommendations: (the last one in particular) https://files.me.com/roland.dobbins/y4ykq0 https://files.me.com/roland.dobbins/k54qkv https://files.me.com/roland.dobbins/9i8xwl https://files.me.com/roland.dobbins/prguob https://files.me.com/roland.dobbins/k4zw3x https://files.me.com/roland.dobbins/dweagy best Jay
Cheers,
Steve
-- Steve Holdoway BSc(Hons) MNZCS
http://www.greengecko.co.nz MSN: steve(a)greengecko.co.nz Skype: sholdowa _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840