Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(ASCEND) Max4030 Crash: DoS attack against dialup user
Greetings all,
Last evening, one of our dialup users was the target of a Denial of Service
attack (IRC Related) which involved Fragmented IP packets.
This attack managed to lock up one of our ascend max 4030's (6.1.3 feik.m40)
It managed to still send logging info via syslog, but users could not dial into
it, and it would not respond to ping, telnet, snmp. I power-cycled the unit
and it came back up fine.
after reboot of the unit, the check of the fatal-history buffer in the debug
utility revealed the following:
WARNING: Index: 175 Load: feik.m40 Revision: 6.1.3
Date: 06/30/1998. Time: 00:19:13
Location: b004fe08 b00c0168 b00c6d70 b00bf04c b0168554 b0094e30
WARNING: Index: 175 Load: feik.m40 Revision: 6.1.3
Date: 06/30/1998. Time: 00:19:17
Location: b004fe08 b00c6ce8 b00bf04c b0168554 b0094e30 b00939e0
WARNING: Index: 175 Load: feik.m40 Revision: 6.1.3
Date: 06/30/1998. Time: 00:19:22
Location: b004fe08 b00c0168 b00c6d70 b00bf04c b0168554 b0094e30
WARNING: Index: 175 Load: feik.m40 Revision: 6.1.3
Date: 06/30/1998. Time: 00:19:31
Location: b004fe08 b00c6ce8 b00bf04c b0168554 b0094e30 b00939e0
WARNING: Index: 175 Load: feik.m40 Revision: 6.1.3
Date: 06/30/1998. Time: 00:19:35
Location: b004fe08 b00c0168 b00c6d70 b00bf04c b0168554 b0094e30
SYSTEM IS UP: Index: 100 Load: feik.m40 Revision: 6.1.3
Date: 06/30/1998. Time: 00:54:03
tcpdump traces from a machine on our lan which is configured to listen in
"promiscuous" mode revealed the following interesting output.
00:19:14.821715 efnet.demon.co.uk.6667 > max-pool-p12.innotts.co.uk.1905: P 92:150(58) ack 15 win 64240 (DF)
00:19:15.183561 max-pool-p12.innotts.co.uk.1905 > efnet.demon.co.uk.6667: . ack 150 win 8421 (DF) [tos 0x7]
00:19:16.585216 efnet.demon.co.uk.6667 > max-pool-p12.innotts.co.uk.1905: P 150:197(47) ack 15 win 64240 (DF)
00:19:16.923657 max-pool-p12.innotts.co.uk.1905 > efnet.demon.co.uk.6667: . ack 197 win 8374 (DF) [tos 0x7]
00:19:17.038114 51.68.124.172.21087 > max-pool-p12.innotts.co.uk.37835: udp 28 (frag 242:36@0+)
00:19:17.067222 51.68.124.172 > max-pool-p12.innotts.co.uk: (frag 242:4@24)
00:19:17.110365 97.188.96.28.21087 > max-pool-p12.innotts.co.uk.37835: udp 40 (frag 242:28@0+)
00:19:17.110428 97.188.96.28 > max-pool-p12.innotts.co.uk: (frag 242:4@24)
00:19:17.119406 51.68.124.172.21087 > max-pool-p12.innotts.co.uk.37835: udp 28 (frag 242:36@0+)
00:19:17.119470 51.68.124.172 > max-pool-p12.innotts.co.uk: (frag 242:4@24)
00:19:17.120003 97.188.96.28.21087 > max-pool-p12.innotts.co.uk.37835: udp 40 (frag 242:28@0+)
00:19:17.120332 97.188.96.28 > max-pool-p12.innotts.co.uk: (frag 242:4@24)
00:19:17.121420 97.188.96.28.21087 > max-pool-p12.innotts.co.uk.37835: udp 40 (frag 242:28@0+)
00:19:17.121746 97.188.96.28 > max-pool-p12.innotts.co.uk: (frag 242:4@24)
00:19:17.227837 97.188.96.28.21087 > max-pool-p12.innotts.co.uk.37835: udp 40 (frag 242:28@0+)
00:19:17.227902 97.188.96.28 > max-pool-p12.innotts.co.uk: (frag 242:4@24)
00:19:17.248145 97.188.96.28.21087 > max-pool-p12.innotts.co.uk.37835: udp 40 (frag 242:28@0+)
00:19:17.249780 97.188.96.28 > max-pool-p12.innotts.co.uk: (frag 242:4@24)
00:19:17.275692 162.122.55.246.domain > max-pool-p12.innotts.co.uk.domain: 0 [0q] Type0(Class 0)? . (28) (frag 1109:36@0+)
00:19:18.063894 148.89.206.54.53848 > max-pool-p12.innotts.co.uk.32753: . 0:40(40) ack 0 win 512 urg 0 (frag 242:40@0+)
00:19:18.063962 148.89.206.54 > max-pool-p12.innotts.co.uk: (frag 242:4@24)
00:19:18.132297 88.39.224.28.53848 > max-pool-p12.innotts.co.uk.32753: udp 10 (frag 242:18@0+)
00:19:18.432101 148.89.206.54.53848 > max-pool-p12.innotts.co.uk.32753: . 0:40(40) ack 1 win 512 urg 0 (frag 242:40@0+)
00:19:18.433615 148.89.206.54 > max-pool-p12.innotts.co.uk: (frag 242:4@24)
00:19:18.503655 88.39.224.28.53848 > max-pool-p12.innotts.co.uk.32753: udp 10 (frag 242:18@0+)
00:19:18.503743 148.89.206.54.53848 > max-pool-p12.innotts.co.uk.32753: . 0:40(40) ack 1 win 512 urg 0 (frag 242:40@0+)
00:19:18.504056 148.89.206.54 > max-pool-p12.innotts.co.uk: (frag 242:4@24)
00:19:18.507423 88.39.224.28 > max-pool-p12.innotts.co.uk: (frag 242:116@48)
00:19:18.627889 [|udp] (frag 242:224@0+)
This was no-doubt an IRC-related attack (kiddies and their toys on irc.. *sigh*)
Evidence that the MAX3030 was still sending syslog information was
confirmed from the following, when it appeared to be dropping
all of its connections. New incoming connections were either ignored
or radius timed out. Ping and telnet to the unet were unsuccessful at this
time forcing me to power-cycle the unit.
Jul 30 00:36:43 eth0-max1.innotts.co.uk ASCEND: slot 3 port 11, Call Terminated [MBID 245]
Jul 30 00:36:43 eth0-max1.innotts.co.uk ASCEND: slot 0 port 0, LAN session down, vega [MBID 245]
Jul 30 00:36:57 eth0-max1.innotts.co.uk ASCEND: slot 3 port 13, Call Terminated [MBID 290]
Jul 30 00:36:57 eth0-max1.innotts.co.uk ASCEND: slot 0 port 0, LAN session down, ghost [MBID 290]
Jul 30 00:37:02 eth0-max1.innotts.co.uk ASCEND: slot 4 port 11, Call Terminated [MBID 274]
Jul 30 00:37:02 eth0-max1.innotts.co.uk ASCEND: slot 0 port 0, LAN session down, smurf [MBID 274]
Jul 30 00:37:59 eth0-max1.innotts.co.uk ASCEND: slot 3 port 8, Call Terminated [MBID 261]
Jul 30 00:37:59 eth0-max1.innotts.co.uk ASCEND: slot 0 port 0, LAN session down, petew [MBID 261]
Jul 30 00:38:13 eth0-max1.innotts.co.uk ASCEND: slot 4 port 14, Call Terminated [MBID 281]
Jul 30 00:38:13 eth0-max1.innotts.co.uk ASCEND: slot 0 port 0, LAN session down, philstuart [MBID 281]
Jul 30 00:38:15 eth0-max1.innotts.co.uk ASCEND: slot 3 port 2, Call Terminated [MBID 263]
Jul 30 00:38:15 eth0-max1.innotts.co.uk ASCEND: slot 0 port 0, LAN session down, hamster [MBID 263]
Jul 30 00:38:18 eth0-max1.innotts.co.uk ASCEND: slot 4 port 2, Call Terminated [MBID 315]
Jul 30 00:38:22 eth0-max1.innotts.co.uk ASCEND: slot 4 port 6, Call Terminated [MBID 297]
Jul 30 00:38:22 eth0-max1.innotts.co.uk ASCEND: slot 0 port 0, LAN session down, spelectronics [MBID 297]
Jul 30 00:39:00 eth0-max1.innotts.co.uk Radius client timeout (code=1) for user speake
Does Ascend (or any ascend users) have any ideas on this issue, and/or
suggestions for preventative measure?
I have a very strict set of filter rules on our main core router, however,
since it is a rather low-end cisco running IOS 11.1(16). I can't run anything
newer on it to make use of the newer IOS features to re-assemble fragmented IP
before forwarding due to ram and resource limitations on these routers.
Unfortunately, as a result, fragmented IP packets can walk straight through
the filter sets.
Nevertheless... a production terminal server (IMO) should NOT hang like this
as a result of forwarding such fragmented packets to a connected dialup session.
Other than this one problem, I have had NO issues with version 6.1.3 of the
MAX firmware, and all-in-all 6.1.3 seems stable for our implimentation.
I have see no IP Pool leaks (as have been mentioned on the ascend-users list),
and 6.1.3 seems to have dealt with some incompatibility issues with USR modems.
Hence downgrading to an earlier release would NOT be my first choice...
--
Leland E. Vandervort | Network Engineer
leland@discpro.org / leland@innotts.com | internet in nottingham, ltd
http://www.discpro.org/~leland/ | http://www.innotts.co.uk/
Undernet NA Routing-Com Secretary | +44 (0)115 956-2288
------------------------------------------------------------------------
UK KDE Web Site Mirror Maintainer: http://kde.innotts.com/
IRC Operator: (Undernet) Baltimore, London, Ann-Arbor
IRC Operator/Admin/Services Coder: (KidsWorld) Notts.UK.EU.KidsWorld.Org
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>
Follow-Ups: