Rune Central

The Official Rune Quake Message Board
It is currently Mon Dec 23, 2024 5:24 am

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2
Author Message
 Post subject:
PostPosted: Tue Feb 07, 2006 6:05 am 
Offline
User avatar

Joined: Mon Jun 13, 2005 11:27 pm
Posts: 214
While we're on the subject of bugs, I got one to report. When I'm using rocket launcher it keeps switching out to something else even when there are plenty of rockets left. And it's been getting worse. Now it's starting to do it with the grenade launcher.

I was thinking about making a demo but Spooker pointed out that the demo wouldn't show whether I was hitting the weapon switch key which I'm not.

This happens on Shmack. Can't remember if it happens on Singed or not but I remember it didnt' happen on Lokinet when I use to play there a little. So I'm thinking maybe it's a server bug.

BETTER HOPE THEY DON'T FIX THIS BUG TOYO 'CUZ IT'S SAVED YER ASS MORE THAN ONCE MY WHITE WEARING FRIEND! HAHAAHAHAAA!!!

_________________
Here is Toyo_MR2, lying broken at my feet.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Feb 07, 2006 4:46 pm 
Offline
QUIT: March 06, 2006

Joined: Sat Mar 08, 2003 11:55 am
Posts: 231
Fuzznut wrote:
Looks like this thread starts in the middle of an argument. Where does it start at? I like a good flame war every now and then.



I made a post in the thread about the rotating shield. I merely stated that I liked that the Rune Quake mod gave one the flexibility to toggle this function on and off. My post is still in that thread.

Mr Wi FI didn't like the post. I guess he does this differently in his mod...? He then proceeded to make personal attacks on me, my site and server, which had nothing to do with the discussion.

He's acts very brave sitting behind his keyboard cowardly making passive aggressive posts, which he often later pretends were jokes. I'm quite sure if we were discussing the matter face to face the discourse would be quite different.

I apologize that you had to read this exchange. I usually ignore him, but just had my fill of his bullshit and decided to reply in kind. I will return to ignoring him once again.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Feb 07, 2006 4:53 pm 
Offline
User avatar

Joined: Mon Nov 24, 2003 12:10 pm
Posts: 82
Same thing happened to me a while back on Shmack Fuzznut. I attributed to either a server bug or one of two players hacking me. I kind of ruled out the bug thing since it only happened one day, and especially noted that it stopped after both players left the game. They both kind of like were teasing me about it when it was happening. I posted about it, but all I got from everyone was it was my fault. They were posting insisting that I was hitting my weapons change key and didn't realize it. What they don't realize is I don't have a special weapons change key, mine are the Quake original number keys on the main keyboard. Since I use the arrow keys for movement and three keys in the middle row of the alpha keys for rune commands, I know I wasn't doing it by mistake. Like most things that I post about, it's always my fault, especially when replys are from the former widowmaker posters.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Feb 07, 2006 6:06 pm 
Offline

Joined: Sun Mar 09, 2003 10:47 pm
Posts: 1612
Location: Ohio
There are several keys that if accidentally pressed in observer mode mess up your keys. One of them is 8, which will change your binds to the "standard ones."

I had this problem numerous times in Rocket Arena where my key setup would be totally messed up and every time it happened I had no idea what was going on.

Eventually, I noticed a pattern and I made efforts to not press my "ALT" key while in observer mode. The reason ALT caused a problem for me is that I had "impulse 8" bound to it to switch to the lightning gun.

There are also impulses that can get set on the IHOC server (or most any server) that carry over even if you switch to another server. My "v" key had the IHOC jet bound which was "impulse 19" at IHOC which was an admin-impulse for on the old Widomaker server and several times I accidentally forced the player I was observing to exit the game and had no clue what was going. I had a similar problem long ago on Shmack with a shared impulse.

So I know you aren't making it up. It happened for real.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Feb 07, 2006 7:44 pm 
Offline
Site Admin
User avatar

Joined: Fri Mar 07, 2003 7:41 pm
Posts: 1258
Location: New Jersey, USA
Fuzznut wrote:
I was thinking about making a demo but Spooker pointed out that the demo wouldn't show whether I was hitting the weapon switch key which I'm not.


Feel free to send me a demo. If it is a bug, I can use the demo to help recreate the problem.

_________________
Slot Zero
Image


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Feb 07, 2006 8:39 pm 
Offline
User avatar

Joined: Tue Mar 11, 2003 5:43 pm
Posts: 239
Location: North Carolina
Diazoild wrote:
Fuzznut wrote:
Looks like this thread starts in the middle of an argument. Where does it start at? I like a good flame war every now and then.



I made a post in the thread about the rotating shield. I merely stated that I liked that the Rune Quake mod gave one the flexibility to toggle this function on and off. My post is still in that thread.

Mr Wi FI didn't like the post. I guess he does this differently in his mod...? He then proceeded to make personal attacks on me, my site and server, which had nothing to do with the discussion.

He's acts very brave sitting behind his keyboard cowardly making passive aggressive posts, which he often later pretends were jokes. I'm quite sure if we were discussing the matter face to face the discourse would be quite different.

I apologize that you had to read this exchange. I usually ignore him, but just had my fill of his bullshit and decided to reply in kind. I will return to ignoring him once again.

Diazoild's a big sissy, yes, Diazoild's a big sissy, all the other big sissy's are throwning a hissie. Diazoild's a big sissy, yes, he's a big sissie, getting all pissy, cause he's all prissy, so why won't the real Diazoild please, please, please shut up. Diazoild won't you pleeeeeeeaseeee, shut up!

8)

_________________
Check out Rune Quake Plus X at fear.lokinetworks.com


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Feb 07, 2006 10:00 pm 
Offline
User avatar

Joined: Sun Oct 09, 2005 4:48 am
Posts: 392
Location: Hey look! Secret Message!!!!
Diazoid and Wifi: No one cares

Mysteri:
Make an alias that initializes all your set bindings, etc. That way, typing in "unbind all, bind n messagemode" won't mess any commands when you can later on type "bindall (ur alias name)" to reestablish bindings after the hacking has stopped. I say this because it'll confuse the attackers into thinking they aren't controlling you correctly.

Ofcourse they could juse bind the keys again but let's assume all hack users are idiots 8)

_________________
If you see me online, say Hi :)


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Feb 08, 2006 8:48 am 
Offline
User avatar

Joined: Fri Aug 12, 2005 8:34 pm
Posts: 121
you two sound like 2 yeard olds...its amazing how this whole argument got started over rotating armor...ieee....stop this right now...it is so....baby-like...STOP FIGHTING OVER ARMOR!

_________________
:mrgreen: :mrgreen: :mrgreen:


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Feb 08, 2006 8:27 pm 
Offline
User avatar

Joined: Tue Mar 11, 2003 5:43 pm
Posts: 239
Location: North Carolina
gamefreak wrote:
you two sound like 2 yeard olds...its amazing how this whole argument got started over rotating armor...ieee....stop this right now...it is so....baby-like...STOP FIGHTING OVER ARMOR!


This isn't fighting, you'd know if it was fighting. Mocking "The Real Slim Shadey" is my way of saying "This is stupid and pointless" in my own way.

DZ needs hoooooooooonky tonk women...

_________________
Check out Rune Quake Plus X at fear.lokinetworks.com


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Feb 09, 2006 2:17 am 
Offline
User avatar

Joined: Sun Oct 09, 2005 4:48 am
Posts: 392
Location: Hey look! Secret Message!!!!
way to defend yourself OJ. so is it true that fear.lokinetworks is smurf attacking it's visitors?

_________________
If you see me online, say Hi :)


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Feb 09, 2006 8:25 pm 
Offline
User avatar

Joined: Tue Mar 11, 2003 5:43 pm
Posts: 239
Location: North Carolina
Canadian*Sniper wrote:
way to defend yourself OJ. so is it true that fear.lokinetworks is smurf attacking it's visitors?

And you are?

_________________
Check out Rune Quake Plus X at fear.lokinetworks.com


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Feb 09, 2006 10:23 pm 
Offline
User avatar

Joined: Mon Jun 13, 2005 11:27 pm
Posts: 214
Canadian*Sniper wrote:
way to defend yourself OJ. so is it true that fear.lokinetworks is smurf attacking it's visitors?


What's Smurf attacking?

_________________
Here is Toyo_MR2, lying broken at my feet.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Feb 09, 2006 10:26 pm 
Offline
User avatar

Joined: Mon Jun 13, 2005 11:27 pm
Posts: 214
This happens after the RL is already selected. It's when I go to fire it that it switches out, or in the middle of firing.

Today on shmack though, when cycling through the weapons, it would completely bypass the grenade launcher on several occasions. I would keep going back thinking I didn't pick it up. But I found out that I had.

I'll start demoing and when I get a demo showing it running rampant I'll send it in, to where again?

_________________
Here is Toyo_MR2, lying broken at my feet.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Feb 10, 2006 2:25 am 
Offline
User avatar

Joined: Fri Aug 19, 2005 10:35 pm
Posts: 96
i like sissies

and I dont know who smurf is, but the lokinetworks admin floods me periodically. ive heard similar complaints from others on shmack. i recommend you dont go there because he gets all your connection info when you do.

re: traditionalism: people have always made games, just lower tech. i saw a 2500 year old greek game board this summer. neat eh?[/quote]


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Feb 10, 2006 3:07 am 
Offline
User avatar

Joined: Mon Jun 13, 2005 11:27 pm
Posts: 214
OK I did a Google search:

THE LATEST IN DENIAL OF SERVICE ATTACKS: "SMURFING"
DESCRIPTION AND INFORMATION TO MINIMIZE EFFECTS

Craig A. Huegen
chuegen@pentics.com

Last Update: Tue Feb 8 17:47:36 PST 2000

(Note: Most of this information is historical and out-of-date. Obviously, we have seen phenomenal growth of Denial-of-Service attacks across the Internet, leveraging security vulnerabilities to assemble networks of compromised hosts which can be used to attack sites, rather than relying upon a big pipe or amplification techniques. Most of this material is left unchanged, for reference.)

New additions:

Removed "smurf update" section -- no longer valid given distributed DoS
Editor's plea: please distribute this information freely, and abide by my redistribution requirements (see the very end) when doing so. It's important that these attacks be minimized, and communication is the only way to help with this.

1. OVERVIEW:

The information here provides in-depth information regarding "smurf" and "fraggle" attacks, with a focus on Cisco routers and how to reduce the effects of the attack. Some information is general and not related to an organization's particular vendor of choice; however, it is written with a Cisco router focus. No confirmation has been made to the effects on other vendors' equipment; however, others have provided me with information for various vendors, which is provided in the document. See the "Acknowledgements" section below for the sources and contact information. I am happy to accept information from other colleagues or other vendors who are willing to provide information about other vendors' products in relation to this topic.

This paper is always being updated as I receive more information about attacks and work with ways to minimize impact.

2. DESCRIPTION:

The "smurf" attack, named after its exploit program, is one of the most recent in the category of network-level attacks against hosts. A perpetrator sends a large amount of ICMP echo (ping) traffic at IP broadcast addresses, all of it having a spoofed source address of a victim. If the routing device delivering traffic to those broadcast addresses performs the IP broadcast to layer 2 broadcast function noted below, most hosts on that IP network will take the ICMP echo request and reply to it with an echo reply each, multiplying the traffic by the number of hosts responding. On a multi-access broadcast network, there could potentially be hundreds of machines to reply to each packet.

The "smurf" attack's cousin is called "fraggle", which uses UDP echo packets in the same fashion as the ICMP echo packets; it was a simple re-write of "smurf".

Currently, the providers/machines most commonly hit are IRC servers and their providers.

There are two parties who are hurt by this attack... the intermediary (broadcast) devices--let's call them "amplifiers", and the spoofed address target, or the "victim". The victim is the target of a large amount of traffic that the amplifiers generate.

Let's look at the scenario to paint a picture of the dangerous nature of this attack. Assume a co-location switched network with 100 hosts, and that the attacker has a T1. The attacker sends, say, a 768kb/s stream of ICMP echo (ping) packets, with a spoofed source address of the victim, to the broadcast address of the "bounce site". These ping packets hit the bounce site's broadcast network of 100 hosts; each of them takes the packet and responds to it, creating 100 ping replies out-bound. If you multiply the bandwidth, you'll see that 76.8 Mbps is used outbound from the "bounce site" after the traffic is multiplied. This is then sent to the victim (the spoofed source of the originating packets).

3. HOW TO DETERMINE IF YOUR NETWORK IS VULNERABLE:

Several sites have been established to do both active and passive scanning of networks to determine whether or not directed-broadcast is enabled.

http://www.netscan.org/ is a site which actively scans the IPv4 address space and mails network contacts with information on how to disable them.

http://www.powertech.no/smurf/ is a site which will test scan your network and allow you to enter a known smurf amplifier site.

4. HOW TO KEEP YOUR SITE FROM BEING THE SOURCE PERPETRATORS USE TO ATTACK VICTIMS:

The perpetrators of these attacks rely on the ability to source spoofed packets to the "amplifiers" in order to generate the traffic which causes the denial of service.

In order to stop this, all networks should perform filtering either at the edge of the network where customers connect (access layer) or at the edge of the network with connections to the upstream providers, in order to defeat the possibility of source-address-spoofed packets from entering from downstream networks, or leaving for upstream networks.

Paul Ferguson of cisco Systems and Daniel Senie of BlazeNet have written an RFC pertaining to this topic. See:

ftp://ftp.isi.edu/in-notes/rfc2267.txt

for more information and examples on this subject.

Additionally, router vendors have added or are currently adding options to turn off the ability to spoof IP source addresses by checking the source address of a packet against the routing table to ensure the return path of the packet is through the interface it was received on.

Cisco has added this feature to the current 11.1CC branch, used by many NSP's, in an interface command '[no] ip verify unicast reverse-path'.

See the "other vendors" section for 3Com information regarding this feature.

5. HOW TO STOP BEING AN INTERMEDIARY:

This attack relies on the router serving a large multi-access broadcast network to frame an IP broadcast address (such as 10.255.255.255) into a layer 2 broadcast frame (for Ethernet, FF:FF:FF:FF:FF:FF). RFC 1812, "Requirements for IP Version 4 Routers", Section 5.3.5, specifies:

---
A router MAY have an option to disable receiving network-prefix-
directed broadcasts on an interface and MUST have an option to
disable forwarding network-prefix-directed broadcasts. These options
MUST default to permit receiving and forwarding network-prefixdirected
broadcasts.
---

Generally, with IP providers and IP applications as we know them today, this behavior should not be needed, and it is recommended that directed-broadcasts be turned off, to suppress the effects of this attack.

RFC 2644, a Best Current Practice RFC by Daniel Senie, updates RFC 1812 to state that router software must default to denying the forwarding and receipt of directed broadcasts.

Ethernet NIC hardware (MAC-layer hardware, specifically) will only listen to a select number of addresses in normal operation. The one MAC address that all devices share in common in normal operation is the media broadcast, or FF:FF:FF:FF:FF:FF. If a device receives a packet destined to the broadcast link-layer address, it will take the packet and send an interrupt for processing by the higher-layer routines.

To stop your Cisco router from converting these layer 3 broadcasts into layer 2 broadcasts, use the "no ip directed-broadcast" interface configuration command. This should be configured on each interface of all routers.

As of Cisco IOS version 12.0, "no ip directed-broadcast" is now the default in order to protect networks by default. "ip directed-broadcast" will be needed if your network requires directed broadcasts to be enabled.

Other vendor information:

Proteon/OpenROUTE: Daniel Senie (dts@senie.com) reports that Proteon/OpenROUTE Networks routers have an option to turn off directed broadcasts in the IP Configuration menus. The command sequence to turn them off is: *CONFIG (on newer routers) or TALK 6 (on older routers) Config>PROTOCOL IP IP Config>DISABLE DIRECTED-BROADCAST A restart of the router is then required.
Nortel Networks (Bay Networks): Jon Green (jcgreen@netins.net) reports that bugID CR33408 added the ability to disable network-directed broadcasts beginning in version 12.01 rev 1 of BayRS code. To disable, enter: [1:1]$bcc bcc> config hostname ip ip set directed-bcast disabled ip# exit Note that this will bounce all IP interfaces. Greg Hankins (ghankins@mindspring.net) reports that in BayRS 13.01 and later, directed-broadcast is disabled by default. Tim Winders (twinders@SPC.cc.tx.us) mentions that if you upgrade to BayRS 13.01+ from 12.01, directed-broadcasts are not disabled.
3Com NETBuilder products: Mike Kouri (Mike_Kouri@3com.com) reports that all 3Com NETBuilders have an option to keep the router from forwarding the directed broadcasts. The command sequence to disable the forwarding is: SETDefault -IP CONTrol = NoFwdSubnetBcast Additionally, 3Com NETBuilder products running version 9.1 or later can be configured to discard source-spoofed packets: SETDefault !port -FireWall CONTrol = (Filter, DenySrcSpoofing) 3Com states in the web page (listed below) that this command "Specifies whether packets are subject to source-spoofing checks. This is a CPU-intensive option and generally results in performance degradation. You should disable this option except on interfaces where external, untrusted traffic is received. The source address of incoming packets is checked against the routing table. If the routing information shows that the source address is unreachable, or reachable on different interfaces, then it is a SrcSpoofing attack."
Lucent (Ascend): Will Pierce (willp@dreamscape.com) reports that on Maxes or Pipelines running TAOS 6.0.0 or higher, you can go to the Ethernet->Mod Config menu and set both "Reply DirectedBcast Ping" and "Forward Directed Bcast" to "No". For the Max TNT, there is an example at ftp://ftp.ascend.com/pub/Software-Relea ... /tnt20.pdf on page 40. TNT versions 2.0.0 and higher support this.
Cabletron SmartSwitch Router (Yago/SSR): Greg Hankins (ghankins@mindspring.net) reports directed-broadcast is disabled by default, and can be enabled by entering the global command "ip enable directed-broadcast".
Foundry Networks: Greg Hankins (ghankins@mindspring.net) reports that hardware running Foundry's routing software can be configured to disable directed-broadcasts with the global or per-interface "no ip directed-broadcast" command.
Redback Networks: Justin Streiner (streiner@stargate.net) reports that on the SMS-500 and SMS-1000 access switches, there is no support for directed broadcasts unless used in conjunction with DHCP, and they are not forwarded by default.
Extreme Networks: Aurobindo Sundaram (sundaram@austin.apc.slb.com) reports that you can disable IP broadcast forwarding on Extreme's Summit 1 switches by using the following commands: disable ipforwarding broadcast all disable ipforwarding broadcast vlan vlan-name
ArrowPoint Communications: Greg Hankins (ghankins@mindspring.net) reports that directed-broadcasts can be disabled by using the "no ip subnet-broadcast" global configuration command.
SGI IRIX as a router: Mike O'Connor (mjo@dojo.mi.org) reports that IRIX has been configured by default to not forward the directed-broadcasts when used as a router. The tunable for this is in /var/sysgen/master.d/bsd.
There is one case study where this will stop intended behavior: In the case where samba (an SMB server for UNIX) or NT is used to "remote broadcast" into a LAN workgroup so that the workstations on that LAN can see the server, this will prevent the LAN machines from seeing the remote server. This is only in the case where there is no WINS server (WINS is routed unicast) and a "remote broadcast" is being used--it's a rare but notable condition.

(Editor's note: I welcome any comments as to what else breaks without the support for directed-broadcast.)

Additionally, hosts can be patched to refuse to respond to broadcasted ICMP echo packets. RFC 1122, "Requirements for Internet Hosts -- Communications Layer", Section 3.2.2.6, states:

---
An ICMP Echo Request destined to an IP broadcast or IP
multicast address MAY be silently discarded.

DISCUSSION:

This neutral provision results from a passionate debate
between those who feel that ICMP Echo to a broadcast
address provides a valuable diagnostic capability and
those who feel that misuse of this feature can too
easily create packet storms.
---

Because of this, most IP stack implementors have chosen to implement the default support provision, which is to reply to an ICMP Echo Request. As mentioned in the paragraph from the RFC (above), it is perfectly legal for a host to silently discard ICMP echos. Several patches have been found floating about in mailing lists for disabling response to broadcast ICMP echos for the freely-available UNIX systems.

In the case of the smurf or fraggle attack, each host which supports this behavior on a broadcast LAN will happily reply with an ICMP or UDP (smurf or fraggle, respectively) echo-reply packet toward the spoofed source address, the victim.

The following section contains information to configure hosts not to respond to ICMP echo requests to broadcast addresses.

IBM has provided a setting in AIX 4.x to disable responses to broadcast addresses. It is not available in AIX 3.x. Use the "no" command to turn it off or on. NOTE: On AIX 4.x responses are DISABLED by default.

no -o bcastping=0 # disable bcast ping responses (default)

Solaris can be set not to respond to ICMP echo requests. Add the following line to your /etc/rc2.d/S69inet startup:

ndd -set /dev/ip ip_respond_to_echo_broadcast 0

If you're using Solaris as a router, you can configure it not to forward directed broadcasts by placing the following line in your /etc/rc2.d/S69inet startup:

ndd -set /dev/ip ip_forward_directed_broadcasts 0

Starting with version 2.2.5, FreeBSD's IP stack does not respond to icmp echo requests destined to broadcast and multicast addresses by default. The sysctl parameter for this functionality is net.inet.icmp.bmcastecho. Beginning with version 3.x, FreeBSD makes this option configurable in the /etc/rc.conf file with an option under the miscellaneous network configuration section.

Under NetBSD, directed broadcasts can be disabled by using the sysctl command:

sysctl -w net.inet.ip.directed-broadcast=0

Under Linux, one can use the CONFIG_IP_IGNORE_ECHO_REQUESTS variable to completely ignore ICMP echo requests. Of course, this violates RFC 1122. "ipfw" can be used from Linux to block broadcast echos, a la:

Any system with ipfw can be protected by adding rules such as:

ipfwadm -I -a deny -P icmp -D 123.123.123.0 -S 0/0 0 8
ipfwadm -I -a deny -P icmp -D 123.123.123.255 -S 0/0 0 8

(replace 123.123.123.0 and 123.123.123.255 with your base network number and broadcast address, respectively)

To protect a host against "fraggle" attacks on most UNIX machines, one should comment the lines which begin with "echo" and "chargen" in /etc/inetd.conf and restart inetd.

6. INFORMATION FOR VICTIMS AND HOW TO SUPPRESS ATTACKS:

The amount of bandwidth and packets per second (pps) that can be generated by this attack is quite large. With a 200-host LAN, I was able to generate over 80 Mbps traffic at around 35 Kpps toward my target--a pretty significant amount. The victims receive this because traffic is multiplied by the number of hosts on the broadcast network used (in this case, with a 200-host network, I was only required to send 400 Kbps to the broadcast address--less than one-third of a T1).

Many hosts cannot process this many packets per second; many hosts are connected to 10 Mbps Ethernet LANs where more traffic than wire speed is sent. Therefore, the ability to drop these packets at the network border, or even before it flows down the ingress pipes, is desired.

Cisco routers have several "paths" which packets can take to be routed; each has a varying degree of overhead. The slowest of these is "process" switching. This is used when a complex task is required for processing packets. The other modes are variations of a fast path--each of them with a set of advantages and disadvantages. However, they're all handled at interrupt level (no process-level time is required to push these packets).

In IOS versions (even the most recent), access-list denies are handled at the process (slow) level, because they require an ICMP unreachable to be generated to the originating host. All packets were sent to the process level automatically to be handled this way.

Under a recent code change (Cisco bug ID CSCdj35407--integrated in version 11.1(14)CA and later 11.1CA, 11.1CC, 11.1CE, and 12.0 trains), packets denied by an access-list will be dropped at the interrupt (fast) level, with the exception of 2 packets per second per access-list deny line. These 2 packets per second will be used to send the "ICMP unreachable via administrative block" messages. This assumes that you don't want to log the access-list violations (via the "log" or "log-input" keywords). The ability to rate-limit "log-input" access-list lines (in order to more easily log these packets) is currently being integrated; see the section below on tracing spoofed packet attacks for information on logging.

Filtering ICMP echo reply packets destined for your high-profile machines at the ingress interfaces of the network border routers will then permit the packets to be dropped at the earliest possible point. However, it does not mean that the network access pipes won't fill, as the packets will still come down the pipe to be dropped at the router. It will, however, take the load off the system being attacked. Keep in mind that this also denies others from being able to ping from that machine (the replies will never reach the machine).

For those customers of providers who use Cisco, this may give you some leverage with the providers' security teams to help save your pipes by filtering before the traffic is sent to you.

An additional technology you can use to protect your machines is to use committed access rate, or CAR. CAR is a functionality that works with Cisco Express Forwarding, found in 11.1CC, 11.1CE, and 12.0. It allows network operators to limit certain types of traffic to specific sources and/or destinations.

For example, a provider has filtered its IRC server from receiving ICMP echo-reply packets in order to protect it, but many attackers are now attacking other customer machines or network devices in order to fill some network segments.

The provider above chose to use CAR in order to limit all ICMP echo and echo-reply traffic received at the borders to 256 Kbps. An example follows:

! traffic we want to limit
access-list 102 permit icmp any any echo
access-list 102 permit icmp any any echo-reply
! interface configurations for borders
interface Serial3/0/0
rate-limit input access-group 102 256000 8000 8000 conform-action transmit exceed-action drop

This limits ICMP echo and echo-reply traffic to 256 Kbps with a small amount of burst. Multiple "rate-limit" commands can be added to an interface in order to control other kinds of traffic as well.

The command "show interface [interface-name] rate-limit" will show the statistics for rate-limiting; "clear counters [interface-name]" will clear the statistics for a fresh look.

CAR can also be used to limit TCP SYN floods to particular hosts -- without impeding existing connections. Some attackers have started using very high streams of TCP SYN packets in order to harm systems once again.

Here is an example which limits TCP SYN packets directed at host 10.0.0.1 to 8 kbps or so:

! We don't want to limit established TCP sessions -- non-SYN packets
access-list 103 deny tcp any host 10.0.0.1 established
! We do want to limit the rest of TCP (this really only includes SYNs)
access-list 103 permit tcp any host 10.0.0.1
! interface configurations for network borders
interface Serial3/0/0
rate-limit input access-group 103 8000 8000 8000 conform-action transmit exceed-action drop

Currently, CAR is only available for 7200 and 7500 series routers. Additional platform support is planned in 12.0.

Additionally, CAR can be used to set IP precedence; this is beyond the scope of this paper. Consult http://www.cisco.com for more information on the uses of CAR.

7. TRACING SPOOFED PACKET STREAMS:

Tracking these attacks can prove to be difficult, but is possible with coordination and cooperation from providers. This section also assumes Cisco routers, because I can speak only about the abilities of Cisco to log/filter packets and what impact it may have.

Today, logging packets which pass through or get dropped in an ACL is possible; however, all packets with the "log" or "log-input" ACL options are sent to process level for logging. For a large stream of packets, this could cause excessive CPU problems. For this reason, tracking attacks via IOS logging today is limited to either lower bandwidth attacks (smaller than 10k packets per second). Even then, the number of log messages generated by the router could overload a syslog server.

Cisco bug ID CSCdj35856 addresses this problem. It has been integrated into IOS version 11.1CA releases beginning with 11.1(14.1)CA (a maintenance interim release), and makes it possible to log packets at defined intervals and to process logged packets not at that interval in the fast path. I will update this page with version numbers as the releases are integrated.

Some information on logging:

In later 11.1 versions, a new keyword was introduced for ACL logging: "log-input". A formatted ACL line utilizing the keyword looks like this:

access-list 101 permit icmp any any echo log-input

When applied to an interface, this line will log all ICMP ping packets with input interface and MAC address (for multi-access networks). Point-to-point interfaces will not have a MAC address listed.

Here's an example of the log entry for a multi-access network (FDDI, Ether):

Sep 10 23:17:01 PDT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp 10.0.7.30 (FastEthernet1/0 0060.3e2f.6e41) -> 10.30.248.3 (8/0), 5 packets

Here's an example of the log entry for a point-to-point network:

Sep 10 23:29:00 PDT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp 10.0.7.30 (BRI0 PPP) -> 10.0.19.242 (8/0), 1 packet

Substituting "log" for "log-input" will eliminate the incoming interface and MAC address from the log messages.

We'll use the first log entry to demonstrate how to go from here. This log entry means the packet came in on FastEthernet1/0, from MAC address 0060.3e2f.6e41, destined for 10.30.248.3. From here, you can use "show ip arp" (if needed) to determine the IP address for the MAC address, and go to the next hop for tracing or contact the necessary peer (in the case of an exchange point). This is a hop-by-hop tracing method.

Example of "show ip arp" used to find next hop:

netlab#show ip arp 0060.3e2f.6e41

Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.0.183.65 32 0060.3e2f.6e41 ARPA FastEthernet1/0

As you can see, 10.0.183.65 is the next hop where the packets came from and we should go there to continue the tracing process, utilizing the same ACL method. By doing this, you can track the spoof attack backwards.

While this is general information on tracking spoofed packets, it must be noted that the victims of a smurf/fraggle attack get packets from the listed source in the packets; i.e., they receive echo-reply packets truly from the source listed in the IP header. This information should be used by the amplifiers or intermediaries to track the spoofed echo request packets back to their source (the perpetrator).

8. OTHER DENIAL OF SERVICE ATTACKS WORTHY OF MENTION:

Two other denial of service attacks frequently encountered are TCP SYN floods, and UDP floods aimed at diagnostic ports on hosts.

TCP SYN attacks consist of a large number of spoofed TCP connection set-up messages aimed at a particular service on a host. Older TCP implementations cannot handle many faked connection set-up packets, and will not allow access to the victim service.

The most common form of UDP flooding directed at harming networks is an attack consisting of a large number of spoofed UDP packets aimed at diagnostic ports on network devices. This attack is also known as the "pepsi" attack (again named after the exploit program), and can cause network devices to use up a large amount of CPU time responding to these packets.

To get more information on minimizing the effects of these two attacks, see:

Defining Strategies to Protect Against TCP SYN Denial of Service Attacks
http://cio.cisco.com/warp/public/707/4.html

Defining Strategies to Protect Against UDP Diagnostic Port DoS Attacks
http://cio.cisco.com/warp/public/707/3.html

9. PERFORMANCE INFORMATION:

One ISP has reported that, spread across three routers (2 RSP2 and 1 RSP4), the fast drop code eliminated a sustained 120 Mbps smurf attack and kept the network running without performance problems.

As always, your mileage may vary.

10. ACKNOWLEDGEMENTS:

Thanks to all those who helped review and provide input to the paper, as well as sanity checking.

11. REFERENCES:

RFC-1122, "Requirements for Internet Hosts - Communication Layers"; R.T. Braden; October 1989.

RFC-1812, "Requirements for IP Version 4 Routers"; F. Baker; June 1995.

RFC-2267, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing"; P. Ferguson, D. Senie; January 1998.

RFC-2644, "Changing the Default for Directed Broadcasts in Routers"; D. Senie; August 1999.

Defining Strategies to Protect Against TCP SYN Denial of Service Attacks
http://cio.cisco.com/warp/public/707/4.html

Defining Strategies to Protect Against UDP Diagnostic Port DoS Attacks
http://cio.cisco.com/warp/public/707/3.html

Cisco command documention to turn off directed broadcasts http://www.cisco.com/univercd/cc/td/doc ... ocid748113

3Com command documentation to turn off directed broadcasts http://infodeli.3com.com/infodeli/tools ... p4.htm#190

3Com command documentation to disable source spoofing http://infodeli.3com.com/infodeli/tools ... 3.htm#1823

12. PERMISSION TO DUPLICATE:

Permission to duplicate this information is granted under these terms:

My name and e-mail address remains on the information as a target for questions and identification of the source
My disclaimer appears on the information at the bottom
Feel free to add extra information from other discussions, etc., but please ensure the correct attribution is made to the author. Also provide Craig Huegen (chuegen@pentics.com) a copy of your additions.
Please help disseminate this information to other network administrators who are affected by these attacks.
If you have questions, I will be happy to answer them to the best of my knowledge.

13. MY DISCLAIMER:

I'm speaking about this as an interested party only. All text in this paper was written by me; I speak/write for no one but myself. No vendors have officially confirmed/denied any of the information contained herein. All research for this paper is being done purely as a matter of self-interest and desire to help others minimize effects of this attack.

Craig A. Huegen
chuegen@pentics.com
http://www.pentics.net/denial-of-service/

_________________
Here is Toyo_MR2, lying broken at my feet.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Feb 10, 2006 3:00 pm 
Offline
User avatar

Joined: Sun Oct 09, 2005 4:48 am
Posts: 392
Location: Hey look! Secret Message!!!!
Fuzznut wrote:
THE LATEST IN DENIAL OF SERVICE ATTACKS: "SMURFING"


It's actually an oldschool attack. Anyways it's just a rumour I heard from spooker one time when he was pleading for my leet programmer help. Too bad I'm not in Systems Integration :lol:

_________________
If you see me online, say Hi :)


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 54 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group