On Thu, 2011-04-07 at 17:22 +1200, Nathan Ward wrote:

On 7/04/2011, at 5:19 PM, Steve Holdoway wrote:

...

To answer a few privately asked questions...

sendmail ( which has greylisting, spamhaus RBL, greet pause running ) sees the traffic as coming from a 192.168.x.x address, which negates all the access controls in place.

However, wireshark sees the SMTP traffic as coming from the external IP addresses...

(I'm saying what I see as I don't want to use the wrong terminology... I'm only a sysadmin!)

We're talking to telstra, and it looks like the simplest solution will be to move addresses. Which will work - until next time! Would be nice to be better prepared though.

SMTP uses TCP which means address spoofing like you describe can't work. Perhaps the mail is coming from an internal host, to the mail server in your office, and then is being sent from your mail server out to spam recipients - ie. you are sending the spam because of a virus or something. This would explain the connections outside your office.

-- Nathan Ward 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? Cheers, Steve -- Steve Holdoway BSc(Hons) MNZCS http://www.greengecko.co.nz MSN: steve(a)greengecko.co.nz Skype: sholdowa

On 7/04/2011, at 7:09 PM, Jay Daley wrote:

Finally, below is a general DDoS mitigation guide adapted from one on how to survive LOIC:

I was asked off list if this guide could be reused in other places, so it probably wasn't clear this mitigation guide was written by Roland Dobbins not me and only slightly amended by me to remove a couple of steps that are HTTP specific. I've added the missing bits back in below for those that are interested. Jay

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.

3. Ensure that UDP/80 is blocked towards servers - nothing standard runs on this, and it's a major component of basic LOIC. 4. Front Web server farms with reverse-proxy cache farms like Squid, cluster them using WCCP v2. This will reduce load on Web servers and provide a policy insertion point to block harmful layer-7 HTTP attack query traffic. This will also automagically block the basic LOIC HTTP attack, as it isn't issuing well-formed HTTP requests, just garbage on TCP/80. The proxy-cache farms should be northbound of any load-balancers or other stateful devices.

5. 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.

6. 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.

7. 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

_______________________________________________ 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