- NLNOG - NLNOG

VIRBL
by alex＠bit.nl 04 May '04

04 May '04

Hi Guys, Ik hebben wat bedacht tijdens RIPE-48 (ja, op de eerste dag al!) :) Check dit en shoot: http://virbl.bit.nl/ -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE

6 7

Fwd: Don't forget physical security: Network Card Theft Causes Internet Outage
by tycho＠e-dude.org 03 May '04

03 May '04

Voor degenen die deze nog niet hebben kunnen lezen. ----- Forwarded message from Sean Donelan <sean at donelan.com> ----- Return-Path: <owner-nanog at merit.edu> From: Sean Donelan <sean(a)donelan.com> To: nanog at merit.edu Date: Mon, 3 May 2004 18:02:16 -0400 (EDT) Subject: Don't forget physical security: Network Card Theft Causes Internet Outage Network Card Theft Causes Internet Outage May 3, 2004 By Sean Gallagher A handful of corporate customers were left without e-mail and Internet access Monday after the theft of networking equipment from a New York City office late Sunday. Law enforcement officials said four DS-3 cards were reported missing from a Manhattan co-location facility owned by Verizon Communications Inc. The theft at 240 E. 38th St. occurred just after 10:30 p.m. on Sunday and is being investigated by New York City Police and members of the joint terrorism task force, according to NYPD spokesman Lt. Brian Burke. http://www.eweek.com/article2/0,1759,1583359,00.asp ----- End forwarded message ----- -- Tycho Eggen (Unix|Network|Social) Engineer tycho at e-dude.org +31 6 41 824 855 "Microsoft wins the Internet Disgrace Award of 2003." - Some one commenting about the MS-SQL Slammer worm on Nanog.

1 0

VIRBL
by raymond＠garnierprojects.com 03 May '04

03 May '04

Hallo Alex, Zie dit niet zo zitten, je blacklist zo wel een server waar misschien 1000 Domeinen op draaien. Neem een XS4all als er dus 1 mail via een smtp server van hem komt dan is heel xs4all geblocked? Is het geen beter idee om eens na te denken of we als isp's relayservers op kunnen zetten voor in en uitgaand mail verkeer , zo kan je inkomende en uitgaande spam en virussen voorkomen, als iedereen dat doet dan is het net zo virusvrij. Ofwel alles over port 110 en port 25 eerst door deze cleaners heen sturen. Dit zal een enorme verlaging van verkeer opleveren en ik denk dat zeer veel partijen geinteresseerd zijn om hierin mee te financieren. Dit is een oplossing die ook in lijn ligt met het europeesche idee om isp's meer te betrekken in de anti spam policy. Als je dan vervolgens ip's gaat blocken zie ik het wel als een doelgerichte oplossing. Raymond Garnier -----Original Message----- From: nlnog-bounces at nlnog.net [mailto:nlnog-bounces@nlnog.net] On Behalf Of Teun Vink Sent: Monday, May 03, 2004 9:49 PM To: Alex Bik; nlnog at nlnog.net Subject: Re: [Nlnog] VIRBL On Monday, May 03, 2004 9:37 PM [GMT+1=CET], Alex Bik <alex at bit.nl> wrote: > Hi Guys, > > Ik hebben wat bedacht tijdens RIPE-48 (ja, op de eerste dag al!) :) > > Check dit en shoot: > > http://virbl.bit.nl/ heyhey, Word ik nu geblacklist als ik je een EICAR stuur? ;-) Een andere belangrijke vraag (naast die je al noemt op je site) is denk ik hoe je om wilt gaan met die data: kun je _alle_ mail van iemand weigeren omdat hij geinfecteerd is met een virus? In sommige gevallen wel denk ik gezien de agressieviteit van sommige virussen, maar in andere gevallen is het misschien wat twijfelachtiger. Ik vind het zeker wel een interessant project verder... mocht je data nodig hebben, dan heb ik ook nog wel eea voor je denk ik. groetjes, Teun Vink Luna.nl _______________________________________________ NLNOG mailing list NLNOG at nlnog.net http://mailman.nlnog.net/mailman/listinfo/nlnog ________________________________________________________________________ This email has been scanned for all viruses by the NETHolding Hosting Facilities Amsterdam. For more information on a proactive email security service working around the clock, visit: http://www.netholding.nl ________________________________________________________________________

3 2

VIRBL
by raymond＠garnierprojects.com 03 May '04

03 May '04

Wij zelf gebruiken voor al onze accessklanten Vircom Spamgate, deze maakt gebruik van een online spam database, dus geen RBL. Ook virussen komen er niet door. Scheelt een berg data op de dsl lijntjes. En als de klant zelf een virus heeft of een spam dan wordt die ook meteen geblocked. Dit werkt perfect, er komt max 1% doorheen, en zelfs die staat al snel op de blocker. Neem onze vrienden van de hypotheek reclame, deze is bij ons nog nooit bij de klant aangekomen. grtz Raymond -----Original Message----- From: nlnog-bounces at nlnog.net [mailto:nlnog-bounces@nlnog.net] On Behalf Of Henk Wevers Sent: Monday, May 03, 2004 10:30 PM To: Alex Bik Cc: nlnog at nlnog.net Subject: Re: [Nlnog] VIRBL Zoiets dergelijks draait al op Matt's Mailtoaster voor FreeBSD. http://www.tnpi.biz/internet/mail/toaster/ Je kunt in de config aanzetten of je wilt dat je vpopmail/etc/tcp.smtp wordt aangepast zodat hij de virus senders blockt. Dit is echter alleen zo met qmail-vpopmail. Ik zelf gebruik het niet vanwege de al eerder aangegeven redenen, wie weet block je ineens freebsd.org ofzo(argh) Henk Alex Bik wrote: > Hi Guys, > > Ik hebben wat bedacht tijdens RIPE-48 (ja, op de eerste dag al!) :) > > Check dit en shoot: > > http://virbl.bit.nl/ > _______________________________________________ NLNOG mailing list NLNOG at nlnog.net http://mailman.nlnog.net/mailman/listinfo/nlnog ________________________________________________________________________ This email has been scanned for all viruses by the NETHolding Hosting Facilities Amsterdam. For more information on a proactive email security service working around the clock, visit: http://www.netholding.nl ________________________________________________________________________

1 0

[gjmoed@xenosite.net: [Techniek-l] Ernstig Cisco SNMP exploit]
by sabri＠cluecentral.net 21 Apr '04

21 Apr '04

----- Forwarded message from "G.J. Moed" <gjmoed at xenosite.net> ----- Date: 21 Apr 2004 13:25:49 +0200 From: "G.J. Moed" <gjmoed(a)xenosite.net> To: techniek-l at nlip.nl Subject: [Techniek-l] Ernstig Cisco SNMP exploit X-Mailer: QuickMail Pro 3.0 (Windows32) http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml -- G.J. Moed GM1535-RIPE AS15426 XenoSite _______________________________________________ Techniek-l mailing list techniek-l at nlip.nl http://list2.xs4all.nl/mailman/listinfo/techniek-l-nlip-nl ----- End forwarded message ----- -- Sabri Berisha - SAB666-RIPE BIT BV - http://www.bit.nl/ AS12859 and AS31064 - lg: http://noc.bit.nl/traceroute

1 0

Fwd: US-CERT Technical Cyber Security Alert TA04-111A -- Vulnerabilities in TCP
by tycho＠e-dude.org 21 Apr '04

21 Apr '04

en wat is er nou precies aan de hand? easy-reader :-) ----- Forwarded message from CERT Advisory <cert-advisory at cert.org> ----- Return-Path: <bugtraq-return-14079-tycho=e-dude.org at securityfocus.com> From: CERT Advisory <cert-advisory(a)cert.org> To: cert-advisory at cert.org Date: Tue, 20 Apr 2004 15:33:19 -0400 Subject: US-CERT Technical Cyber Security Alert TA04-111A -- Vulnerabilities in TCP Delivered-To: tycho at e-dude.org Mailing-List: contact bugtraq-help at securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq at securityfocus.com> List-Help: <mailto:bugtraq-help at securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe at securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe at securityfocus.com> Delivered-To: mailing list bugtraq at securityfocus.com Delivered-To: moderator for bugtraq at securityfocus.com Organization: CERT(R) Coordination Center - +1 412-268-7090 List-Owner: <mailto:cert-advisory-owner at cert.org> Technical Cyber Security Alert TA04-111A archive Vulnerabilities in TCP Original release date: April 20, 2004 Last revised: -- Source: US-CERT Systems Affected * Systems that rely on persistent TCP connections, for example routers supporting BGP Overview Most implementations of the Border Gateway Protocol (BGP) rely on the Transmission Control Protocol (TCP) to maintain persistent unauthenticated network sessions. There is a vulnerability in TCP which allows remote attackers to terminate network sessions. Sustained exploitation of this vulnerability could lead to a denial of service condition; in the case of BGP systems, portions of the Internet community may be affected. Routing operations would recover quickly after such attacks ended. I. Description In 2001, the CERT Coordination Center released CA-2001-09, describing statistical weaknesses in various TCP/IP Initial Sequence generators. In that document (<http://www.cert.org/advisories/CA-2001-09.html>), it was noted by Tim Newsham: [I]f a sequence number within the receive window is known, an attacker can inject data into the session stream or terminate the connection. If the ISN value is known and the number of bytes sent already sent is known, an attacker can send a simple packet to inject data or kill the session. If these values are not known exactly, but an attacker can guess a suitable range of values, he can send out a number of packets with different sequence numbers in the range until one is accepted. The attacker need not send a packet for every sequence number, but can send packets with sequence numbers a window-size apart. If the appropriate range of sequence numbers is covered, one of these packets will be accepted. The total number of packets that needs to be sent is then given by the range to be covered divided by the fraction of the window size that is used as an increment. Paul Watson has performed the statistical analysis of this attack when the ISN is not known and has pointed out that such an attack could be viable when specifically taking into account the TCP Window size. He has also created a proof-of-concept tool demonstrating the practicality of the attack. The National Infrastructure Security Co-Ordination Centre (NISCC) has published an advisory summarizing Paul Watson's analysis in "NISCC Vulnerability Advisory 236929," available at <http://www.uniras.gov.uk/vuls/2004/236929/index.htm>. Since TCP is an insecure protocol, it is possible to inject transport-layer packets into sessions between hosts given the right preconditions. The TCP/IP Initial Sequence Number vulnerability (http://www.kb.cert.org/vuls/id/498440) referenced in CA-2001-09 is one example of how an attacker could inject TCP packets into a session. If an attacker were to send a Reset (RST) packet for example, they would cause the TCP session between two endpoints to terminate without any further communication. The Border Gateway Protocol (BGP) is used to exchange routing information for the Internet and is primarily used by Internet Service Providers (ISPs). For detailed information about BGP and some tips for securing it, please see Cisco System's documentation (<http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/bgp.htm> or Team Cymru (<http://www.cymru.com/>). A vulnerable situation arises due to the fact that BGP relies on long-lived persistent TCP sessions with larger window sizes to function. When a BGP session is disrupted, the BGP application restarts and attempts to re-establish a connection to its peers. This may result in a brief loss of service until the fresh routing tables are created. In a TCP session, the endpoints can negotiate a TCP Window size. When this is taken into account, instead of attempting to send a spoofed packet with all potential sequence numbers, the attacker would only need to calculate an valid sequence number that falls within the next expected ISN plus or minus half the window size. Therefore, the larger the TCP Window size, the the larger the range of sequence numbers that will be accepted in the TCP stream. According to Paul Watson's report, with a typical xDSL data connection (80 Kbps, upstream) capable of sending of 250 packets per second (pps) to a session with a TCP Window size of 65,535 bytes, it would be possible to inject a TCP packet approximately every 5 minutes. It would take approximately 15 seconds with a T-1 (1.544 Mbps) connection. These numbers are significant when large numbers of compromised machines (often called "botnets" or "zombies") can be used to generate large amounts of packets that can be directed at a particular host. To protect against such injections, RFC 2385 provides a method of using MD5 signatures on the TCP Headers. If this form of verification is supported and enabled between two peers, then an attacker would have to obtain the key used to transmit the packet in order to successfully inject a packet into the TCP session. Another alternative would be to tunnel BGP over IPSec. Again, this would provide a form of authentication between the BGP peers and the data that they transmit. The lack of authentication when using TCP for BGP makes this type of attack more viable. US-CERT is tracking this issue as VU#415294. This reference number corresponds to CVE candidate CAN-2004-0230. NISCC is tracking this issue as Advisory 236929. II. Impact Sustained exploitation of the TCP injection vulnerability with regard to the BGP vulnerability could lead to a denial-of-service condition that could affect a large segment of the Internet community. Normal operations would most likely resume shortly after the attack stopped. Since the TCP/IP Initial Sequence Number vulnerability (VU#498440) has been proven more viable of an attack, any services or sites that rely on persistent TCP sessions could also be affected by this vulnerability. Impacts could range from data corruption or session hijacking to a denial-of-service condition. III. Solution Apply a patch from your vendor Please see you vendor's statement regarding the availability of patches, updates and mitigation strategies. Workaround Deploy and Use Cryptographically Secure Protocols TCP initial sequence numbers were not designed to provide proof against TCP connection attacks. The lack of cryptographically-strong security options for the TCP header itself is a deficiency that technologies like IPSec try to address. It must be noted that in the final analysis that if an attacker has the ability to see unencrypted TCP traffic generated from a site, that site is vulnerable to various TCP attacks - not just those mentioned here. A stronger measure that would aid in protecting against such TCP attacks is end-to-end cryptographic solutions like those outlined in various IPSec documents. The key idea with an end-to-end cryptographic solution is that there is some secure verification that a given packet belongs in a particular stream. However, the communications layer at which this cryptography is implemented will determine its effectiveness in repelling ISN based attacks. Solutions that operate above the Transport Layer (OSI Layer 4), such as SSL/TLS and SSH1/SSH2, only prevent arbitrary packets from being inserted into a session. They are unable to prevent a connection reset (denial of service) since the connection handling will be done by a lower level protocol (i.e., TCP). On the other hand, Network Layer (OSI Layer 3) cryptographic solutions such as IPSec prevent both arbitrary packets entering a transport-layer stream and connection resets because connection management is directly integrated into the secure Network Layer security model. The solutions presented above have the desirable attribute of not requiring any changes to the TCP protocol or implementations to be made. Some sites may want to investigate hardening the TCP transport layer itself. RFC2385 ("Protection of BGP Sessions via the TCP MD5 Signature Option") and other technologies provide options for adding cryptographic protection within the TCP header at the cost of some potential denial of service, interoperability, and performance issues. Ingress filtering Ingress filtering manages the flow of traffic as it enters a network under your administrative control. You can configure your BGP routers to only accept packets on a specific network connection. Servers are typically the only machines that need to accept inbound connections from the public Internet. In the network usage policy of many sites, there are few reasons for external hosts to initiate inbound connections to machines that provide no public services. Thus, ingress filtering should be performed at the border to prohibit externally initiated inbound connections to non-authorized services. In this fashion, the effectiveness of many intruder scanning techniques can be dramatically reduced. Network Isolation Complex networks can benefit by separating data channels and control channels, such as BGP, into different logical or physical networks. Technologies such as VLANs, VPNs, leased links, NAT may all be able to contribute to separating the tranmission of control information from the transmission of the data stream. Egress filtering Egress filtering manages the flow of traffic as it leaves a network under your administrative control. There is typically limited need for machines providing public services to initiate outbound connections to the Internet. In the case of BGP, only your BGP routers should be establishing connections to your peers. Other BGP traffic generated on your network could be a sign of an attempted attack. Appendix A. Vendor Information For vendor information, please see NISCC Vulnerability Advisory 236929 "Vulnerability Issues in TCP" (http://www.uniras.gov.uk/vuls/2004/236929/index.htm) or Vulnerability Note VU#415294 (http://www.kb.cert.org/vuls/id/415294#systems. As vendors report new information to US-CERT, we will update the vulnerability note. If a particular vendor is not listed in either the NISCC advisory, or the vulnerability, we recommend that you contact them for their comments. _________________________________________________________________ US-CERT thanks Paul Watson, Cisco Systems and NISCC for notifying us about this problem and for helping us to construct this advisory. _________________________________________________________________ Feedback can be directed to the US-CERT Technical Staff. _________________________________________________________________ Copyright 2004 Carnegie Mellon University. Terms of use Revision History April 20, 2004: Initial release Last updated April 20, 2004 ----- End forwarded message ----- -- Tycho Eggen (Unix|Network|Social) Engineer tycho at e-dude.org +31 6 41 824 855 "Never argue with an idiot. They bring you down to their level, then beat you with experience."

1 0

[Fwd: [IDS-Europe] On the TCP RST & BGP issue]
by henk＠wevers.org 20 Apr '04

20 Apr '04

More details Henk -------- Original Message -------- Subject: [IDS-Europe] On the TCP RST & BGP issue Date: Tue, 20 Apr 2004 19:53:22 +0200 From: Arrigo Triulzi <arrigo(a)northsea.sevenseas.org> To: ids-europe at alchemistowl.org Dear all, for those who haven't seen it yet: http://www.uniras.gov.uk/vuls/2004/236929/index.htm The CanSecWest presentation is tomorrow and hopefully I'll be able to report a few details via my contacts there. The big debate is whether or not it is reproducible "in the wild" as opposed to "under lab conditions". Hope this helps, Arrigo _______________________________________________ ids-europe mailing list ids-europe at alchemistowl.org https://ids-europe.alchemistowl.org/mailman/listinfo/ids-europe

1 0

[Fwd: [Fwd: [IDS-Europe] Unauthenticated BGP vulnerability - vendor independent]]
by marcel＠sc-network.nl 18 Apr '04

18 Apr '04

fyi -------- Original Message -------- Subject: [IDS-Europe] Unauthenticated BGP vulnerability - vendor independent Date: Wed, 14 Apr 2004 21:12:31 +0200 From: Arrigo Triulzi <arrigo(a)northsea.sevenseas.org> To: ids-europe at alchemistowl.org Dear all, I don't normally post vulnerability information but this one warrants an exception. There is a DoS, vendor independent, against unauthenticated BGP circulating on the net. Apparently both Cisco TAC and Juniper know about this if asked (I no longer have Cisco TAC access to verify this). The current "best fix" is to enable MD5. Hope this helps, Arrigo _______________________________________________ ids-europe mailing list ids-europe at alchemistowl.org https://ids-europe.alchemistowl.org/mailman/listinfo/ids-europe -- Met vriendelijke groet/With kind regards, Marcel ten Berg Network Engineer Scarlet Telecom B.V.

2 2

nummer trueserver
by marcel＠sc-network.nl 18 Apr '04

18 Apr '04

Hi, does anyone of you have a number of trueserver which is answered now. -- Met vriendelijke groet/With kind regards, Marcel ten Berg Network Engineer Scarlet Telecom B.V.

1 0

Re: MD5 authentication on peering sessions
by otter＠surfnet.nl 15 Apr '04

15 Apr '04

On Thursday, 15 April 2004, Neil J. McRae wrote: > Sorry wrong link, but that one is as valid an issue, can't find the right > link at the moment. > > The issue not a new one. its the same old stuff that other TCP sessions > have had for years and why we run ssh instead of telnet. > > I'd guess that someone has made some progress on those aspects of the > issue and I'd urge everyone to look at MD5. I think this is the one: http://www.nanog.org/mtg-0306/pdf/franz.pdf -- Niels

1 0