Ddos by someone else

Post Reply [phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable
nethic
Newby Cowboy
Posts: 32
Joined: Wed Sep 22, 2004 8:22 pm
Location: in your room
Contact:

Ddos by someone else

Post by nethic » Sun Sep 26, 2004 10:33 am

G-48: TCP SYN Flooding and IP Spoofing Attacks

September 20, 1996 18:00 GMT

PROBLEM: Two "underground magazines" for intruders have recently
published code to conduct denial-of-service attacks by creating
TCP "half open" connections.
PLATFORM: Any system connected to the Internet and providing TCP-based
network services such as a Web server, FTP server, or mail
server is potentially subject to this attack.
DAMAGE: Systems providing TCP-based services to the Internet community
may be unable to provide those services while under attack and
for some time after the attack ceases.
SOLUTION: See the bulletin below for information on how to protect your
site from these attacks.

VULNERABILITY Scripts are actively being used to attack sites connected to
ASSESSMENT: the Internet. TCP services are not harmed by the attack, only
the ability to provide those services is impaired. But, these
attack scripts are widely available, so the available solutions
should be considered for all systems providing critical
services.


[Begin CERT Bulletin]
=============================================================================
CERT(sm) Advisory CA-96.21
Original issue date: September 19, 1996
Last revised: --

Topic: TCP SYN Flooding and IP Spoofing Attacks
------------------------------------------------------------------------------
*** This advisory supersedes CA-95:01. ***

Two "underground magazines" have recently published code to conduct
denial-of-service attacks by creating TCP "half-open" connections. This code
is actively being used to attack sites connected to the Internet. There is,
as yet, no complete solution for this problem, but there are steps that can be
taken to lessen its impact. Although discovering the origin of the attack is
difficult, it is possible to do; we have received reports of attack origins
being identified.

Any system connected to the Internet and providing TCP-based network services
(such as a Web server, FTP server, or mail server) is potentially subject to
this attack. The consequences of the attack may vary depending on the system;
however, the attack itself is fundamental to the TCP protocol used by all
systems.

If you are an Internet service provider, please pay particular attention to
Section III and Appendix A, which describes step we urge you to take to
lessen the effects of these attacks. If you are the customer of an Internet
service provider, please encourage your provider to take these steps.

This advisory provides a brief outline of the problem and a partial solution.
We will update this advisory as we receive new information. If the change in
information warrants, we may post an updated advisory on comp.security.announce
and redistribute an update to our cert-advisory mailing list. As always, the
latest information is available at the URLs listed at the end of this advisory.

- -----------------------------------------------------------------------------

I. Description

When a system (called the client) attempts to establish a TCP connection
to a system providing a service (the server), the client and server
exchange a set sequence of messages. This connection technique applies
to all TCP connections--telnet, Web, email, etc.

The client system begins by sending a SYN message to the server. The
server then acknowledges the SYN message by sending SYN-ACK message to
the client. The client then finishes establishing the connection by
responding with an ACK message. The connection between the client and
the server is then open, and the service-specific data can be exchanged
between the client and the server. Here is a view of this message flow:

Client Server
------ ------
SYN-------------------->

<--------------------SYN-ACK

ACK-------------------->

Client and server can now
send service-specific data

The potential for abuse arises at the point where the server system has
sent an acknowledgment (SYN-ACK) back to client but has not yet received
the ACK message. This is what we mean by half-open connection. The
server has built in its system memory a data structure describing all
pending connections. This data structure is of finite size, and it can be
made to overflow by intentionally creating too many partially-open
connections.

Creating half-open connections is easily accomplished with IP
spoofing. The attacking system sends SYN messages to the victim server
system; these appear to be legitimate but in fact reference a client
system that is unable to respond to the SYN-ACK messages. This means that
the final ACK message will never be sent to the victim server system.

The half-open connections data structure on the victim server system
will eventually fill; then the system will be unable to accept any new
incoming connections until the table is emptied out. Normally there is a
timeout associated with a pending connection, so the half-open
connections will eventually expire and the victim server system will
recover. However, the attacking system can simply continue sending
IP-spoofed packets requesting new connections faster than the victim
system can expire the pending connections.

In most cases, the victim of such an attack will have difficulty in
accepting any new incoming network connection. In these cases, the
attack does not affect existing incoming connections nor the ability to
originate outgoing network connections.

However, in some cases, the system may exhaust memory, crash, or be
rendered otherwise inoperative.

The location of the attacking system is obscured because the source
addresses in the SYN packets are often implausible. When the packet
arrives at the victim server system, there is no way to determine its
true source. Since the network forwards packets based on destination
address, the only way to validate the source of a packet is to use input
source filtering (see Appendix A).

II. Impact

Systems providing TCP-based services to the Internet community may
be unable to provide those services while under attack and for some
time after the attack ceases. The service itself is not harmed by the
attack; usually only the ability to provide the service is impaired.
In some cases, the system may exhaust memory, crash, or be rendered
otherwise inoperative.

III. Solution

There is, as yet, no generally accepted solution to this problem with
the current IP protocol technology. However, proper router configuration
can reduce the likelihood that your site will be the source of one of
these attacks.

Appendix A contains details about how to filter packets to reduce the
number of IP-spoofed packets entering and exiting your network. It also
contains a list of vendors that have reported support for this type of
filtering.

NOTE to Internet Service Providers:
We STRONGLY urge you to install these filters in your routers to
protect your customers against this type of an attack. Although these
filters do not directly protect your customers from attack, the
filters do prevent attacks from originating at the sites of any of your
customers. We are aware of the ramifications of these filters on some
current Mobile IP schemes and are seeking a position statement from
the appropriate organizations.

NOTE to customers of Internet service providers:
We STRONGLY recommend that you contact your service provider to verify
that the necessary filters are in place to protect your network.

Many networking experts are working together to devise improvements to
existing IP implementations to "harden" kernels to this type of attack.
When these improvements become available, we suggest that you install
them on all your systems as soon as possible. This advisory will be
updated to reflect changes made by the vendor community.

IV. Detecting an Attack

Users of the attacked server system may notice nothing unusual since the
IP-spoofed connection requests may not load the system noticeably. The
system is still able to establish outgoing connections. The problem will
most likely be noticed by client systems attempting to access one of the
services on the victim system.

To verify that this attack is occurring, check the state of the server
system's network traffic. For example, on SunOS this may be done by the
command:

netstat -a -f inet

Too many connections in the state "SYN_RECEIVED" indicates that the
system is being attacked.


...........................................................................

Appendix A - Reducing IP Spoofed Packets


1. Filtering Information
- -------------------------

With the current IP protocol technology, it is impossible to eliminate
IP-spoofed packets. However, you can take steps to reduce the number of
IP-spoofed packets entering and exiting your network.

Currently, the best method is to install a filtering router that restricts
the input to your external interface (known as an input filter) by not
allowing a packet through if it has a source address from your internal
network. In addition, you should filter outgoing packets that have a source
address different from your internal network to prevent a source IP spoofing
attack from originating from your site.

The combination of these two filters would prevent outside attackers from
sending you packets pretending to be from your internal network. It would also
prevent packets originating within your network from pretending to be from
outside your network. These filters will *not* stop all TCP SYN attacks, since
outside attackers can spoof packets from *any* outside network, and internal
attackers can still send attacks spoofing internal addresses.

We STRONGLY urge Internet service providers to install these filters in your
routers.

In addition, we STRONGLY recommend customers of Internet service providers to
contact your service provider to verify that the necessary filters are in
place to protect your network.


2. Vendor Information
- ----------------------

The following vendor(s) have reported support for the type of filtering we
recommend and provided pointers to additional information that describes how
to configure your router. If you need more information about your router or
about firewalls, please contact your vendor directly.

Cisco
-----
Refer to the section entitiled "ISP Security Advisory"
on http://www.cisco.com for an up-to-date explanation of
how to address TCP SYN flooding on a Cisco router.


NOTE to vendors:
If you are a router vendor who has information on router capabilities and
configuration examples and you are not represented in this list, please contact
the CERT Coordination Center at the addresses given in the Contact Information
section below. We will update the advisory after we hear from you.


3. Alternative for routers that do not support filtering on the inbound side
- ----------------------------------------------------------------------------

If your vendor's router does not support filtering on the inbound side of the
interface or if there will be a delay in incorporating the feature into your
system, you may filter the spoofed IP packets by using a second router
between your external interface and your outside connection. Configure this
router to block, on the outgoing interface connected to your original router,
all packets that have a source address in your internal network. For this
purpose, you can use a filtering router or a UNIX system with two interfaces
that supports packet filtering.

Note: Disabling source routing at the router does not protect you from this
attack, but it is still good security practice to follow.

On the input to your external interface, that is coming from the Internet to
your network, you should block packets with the following addresses:

* Broadcast Networks: The addresses to block here are network 0 (the all zeros
broadcast address) and network 255.255.255.255 (the all ones broadcast
network).

* Your local network(s): These are your network addresses

* Reserved private networks: The following networks are defined as reserved
private networks and no traffic should ever be received from or transmitted
to these networks through a router:
10.0.0.0
127.0.0.0
172.16.0.0
192.168.0.0

------------------------------------------------------------------------------
The CERT Coordination Center staff thanks the team members of NASIRC
for contributing much of the text for this advisory and thanks the many
experts who are devoting time to addressing the problem and who provided input
to this advisory.
------------------------------------------------------------------------------

[End CERT Bulletin]



CIAC wishes to acknowledge the contributions of NARSIRC and CERT for the information contained in this bulletin.

CIAC services are available to DOE, DOE Contractors, and the NIH. CIAC can be contacted at:
Voice: +1 925-422-8193 (7 x 24)
FAX: +1 925-423-8002
STU-III: +1 925-423-2604
E-mail: ciac@ciac.org
World Wide Web: http://www.ciac.org/
Anonymous FTP: ftp.ciac.org


This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes.
UCRL-MI-119788
[Privacy and Legal Notice]

eekay
Administrator
Posts: 231
Joined: Mon Sep 20, 2004 3:38 pm
Location: Denver, CO.
Contact:

Post by eekay » Tue Oct 05, 2004 7:41 pm

Always nice to keep up with standard vulnerability issues. People who read this should pay attention. Fixes are possible no matter what OS or personal machine you run. Thanks, Nethic.

Post Reply
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable