- Test - lists.nanog.org

ISP responses to DOS/DDOS attacks for customers
by Wayne Bogan 24 Oct '02

24 Oct '02

Is there a standard/general level of response that ISPs should provide when responding to DOS/DDOS attacks for customer networks. We try to respond and help any customer with identifying and resolving the problem since most of our customers don't have the staff to respond appropriately. How far should we go? If this issue has already been addressed, please respond off-list with the correct direction to search. Regards, Wayne

3 2

Sugestions for a colocation equipment check-list
by Dan Lockwood 24 Oct '02

24 Oct '02

Does anyone have a list of criteria that is collected when a customer brings equipment into a colocation facility? Things may include make and model, number of power supplies, serial number, etc. Any comments on this type of operation are greatly appreciated. TIA Dan Lockwood Microsoft Certified Professional CompTIA Network+ Certified Cisco Certified Network Associate

2 1

Yahoogroups probs?
by blitz 24 Oct '02

24 Oct '02

Anyone hearing of yahoogroups probs these past few days? >I sent an email to a group im subscribed to there and it bounced, saying >the bounce was from: Reporting-MTA: dns; mail.gallyas.cl Figure the esteemed group here might know if theres been a domain hijacking or other problem. Thanks Marc macronet.net

1 0

Multiple vendors' TCP/IP implementation allow packets to bypass firewalls - VU#464113
by CERT(R) Coordination Center 24 Oct '02

24 Oct '02

-----BEGIN PGP SIGNED MESSAGE----- Hello NANOGers, I am sending this to you for your evaluation and possible feedback. The CERT/CC has reviewed a report describing a method that significantly improves an attacker's chances of successfully circumventing a firewall. In a mail thread taking place on the Bugtraq mailing list, research is described which may allow an attacker to circumvent a firewall. - - Paper: <http://online.securityfocus.com/archive/1/296122/2002-10-19/2002-10-25/2> - - Thread: <http://online.securityfocus.com/archive/1/296558/2002-10-19/2002-10-25/1> In this message, we begin by presenting some background information for those who are unfamiliar with TCP/IP connection semantics. We then go into specifics regarding how an attacker can circumvent various firewalls by using specially crafted packets. Next, we examine the various impacts resulting from exploitation of this vulnerability. Finally, we present a sample mitigation strategy that will enable you to better protect resources located behind firewalls. - ---Background on TCP/IP Connection Semantics--- As many of you may know, to establish a TCP connection, the client and server must participate in a three-way handshake. 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. A firewall can be used to manage the connection setup and subsequent traffic flow between the client and server. In general, firewalls are of two types: packet-filtering firewalls, and application-level firewalls. Packet filters look at the source, destination, types, and options associated with the packet, while an application level firewall can "look inside" the packet to examine application-specific attributes. This document is concerned primarily with packet-filtering firewalls (which are much more common), including routers acting as packet filters. Section 3.4 (Establishing a connection) of RFC793 (Transmission Control Protocol) describes the three-way handshake as the standard procedure used to establish a connection. Firewalls will typically not allow this process between hosts that are not permitted to communicate with each other. For example, if an attacker sends a packet (with the SYN bit set) to a victim server, the firewall will not relay this packet to the victim because the firewall's rules only allow packets with the SYN bit set to originate from certain hosts. As a result, the three-way handshake will not be completed, and the attacker will not be able to establish a connection with a host behind the firewall. This method of filtering SYN packets is typically the method used by packet-filtering firewalls to prevent certain hosts from "getting past the firewall." - ---How the Attacker Can Bypasses the Firewall--- An attacker is free to set whatever flags he chooses to set on any packet. RFC973 defines the meaning of certain bits, but does not address scenarios in which odd bit combinations are encountered. The method in which the packet is handled is left up to the TCP implementer. As you might imagine, different implementations handle these "odd bit combinations" in a variety of ways. Some implementations are more liberal in what they accept, and choose to treat ANY packet with the SYN bit set (regardless of what other bits are set or unset) as the opening in the three-way handshake. Some implementations are more conservative, and drop packets with unexpected combinations of flags. In the case of a liberal packet-filtering firewall, it may allow a packet to pass if, for example, the FIN bit is set, even if the SYN bit is set. This ambiguity results in a vulnerability in certain conditions. Suppose you have a "liberal" firewall which passes packets if the FIN bit is set, regardless of the value of the SYN bit. Furthermore, suppose you have a "liberal" host that accepts a SYN bit as the opening of the three-way handshake even if the FIN bit is set . An intruder can now send a packet with the SYN and FIN bits set, and establish a connection with the host behind the firewall in violation of the expected behavior. In effect, the firewall says,"I'll let this packet pass because its a FIN packet," but the host says, "I'm going to establish a connection because its a SYN packet." In reality, the meaning of a packet with the SYN and FIN bits set is undefined. Research has shown that multiple TCP implementations will allow a TCP session to be established with hosts located behind the firewall by setting certain combinations of bits in an initial packet. This research indicates the following TCP implementations are "liberal" in what they accept. Linux (2.4.19 Kernel) Solaris 5.8 FreeBSD 4.5 Windows NT 4.0 The researchers go on to indicate that, "Other OSes than those tested above are expected to behave in a similar manner after obtaining such a discouraging result..." Additionally, it appears that many firewalls are unexpectedly liberal in passing packets. We are investigating both aspects of this systemic vulnerability. - ---Impact--- The impact of this vulnerability is that an attacker may be able to establish connections with hosts behind firewalls in violation of implied security policies. As a result, an attacker can send data to hosts and services that he ordinarily cannot reach by exploiting this vulnerability. As an example, consider the following scenario. You want your internal name server to be able to initiate zone transfers with certain hosts external to your network. Depending on what firewall implementation you are using, you might have a rule that looks similar to the following. iptables -A FORWARD -p tcp -s 10.10.10.1/32 --dport 53 -j ACCEPT And, you may have a rule that permits the reply, that looks like this: iptables -a FORWARD -p tcp --sport 53 -d 10.10.10.1/32 ! --syn ACCEPT Because of the ambiguous nature of TCP semantics, *anyone* can attempt *inbound* TCP connections to *any* port on 10.10.10.1 using SYN,RST packets sourced from port 53. Hopefully you do not have other services running on this machine, because now the attacker can connect to any listening services on the host in question. You might also imagine that an intruder could leverage this flaw to exploit a vulnerability in passive software listening promiscuously on the inside of the firewall (e.g. vulnerability in tcpdump <http://www.kb.cert.org/vuls/id/776781> or some similar vulnerability). The specific kinds of packets that may bypass a firewall are highly dependent on the implementation of the firewall. - ---Mitigation Strategies--- Create filtering rules designed to drop and/or reject packets with certain combinations of bits set in initial synchronization packets. Paul Starzetz <paul(a)starzetz.de> (the author of the research) proposes using the following mitigation strategy for systems making use of iptables. Please note that this particular ruleset will only protect you from an attacks using the combination of the SYN & FIN bits. iptables -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j LOG -m limit --limit 10/m --log-level "LOGLEVEL" --log-prefix="bogus packet" iptables -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j DROP Please make sure to include VU#464113 in any feedback you send to us at cert(a)cert.org. This unique, random number will help us track correspondence and coordinate our activities. As always, thanks. Regards, Ian Ian Finlay Internet Systems Security Analyst - CERT/CC Operations Networked Systems Survivability Program =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= CERT (R) Coordination Center Email: cert(a)cert.org Software Engineering Institute WWW: http://www.cert.org Carnegie Mellon University Hotline: +1-412-268-7090 Pittsburgh, PA USA 15213-3890 FAX: +1-412-268-6989 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBPbdDDmjtSoHZUTs5AQHPsAP/T8SR/K8OZ4IT5neq3kxMMF5JFPLrKdmq DgmDZD1QFDvNHd6P9WOZsI8ike70r7y/ACX5Idlt2LIk3IKO48pcHIQ2F0fWl3Z5 gxt03egJLhEtdIwEMz64Jt9HvKEz2rhZiXI8b3cL4aS7PzEfMxYGiOFUJJbmox3M dvhwkv4xANY= =lFt7 -----END PGP SIGNATURE-----

1 0

The power of water
by Sean Donelan 23 Oct '02

23 Oct '02

Stuff happens to everyone, its how you respond. Would your company have been able to recover as quickly? http://media.corporate-ir.net/media_files/nsd/tess/consumermail.html Thanks to folks for pointing this one out.

4 3

RE: WP: Attack On Internet Called Largest Ever
by Greg Pendergrass 23 Oct '02

23 Oct '02

It's universally agreed that the articles have mostly been blown out of proportion and dramatized, but that doesn't mean that attacks against the root servers can't be successful. Future attacks will be stronger and more organized. So how do we protect the root servers from future attack? There has been a lot about what did not happen yesterday, but how about some details about what did happen? Was it a ping flood, syn-flood, smurf, or some combination of types? Were the zombie machines windows, linux, or both? Some of the root servers were affected more than others, why? Was it that there was more ddos traffic directed at them, or that they had less hardware and network resources? - Greg Pendergrass

5 5

Testing root server down code
by Sean Donelan 23 Oct '02

23 Oct '02

The last time all the root servers were down was June 28 1985. On June 29 1985 there was a flurry of messages about adding root server down code to the various DNS implementations of the day. Apparently, some of the software had a poor response to all root servers being unreachable, and spun out of control. Has anyone tested modern DNS code (Microsoft and BIND to name two) for this condition recently? I haven't, hence my question.

5 5

Re: [RE: WP: Attack On Internet Called Largest Ever ]
by Joshua Smith 23 Oct '02

23 Oct '02

"Deepak Jain" <deepak(a)ai.net> wrote: > > > > > http://www.washingtonpost.com/wp-dyn/articles/A828-2002Oct22.html > > > > > > The heart of the Internet sustained its largest and most sophisticated > > > attack ever, starting late Monday, according to officials at key online > > > backbone organizations. > > > > Can someone point out to me where the heart of Internet is? Last time I > > looked, the Internet looked more like a bunch of spiders having an orgy. > > > > You must admit, that if you are into spiders having sex, some of those > pictures are damned sexy. ;) > > DJ > mmmmmmm, spider porn (i smell a brand-new porn market in the works...) "Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence." - Stephen Hawking -

1 0

RADB Unpaid Maintainer Clean-Up status and other news
by Larry J. Blunk 23 Oct '02

23 Oct '02

This past April, Merit announced it's intention to begin removing RADB registry objects due to non-payment of the annual maintainer fee. At this point, the unpaid maintainer clean-up process is considered complete. When the clean-up was announced, there were approximately 3150 maintainers registered in the RADB. With the completion of the clean-up, there are now 1972 active maintainers. The RADB team would now like to move forward with improving the database accuracy. We will be deploying notification and update tools to better assist maintainers in making sure their objects reflect configured routing policy. In other news, Merit RADB staff will again be hosting a helpdesk at next week's NANOG meeting. Staff will be available during breaks on Monday and Tuesday to accept questions/comments regarding the RADB and routing registry issues. Finally, Merit is pleased to announce the 2.1.5 release of the IRRd routing registry daemon software. The release is available at www.irrd.net. For Merit RADB, Larry Blunk

1 0

RE: 601 West 26th Street
by Owens, Shane (EPIK.ORL) 23 Oct '02

23 Oct '02

New York...Sorry. It's been a long day... -----Original Message----- From: Owens, Shane (EPIK.ORL) [mailto:sowens@epik.net] Sent: Wednesday, October 23, 2002 3:23 PM To: nanog(a)nanog.org Subject: 601 West 26th Street Does anyone do any IP business out of this address?? Shane Owens Sr. Manager IP Engineering and Operations EPIK Communications 3501 Quadrangle Blvd Ste 225 Orlando FL 32817 Phone:(407)472-8291 Cell:(321)436-3232 fax:(407)472-8216 sowens(a)epik.net

1 0