Large Scale Internet Attacks - Technical article.
Gentlefolk (are there any women on this list????) I thought this sufficiently interesting to post to the NOG, so that it may help anyone who is considering how to avoid these attacks in the future. I have removed all the sales guff (I hope). I hope this is of use. ==================================================================== At one account they were all Cisco. They were blown up by a massive amount of spoofed SYN flood attacks. The PIX did stop the SYN floods it did see, however most of traffic never reached the PIX because the egress router had a of overflow of traffic. I have personal experience with the account. We had recommended they put anti-spoofing filters and CAR filtering for ICMP on the egress routers. They told us they would not put any filters on the routers because they did not want to lose any performance. The attacks were designed to take advantage of a specific flaw in the network design of the target. This discovered by using an automated tool that tries literality hundreds of different exploits till it finds a successful avenue of attack. Since the hackers tools try over hundred types of exploits, it is possible that if the customer had implemented the egress filtering that we had recommend than the hackers would have been able to crash them with some other attack. However, a continual theme is that there are a large number of sites on the Internet, and the well defended sites tend to get ignored by this type of attack. Since these criminals don't tend to be very clever, in fact they seem downright lazy, they only go after sites that can be assaulted with off the shelf tools. In the case of one web portal, the attack was a BSD UNIX specific attack that rides on port 80 like any other HTTP traffic. It went thought the Cisco router and a Checkpoint firewall, just like it is supposed to do. Had the network administrator patched their Web servers with against this known type of attack, then the exploit would have done not worked at all. In one of the e commerce sites, they were blown up by a Smurf attack. However, the attack was against the upstream ISP, not the e commerce site itself. Had the target insisted the ISP put the "no ip directed broadcast" command on the outgoing line from the ISP to the target, then the Smurf would have not worked. ======================================================================== -- \_ Roger De Salis Cisco Systems NZ Ltd
On Mon, 14 Feb 2000, Roger De Salis wrote:
Had the target insisted the ISP put the "no ip directed broadcast" command on the outgoing line from the ISP to the target, then the Smurf would have not worked.
On the same topic - the Lucent/Ascend equivalent of this is IP-GLOBAL/icmp-reply-directed-bcast, IP-INT/directed-broadcast-allowed, or (on the LCD interface), Ethernet/Mod Config/Reply DirectedBcast and Forward Directed Bcast. In addition, I strongly recommend usage of the Ascend-Source-IP-Check RADIUS attribute in your default RADIUS reply profile. This attribute tells the NAS to enforce the netmask on the *source* address of packets coming in a switched connection. This lets you dispose of all spoofed packets from dialups without the use of a explicit, hard to maintain (and CPU expensive) filter (needs TAOS 7.x and later). -- Josh Bailey (joshbailey(a)lucent.com) "Josh is... at large" -- F.W. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Keep an eye out for a lot of traffic from / to ip protocol 255. We were attacked a couple of nights ago with a DDOS from 6 sites around the world. Our firewall detected unusual traffic and paged us. On our international router I found excessive traffic to one of our servers, using ip protocol 255. (not used by that server). An access list fixed the problem. Please go to www.fbi.gov. They have tools you can use to scan for DDOS software on your servers / Network. /Martin Forest -- Martin Forest Senior Internet Engineer ICONZ - an Asia Online Company Ph: +64 9 358 1186 Fax: +64 9 300 3122 http://www.iconz.co.nz http://www.asiaonlineltd.com Caution - The information contained in this e-mail (and any accompanying documents) may be legally privileged and confidential. The information is intended only for the recipient named in this message. If you are not the named recipient, you must not peruse, use, disseminate or copy any information received in or with this e-mail. If you have received this e-mail in error, please telephone us on 0800 THE NET (0800 843 638) or reply to this e-mail. Josh Bailey wrote:
On Mon, 14 Feb 2000, Roger De Salis wrote:
Had the target insisted the ISP put the "no ip directed broadcast" command on the outgoing line from the ISP to the target, then the Smurf would have not worked.
On the same topic - the Lucent/Ascend equivalent of this is IP-GLOBAL/icmp-reply-directed-bcast, IP-INT/directed-broadcast-allowed, or (on the LCD interface), Ethernet/Mod Config/Reply DirectedBcast and Forward Directed Bcast.
In addition, I strongly recommend usage of the Ascend-Source-IP-Check RADIUS attribute in your default RADIUS reply profile. This attribute tells the NAS to enforce the netmask on the *source* address of packets coming in a switched connection. This lets you dispose of all spoofed packets from dialups without the use of a explicit, hard to maintain (and CPU expensive) filter (needs TAOS 7.x and later).
-- Josh Bailey (joshbailey(a)lucent.com) "Josh is... at large" -- F.W.
--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Sun, Feb 13, 2000 at 03:24:07PM -0800, Josh Bailey wrote:
In addition, I strongly recommend usage of the Ascend-Source-IP-Check RADIUS attribute in your default RADIUS reply profile. This attribute tells the NAS to enforce the netmask on the *source* address of packets coming in a switched connection. This lets you dispose of all spoofed packets from dialups without the use of a explicit, hard to maintain (and CPU expensive) filter (needs TAOS 7.x and later).
I'd also add that ISP's should turn `Remote Mgmt' to `No' on Ascend units. I've lost count of the ammount of times I've been troubleshooting ISP networks and found this still set to on. It means that any customer able to dial in with an MPP call can get direct access to the RAS via an inband management protocol. Bad Bad Bad. As for the exploits in the original message - They all seemed pretty common sense to me. Nothing that sitting on bugtraq and applying recent patches would not fix. The interesting point is, and the one that I would like comment on, is this sort of network security (anti-smurf and the like) the responsibility of the ISP or the client. How much of the burden of stopping network borne security attacks should be borne by the provider and how much by the end user of the server? ie, should ISP's filter traffic to clients based on sensible rules of should they just provide IP dialtone and leave the filtering up to the client. Comment? Dean -- ----------------------------------------------------------------------- Dean Pemberton - dp(a)lucent.com Linux User# 157870 Guy who does stuff at Lucent Technologies - Bell Labs Innovations Lvl 38, 55 Collins St, Melbourne 3000, Australia ----------------------------------------------------------------------- --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, 15 Feb 2000, Dean Pemberton wrote:
ie, should ISP's filter traffic to clients based on sensible rules of should they just provide IP dialtone and leave the filtering up to the client.
IMHO; I am wary of vigilante-style enforcement of this sort of thing developing - people putting up access lists, etc preemptively, against the "other guy" because in someone's opinion they didn't set up their network "correctly." Joe Customer suddenly can't ping Jim Customer because in ISP A's opinion ISP B hasn't got it together. Which is worse, the DDOS or the "cure?" Don't have a specific answer m'self. Just a bit wary of some of the possible "answers." -- Josh Bailey (joshbailey(a)lucent.com) "Josh is... at large" -- F.W. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Yeah thats pretty much my opinion too. I'm interested to see if there's anyone on the other side of the fence. Dean On Mon, Feb 14, 2000 at 04:11:25PM -0800, Josh Bailey wrote:
IMHO;
I am wary of vigilante-style enforcement of this sort of thing developing - people putting up access lists, etc preemptively, against the "other guy" because in someone's opinion they didn't set up their network "correctly."
Joe Customer suddenly can't ping Jim Customer because in ISP A's opinion ISP B hasn't got it together. Which is worse, the DDOS or the "cure?"
Don't have a specific answer m'self. Just a bit wary of some of the possible "answers."
-- Josh Bailey (joshbailey(a)lucent.com) "Josh is... at large" -- F.W.
-- ----------------------------------------------------------------------- Dean Pemberton - dp(a)lucent.com Linux User# 157870 Guy who does stuff at Lucent Technologies - Bell Labs Innovations Lvl 38, 55 Collins St, Melbourne 3000, Australia ----------------------------------------------------------------------- --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Mon, 14 Feb 2000, Josh Bailey wrote:
On Tue, 15 Feb 2000, Dean Pemberton wrote:
ie, should ISP's filter traffic to clients based on sensible rules of should they just provide IP dialtone and leave the filtering up to the client.
I am wary of vigilante-style enforcement of this sort of thing developing - people putting up access lists, etc preemptively, against the "other guy" because in someone's opinion they didn't set up their network "correctly."
I'm not sure that's what's being discussed. Most of the real problem of
(D)DoS attacks is, IMO, forging to make it (more) difficult to identify
which machines are the source of the attack.
If a customer has been assigned addresses X thru Z, it has _no_ need to be
able to generate traffic from addresses A thru W, but that is usually the
case with most ISPs. "Sensible rules" means to me dropped traffic with
sources outside their assigned range.
This should not impact their ability to use the connection.
All IMO, I'm not claiming a complete correct answer either..
--
David Zanetti
On Wed, 16 Feb 2000, David Zanetti wrote:
I'm not sure that's what's being discussed.
I am expressing a concern with what is being discussed;
This should not impact their ability to use the connection.
..that some ISPs may feel one way to address the problem is to block traffic, preemptively, from other ISPs they feel aren't taking "appropriate measures" to prevent spoofing/other types of network attacks. I was one of TAOS' antispoofing feature advocates back when added such features in 7.0 (in the form of a netmask applied to a source address so as to specifically *NOT* require a CPU expensive filter) - the problem isn't completely technical nor administrative. -- Josh Bailey (joshbailey(a)lucent.com) "Josh is... at large" -- F.W. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
If a customer has been assigned addresses X thru Z, it has _no_ need to be able to generate traffic from addresses A thru W, but that is usually the case with most ISPs. "Sensible rules" means to me dropped traffic with sources outside their assigned range.
This should not impact their ability to use the connection.
In the RAS devices I have experience with -- generally it does affect performance putting an ACL on every connected user... -cw -- Chris Wedgwood chris.wedgwood(a)clear.co.nz --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Thu, Feb 17, 2000 at 11:05:44AM +1300, Chris Wedgwood wrote:
If a customer has been assigned addresses X thru Z, it has _no_ need to be able to generate traffic from addresses A thru W, but that is usually the case with most ISPs. "Sensible rules" means to me dropped traffic with sources outside their assigned range.
This should not impact their ability to use the connection.
In the RAS devices I have experience with -- generally it does affect performance putting an ACL on every connected user...
... but that's not necessarily the case on many platforms, consult your vendor for further details :) --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Wed, 16 Feb 2000, David Zanetti wrote:
If a customer has been assigned addresses X thru Z, it has _no_ need to be able to generate traffic from addresses A thru W, but that is usually the case with most ISPs. "Sensible rules" means to me dropped traffic with sources outside their assigned range.
The problem with rules is they are very easy to stuff up. Currently very few companies (or ISPs for that matter) are connecting to multiple ISPs but I would expect the number to grow over time. Every time one of these connects you have to ensure (or sometimes manually update) your filters are not causing them problems. For example if (say) a company has a DDS to clear but runs their procy server via an ihug satellite system then Clear will see ihug ip's originating inside their network. I know of at least one company that does this BTW. connect.com over is Aus have very heavy filters on traffic in various directions which can cause all sorts of problems, they also seem to be having other problems over the last week. -- Simon Lyall. | Newsmaster | Work: simon.lyall(a)ihug.co.nz System/Network Admin. | T&C Enforcement | Home: simon(a)darkmere.gen.nz Ihug Limited, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
participants (8)
-
Chris Wedgwood -
David Zanetti -
Dean Pemberton -
Joe Abley -
Josh Bailey -
Martin Forest -
Roger De Salis -
Simon Lyall