NASA hacker jailed for six months

A US man has been jailed for six months for a 2001 attack on the web systems of space agency NASA which cost $200,000 to fix.

Gregory Aaron Herns, 21, from Portland, Oregon, hacked into the network at NASA's Goddard Space Flight Center to store movies he had downloaded. The intrusion caused systems to crash and took technicians hours to fix, according to reports. In court last Friday, Herns admitted his guilt and apologised for the inconvenience he caused.

Cisco to buy Protego Networks for about $65 million in cash

SAN JOSE, Calif. (Dow Jones/AP) -- Cisco Systems Inc. said it will buy privately held Protego Networks Inc. for about $65 million in cash.

Protego, based in Sunnyvale, Calif., provides security monitoring and threat management products.
Computer networking giant Cisco on Monday said the ability of Protego's products to detect, correlate and mitigate threats extends Cisco's Self-Defending Network initiative.
The Self-Defending Network initiative attempts to build security capabilities directly into a computer network.
The acquisition, which is subject to various standard closing conditions, is expected to close in the quarter ending Jan. 29.
Protego and Cisco have worked together to sell security products.
Protego, which has 38 employees, will be integrated into Cisco's Security Technology Group.Shares of San Jose-based Cisco closed Monday at $19.05, up 6 cents, on the Nasdaq Stock Market.

Google: We've fixed desktop search tool flaw

The vulnerability in Google's desktop search application could have compromised users' security.

Google has fixed a flaw that allowed hackers to search the contents of a PC running its desktop search tool.
According to a statement from the Web search company on Monday, it has rolled out a fix for the vulnerability that a US computer scientist and two of his students found in the tool in late November."We were made aware of this vulnerability with the Google Desktop Search software and have since fixed the problem so that all current and future users are secure," said a Google spokeswoman.

Dan Wallach, an assistant professor of computer science at Rice University, discovered the vulnerability while working with graduate students Seth Fogarty and Seth Nielson. Wallach describes it as a composition flaw -- where a security weakness is caused by the interaction of several separate components.
According to The New York Times , which first reported the discovery of the vulnerability, Wallach, Fogarty and Nielson found that the Google desktop tool looks for traffic that appears to be going to Google.com and then inserts results from a user's hard disk for a particular search.

They managed to trick the Google desktop search program into inserting those results into other Web pages where an attacker could read them. This would only work after a user had visited an attacker's Web site, upon which a Java program (as created by the Rice group) would be able to fool the Google desktop software into providing the user's search information. The program was able to do anything with the results, including transmitting them back to the attacking site.

Hotmail moves to Trend Micro for antivirus

The email service, with 187 million users worldwide, is to move away from McAfee to Trend Micro for its antivirus scanning and protection...

MSN's Hotmail service, which has almost 200 million users worldwide, has dumped McAfee as its antivirus partner in favour of rival Trend Micro.

According to Microsoft, emails and attachments sent or received by any of Hotmail's 187 million Web mail customers will from Monday be scanned and cleaned in real time by Trend Micro's antivirus software.Hotmail's antivirus service was previously provided by McAfee and the reason for the change is unclear. However, Martin Hoffman, chief executive of ninemsn, which operates Hotmail in Australia and is half owned by Microsoft, said in a statement that Hotmail will be able to provide a "safer online experience" using Trend Micro's products because they provide "deeper antivirus protection".

Protect BGP sessions with the TCP MD5 option

Since BGP uses TCP as its transport protocol, it is is vulnerable to all weaknesses of the TCP protocol itself. For a determined attacker, it is possible to forcibly close a BGP session or even hijack it and insert mailicious routing information into the BGP data stream.

Running BGP over IPsec would protect it against attacks on the TCP stream, but in practice that configuration is not deployed widely. Instead, the TCP MD5 option described in RFC 2385 is used commonly, as support for this protocol option is available on most BGP implementations.
The idea behind this feature is that to every packet in a TCP session a field is added with the MD5 checksum of the packet contents and a secret key. This establishes a cryptographically secure signature of the packet. Without knowing the key, it is near impossible to construct a packet with a valid signature. Since BGP speakers will immediately discard packets without a signature or with an invalid signature, the types of attacks described above cannot be executed without knowing the key.
The TCP MD5 option is available in most BGP implementations. For Cisco routers, all that is needed is a "neighbor x.x.x.x password mysecret" statement applied to the neighbor or peer-group definition. Juniper JunOS provides the "authentication-key mysecret" statement which can be applied globally at the BGP level, at the group level, or or at the individual neighbor level.
Unfortunately, for the open source Zebra and Quagga routing suites, the situation is more complicated. Since the MD5 checksum is computed at the TCP protocol level, it is a function of the operating system. For example, Linux does not support it natively, although a third-party kernel patch used to be available along with a wrapper library to have Zebra set the appropriate socket options. This is far from trivial to implement, unlike the password and authentication-key options described above.
Another approach to protect the the TCP session used by BGP is the BGP TTL security hack, presented at a recent NANOG meeting by Dave Meyer. These methods only protect the TCP session against attacks but do not protect against hostile BGP information received from the peer. Several other proposed BGP enhancements, such as S-BGP and soBGP address these issues. Unlike the TCP MD5 option described in this article, none of these protocols are widely deployed.

What is IP Routing?

...because of a few next topics, I would rather to explain the meaning of IP Routing for who wants to know about next topics but don't know the meaning of the terms related to those topics.

IP Routing is an umbrella term for the set of protocols that determine the path that data follows in order to travel across multiple networks from its source to its destination. Data is routed from its source to its destination through a series of routers, and across multiple networks. The IP Routing protocols enable routers to build up a forwarding table that correlates final destinations with next hop addresses.These protocols include:

• BGP (Border Gateway Protocol)
• IS-IS Intermediate System - Intermediate System
• OSPF Open Shortest Path First
• RIP Routing Information Protocol.

When an IP packet is to be forwarded, a router uses its forwarding table to determine the next hop for the packet's destination (based on the destination IP address in the IP packet header), and forwards the packet appropriately. The next router then repeats this process using its own forwarding table, and so on until the packet reaches its destination. At each stage, the IP address in the packet header is sufficient information to determine the next hop; no additional protocol headers are required.The Internet, for the purpose of routing, is divided into Autonomous Systems (ASs). An AS is a group of routers that are under the control of a single administration and exchange routing information using a common routing protocol. For example, a corporate intranet or an ISP network can usually be regarded as an individual AS. The Internet can be visualized as a partial mesh of ASs. An AS can be classified as one of the following three types.
A Stub AS has a single connection to one other AS. Any data sent to, or received from, a destination outside the AS must travel over that connection. A small campus network is an example of a stub AS.
A Transit AS has multiple connections to one or more ASs, which permits data that is not destined for a node within that AS to travel through it. An ISP network is an example of a transit AS.
A Multihomed AS also has multiple connections to one or more ASs, but it does not permit data received over one of these connections to be forwarded out of the AS again. In other words, it does not provide a transit service to other ASs. A Multihomed AS is similar to a Stub AS, except that the ingress and egress points for data traveling to or from the AS can be chosen from one of a number of connections, depending on which connection offers the shortest route to the eventual destination. A large enterprise network would normally be a multihomed AS.
An Interior Gateway Protocol (IGP) calculates routes within a single AS. The IGP enables nodes on different networks within an AS to send data to one another. The IGP also enables data to be forwarded across an AS from ingress to egress, when the AS is providing transit services.Routes are distributed between ASs by an Exterior Gateway Protocol (EGP). The EGP enables routers within an AS to choose the best point of egress from the AS for the data they are trying to route.The EGP and the IGPs running within each AS cooperate to route data across the Internet. The EGP determines the ASs that data must cross in order to reach its destination, and the IGP determines the path within each AS that data must follow to get from the point of ingress (or the point of origin) to the point of egress (or the final destination).The diagram below illustrates the different types of AS in a network. OSPF and IS-IS are IGPs used within the individual ASs; BGP is the EGP used between ASs.

Quickly find the announcing AS of an IP address

...with no reason but because of my mind & mood I would like to write about BGP and IP routing related topics which found on the net, today. I'll write more... .

In the course of network operations, one sometimes would like to know which autonomous system (AS) announces a given IP address. One way to do this is by querying the whois server of a routing registry such as RADB or RIPE, and looking for the origin attribute of a route object. However, not all networks properly register their route objects, so the information might not be available or may be outdated.

Another method is by looking at the actual BGP route table for the origin AS of a prefix. You could do this on your own BGP speaking routers or on a public route server with the "show ip bgp" command (or equivalent), or by using one of the public looking glasses on the web. However, this method is cumbersome, especially if you want to quickly look up something or if you have a large number of addresses that you want to analyze with a script.
You can using command line whois client to lookup for AS and Provider :

$ whois -h whois.cymru.com [IP]

If you have a list of IPs, then do the following steps:
1. At First download the GNU netcat from http://netcat.sourceforge.net/download.php
then create your list such this list:
Example of list01:

	begin

	68.22.187.5

	207.229.165.18

	...

	198.6.1.65

	end

you can add comment if you would like:

        begin

	68.22.187.5 Checked on 2004-06-30 05:05:05 GMT

	207.229.165.18 Checked on 2004-06-30 05:05:05 GMT

	...

	198.6.1.65 Checked on 2004-06-30 05:05:05 GMT

	end

2. Finally run the netcat:

  $ netcat whois.cymru.com 43 "<" list01 | sort -n ">" list02

(Remove " in your script)

3. The file list02 will be sorted by origin AS, and should appear as:

Bulk mode; one IP per line. [2004-06-30 15:37:07 GMT]
701 | 198.6.1.65 | UU UUNET Technologies, Inc.
6079 | 207.229.165.18 | RCN RCN Corporation
23028 | 68.22.187.5 | SAUNET SAUNET

4. Take a peek at the list02 file, and remove any RFC1918 or other
unrouted IPs.

Note: A similar service was announced by the RIPE RIS project. Their whois server can be queried using "whois -h riswhois.ripe.net", and returns results in RPSL like format (as used by the RIPE whois database itself). The data is gathered from route collector boxes in various locations. For more information about this service, see this web page.

Multi-homing to a single provider

In practice, the Border Gateway Protocol (BGP) is mainly used by ISP's and enterprises for connecting their autonomous systems (AS) to multiple other ASes, such as upstream providers, peers, and customers. An organization wishing to obtain better connectivity can do so by connecting to more than one upstream provider (multi-homing) and announcing its address space using BGP.

When using more than one connection to the same upstream provider, BGP is a logical choice for the routing protocol, since it supports load balancing and redundancy, and provides a clear separation between responsibilities and administrative domains of the provider and the customer, unlike an IGP would. However, the AS allocation guidelines (described in RFC 1930) preclude the use of a dedicated AS number for an organization connected in that way, since there is no need to exchange routing information with more than one party, i.e., there is no separate routing policy.
RFC 2270 proposes to use a single AS number for all customers multi-homed to the same (single) provider, preferably one of the private AS numbers, 64512 to 65535. In this way, there is no unnecessary use of AS numbers by organizations who do not strictly need them. The customer can use BGP to announce its address space, which will then be announced to the rest of the world by its provider. Despite the non-unique (and possibly private) AS number, one still has the advantages of BGP such as a fine grained control over routing announcements and preferences.The RFC also describes some of the implications of using this scheme, such as the need to announce a default route to the customer AS, effects of changes in connectivity, as well as points regarding aggregation and registering routes in a registry.

83.0.0.0/8 and 84.0.0.0/8 allocated to RIPE by IANA

As of November 14, 2003, the Internet Assigned Numbers Authority (IANA) has allocated the netblocks 83.0.0.0/8 and 84.0.0.0/8 to RIPE NCC, the Regional Internet Registry (RIR) for Europe, the Middle East, Central Asia and Africa.
If you use bogon filters to keep bogon announcements out of your BGP routing table or to drop packets with bogon addresses, please update them to allow these new ranges. Refer to our earlier article for more information about bogons and bogon filters.