0blivion nº4:(0blivion4.txt):15/03/2000 << Back To 0blivion nº 4

_ / / /_ / . . _ _ _ _ _ /_/ /_// / |// /_// /./_// /_/ ===========================_/ Issue #4 - 15/06/2000 Editor - Cyber0ptix Deputer Ed - Slider www.0blivion.org #0blivion on EFnet Contents 0 Introduction to Issue 4 - Cyber0ptix 1 Deputy Editors Rant - Slider 2 Simple Mail Transfer Protocol - Slider 3 POP3 Interactive Session - Cyber0ptix 4 A Look Into Wiretapping - Spyderco Psyops 5 An Introduction to DNS - Cyber0ptix 6 IPv6 - Slider and Lockdown 7 Token Ring Security - Slider 5 Understanding System Daemons - Spyderco Psyops 9 The Months News - Slider and Help-net _____________________________________________________ 0. Introduction to Issue 3 - Cyber0ptix [cyberoptix@0blivion.org] _____________________________________________________ Well another month has passed and we are still here. This is the forth issue that we have released. Hopefully the new site is online now, and you all found it through the old URL. Well first off I would like to thank Vortex at caffeine.org.uk for hosting our new site on his box. Thanks a lot Vortex! Well we have changed the look of the site a lot and are now planning on releasing articles not just aimed at 'the underground' but more at all technical computer users. Well It is now 7.20pm on the 15th and the mag is just about to be uploaded and set out ;) I have got a real bad hangover still after a great night out at Bed lastnight. I can barely remeber getting home, but I know I ended up buying some hash from the taxi driver ;) although I have no idea where it went as I didn;t have any rizzlas left. Well thats it for now, I had best get the issue uploaded and emailed out. Well remember you can always get the latest issue from the website and if you signup to the mailing list (via the website) you will recieve the issues as soon as they are released. _____________________________________________ 1. Deputy Editors Rant - Slider [slider@0blivion.org] _____________________________________________ As you might of noticed we have dumped the use of the exploits section. This is due tosome things beyond my control. If someone wants to do this instead and get there names into Oblivion then give me a shout I will be quite pleased to send you the template, or you can create your own. Anyways, my life is going to pot at the moment. Im going to lose my job soon, because my contract runs out. And then last week my G/f dumped me for anther bloke... heh! Anyways... Oblivion has started to take off quite alot. We are now read by a large number of people and alot of constructive and positive critcism has been coming in! Thank you. You the audience make it what it is. I decided on behalf of the news section i would affiliate with Help Net Security, they now supply me every week with a security letter, which i then in turn compile at the end of the month into a article for Oblivion. This month has slowed down alot, due the fact that i have not been generating articles as much as i should do. But, instead i have been working more towards affiliations and honing my skills to carry on working and living :] As you may of noticed with have a new site, many thanks Cyber for sorting that out. Our IRC chan is also starting to take off, with two - three ppl in there all the time and a few regs :] Heh, were not massive yet! Slidersecurity.co.uk has also had a make over, and i have now just started up a free and fee based comapny with a few mates doing from security work through to web page design :] At the moment we have racked up a few clients, and we are just doing free work until we have a suffcient list of happy clients to start charging. Project Omega can be checked out on http://www.slidersecurity.co.uk/omega we will soon have our own domain. Also, when im here many thanks to all that have supported me in my time of problems earlier this month. We all need friends. Slider. _______________________________________________________ 2. Simple Mail Transfer Protocol - Slider [slider@0blivion.org] _______________________________________________________ A very simple text explaining the basics of SMTP architecture. Electronic mail (e-mail) is probably the most widely used TCP/IP application. The basic Internet mail protocols provide mail (note) and message exchange between TCP/IP hosts; facilities have been added for the transmission of data that cannot be represented as 7-bit ASCII text. There are three standard protocols that apply to mail of this kind. Each is recommended. The term SMTP is frequently used to refer to the combined set of protocols, since they are so closely inter-related, but strictly speaking SMTP is just one of the three. Normally, it is evident from the context which of the three protocols is being referred to. Whenever some doubt might exist, we refer to the STD or RFC numbers to avoid ambiguity. The three standards are: * A standard for exchange of mail between two computers (STD 10/RFC 821), which specifies the protocol used to send mail between TCP/IP hosts. This standard is SMTP itself. * A standard (STD 11) on the format of the mail messages, contained in two RFCs. RFC 822 describes the syntax of mail header fields and defines a set of header fields and their interpretation. RFC 1049 describes how a set of document types other than plain text ASCII can be used in the mail body (the documents themselves are 7-bit ASCII containing imbedded formatting information: PostScript, Scribe, SGML, TEX, TROFF and DVI are all listed in the standard). The official protocol name for this standard is MAIL. * A standard for the routing of mail using the Domain Name System, described in RFC 974. The official protocol name for this standard is DNS-MX. The STD 10/RFC 821 dictates that data sent via SMTP is 7-bit ASCII data, with the high-order bit cleared to zero. This is adequate in most instances for the transmission of English text messages, but is inadequate for non-English text or non-textual data. There are two approaches to overcoming these limitations: * Multipurpose Internet Mail Extensions (MIME), defined in RFCs 2045 to 2049, which specifies a mechanism for encoding text and binary data as 7-bit ASCII within the mail envelope defined by RFC 822. MIME is described in 4.8, * SMTP Service Extensions, which define a mechanism to extend the capabilities of SMTP beyond the limitations imposed by RFC 821. There are three current RFCs that describe SMTP Service Extensions: * A standard for a receiver SMTP to inform a sender SMTP which service extensions it supports (RFC 1869). RFC 1869 modifies RFC 821 to allow a client SMTP agent to request that the server respond with a list of the service extensions that it supports at the start of an SMTP session. If the server SMTP does not support RFC 1869, it will respond with an error and the client can either terminate the session or attempt to start a session according to the rules of RFC 821. If the server does support RFC 1869, it can also respond with a list of the service extensions that it supports. A registry of services is maintained by IANA. The initial list defined in RFC 1869 contains those commands listed in RFC 1123. Other service extensions are defined via RFCs in the usual manner. The next two RFCs define specific extensions: * A protocol for 8-bit text transmission (RFC 1652) that allows an SMTP server to indicate that it can accept data consisting of 8-bit bytes. A server that reports that this extension is available to a client must leave the high order bit of bytes received in an SMTP message unchanged if requested to do so by the client. The MIME and SMTP Service Extension approaches are complementary rather than competing standards. In particular, RFC 1652 is titled SMTP Service Extension for 8-bit-MIMEtransport, since the MIME standard allows messages to be declared as consisting of 8-bit data rather than 7-bit data. Such messages cannot be transmitted by SMTP agents that strictly conform to RFC 821, but can be transmitted when both the client and the server conform to RFCs 1869 and 1652. Whenever a client SMTP attempts to send 8-bit data to a server that does not support this extension, the client SMTP must either encode the message contents into a 7-bit representation compliant with the MIME standard or return a permanent error to the user. This service extension does not permit the sending of arbitrary binary data because RFC 821 defines the maximum length of a line that an SMTP server is required to accept as 1000 characters. Non-text data could easily have sequences of more than 1000 characters without a <CRLF> sequence. Note: The service extension specifically limits the use of non-ASCII characters (those with values above decimal 127) to message bodies. They are not permitted in RFC 822 message headers. * A protocol for message size declaration (RFC 1870) that allows a server to inform a client of the maximum size message it can accept. Without this extension, a client can only be informed that a message has exceeded the maximum size acceptable to the server (either a fixed upper limit or a temporary limit imposed by a lack of available storage space at the server) after transmitting the entire message. When this happens, the server discards the failing message. If both client and server support the Message Size Declaration extension, the client may declare an estimated size of the message to be transferred and the server will return an error if the message is too large. Each of these SMTP Service Extensions is a draft standard protocol and each has a status of elective. - How SMTP Works SMTP (that is, STD 11/RFC 821) is based on end-to-end delivery; an SMTP client will contact the destination host's SMTP server directly to deliver the mail. It will keep the mail item being transmitted until it has been successfully copied to the recipient's SMTP. This is different from the store-and-forward principle that is common in many mailing systems, where the mail item may pass through a number of intermediate hosts in the same network on its way to the destination and where successful transmission from the sender only indicates that the mail item has reached the first intermediate hop. In various implementations, there is a possibility to exchange mail between the TCP/IP SMTP mailing system and the locally used mailing systems. These applications are called mail gateways or mail bridges. Sending mail through a mail gateway can alter the end-to-end delivery specification, since SMTP will only guarantee delivery to the mail-gateway host, not to the real destination host, which is located beyond the TCP/IP network. When a mail gateway is used, the SMTP end-to-end transmission is host-to-gateway, gateway-to-host or gateway-to-gateway; the behavior beyond the gateway is not defined by SMTP. CSNET provides an interesting example of mail gateway service. Started as a low-cost facility to interconnect scientific and corporate research centers, CSNET operates a mail gateway service that allows subscribers to send and receive mail across the Internet using only a dial-up modem. The mail gateway polls the subscribers at regular times, delivers mail that was addressed to them and picks up the outgoing mail. Although this is not a direct end-to-end delivery, it has proven to be a very useful system. Each message has: * A header, or envelope, the structure of which is strictly defined by RFC 822 The mail header is terminated by a null line (that is, a line with nothing preceding the <CRLF> sequence). However, some implementations (for example VM, which does not support zero-length records in files) may interpret this differently and accept a blank line as a terminator. * Contents Everything after the null (or blank) line is the message body which is a sequence of lines containing ASCII characters (that is, characters with a value less than 128 decimal). RFC 821 defines a client/server protocol. As usual, the client SMTP is the one that initiates the session (that is, the sending SMTP) and the server is the one that responds (the receiving SMTP) to the session request. However, since the client SMTP frequently acts as a server for a user mailing program, it is often simpler to refer to the client as the sender SMTP and to the server as the receiver SMTP. * Mail Header Format The user normally doesn't have to worry about the message header, since it is taken care of by SMTP itself. A short reference is included below for completeness. RFC 822 contains a complete lexical analysis of the mail header. The syntax is written in a form known as the augmented Backus-Naur Form (BNF). RFC 822 contains a description of augmented BNF, and many RFCs that are related to RFC 822 use this format. RFC 822 describes how to parse a mail header to a canonical representation, unfolding continuation lines, deleting insignificant spaces, removing comments and so on. The syntax is powerful, but relatively difficult to parse. A basic description is given here, which should be adequate for the reader to interpret the meaning of simple mail headers that he or she encounters. However, this description is too great a simplification to understand the details workings of RFC 822 mailers; for a full description, refer to RFC 822. Briefly, the header is a list of lines, of the form: *field-name: field-value Fields begin in column 1. Lines beginning with white space characters (SPACE or TAB) are continuation lines that are unfolded to create a single line for each field in the canonical representation. Strings enclosed in ASCII quotation marks indicate single tokens within which special characters such as the colon are not significant. Many important field values (such as those for the To and From fields) are mailboxes. The most common forms for these are: octopus@garden.under.the.sea, The Octopus <octopus@garden.under.the.sea>, "The Octopus" <octopus@garden.under.the.sea> The string The Octopus is intended for human recipients and is the name of the mailbox owner. The string octopus@garden.under.the.sea is the machine-readable address of the mailbox. (The angle brackets are used to delimit the address but are not part of it.) One can see that this form of addressing is closely related to the Domain Name System concept. In fact, the client SMTP uses the Domain Name System to determine the IP address of the destination mailbox. Some frequently used fields are: Keyword Value to Primary recipients of the message. cc Secondary (carbon-copy) recipients of the message. from Identity of sender. reply-to The mailbox to which responses are to be sent. This field is added by the originator. return-path Address and route back to the originator. This field is added by the final transport system that delivers the mail. Subject Summary of the message. This is usually provided by the user. - Mail Exchange The SMTP design is based on the model of communication shown below. As a result of a user mail request, the sender SMTP establishes a two-way connection with a receiver SMTP. The receiver SMTP can be either the ultimate destination or an intermediate (mail gateway). The sender SMTP will generate commands that are replied to by the receiver SMTP. USER <-----------> <-----------> USER SENDERS RECIEVERS SMTP <--------> SMTP FILE SYSTEM <---> <---> FILE SYSTEM SMTP Mail Transaction Flow: Although mail commands and replies are rigidly defined. All exchanged commands/replies/data are text lines, delimited by a <CRLF>. All replies have a numeric code at the beginning of the line. 1. The sender SMTP establishes a TCP connection with the destination SMTP and then waits for the server to send a 220 Service ready message or a 421 Service not available message when the destination is temporarily unable to proceed. 2. HELO (HELO is an abbreviation for hello) is sent, to which the receiver will identify himself or herself by sending back its domain name. The sender-SMTP can use this to verify if it contacted the right destination SMTP. If the sender SMTP supports SMTP Service Extensions as defined in RFC 1869, it may substitute an EHLO command in place of the HELO command. A receiver SMTP that does not support service extensions will respond with a 500 Syntax error, command unrecognized message. The sender SMTP should then retry with HELO, or if it cannot transmit the message without one or more service extensions, it should send a QUIT message. If a receiver-SMTP supports service extensions, it responds with a multi-line 250 OK message, which includes a list of service extensions that it supports. 3. The sender now initiates the start of a mail transaction by sending a MAIL command to the receiver. This command contains the reverse-path which can be used to report errors. Note that a path can be more than just the user mailbox@host domain name pair. In addition, it can contain a list of routing hosts. Examples of this are when we pass a mail bridge, or when we provide explicit routing information in the destination address. If accepted, the receiver replies with a 250 OK. 4. The second step of the actual mail exchange consists of providing the server SMTP with the destinations for the message. There can be more than one recipient.) This is done by sending one or more RCPT TO:<forward-path> commands. Each of them will receive a reply 250 OK if the destination is known to the server, or a 550 No such user here if it isn't. 5. When all RCPT commands are sent, the sender issues a DATA command to notify the receiver that the message contents are following. The server replies with 354 Start mail input, end with <CRLF>.<CRLF>. Note the ending sequence that the sender should use to terminate the message data. 6. The client now sends the data line by line, ending with the 5-character sequence <CRLF>.<CRLF> line upon which the receiver acknowledges with a 250 OK or an appropriate error message if anything went wrong. 7. We now have several possible actions: * The sender has no more messages to send. He or she will end the connection with a QUIT command, which will be answered with a 221 Service closing transmission channel reply. * The sender has no more messages to send, but is ready to receive messages (if any) from the other side. He or she will issue the TURN command. The two SMTPs now switch their role of sender/receiver and the sender (previously the receiver) can now send messages by starting with step 3 above. * The sender has another message to send, and simply goes back to step 3 to send a new MAIL command. The SMTP Destination Address (Mailbox Address): Its general form is local-part@domain-name and can take several forms: user@host For a direct destination on the same TCP/IP network. user%remote-host@gateway-host For a user on a non-SMTP destination remote-host, via the mail gateway gateway-host. @host-a,@host-b:user@host-c For a relayed message. This contains explicit routing information. The message will first be delivered to host-a, who will resend (relay) the message to host-b. Host-b will then forward the message to the real destination host-c. Note that the message is stored on each of the intermediate hosts, so we don't have an end-to-end delivery in this case. In the above description, only the most important commands were mentioned. All of them are commands that must be recognized in each SMTP implementation. Other commands exist, but most of those are only optional; that is, the RFC standard does not require them to be implemented everywhere. However, they implement very interesting functions such as relaying, forwarding, mailing lists, etc. - SMTP and the Domain Name System If the network is using the domain concept, an SMTP cannot simply deliver mail sent to TEST.HOTMAIL.COM by opening a TCP connection to TEST.HOTMAIL.COM. It must first query the name server to find out to which host (again a domain name) it should deliver the message. For message delivery, the name server stores resource records (RRs) known as MX RRs. They map a domain name to two values: * A preference value. As multiple MX resource records may exist for the same domain name, a preference (priority) is assigned to them. The lowest preference value corresponds to the most preferred record. This is useful whenever the most preferred host is unreachable; the sending SMTP then tries to contact the next (less preferred) host. * A host name. It is also possible that the name server responds with an empty list of MX RRs. This means that the domain name is in the name server's authority, but has no MX assigned to it. In this case, the sending SMTP may try to establish the connection with the host name itself. - Addressing Mailboxes on Server Systems When a user employs a server system for all mail functions, the mailbox address seen by other SMTP users refers exclusively to the mail server system. For example if two NT systems are named: Slider.ECHO.HOST.COM and SLIDER1.ECHO1.HOST.COM with the first one being used as an UltiMail client and the second as an UltiMail server, the mailbox address might be: SLIDER@Slider.ECHO.HOST.COM This mailbox address would appear in the From: header field of all outgoing mail and in the SMTP commands to remote servers issued by the UltiMail server system. When the user uses a POP server, however, the mailbox address on outbound mail items contains the workstation's hostname. In this case, the sender should include a Reply-To: field in the mail header to indicate that replies should not be sent to the originating mailbox. Using the Domain Name System to Direct Mail: An alternative approach to using the Reply-To: header field is to use the Domain Name System to direct mail to the correct mailbox. The administrator for the domain name server with authority for the domain containing the user's workstation and the name server can add MX resource records to the Domain Name System to direct mail appropriately. ______________________________________________________ 3. POP3 Interactive Session - Cyber0ptix [cyberoptix@0blivion.org] ______________________________________________________ This text is a brief outline of some of the commands that you can use when accessing a POP3 Server via Telnet. POP3 is the standard for remote email collection that most if not all ISP's use except for AOL, but hell they arnt even a real ISP are they. So how do you access the server? Simple, just run a standard telnet client and connect to the mail server on port 110. You will be greeted with a banner something like this. +OK <9529.958822463@mail.DOMAIN.net> So now you need to authenticate yourself before you can use issue any commands to the server. Well you know YOUR username and password don't you? Well the two commands to authenticate yourself with the server are 'USER' and 'PASS'. So here goes USER username <-- Issued by you +OK <-- Response from server PASS xxxxxxx <-- Issued by you +OK <-- Response from server So now you want to see if you have any mail dont you? This is where you will use the 'LIST' command, to show you how many messages are waiting for you on the server. LIST <-- Issued by you +OK <-- Response from server . <-- Response from server Well the response here shows that there is no mail in the account. If there is mail waiting for collection then you would see something like this LIST <-- Issued by you +OK <-- Response from server 1 13456 <-- Response from server 2 4324 <-- Response from server 3 53456 <-- Response from server . <-- Response from server So now there are 3 emails waiting to be read. The first number is the number of the mail and the number following that is the size in kilobytes that the message is. So what else can I do? To read a mail that is stored on the server you can use the 'TOP' command. Simply type, TOP 1 <-- Issued by you This will display message number 1, if you dont want to see all of it, which is usually the case as it will just scroll past, and you wont have time to read it you can specify the number of lines of the message to display with, TOP 1 10 <-- Issued by you This will now display the first 10 lines of the message. I've read my mail how do I delete it? Right, you can delete messages using the 'DELE' DELE 1 <-- Issued by you This will delete message 1 from the server, unfortunately you can only delete mail 1 at a time when you are loged into the server in this fashion. Although it is possible to use a script on a shell somewhere to connect and issue the commands to delete multiple messages. So I've finished what im doing, what next? Well dont just close your telnet client, without issuing the 'QUIT' command as any mail that you have deleted will suddenly undelete itself. And belive me if you have just deleted a lot of mail it will be quite annoying having to type all the commands again to delete them for a second time. Well this is a feature to make sure you actually want to delete it. So when you are finished just type 'QUIT' and the session will end. Well there isn't really a lot you can do, but at least now you know how to check your mail when you arn't on your own computer, without setting up a POP3 client to do it for you. __________________________________________________ 4. A Look Into Wiretapping - Spyderco Psyops [psyops@scientist.com] __________________________________________________ Wiretapping is the traditional term for interception of telephone conversations. This should not be taken too literally. The word is no longer restricted to communications traveling by wire, and contemporary wiretaps are more commonly placed on radio links or inside telephone offices. The meaning has also broadened in that the thing being tapped need no longer be a telephone call in the classic sense; it may be some oher form of electronic communication, such as fax or data. Compared with the more precise but more general phrase "communications interception," the word "wiretapping" has two connotations. Much the stronger of these is that a wiretap is aimed at a particular target, in sharp contrast to the "vacuum cleaner" interception widely practiced by national intelligence agencies. The weaker connotation is that it is being done by the police. The history of wiretapping in the United States is in fact two histories intertwined. It is a history of wiretapping per se--that is, a history of the installation and use of wiretaps by police, intelligence agencies, hones citizens, businesses, and criminals. It is also a history of society's legal response to wiretapping by these various groups. The origins of wiretapping lie in two quiet different practices: eavesdropping and letter opening. "Eavesdropping," although once more restricted in meaning, has come to describe any attempt to overhear conversations without the knowledge of the participants. "Letter opening" takes in all acquisition, opening reading, and copying of written messages, also without knowledge of the sending and receiving parties. Telecommunication has unified and systematized these practices. Before the electronic era, a conversation could only be carried on by people located within earshot of each other, typically a few feet apart. Neither advanced planning nor great effort on the part of the participans was required to ensure a high degree of security. Written communications were more vulnerable, but intercepting one was still a hit-or-miss affair. Messages traveled by a variety of postal services, couriers, travelers, and merchants. Politically sensitive messages, in particular, could not be counted on to go by predictable channels, so special couriers were sometimes employed. And written messages enjoyed another sort of protection. Regardless of a spy's skill with flaps and seals, there was no guarantee that, if a letter was intercepted, opened, and read, the victim would not notice the intrusion. Since spying typically has to be done covertly in order to succeed, the chance of detection is a substantial deterrent. Electronic communication has changed all this in three fundamental ways: it has made telecommunication too convenient to avoid; it has, despite appearances, reduced the diversity of channels by which written messages once traveled; and it has made the act of interception invisible to the target. Conversation by telephone has achieved an almost equal footing with face-to-face conversation. It is impossible today to run a successful business without the telephone, and eccentric even to attempt to do without the telephone in private life. The telephone provides a means of communication so effective and convenient that even people who are aware of the danger of being overheard routinely put aside their caution and use it to convey sensitive information. As the number of channels of communication has increased (there are now hundres of communication companies, with myriad fibers, satellites, and microwave links), the diversity of communication paths has diminished. In the days of oxcart and sail, there was no registry of the thousands of people willing to carry a message in return for a tip from the recipient. Today, telecommunications carriers must be registered with national and local regulatory bodies and are well known to trace associations and industry watch groups. Thus, interception has become more systematic. Spies, no longer faced with a patchwork of ad hoc couriers, know better where to look for what thet seek. Perhaps more important, interception of telecommunications leaves no telltale "marks on the envelop." It is inherent in telecommunication-- and inseparable from its virtues--that the sender and the receiver of a message have no way of telling who else may have recorded a copy. Any discussion of wiretapping, particularly a legal discussion, is complicated by the fact that electronics has not only made interception of telecommunications possible; it has also made it easier to "bug" face-to-face conversations. Bugging would be nearly irrelevant to the central subject of this document--Taking A Deeper Trip Into Wiretapping--were it not for the fact that bugs and wiretaps are inseparably intertwined in law and jurisprudence and named by one collective term: electronic surveillance. Wiretaps and bugs are powerful investigative tools. They allow the eavesdropper to overhear conversations between politicians, criminals, lawyers, or lovers without the targets' knowing that their words are being share with unwanted listeners. Electronic surveillance is a tool that can detect criminal conspiracies and provide prosecutors with strong evidence--the conspirators' incriminating statements in their own voices --all without danger to law-enforcement officers. On the other hand, the very invisibility on which electronic surveillance depends for its effectiveness makes it evasive of oversight and readily adaptable to malign uses. Electronic surveillance can be and has been used by those in power to undermine the democratic process by spying on their political opponents. In light of this, it is not surprising that Congress and the courts have approached wiretapping and bugging with suspicion. Today, communication enjoys a measure of protection under US law, and neither government agents nor private citizens are permitted to wiretap at will. This has not always been the case. The current view--that wiretaps are a kind of search--has evolved by fits and starts over a century and a half. The Supreme Court ruled in 1967 that the police may not employ wiretaps without court authorization. Congress has embraced this principle, limiting police use of wiretaps and setting standards for the granting of warrants. The same laws prohibit most wiretapping by private citizens. The rules against unwarranted wiretapping are not absolute, however. For example, the courts ruled in 1992 (United States vs. David Lee Smith, 978 F. 2nd 171, US App) that conversations over cordless phones were not protected and that police tapping of cordless phones did not require a search warrant. A 1994 statute (Communications Assistance for Law Enforcement Act of 1994, Public Law 103-414, º202) extended the warrant requirements of the earlier law to cover cordless phones. The law also makes some exceptions for businesses intercepting the communications of their own employees on company property. Contact. I don't like to be contacted with subjects like "I think your article sucks," but since you can't make everyone happy, I must learn to live with it. For the ones with a positive attitude, you can e-mail me at psyops@evidence2k.de with all questions security-related. _____________________________________________________ 5. An Introduction to DNS - Cyber0ptix [cyberoptix@0blivion.org] _____________________________________________________ The domain name system is a global network of servers thats primary job is to translate hostnames such as www.0blivion.org or wargame.0blivion.org into IP addresses so that a connection to the server can be made. Without the DNS Servers in place everyone on the internet would need to remember server addresses in their IP format and domain names would be redundant. History of DNS Paul Mockapetris designed DNS in 1984 to solve escalating problems with the old name-to-address mapping system. The old system consisted of a single file, known as the host table, maintained by the Stanford Research Institute's Network Information Center (SRI-NIC). As new host names trickled in, SRI-NIC would add them to the table - a couple times a week. Systems administrators would grab the newest version (via FTP) and update their domain name servers. But as the Net grew, the host table became unwieldy. Though it worked fine for name-to-address mapping, it wasn't the most practical or effective way to update and distribute the information. And since the stability of the rapidly growing Internet was at stake, Mockapetris and some other folks decided to find a better way. Enter DNS. The great thing about the domain name system is that no single organization is responsible for updating it. It's what's known as a distributed database; it exists on many different name servers around the world, with no one server storing all the information. Because of this, DNS allows for almost unlimited growth. The domain name space In order to understand how a DNS server works, you should be familiar with what is called the domain name space. It sounds a little ominous, I know, but really it's quite simple. In fact, you've probably seen it at one time or another represented by an inverted tree that looks something like this: (.root) __________________|_________________ | | | | | | | .com .org .edu .net .gov .mil .arpa _____|_____________ | | oxfam 0blivion __________________|_____________________ | | | | | | | www mail relay irc ftp news wargame Each node on the tree represents a domain. Everything below a node falls into its domain. One domain can be part of another domain. Using this inverted tree it is easy to see how the different levels of domains are named and ordered. First off there are the top level domains such as .com, .org, .net. Under these come the second level domains which is the main part of the domain name that you decide to register. After this there are the third level domains such as www, mail, ftp and these point to various IPs or hostnames on your network. How does it work? A DNS server is just a computer that's running DNS software. Since most servers are Unix machines, the most popular program is BIND (Berkeley Internet Name Domain), but you can find software for the Mac and the PC as well. DNS software is generally made up of two elements: the actual name server, and something called a resolver. The name server responds to browser requests by supplying name-to-address conversions. When it doesn't know the answer, the resolver will ask another name server for the information. When you type in a URL, your browser sends a request to the closest name server. If that server has ever fielded a request for the same host name (within a time period set by the administrator to prevent passing old information), it will locate the information in its cache and reply. If the name server is unfamiliar with the domain name, the resolver will attempt to "solve" the problem by asking a server farther up the tree. If that doesn't work, the second server will ask yet another - until it finds one that knows. (When a server can supply an answer without asking another, it's known as an authoritative server.) Once the information is located, it's passed back to your browser, and you're sent on your merry way. Usually this process occurs quickly, but occasionally it can take an excruciatingly long time (like 15 seconds). In the worst cases, you'll get a dialog box that says the domain name doesn't exist - even though you know damn well it does. This happens because the authoritative server is slow replying to the first, and your computer gets tired of waiting so it times-out (drops the connection). But if you try again, there's a good chance it will work, because the authoritative server has had enough time to reply, and your name server has stored the information in its cache. Different type of Records Domain name servers carry 3 main types of records for a domain. They are known as the following, MX, CNAME and A Type Records. MX or Mail Exchange records are used to specify the mail routing for the domain, to make sure your email gets to the right server. CNAME records are used to point a host at another host, for example ftp.0blivion.org > ftp.hosting.com A Type records on the other hand point the host straight at a IP Address such as wargame.0blivion.org > 196.34.56.24 These are great for when you own the entire network as you know which IP address is related to which server. On the other hand if you are wanting to use a domain you purchased to point at other servers you will be best off using a CNAME records as the network admin will keep their DNS upto date and you will have nothing to worry about. Well that is just a basic intro to how DNS works, hope you all found it interesting and if you have any ideas for articles that you would like to see in the next issue, feel free to email your ideas in. _________________________________ 6. IPv6 - Slider [slider@0blivion.org] - Lockdown [lockdown@hushmail.com] _________________________________ IP Version 6 This text was written jointly by Lockdown and myself. You will see where lockdown added his bits. The Internet is growing extremely rapidly. The latest Internet Domain Survey, conducted in January 1998, counted over 29.5 million hosts in more than 190 countries. The IPv4 addressing scheme, with a 32-bit address field, provides for over 4 billion possible addresses, so it might seem more than adequate to the task of addressing all of the hosts on the Internet, since there appears to be room for a thousand-fold increase before it is completely filled. Unfortunately, this is not the case, for a number of reasons, including the following: * The IP address is divided into a network number and a local part which is administered separately. Although the address space within a network may be very sparsely filled, as far as the effective IP address space is concerned, if a network number has been allocated, then all addresses within that network are unavailable for allocation elsewhere. * The address space for networks is structured into Class A, B and C networks of differing sizes, and the space within each needs to be considered separately. * The IP addressing model requires that unique network numbers be assigned to all IP networks whether or not they are actually connected to the Internet. * It is anticipated that growth of TCP/IP usage into new areas outside the traditional connected PC will shortly result in a rapid explosion of demand for IP addresses. For example, widespread use of TCP/IP for interconnecting hand-held devices, electronic point-of-sale terminals or for Web-enabled television receivers, all devices that are now available, will enormously increase the number of IP hosts. ****lock edit- routing/CIDR/ ************** To support H-R routing and to conserve routing table space, a number of subnets can be combine into one routing entry. See CIDR and Super Subnetting, maybe another .txt. So even though IPV6, solves the immediate problem of a shortage of unique network numbers, it does'nt solve the problem of very large routing tables. IPV6 can be used to create better HR on networks, as there is enough space to encapsulate the whole IPV4 address space into and IPV6 Address. So IPV6 on major backbones may be a distinct advantage when build fast(small) routing tables. ******************************************* These factors mean that the address space is much more constrained than our simple analysis would indicate. This problem is called IP Address Exhaustion. Methods of relieving this problem are already being employed but eventually, the present IP address space will be exhausted. The Internet Engineering Task Force (IETF) set up a working group on Address Lifetime Expectations (ALE) with the express purpose of providing estimates of when exhaustion of the IP will become an intractable problem. Their final estimates (reported in the ALE working group minutes for December 1994) were that the IP address space would be exhausted at some point between 2005 and 2011. Since then the position may have changed somewhat in that the use of CIDR and the increased use of DHCP may have relieved pressure on the address space, but on the other hand, current growth rates are probably exceeding expectation at that time. Apart from address exhaustion, other restrictions in IPv4 also called for the definition of a new IP protocol: 1. Even with the use of CIDR, routing tables, primarily in the IP backbone routers, are growing too large to be manageable. ****Lock Edit**** At major peering points, where the number of routes are large, this can be a very serious problem, even to the point where the routing becomes so instable that no traffic is routed. Hieracle routing is the only way to go. It can't be done with IPV4 on it's own, as the cat is out of the bag concerning, network numbering. I.E. Address are allocated independtly to how the physyical network actually looks. This is problem with flat networks, every network number in use, needs a routing entry, when this grows large, major routing problems can occur. CIDR go someway into sorting the problem, i.e. it's a general rule of thumb the european internet network get's allocated 194/8 or 195/8 addresses space. So, any top level router's just need routing entries for those's network and it can get to europe. IPV6 could solve major routing problems, there is enough address space to for an IP address to start to have meaning, in the hieracle routing scheme. Public Exchange Point Cisco Router 4 Routes | | | | Tier 1 Provider Cisco Router Cisco Router 4000 Routes 4000 Routes | | ISP Cisco Router Cisco router 40000 routes 40000 routes access Layer -----------ADSL/PPP/CM----------- as you can see, the job a routing becomes more simple, as you traverse down the tree, you have relived routing pressure from the backbone device. Breaking down the address space into 'zones' can save lots of headaches. Imagine a internet peering point that only need a handful of routes to access all other peering point on the globe, how easy would is be to manage, and how much cheaper would this be ;-)....no cisco routers with 40mb of routing data to siff through. Remember, the lookup for routing get's done for all packets being routed, even one to the same destination. Hieracle routing only works correctly if IP address are assigned in. 1. Large Blocks (so the can be summrised in routes) 2. Some kind of physical Location (i.e. a block for each country, city, steet??) 3. Break out of IP ownship loop - Break the old fashion method of owning IP address, addresses should be able to be reclaimed if not in use. NAT etc etc makes renumbering easy (not like the dark days!). There a lot of talk at the moment, about MPLS/LSR (label switched routers .txt comming soon). The layer 2 packet has extra information, this allows networking engineer's (hackers) to create traffic flow's thru certain routers on a network (traffic engineering!). I don't like it, as this makes it difficult to create flows between two network out of administrative control (e.g ntl.net and bt.net). By creating HR without LSR, we keep the traffic flow information 'public' so routers can make flow deciedions based on destination/ source IP pairs, not on some mysterous traffic flow label hidden in layer 2. Using a traffic flow identyfier at layer 3 is vital for interprovider traffic engineering and qos. All providers are connected a IP layer 3, not many IP providers are connected to each other directly at layer 2, in fact' I don't know of any providers who do this!!!, it's just too insecure/danerous. You even tried to connect to layer 2 clouds together...nasty...but layer 3 clouds...easy. All the providers are connected at layer 3, they have to because they route IP and this is where flow information should be determined, where it has more fucking meaning. See my point. that's the point of IPV6. LSR add's another layer of routing on the network, basicly you can transmit packets, without an IP header, kinda defeats the object of IP addressing, it makes IP addressing the local form of addressing , not the global....why, the fuck bother....ah, because large mega telco's can start to reclaim some of there power...sinister..because it is. So, who's gonna give me a 15 LSR routers to muck around with? ;-). ****************end edit lock*********** 2. Traffic priority, or class of service, is vaguely defined, scarcely used and not at all enforced in IPv4, but highly desirable for modern real-time applications. In view of these issues, the IETF established an IPng (IP next generation) working group and published RFC 1752 *The Recommendation for the IP Next Generation Protocol. Eventually, the specification for Internet Protocol, Version 6 (IPv6) was produced in RFC 1883. - IPv6 Overview IPv6 offers the following significant features: * A dramatically larger address space, said to be sufficient for the next 30 years * Globally unique and hierarchical addressing, based on prefixes rather than address classes, to keep routing tables small and backbone routing efficient * A mechanism for the autoconfiguration of network interfaces * Support for encapsulation of itself and other protocols * Class of service to distinguish types of data * Improved multicast routing support (in preference to broadcasting) * Built-in authentication and encryption * Transition methods to migrate from IPv4 * Compatibility methods to coexist and communicate with IPv4 Note: IPv6 uses the term packet rather than datagram. The meaning is the same, although the formats are different. IPv6 uses the term 'node' for any system running IPv6, that is, a host or a router. An IPv6 host is a node that does not forward IPv6 packets that are not explicitly addressed to it. A router is a node that does forward IP packets not addressed to it. - The IPv6 Header Format The format of the IPv6 packet header has been simplified from its counterpart in IPv4. The length of the IPv6 header is increased to 40 bytes (from 20 bytes), and contains two 16-byte addresses (source and destination) preceded by 8 bytes of control information. The IPv4 header has two 4-byte addresses preceded by 12 bytes of control information and possibly followed by option data. The reduction of the control information and the elimination of options in the header for most IP packets are intended to optimize the processing time per packet in a router. The infrequently used fields that have been removed from the header are moved to optional extension headers when they are required. - Hop Limit This is the IPv4 TTL field but now it is measured in hops and not seconds. It was changed for two reasons: * IP normally forwards datagrams at faster than one hop per second and the TTL field is always decremented on each hop, so in practice it is measured in hops and not seconds. * Many IP implementations do not expire outstanding datagrams on the basis of elapsed time. The packet is discarded once the hop limit is decremented to zero. - Identification, Fragmentation Flags and Fragment Offset Fragmented packets have an extension header rather than fragmentation information in the IPv6 header. This reduces the size of the basic IPv6 header. Since higher level protocols, particularly TCP, tend to avoid fragmentation of datagrams, this reduces the IPv6 header overhead for the normal case. As noted below, IPv6 does not fragment packets en route to their destinations, only at the source. - Header Checksum Because transport protocols implement checksums, and because IPv6 includes an optional authentication header that can also be used to ensure integrity, IPv6 does not provide checksum monitoring of IP packets. Both TCP and UDP include a pseudo IP header in the checksums they use, so in these cases, the IP header in IPv4 is being checked twice. TCP and UDP, and any other protocols using the same checksum mechanisms running over IPv6 will continue to use a pseudo IP header although, obviously, the format of the pseudo IPv6 header will be different from the pseudo IPv4 header. ICMP and IGMP and any other protocols that do not use a pseudo IP header over IPv4 will use a pseudo IPv6 header in their checksums. - Options All optional values associated with IPv6 packets are contained in extension headers ensuring that the basic IP header is always the same size. - Packet Sizes All IPv6 nodes are expected to dynamically determine the maximum transmission unit (MTU) supported by all links along a path and source nodes will only send packets that do not exceed the Path MTU. IPv6 routers will therefore not have to fragment packets in the middle of multihop routes and allow much more efficient use of paths that traverse diverse physical transmission media. IPv6 requires that every link supports an MTU of 576 bytes or greater. - Extension Headers Every IPv6 packet starts with the basic header. In most cases this will be the only header necessary to deliver the packet. Sometimes, however, it is necessary for additional information to be conveyed along with the packet to the destination or to intermediate systems on route (information that would previously have been carried in the Options field in an IPv4 datagram). Extension headers are used for this purpose. Extension headers are placed immediately after the IPv6 basic packet header and are counted as part of the payload length. Each extension header (with the exception of 59) has its own 8-bit Next Header field as the first byte of the header that identifies the type of the following header. This structure allows IPv6 to chain multiple extension headers together. The length of each header varies, depending on type, but is always a multiple of 8 bytes. There are a limited number of IPv6 extension headers, any one of which may be present once only in the IPv6 packet (with the exception of the Destination Options Header - 60, which may appear more than once). IPv6 nodes that originate packets are required to place extension headers in a specific order (numeric order with exception of 60), although IPv6 nodes that receive packets are not required to verify that this is the case. The order is important for efficient processing at intermediate routers. Routers will generally only be interested in the hop-by-hop options and the routing header. Once the router has read this far, it does not need to read further in the packet and can forward immediately. When the Next Header field contains a value other than one for an extension header, this indicates the end of the IPv6 headers and the start of the higher level protocol data. IPv6 allows for encapsulation of IPv6 within IPv6 (*tunneling*). This is done with a Next Header value of 41 (IPv6). The encapsulated IPv6 packet may have its own extension headers. Because the size of a packet is calculated by the originating node to match the path MTU, IPv6 routers should not add extension headers to a packet but instead should encapsulate the received packet within an IPv6 packet of their own making (which may be fragmented if necessary). With the exception of the Hop-by-Hop header (which must immediately follow the IP header if present) and sometimes the Destination Options header, extension headers are not processed by any router on the packet's path except the final one. - Hop-by-Hop Header A Hop-by-Hop header contains options that must be examined by every node the packet traverses as well as the destination node. It must immediately follow the IPv6 header if present and is identified by the special value 0 in the Next Header field of the IPv6 basic header. (This value is not actually a protocol number but a special case to identify this unique type of extension header). Hop-by-hop headers contain variable length options of the following format (commonly known as the Type-Length-Value (TLV) format). - Routing Header The path that a packet takes through the network is normally determined by the network itself. Sometimes, however, the source may wish to have more control over the route taken by the packet. It may wish, for example, for certain data to take a slower, but more secure route than would normally be taken. The routing header allows a path through the network to be predefined. The routing header is identified by the value 43 in the preceding Next Header field. It has its next header field as the first byte and a single byte routing type as the second. The only type defined initially is type 0 - Strict/Loose Source Routing, which operates in a similar way to source routing in IPv4. The first hop on the required path of the packet is indicated by the destination address in the basic header of the packet. When the packet arrives at this address, the router swaps the next address from the router extension header with the destination address in the basic header. The router also decrements the addresses left field by one, then forwards the packet. - Authentication Header The authentication header is used to ensure that a received packet has not been altered in transit and that it really came from the claimed sender. The authentication header is identified by the value 51 in the preceding Next Header field. - Encapsulating Security Payload The Encapsulated Security Payload (ESP) is a special extension header, in that it can appear anywhere in a packet between the basic header and the upper layer protocol. All data following the ESP header is encrypted. - Destination Options Header This has the same format as the Hop-by-Hop header, but it is only examined by the destination node(s). Normally the destination options are only intended for the final destination only and the destination options header will be immediately before the upper layer header. However, destination options can also be intended for intermediate nodes, in which case they must precede a routing header. A single packet may therefore include two destination options headers. Currently, only the Pad1 and PadN types of options are specified for this header. The value for the preceding Next Header field is 60. - IPv6 Addressing The IPv6 address model is specified in RFC 2373 * IP Version 6 Addressing Architecture. IPv6 uses a 128-bit address instead of the 32-bit address of IPv4. That theoretically allows for as many as 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses. Even when used with the same efficiency as today's IPv4 address space, that would still allow for 50,000 addresses per square meter of land on Earth. IPv6 addresses are represented in the form of eight hexadecimal numbers divided by colons, for example: FE8≡:≡≡≡≡:≡≡≡≡:≡≡≡≡:≡≡≡1:≡8≡≡:23e7:f5db To shorten the notation of addresses, leading zeroes in any of the groups can be omitted, for example: FE8≡:≡:≡:≡:1:8≡≡:23e7:f5db Finally, a group of all zeroes, or consecutive groups of all zeroes, can be substituted by a double colon, for example: FE8≡::1:8≡≡:23e7:f5db Note: The double colon shortcut can be 0sed only once in the notation of an IPv6 address. If there are more groups of all zeroes that are not consecutive, only one may be substituted by the double colon; the others would have to be noted as 0. The IPv6 address space is organized using format prefixes, similar to telephone country and area codes, that logically divide it in the form of a tree so that a route from one network to another can easily be found. - Unicast Address A unicast address is an identifier assigned to a single interface. Packets sent to that address will only be delivered to that interface. Special purpose unicast addresses are defined as follows: Loopback address (::1) This address is assigned to a virtual interface over which a host can send packets only to itself. It is equivalent to the IPv4 loopback address 127.0.0.1. Unspecified address (::) This address is used as a source address by hosts while performing autoconfiguration. It is equivalent to the IPv4 unspecified address 0.0.0.0. IPv4-compatible address (::<IPv4_address>) Addresses of this kind are used when IPv6 traffic needs to be tunneled across existing IPv4 networks. The endpoint of such tunnels can be either hosts (automatic tunneling) or routers (configured tunneling). IPv4-compatible addresses are formed by placing 96 bits of zero in front of a valid 32-bit IPv4 address. For example, the address 1.2.3.4 (hex 01.02.03.04) becomes ::0102:0304 IPv4-mapped address (::FFFF:<IPv4_address>) Addresses of this kind are used when an IPv6 host needs to communicate with an IPv4 host. This requires a dual stack host or router for header translations. For example, if an IPv6 node wishes to send data to host with an IPv4 address of 1.2.3.4, it uses a destination address of ::FFFF:0102:0304. Link-local address Addresses of this kind can be used only on the physical network that a host's interface is attached to. Site-local address Addresses of this kind cannot be routed into the Internet. They are the equivalent of IPv4 networks for private use (10.0.0.0, 176.16.0.0-176.31.0.0, 192.168.0.0-192.168.255.0). - Global Unicast Address Format The Global Unicast address format, as specified in RFC 2374 * An IPv6 Aggregatable Global Unicast Address Format is expected to become the predominant format used for IPv6 nodes connected to the Internet. The aggregatable address can be split into three sections that relate to the three-level hierarchy of the Internet, namely: Public Topology Providers and exchanges that provide public Internet transit services. Site Topology Local to an organization that does not provide public transit service to nodes outside of the site. Interface Identifiers Identify interfaces on links. - Multicast Address A multicast address is an identifier assigned to a set of interfaces on multiple hosts. Packets sent to that address will be delivered to all interfaces corresponding to that address. - Anycast Address An anycast address is a special type of unicast address that is assigned to interfaces on multiple hosts. Packets sent to such an address will be delivered to the nearest interface with that address. Routers determine the nearest interface based upon their definition of distance, for example hops in case of RIP or link state in case of OSPF. Anycast addresses use the same format as unicast addresses and are undistinguishable from them. However, a node that has been assigned an anycast address must be configured to be aware of this fact. RFC 2373 currently specifies the following restrictions on anycast addresses: * An anycast address must not be used as the source address of a packet. * Any anycast address may only be assigned to a router A special anycast address, the subnet-router address, is predefined. This address consists of the subnet prefix for a particular subnet followed by trailing zeroes. This address may be used when a node needs to contact a router on a particular subnet and it does not matter which router is reached (for example, when a mobile node needs to communicate with one of the mobile agents on its *home* subnet). - Priority The 4-bit priority field allows applications to specify a certain priority for the traffic they generate thus introducing the concept of Class of Service. IPv4-based routers normally treat all traffic equal, whereas IPv6-based routers now must act on such prioritized packets in the following way: 1. For priorities 0 to 7, start dropping packets when the network becomes congested (congestion-controlled). 2. For priorities 8 to 15, try to forward packets even when the network is becoming congested by dropping packets with lower priority (noncongestion-controlled). Real-time applications would opt for this range of priority. - Flow Labels IPv6 introduces the concept of a flow, which is a series of related packets from a source to a destination that requires a particular type of handling by the intervening routers, for example real-time service. The nature of that handling can either be conveyed by options attached to the datagrams (that is, by using the IPv6 Hop-by-Hop options header) or by a separate protocol (such as resource reservation protocol. The handling requirement for a particular flow label is known as the state information; this is cached at the router. When packets with a known flow label arrive at the router, the router can efficiently decide how to route and forward the packets without having to examine the rest of the header for each packet. There may be multiple active flows between a source and a destination, as well as traffic that is not associated with any flow. Each flow is distinctly labelled by the 24-bit flow label field in the IPv6 packet. Now the big question, how is this all going to work? - Internet Transition - Migrating from IPv4 to IPv6 If the Internet is to realize the benefits of IPv6, then a period of transition will be necessary when new IPv6 hosts and routers will need to be deployed alongside existing IPv4 systems. Routing Aspects of IPv6 Transition define a number of mechanisms to be employed to ensure both compatibility between old and new systems and a gradual transition that does not impact the functionality of the Internet. These techniques are sometimes collectively termed Simple Internet Transition (SIT). The transition employs the following techniques: * Dual-stack IP implementations for hosts and routers that must interoperate between IPv4 and IPv6. * Imbedding of IPv4 addresses in IPv6 addresses. IPv6 hosts will be assigned addresses that are interoperable with IPv4, and IPv4 host addresses will be mapped to IPv6. * IPv6-over-IPv4 tunneling mechanisms for carrying IPv6 packets across IPv4 router networks. * IPv4/IPv6 header translation. This technique is intended for use when implementation of IPv6 is well advanced and only a few IPv4-only systems remain. The techniques are also adaptable to other protocols, notably Novell IPX, which has similar internetwork layer semantics and an addressing scheme which can be mapped easily to a part of the IPv6 address space. - Dual IP Stack Implementation - The IPv6/IPv4 Node The simplest way to ensure that a new IPv6 node maintains compatibility with existing IPv4 systems is to provide a dual IP stack implementation. An IPv6/IPv4 node can send and receive either IPv6 packets or IPv4 datagrams, depending on the type of system with which it is communicating. The node will have both a 128-bit IPv6 address and a 32-bit IPv4 address, which do not necessarily need to be related. The IPv6/IPv4 node may use stateless or stateful autoconfiguration to obtain its IPv6 address. It may also use any method to obtain its IPv4 address, such as DHCP, BOOTP or manual configuration. However, if the node is to perform automatic tunneling, then the IPv6 address must be an IPv4-compatible address, with the low order 32-bits of the address serving as the IPv4 address. Conceptually, the dual stack model envisages a doubling-up of the protocols in the internetwork layer only. However, related changes are obviously needed in all transport-layer protocols to operate using either stack, and possibly in applications if they are to exploit IPv6 capabilities, such as longer addresses. When an IPv6/IPv4 node wishes to communicate with another system, it needs to know the capabilities of that system and which type of packet it should send. The DNS plays a key role here. A new resource record type, AAAA, is defined for mapping hostnames to IPv6 addresses. The results of a name server lookup determine how a node will attempt to communicate with that system. The records found in the DNS for a node depend on which protocols it is running. * IPv4-only nodes have only A records containing IPv4 addresses in the DNS. * IPv6/IPv4 nodes that can interoperate with IPv4-only nodes have AAAA records containing IPv4-compatible IPv6 addresses and A records containing the equivalent IPv4 addresses. * IPv6-only nodes that cannot interoperate with IPv4-only nodes have only AAAA records containing IPv6 addresses. Because IPv6/IPv4 nodes make decisions about which protocols to use based on the information returned by the DNS, the incorporation of AAAA records in the DNS is a prerequisite to interoperability between IPv6 and IPv4 systems. Note that name servers do not necessarily need to use an IPv6-capable protocol stack, but they must support the additional record type. - Tunneling When IPv6 or IPv6/IPv4 systems are separated from other similar systems, with which they wish to communicate, by older IPv4 networks, then IPv6 packets must be tunneled through the IPv4 network. IPv6 packets are tunnelled over IPv4 very simply; the IPv6 packet is encapsulated in an IPv4 datagram, or in other words, a complete IPv4 header is added to the IPv6 packet. The presence of the IPv6 packet within the IPv4 datagram is indicated by a Protocol value of 41 in the IPv4 header. There are two kinds of tunneling of IPv6 packets over IPv4 networks: automatic and configured. - Automatic Tunneling Automatic tunneling relies on IPv4-compatible addresses. The decision on when to tunnel is made by an IPv6/IPv4 host that has a packet to send across an IPv4-routed network area, and it follows the following rules: * If the destination is an IPv4 or an IPv4-mapped address, send the packet using IPv4 because the recipient is not IPv6-capable. Otherwise: * If the destination is on the same subnet, send it using IPv6 because the recipient is IPv6-capable. * If the destination is not on the same subnet but there is at least one default router on the subnet that is IPv6-capable, or there is a route configured to an IPv6 router for that destination, then send it to that router using IPv6. Otherwise: * If the address is an IPv4-compatible address, send the packet using automatic IPv6-over-IPv4 tunneling. Otherwise: * The destination is a node with an IPv6-only address that is connected via an IPv4-routed area, which is not also IPv6-routed. Therefore, the destination is unreachable. The rules listed above emphasize the use of an IPv6 router in preference to a tunnel for three reasons: * There is less overhead because there is no encapsulating IPv4 header. * IPv6-only features are available. * The IPv6 routing topology will be used when it is deployed in preference to the pre-existing IPv4 topology. A node does not need to know whether it is attached to an IPv6-routed or an IPv4-routed area; it will always use an IPv6 router if one is configured on its subnet and will use tunneling if one is not (in which case it can infer that it is attached to an IPv4-routed area). Automatic tunneling may be either host-to-host, or it may be router-to-host. A source host will send an IPv6 packet to an IPv6 router if possible, but that router may not be able to do the same, and will have to perform automatic tunneling to the destination host itself. Because of the preference for the use of IPv6 routers rather than tunneling, the tunnel will always be as *short* as possible. However, the tunnel will always extend all of the way to the destination host; because IPv6 uses the same hop-by-hop routing paradigm, a host cannot determine if the packet will eventually emerge into an IPv6-complete area before it reaches the destination host. In order to use a tunnel that does not extend all of the way to the recipient, configured tunneling must be used. The mechanism used for automatic tunneling is very simple. * The encapsulating IPv4 datagram uses the low-order 32 bits of the IPv6 source and destination addresses to create the equivalent IPv4 addresses and sets the protocol number to 41 (IPv6). * The receiving node's network interface layer identifies the incoming packets (or packets if the IPv4 datagram was fragmented) as belonging to IPv4 and passes them upwards to the IPv4 part of the dual IPv6/IPv4 internetwork layer. * The IPv4 layer then receives the datagram in the normal way, re-assembling fragments if necessary, notes the protocol number of 41, then removes the IPv4 header and passes the original IPv6 packet *sideways* to the IPv6 part of the internetwork layer. * The IPv6 code then processes the original packet as normal. Since the destination IPv6 address in the packet is the IPv6 address of the node (an IPv4-compatible address matching the IPv4 address used in the encapsulating IPv4 datagram) the packet is at its final destination. IPv6 then processes any extension headers as normal and then passes the packet's remaining payload to the next protocol listed in the last IPv6 header. A theroy of two IPv6/IPv4 nodes separated by an IPv4 network. Both workstations have IPv4-compatible IPv6 addresses. Workstation A sends a packet to workstation B, as follows: 1. Workstation A has received router solicitation messages from an IPv6-capable router (X) on its local link. It forwards the packet to this router. 2. Router X adds an IPv4 header to the packet, using IPv4 source and destination addresses derived from the IPv4-compatible addresses. The packet is then forwarded across the IPv4 network, all the way to workstation B. This is router-to-host automatic tunneling. 3. The IPv4 datagram is received by the IPv4 stack of workstation B. As the Protocol field shows that the next header is 41 (IPv6), the IPv4 header is stripped from the datagram and the remaining IPv6 packet is then handled by the IPv6 stack. Workstation B responds as follows: 1. Workstation B has no IPv6-capable router on its local link. It therefore adds an IPv4 header to its own IPv6 frame and forwards the resulting IPv4 datagram directly to the IPv4 address of workstation A via the IPv4 network. This is host-to-host automatic tunneling. 2. The IPv4 datagram is received by the IPv4 stack of workstation A. As the Protocol field shows that the next header is 41 (IPv6), the IPv4 header is stripped from the datagram and the remaining IPv6 packet is then handled by the IPv6 stack. - Configured Tunneling Configured tunneling is used for host-router or router-router tunneling of IPv6-over-IPv4. The sending host or the forwarding router is configured so that the route, as well as having a next hop, also has a tunnel end address (which is always an IPv4-compatible address). The process of encapsulation is the same as for automatic tunneling except that the IPv4 destination address is not derived from the low-order 32 bits of the IPv6 destination address, but from the low-order 32 bits of the tunnel end. The IPv6 destination and source addresses do not need to be IPv4-compatible addresses in this case. When the router at the end of the tunnel receives the IPv4 datagram, it processes it in exactly the same way as a node at the end of an automatic tunnel. When the original IPv6 packet is passed to the IPv6 layer in the router, it recognizes that it is not the destination, and the router forwards the packet on to the final destination as it would for any other IPv6 packet. It is, of course, possible that after emerging from the tunnel, the IPv6 packet is tunnelled again by another router. Another theory of two IPv6-only nodes separated by an IPv4 network. A router-to-router tunnel is configured between the two IPv6/IPv4 routers X and Y. 1. Workstation A constructs an IPv6 packet to send to workstation B. It forwards the packet to the IPv6 router advertising on its local link (X). 2. Router X receives the packet, but has no direct IPv6 connection to the destination subnet. However, a tunnel has been configured for this subnet. The router therefore adds an IPv4 header to the packet, with a destination address of the tunnel-end (router Y) and forwards the datagram over the IPv4 network. 3. The IPv4 stack of router Y receives the frame. Seeing the Protocol field value of 41, it removes the IPv4 header, and passes the remaining IPv6 packet to its IPv6 stack. The IPv6 stack reads the destination IPv6 address, and forwards the packet. 4. Workstation B receives the IP6 packet. - Header Translation Installing IPv6/IPv4 nodes allows for backward compatibility with existing IPv4 systems. However, when migration of networks to IPv6 reaches an advanced stage, it is likely that new systems being installed will be IPv6 only. There will therefore be a requirement for IPv6-only systems to communicate with the remaining IPv4-only systems. Header translation is required for IPv6-only nodes to interoperate with IPv4-only nodes. Header translation is performed by IPv6/IPv4 routers on the boundaries between IPv6 routed areas and IPv4 routed areas. The translating router strips the header completely from IPv6 packets and replaces it with an equivalent IPv4 header (or the reverse). In addition to correctly mapping between the fields in the two headers, the router must convert source and destination addresses from IPv4-mapped addresses to real IPv4 addresses (by taking the low-order 32 bits of the IP address). In the reverse direction, the router adds the ::FFFF /96 prefix to the IPv4 address to form the IPv4-mapped address. If either the source or the destination IPv6 address is IPv6 only, the header cannot be translated. Note that for a site with even just one IPv4 host, every IPv6 node with which it needs to communicate must have an IPv4-mapped address. - Interoperability Summary Whether two nodes can interoperate depends upon their capabilities and their addresses. An IPv4 node can communicate with: * Any IPv4 node on the local link * Any IPv4 node via an IPv4 router * Any IPv6 node with IPv4-mapped address via a header translator An IPv6 node (IPv6-only address) can communicate with: * Any IPv6 node on the local link * Any IPv6 node via an IPv6 router on the local link (may require tunneling through IPv4 network from the router) An IPv6 node (IPv4-mapped address) can communicate with: * Any IPv6 node on the local link * Any IPv6 node via an IPv6 router on the local link (may require tunneling through IPv4 network from the router) * Any IPv4 node via a header translator An IPv6/IPv4 node (IPv4-compatible address) can communicate with: * Any IPv4 node on the local link * Any IPv4 node via an IPv4 router on the local link * Any IPv6 node on the local link * Any IPv6 node via an IPv6 router on the local link (may require tunneling through IPv4 network from the router) * Any IPv6/IPv4 node (IPv4-compatible address) via host-to-host tunnel - The Drive Towards IPv6 The drivers for the introduction of IPv6 networks are likely to be requirements for new facilities that require IPv6, or exhaustion of the IPv4 address space. Which of these is seen as more important will vary between organizations. For example, commercial organizations with large, long-established internal IPv4 networks are unlikely to be keen to upgrade thousands of working IPv4 hosts and routers, unless they have a problem with the address space within their own networks. They will, however, be likely to invest in IPv6 deployment if new business-critical applications require facilities that are only available on IPv6 or if they require connectivity to other organizations that are using IPv6-only addresses. Businesses that are implementing IP networks for the first time, however, may be interested in some of the capabilities of IPv6, such as the address autoconfiguration. However, anyone thinking of implementing IPv6 today needs to be aware that the protocol is still, as of today, very much under development. It may be said that IPv4 is also still under development, as new RFCs and Internet drafts are constantly being produced, but for IPv6, certain key protocols, such as DHCP, at time of writing are still at Internet draft stage only. The Internet backbone today consists of IPv4 routers and, until such time as the IPv6 protocols have been widely used and tested, the owners of these production routers are unlikely to put them at risk by upgrading them to IPv6. One off-shoot of the IETF IPng (next generation) project was the development of the 6Bone, which is an Internet-wide IPv6 virtual network, layered on top of the physical IPv4 Internet. The 6Bone consists of many islands supporting IPv6 packets, linked by tunnels across the existing IPv4 backbone. The 6Bone is widely used for testing of IPv6 protocols and products. It is expected that, as confidence grows in IPv6 and more products with IPv6 capability become available, the 6Bone will eventually be replaced by a production backbone of ISP and user network IPv6 capable routers. Another way that might combat the lack of IP's is the use of IP masquerading, this is very a very "dirty" way of correcting a problem of this kind. - IP Masquerading **** lock edit aka NAT/PAT One way to combat an IP address shortage is to avoid assigning addresses in the first place. Yet without an IP address, no system can communicate on a TCP/IP network. IP masquerading allows you to effectively share one IP address among several different systems while still providing reliable, full function TCP/IP connections to every host. This technique can be used to provide Internet service to more than one computer using a single dial-up connection from an Internet Service Provider (ISP) for example. Or, you may wish to link branch office systems to your company's network without assigning IP addresses from your company's main address pool. In practice, an IP address is assigned to each host that needs to communicate on the TCP/IP network, but the addresses are from a private network pool, such as the Class A network 10. A masquerading gateway accepts connection requests from these private hosts and translates them into requests originating from the IP address of the gateway itself. Responses from the TCP/IP network are then routed by the gateway back to the correct host on the private network. As a result, a single IP address on a network can effectively serve several different hosts without requiring additional IP address assignments on that same network. There are currently no RFCs or IETF drafts that cover IP masquerading. However, IP masquerading is implemented in certain routers and is available for several software platforms. So, thats generally a run down on IPV6, I might if i have time in the following months write a few texts on DHCP and DNS using the IPV6 protocol. Slider. Werd - To all that know me Fuqs - To all that hate me Thanks - Dave J, for allowing me use of his router and workstations and subnet setup. _____________________________________________ 7. Token Ring Networks - Slider [slider@0blivion.org] _____________________________________________ The IBM Token Ring network is a general purpose Local Area Network (LAN) with a star-wired ring topology, using baseband signalling and token-passing protocols conforming with IEEE 802.5 standards. Device attachments conforming with IEEE 802.2 and 802.5 standards may communicate over an IBM Token Ring network. The token-passing protocol for ring access control is based on a predefined 24-bit pattern, called a token, which continuously circulates around the ring. When a station has data to transmit, it waits until its station adapter receives a free token (token bit=0). Upon capturing the free token, the station creates a frame by setting the token bit to 1. It then inserts source and destination addresses, certain control information and the data to be sent to the destination station, and starts frame transmission. During the time the frame is being transmitted, no token is available on the ring and no other station can initiate a transmission. Thus, collisions on the ring are avoided. The frame is passed (received, regenerated and retransmitted) from one station to another on the ring until it is received by a station with a matching destination address. The destination station copies the data to its internal buffers, sets control bits to indicate that it recognized the address and successfully copied the data, and retransmits the frame. When the frame returns to the source station following successful transmission and receipt, it is removed from the ring. The source station creates a new free token and transmits it on the ring, thereby allowing other stations access. Until the source station releases a free token, the rest of the stations are unable to transmit. To reduce the amount of time a station has to wait for a free token, a function, known as Early Token Release is available. With Early Token Release, a sending station releases a free token following frame transmission without waiting for the transmitted frame to return. This enhances the utilization of the ring by allowing one token and one or more frames to circulate on the network at the same time. Token ring has certain important architectural considerations: -- Token ring frames may contain as many as 17,800 bytes of information, which is significantly more than the 1500 bytes of user data in an Ethernet frame. A negotiation process is required by token ring stations to determine the maximum frame size they can use, but most implementations end up using larger frames than Ethernet implementations, which is more efficient when transferring large volumes of data. -- A single token ring may have up to 260 devices connected to it. -- Timing considerations affect the maximum frame size (only 4472 bytes for a 4 Mbps ring) and the cable lengths comprising a single ring. -- Most bridged token ring networks implement source-route bridging. Stations that want to communicate with each other across a bridged network first send discovery frames through the network to discover the best route. The stations then save this routing information and include it in every frame they subsequently send. The token ring frame itself contains an indicator bit to denote that this source-routing information is present in the frame. Source-route bridging is especially useful in SNA networks, because it allows multiple paths between two points across the network and also allows configuration of duplicate MAC addresses, both of which increase reliability and availability of the network. Maybe this has led to the perception that SNA and token ring are somehow inextricably linked, but the facts are that: 1. Token ring networks can implement transparent bridging; itÆs just less common for them to do so. 2. Whatever bridging method is used has no direct impact on the layer 3 traffic being transported in the frame: SNA, TCP/IP or any other protocol. -- Hubs which provide active token ring ports can effectively increase the total cable length of a single ring because they re-drive and re-synchronize the signals on these ports. -- There are some minor differences between the IEEE 802.5 and the IBM Token Ring standards, but for all practical purposes they are identical. IEEE 802.5 is the formal standard based on IBMÆs original implementation. - Token Ring versus Ethernet There is no simple and objective answer as to which technology is *better*; any comparisons between token ring and Ethernet end up being emotional and subjective. The only points which need to be made here are: 1. Shared media token ring copes much better under heavy load than shared media Ethernet. As traffic increases, Ethernet performance degrades significantly whereas 16 Mbps token ring has been shown to be capable of delivering an aggregate data throughput of 15.9 Mbps. The vast majority of end users, however, do not themselves require more than 10 Mbps of network bandwidth, and a switched Ethernet infrastructure delivering switched 10 Mbps dedicated bandwidth to each user can meet their needs. What this means, though, is that existing 16 Mbps shared token ring users may well be able to continue using their existing networks when 10 Mbps shared Ethernet users are required to upgrade to switched Ethernet or 100 Mbps Ethernet. 2. Many existing token ring users, most especially those with S/390 mainframes, will want to remain with token ring because of its ability to support duplicate identical MAC addresses. Duplicate addresses are used on mainframe token ring gateways to provide a measure of automatic load-balancing and switch-over in the case of failure, which requires the implementation of a source-route bridging network which is not normally possible to implement with Ethernet LANs. In its simplest form a single token ring can be viewed as a ring like to which all network stations attach. The adapters on the network stations themselves provide the intelligence in the network: an *active monitor* is elected and then serves to monitor the status of the ring, for example. -- Unmanaged hubs The simplest token ring hub does not even have to have a power supply. The network adapters themselves provide all the intelligence in the network, even to the extent of determining the ring speed. A complete ring is established by *daisy chaining* hubs together: a cable connects the *ring out* port of one hub to the *ring in* port on the next one, with the last hub connecting back to the first one to complete the ring. A complete ring can be implemented on just one hub since the ring-in and ring-out ports will be wrapped internally to complete the ring. Most unmanaged hubs will have a power supply, but this will only serve to illuminate indicator LEDs in the hub itself. Even an unmanaged hub such as the 8228 provides some resilience; if a cable between one hubÆs ring-out port and the next hubÆs ring-in port should break or be removed, the 8228 will wrap the connection internally and a single ring will be preserved, although this recovery requires that both ends of the failing cable be removed from the hubs manually. -- Managed hubs Managed hubs differ from unmanaged hubs in two ways: 1. Their configuration can be specified and changed from a management station. 2. They report status and error indications to the management station. -- Bridges The original bridge definition for the token ring was for a source routing bridge. This differs from the transparent bridge operation normally seen on Ethernet networks; transparent bridge operation requires that the bridges maintain tables of MAC addresses whereas in source routing each frame carries information about the route it is to follow through the network. In a source routing environment, this routing information is acquired through a search process that originates at the source station, using commands such as TEST or XID (Exchange ID). Source-route bridging allows the configuration of parallel bridge paths through the network, which has to be blocked in a transparent bridging environment. It allows for multiple (redundant) routes through a network, with automatic discovery of the quickest path through the network without the necessity of maintaining a record of network topology (which may change rapidly requiring extensive updates). There are several ways that this route discovery process can proceed, and the following paragraphs describe two of these methods. Consider a set of interconnected (bridged) token rings where node S1 is ready to transmit a series of messages (or set up a session with) to node S2 (which may be in another city or another country). The location of the ring that includes S2 as well as the interconnections of the various rings are initially unknown to S1. In the first method, S1 will send an ARB (All Routes Broadcast) frame to S2. This frame or frames will cross all available bridges in the network on the way to S2 (unless the *hop count* expires), thus exploring all possible routes between the two nodes. It is perfectly acceptable to have two bridges actively forwarding frames from any source ring to the same destination ring simultaneously because the bridges will have different bridge numbers assigned (1 and 2 in our example). While doing this, each frame records its route in the Routing Information Fields included in the 802.5 frame header. (Each RIF contains a source ring number, bridge number, and destination ring number). Upon receiving each frame, S2 will send a specific unicast reply back to S1 with a bit set in the header indicating that the RIF route is to be inverted (traveled backwards). Now, this is where it gets interesting! S1 will receive these replies and discard all but the first (which, by definition, is the one that won the race and which has traversed the quickest and most optimal path through the network). It can then use the routing information stored in the RIFs for future messages to that destination (generally for the duration of the session). It has found the most efficient path through the network without having to be aware of its topology. In the second method, S1 can send an SRB (Single Route Broadcast) frame to S2. This frame crosses only a designated set of bridges (only bridge 1 in our simple example) resulting in only one copy of the frame appearing on any given ring in the network. When the SRB frame gets to S2, S2 will reply using ARB, which will generate multiple frames (with the route inverted) which will explore all of the possible return paths, with the first frame returning to S1 again being the fastest. The result is the same - the source node has discovered the most efficient path between itself and the desired destination node without having to know where it is or how the network was set up (or changed). Source-route bridges still require the configuration of a spanning tree, which represents the network topology, in order to handle single-route broadcast frames. This will normally be handled by having the bridges communicate with each other and dynamically maintain a single-route broadcast path through the network, just as is normally the case with transparent bridges. Many broadcasts in a token ring environment are all-routes broadcast frames, which will be forwarded by all bridges without consideration of spanning tree topology. If appropriate, as an alternative to implementing any kind of spanning tree configuration, bridges can be configured simply to discard single-route broadcast frames. Bridges need to be configured with a bridge number which has to be a unique number for the rings to which it attaches; ring numbers also need to be defined and are usually configured in one or more of the bridges as well. -- Priority and class of service Token ring implements access priority by including three bits of priority information in every token or LAN frame. A ring station can transmit a frame of a given priority using an available token with a priority less than or equal to that of the frame. If no token is available (because another station is transmitting data) then the ring station may reserve a token of the required priority by setting bits in a passing frame. The next free token will then be sent at that priority and will not be used by any other ring station, allowing our station to transmit a frame at the required priority. Two stations may not make a reservation for the same priority value, but a station may make a higher-level priority reservation than another stationÆs existing priority reservation and effectively pre-empt it. Token ring access priority relates to two emerging and complementary layer 2 standards which can be implemented in a bridged environment: a. 802.1p, which is a component of the 802.1D standard for LAN bridges. 802.1p implements a priority queueing mechanism inside a LAN bridge which allows certain LAN frames to be given higher forwarding and transmission priority than other LAN frames. The access priority in a received token ring frame may be mapped to an internal priority value inside the LAN bridge, and could be used - for example - to allow voice traffic to *overtake* data traffic inside a bridge. b. 802.1Q, which provides the ability of all LAN media to include user priority information as part of the MAC frame. So a translational bridge could map token ring access priority in received frames into a priority marking for frames transmitted over Ethernet using 802.1Q. For more information on these two standards, see Application-Driven Networking: Class of Service in IP, Ethernet, and ATM Networks, SG24-5384. On the face of it, this priority value seems to map nicely to the 802.1Q standard for LAN frames. 802.1Q adds 3 bits of priority information to a LAN frame, and a related standard (802.3ac) allows the maximum frame size for Ethernet frames to be increased to allow the addition of this information without the need to reduce the data payload in the frame. So a growing implementation and use of 802.1Q (such as in Windows 98 and Windows 2000) even on Ethernet networks might seem to allow the priority indication in the LAN frame to map directly to this access priority on token ring. In reality, things are not quite as simple. The default action of most token ring bridges and switches is to forward user frames with an access priority value of xÆ100Æ, and the highest value, xÆ111Æ, is reserved for vital network management frames such as *Active Monitor Present* frames. Although the two next higher values of access priority, xÆ101Æ and xÆ110Æ, are described as *reserved* by IBM, these are in fact the values which need to be used for more important traffic such as mission-critical data traffic and voice traffic. What this means, though, is that the token ring access priority can be used to differentiate between different types of user traffic, which can be placed in separate transmission queues by token ring devices including bridges which implement 802.1p along the following lines: Prority bits Traffic type +----------+------------------------------------------------------------+ xÆ000Æ Normal data traffic xÆ001Æ Not used xÆ010Æ Not used xÆ011Æ Not used xÆ100Æ Normal data traffic forwarded by bridges and switches xÆ101Æ Time-sensitive data traffic (SNA traffic perhaps) xÆ110Æ Real-time critical traffic (voice traffic, for example) xÆ111Æ Station management +----------+------------------------------------------------------------+ In order to support this sort of quality of service mechanism, LAN bridges and switches need to support both the following IEEE standards: - 802.1Q to preserve packet priority values across the entire network - 802.1p to implement multiple transmission queues to enable higher priority packets to be sent ahead of normal priority packets during congestion Neither of these standards is required to implement *class of service* on a hop-by-hop basis, and this function is implemented for IP traffic by IBM token ring adapters. The use of token ring access priority in this way is just not possible on Ethernet LANs where all stations contend equally for use of the shared medium. 802.1Q provides a means of indicating a frameÆs priority across the entire network but plays no part in prioritizing the transmission of LAN frames over a single LAN segment; this is something only token ring can do. -- Switched networks Switched LAN networks are implemented by LAN switches in which traffic is not sent to all stations which attach to each port in the switch. LAN switches learn MAC addresses in much the same way as transparent bridges do, and use this information to transmit specifically-addressed LAN frames to only those ports over which it is necessary to transmit them. LAN switches do have to transmit broadcast frames (those with MAC address *FFFF FFFF FFFF*) over all ports. LAN switches originated in the Ethernet world, where there was the greatest need to increase network capacity coupled with the relative simplicity of the Ethernet design. Now LAN switches also exist for token ring networks. -- Backbone, workgroup, desktop On one level, LAN switches are translational bridges, and they can be used in the same way as bridges to segment a single token ring LAN into multiple LAN segments. One way in which switches differ from bridges is that they can operate in *cut through* mode, in which a LAN frame is being transmitted on an outbound port before it has been received on an inbound port. Bridges need to receive a frame in its entirety before re-transmitting it, but this does have the advantage that the frame check sequence (FCS) at the end of the received frame can be verified. If the FCS is found not to match the frame itself, the bridge will discard the frame. The switch which doesnÆt check FCS will needlessly transmit a corrupted frame, wasting network bandwidth; at some point further in the network the FCS will be checked and the frame will ultimately be discarded anyway. Because of the reduction of traffic on each port of a LAN switch, the ultimate design point is to have end stations themselves directly attached to a switch. Under these circumstances there is little contention for use of the connection: the only traffic apart from broadcast traffic flowing between the end station and the switch is real traffic to or from the end station itself. Because of the extra cost and implementation effort/disruption, a mid-point in a network designed around LAN switches will be on in which the important servers in the network are connected directly to the LAN switches but the less demanding end users will continue to connect to shared LAN hubs. -- Full-duplex dedicated Token Ring If an end station is directly connected to a LAN switch in an Ethernet network, it knows that no other end stations will be attempting to use the connection and it therefore no longer has to attempt to detect their presence before transmitting data as it would have to do in a shared hub environment. It also allows the switch and end station to *break the rules* and implement a full-duplex connection where both devices can be transmitting data to each other simultaneously. This is not permitted in a shared Ethernet environment. Token ring is different, but a similar enhancement is possible by the use of dedicated token ring (DTR) connections. In the standard RJ-45 token ring implementation (*Classic Token Ring* or CTR) a connection between a device and a hub/switch is made with two twisted pairs of wires. Although one pair is used for the receipt of data and the other used for the transmission of data, the standard token-passing protocol (TKP) means that these will never happen simultaneously: a token or frame will first be received by the station and then a token or frame will be transmitted around the ring. DTR provides a dedicated connection between end station and switch, but TKP can still be used over it, in which case tokens and frames flow over a two-port LAN. Little advantage has been gained here, but this mode of operation is required in DTR devices for downward compatibility. Of significant advantage, however, is the TKI (Transmit Immediate Access) protocol, where tokens are no longer used and both devices can transmit at will. The use of TKI allows two DTR stations to transmit and receive in *full duplex* mode, which doubles the bandwidth available to them to 32 Mbps. Of course, this means that 16 Mbps of bandwidth is simultaneously available in both directions and not that 32 Mbps is available in any one direction. Unlike Ethernet adapters, most token ring adapters can be configured for DTR operation with, at most, a microcode upgrade. It offers a significant upgrade to network servers. -- ATM, MSS, MPOA ATM can be used as a high-speed backbone connection between token ring switches, typically using a 155 Mbps up-link from the switch and defining an emulated token ring LAN across the ATM network. IBMÆs Multiprotocol Switched Services (MSS) Server can be used to define the emulated LAN, and Multiprotocol Over ATM (MPOA) provides one way of defining and using short-cut direct connections across complex ATM networks. - Higher speeds What technologies exist and are under development for the transport of token ring traffic at speeds greater than 16 Mbps? -- 100 Mbps and gigabit Token Ring IBM continues to chair the IEEE 802.5 committee in the development and ratification of token ring standards. In particular, the committee developed the 802.5t standard for 100 Mbps token ring, which is now an approved IEEE standard. The 802.5v standard for gigabit token ring is going through the final balloting stages (as of March 2000), and should be approved as a standard by July 2000. The purpose of these standards is to ensure interoperability between different vendorsÆ high speed token ring implementations. IBM supports 100 Mbps token ring on its 100/16/4 PCI adapter. IBM does not view high-speed token ring as a requirement for the majority of its customers, and therefore the decision has been made not to provide 100 Mbps high-speed token ring uplinks on its products - primarily the 8270 token ring switch. That is not to say, however, that IBM does not provide high-speed uplinks at all; the rest of this paper will serve to describe how FasTR, TokenPipe and ATM can each be used to provide 100 Mbps or faster uplinks from IBMÆs token ring switch. High-speed server attachment can be made using one or more dedicated token ring connections between a server and LAN switch, each offering 32 Mbps of full-duplex network bandwidth. More information on high-speed token ring can be found at the Web site of the High-Speed Token Ring Alliance, http://www.hstra.com. - FasTR FasTR is a special name for a special implementation; itÆs a form of high-speed token ring which is actually implemented using ATM adapters on the 2216 router, the 8270-800 switch, the 3-slot 8272 blade in the 8260 hub and the Multiaccess Enclosure (MAE) inside the 3746-9x0. FasTR encapsulates the token ring frames using ATM AAL5; it is intended to be used without the use of any actual ATM network but simply as a point-to-point link using singlemode or multimode fiber between two devices. It can be established using an ATM permanent virtual circuit (PVC) but in all likelihood it would not make much sense to do so; if thereÆs really an ATM network then the adapters should be configured as real ATM adapters and not as FasTR adapters. FasTR can be used to relieve congestion in a token ring backbone connection to a mainframe server. It is configured as a token ring to the devices which support it. Tests have shown throughput of greater than 100 Mbps using 4,000-byte packets. FasTR is actually supported on two basic adapters only: the MSS Client UFC for the 8270-800 and the 8272 blade, and the ATM-155 adapter for the 2216 and MAE. The devices which support FasTR can simply be used for source-route bridging, or they can configure themselves as IP routers and use it as a fast router-router link. In addition, the 2216 and MAE can route APPN traffic over FasTR links. -- TokenPipe A TokenPipe is another type of high-speed backbone connection between token ring switches; it is a collection or bundle of between 2 and 4 connections between two token ring switches. Each of the connections in a token-pipe is a 16 Mbps connection and is capable of operating as full-duplex (DTR, TKI). This gives a theoretical maximum capacity of a TokenPipe of 128 Mbps (16 x 2 x 4). The ports in a TokenPipe should be configured in ascending order of the actual port number on the switch; the lowest-numbered port is known as the primary port and is used for transmission of all broadcast frames and spanning-tree frames. Traffic on any one connection between devices on separate token ring switches which are connected using TokenPipe will flow on just one of the links which comprise the TokenPipe. The switch will use its internal table of MAC addresses to assign each target address to one of the TokenPipe links, but it will assign many addresses in a round-robin or similar fashion to achieve load balancing across the set of links. If a single link configured as part of a TokenPipe should be disconnected or fail for any reason, the entire TokenPipe is made inoperable. -- Load balancing Other solutions for higher speed token ring connectivity include load balancing between multiple token ring LAN adapters. This approach is one that should not be undertaken lightly: there are many complications possible using multiple LAN adapters connecting to the same switch or backbone LAN segment. One possible approach would be to configure multiple LAN adapters with different IP addresses and use layer 3 load balancing techniques such as OSPF equal-cost multipath to spread the load across multiple LAN adapters; this requires some kind of OSPF *gated* implementation in the machine. Multiple LAN adapters can cause problems in NetBIOS environments because of the requirement for a computerÆs name to be unique in a network. Load balancing approaches are fraught with danger and can often, at best, lead to a configuration in which only one LAN adapter is used for the significant majority of network traffic anyway. - Network management Network management is essentially concerned with two issues: the remote configuration and monitoring of network-attached devices. The first network management implementations were used to control the building blocks of the network: the hubs, bridges and routers. Specific users could be permitted or denied access at specified times of day or days of the week, but this was accomplished by configuring the network devices themselves. Network devices reported faults and errors back to a management station to improve problem determination in complex network environments. More recently, distributed intelligence has been provided in workstations themselves, not just in complex servers but in more basic PCs, to the extent that a PC can report the removal of its cover or a basic hardware fault. This increases the controllability and manageability of the total network environment. -- Overview Network management relies on standard protocols and architectures for the creation and transmission of network management information. In essence, network devices and network management stations communicate using standard LAN packets conforming to different specifications. --- CMOL CMOL stands for Common Management Information Protocol over LLC (or CMIP over LLC) and is an OSI standard for the transport of network management information. It was much favored in the public telecommunications carrier environment and provides a rich set of management functions; it was originally used by IBM to provide network management of the 8230 Controlled Access Unit. The management station for the 8230 was typically an OS/2 workstation running LAN Network Manager for OS/2, and many customer 8230 installations continue to run this today. The 8230 uses one of its internal MAC addresses as the source address for network management communication to the network management station, and hence CMOL information flows at the layer 2 level, using MAC addresses across a bridged LAN environment. The related CMOT (CMIP over TCP/IP) standard allows this information to be transported using layer 3 IP packets, but this is not implemented by the 8230. --- SNMP The Simple Network Management Protocol (SNMP) grew up in much the same way as the rest of the TCP/IP protocol stack: rather than being designed by committee and providing a rich set of functions it grew up as a pragmatic implementation based on what was really required in the network. SNMP has since grown to be the effective industry standard for management of network devices, and provides a relatively simple *vocabulary* of commands which effectively comprises just three - the ability to SET commands on the remote device, the ability to GET information from the remote device and the ability of the remote device to send unsolicited TRAPs alerting the network management station of status changes and problems in the network. Most hubs, bridges, routers and similar devices in networks today offer the capability of being managed using SNMP, which requires them to be configured with an internal IP address (if they donÆt already have one) and requires IP connectivity between the device and the management station. Even the 8230 now offers this capability, selected by a switch on the front of the base unit. --- RMON Remote Network Monitoring (RMON) is concerned with the implementation of probes which can be used to troubleshoot and monitor remote LANs. RMON probes are typically accessed across the network using IP protocols and allow the retrieval of status information - percentage utilization, for example - rather than the application of configuration information and retrieval of error information. So RMON serves a separate purpose to both SNMP and CMOL/CMOT and both would normally be expected to operate in parallel. --- DMI The Desktop Management Interface standard is concerned with the monitoring and retrieval of status and error information from workstations. It serves much the same purpose as either SNMP or CMOL/CMOT but usually applies to a different set of network devices - user workstations themselves rather than the building blocks of the network. - TCP/IP and SNA There has always been a perception that the SNA networking protocol is in some way linked to the token ring LAN medium. This probably comes about because SNA and token ring were both developed by IBM. It is also true that most large SNA networking customers tend to use token ring, in the data center at least, and there are certain features inherent in token ring which are specifically used in token ring environments: the efficiencies of transporting large frames and the resilience of duplicate MAC addresses coupled with source-route bridging. The problem with this perception is that the assumption is sometimes made that because token ring is somehow good for SNA traffic that it is also somehow bad for IP traffic. Nothing could be further from the truth. Indeed, IBM has made many innovations and enhancements, specifically for TCP/IP, which apply to the token ring environment just as for any other. Route switching allows token ring devices to establish shortcuts to increase IP throughput. Token ring devices are monitored and managed using IP protocols. Indeed, some of the advantages of token ring can be used to the advantage of IP traffic: *CoS for IP* allows the marking of important IP traffic with higher transmission priority than other IP traffic in a way which is just not possible using Ethernet. Almost nothing described in this paper on token ring applies exclusively to SNA traffic or, indeed to any other layer 3 protocol. Customers with existing token ring networks are going to want to continue using it as their layer 2 transport mechanism of choice for all network traffic. - Conclusion Token ring is not about to be overtaken and superseded by other technologies such as high-speed Ethernet and ATM, primarily due to the fact that token ring has delivered a reliable and stable infrastructure for many years and will continue to do so in the future. Many customers are not going to replace their token ring infrastructures simply because it may be fashionable: they realize that their investment in token ring is capable of catering to their networking needs for years to come. Token ring offers significant architectural advantages and in many cases significant improvements to existing token ring infrastructures can be made by microcode updates and replacement of key network components rather than by wholesale replacement of the entire network. As an example, key bottlenecks in token ring networks can be eliminated by replacing a few hubs with switches and by leaving the rest of the network unchanged. Slider. Werd : To all that know me FuqU : To all that hate me TUVM : Mark P, for giving me research books to complete this short text. _______________________________________________________ 8. Understanding System Daemons - Spyderco Psyops [psyops@scientist.com] _______________________________________________________ Introduction. The most secretive, yet most productive, application or service on a Unix system is the daemon process. A daemon, pronounced 'demon,' process is secretive because it runs in the background, and often does not indicate its presence in any significant way. Without it, most Unix systems would cease to function. Programmers write daemons to carry out a function with little or no intervention by users or system administrators. In fact, many daemons require no intervention at all! The services offered by daemon processes are important to understand, because the potential security violation may be through a program that masquarades as a daemon. What is a daemon? A daemon process is a process that is not associated with a user, but performs system-wide functions, such as administration and control, network services, execution of time-dependent activities, and print services. To qualify as a daemon process, several criteria must be met: the process must not be associated with a user's terminal session; and it must continue after the user logs off. From the rudimentary process management knowledge you have read about so far, you know that each process a user starts is terminated by the init program when the user exits. The init program is the most famous of all system daemons. This approach allows for proper management of the process table. Although daemon processes are almost completely invisible, they do provide some level of service to users. Daemon processes accept user requests and process them; they also respond to various events and conditions. They are often inactive, however, and are designed to be called into service only when required. By using a daemon instead of starting a new process for every instance, system load is reduced, and large programs that take time to get started will not slow down the user or the operation. A daemon can be distinguished from other programs on the system by examining the process table--the ps command displays this table. The distinguishing characteristic of a daemon is that the TTY column does not reflect the controlling terminal name. The daemon is the process with a questions mark "?" as the controlling terminal name. The controlling terminal is identified in the "TT" or "TTY" column of the ps output. Whenever this is found in a process entry, the process is a daemon. Daemon processes usually do not accumulate very much CPU in the short run, unless they have a lot of processing to do when they start. It usually takes a tremendous amount of time for these daemons processes to equal the CPU requirements that many other processes accumulate in a minute or two. The daemon processes shown in the ps output were likely started as part of the system's boot process. It is important to consider that the startup procedures of the various Unix flavors often are very different depending upon the heritage. SunOS 4.1.x, for example, is derived from the Berkeley Software Distribution (BSD) code and as such bears little or no resemblence to the startup procedure seen in Solaris 2.x, which is based upon the Unix System Laboriatories Unix Systen V Release 4. The same is true when comparing Unix System V Release 3.2 and 4.0. These differences are important to note, because they make it easier to hide inconspicuous programs for later action. The HP-UX startup sequence makes use of a large number of files, each of which are tightly linked to a given subsystem. For example, the file netlinkrc is used to start network processes. With this type of startup file layout, it is much harder to locate the daemons and to modify the system startup procedure. Regardless of the Unix implementation being considered, the use of the /etc/rc/ file start the system is common. Consider the list of files required to start the daemons on an SCO OpenServer 5.0 system. SCO Unix products use a file system structure that is grouped by the desired run level. Run levels, their meanings, and how to switch between them. Like the HP-UX implementation, a number of SCO Unix startup scripts are used to start daemons. Each script essentially is dedicated to starting the daemons for a specific function group. This is not nessessarily bad design, but it requires a detailed level of understanding of the underlying system structure. Examining the System Daemons. A number of system daemons can exist in a Unix system. Some are only found in a specific version of Unix, but many daemons are common to all versions of Unix. This section discussess many of the common daemons and describes their function on the system. init The init daemon is known as the parent process for all the processes on the system. It performs a broad range of functions that are vital to the operation of a Unix system. The most commonly known purpose of the init process is to boot the system. The method init uses to boot the system differs among Unix versions. The BSD and XENIX init programs, for example, do not work the same way as the System V implementation. The System V init program relies on the file /etc/inittab/ to provide details of how init is to govern the startup and initialization of the various services on the system. The init process is commonly known as "init" because of its role in the initialization of various processes during system operation. The init program considers the system to be in a run level at any given time. Run levels are the operating states of the system. For the purposes of this section, a run level can be viewed as a software configuration; each configuration allows only a selected group of processes to exit. swapper Some Unix system administrators refer to swapper as a daemon, and others do not. The swapper process is responsible for scheduling the use of memory by the various processes on the system. The swapper process is actually part of the kernel, so you could say that it is not a daemon after all. update and bdflush Update and bdflush are similar commands that periodically executes the sync system call to flush disk buffers. These daemons execute every 30 seconds. Users and system administrators rely on these daemons to update the file system in case of a crash. Although two commands are listed, your system will see one or the other, but rarely both. lpd The lpd daemon is part of the BSD print services. It listens for and accepts connections via TCP/IP to submit a print request. The lpd daemon relies on the LPD protocol to accept the job, and submit it to the requested printer. This daemon was almost exclusively found on BSD-based systems until the more popular System V derivatives started adding similar services. lpsched The lpsched daemon is the System V version of the print spooler. It performs the same tasks as the BSD lpd program, but in a much different format. Despite lpsched's inability to communicate directly via the LPD protocol, it is still considered stronger than lpd because of its flexibility with printer interface scripts. cpd and sco_cpd The cpd and sco_cpd daemons are the license managers for SCO products. They are similar to license managers on other implementations of Unix in that they ensure that all products on the local network have unique serial numbers. With the release of SCO OpenServer 5.0, the license managers support shrink-wrapped software and operating system software. cron The cron daemon is the automated task scheduler; it runs scheduled jobs at the requested time. A user may want to execute a number of jobs at regular intervals, for example. To do this, a crontab file is created resembling the following: 0,15,30,45 * * * * /usr/stats/bin/getstats border1.ottowa 0 3 * * 0 /usr/stats/bin/merge border1.ottawa 0 4 * * 0 /usr/stats/bin/ar border1.ottawa This specification identifies when the job is to be executed and what the command to be executed is. The cron daemon builds an internal list of the jobs to be executed, and runs them at the requested time intervals. syslog The syslog daemon is a UDP/IP service that allows information and status messages for different network services to be logged through a central logging mechanism. The syslog daemon is controlled through the file /etc/syslog.conf and can write messages of different types into different log files. A sample syslog.conf file is shown here: user.* /usr/log/user_logs kern.* /usr/log/kernel_logs daemon.* /usr/log/messages mail.debug /usr/log/mail etc. etc. The syslog.conf file lists the facility priority level of the messages, and where that message is to be stored when received. Any message that is received with a priority level of critical, for example, is written to the file /usr/log/critical. sendmail The sendmail daemon is the common Mail Transport Agent included with current versions of Unix. Because this program is a daemon, it listens for and accepts incoming e-mail connections from external systems. This daemon receives and subsequently delivers messages to local or remote users. Sendmail is not intended to function as a user interface, but rather as the processing agent for user mail programs such as elm, pine, mailx, and mush. The sendmail program functions in two modes: incoming and outgoing. It accepts mail from internal and external sources and processes it according to the rules found in the /etc/sendmail.cf configuration file. The format of and options for the /etc/sendmail.cf configuration file are far too complex to cover here. The sendmail program is capable of accepting TCP/IP connections on port 25. The following output illustrates a connection to sendmail on this port. nms% telnet nms 25 Trying 198.53.64.4 ... Connected to nms. Escape character is '^]'. 220 nms.home.org Sendmail 4.1/ch-950121.1 ready at Thu, 18 May 95 11:28:36 CET help 214-Commends: 214- HELO MAIL RCPT DATA RSET 214- NOOP QUIT HELP VRFY EXPN 214.For more info use "HELP <topic>". 214-stmp 214-To report bugs in the implementation contact Sun Microsystems 214-Technical Support. 214-For local information contact postmaster at this site. 214-End of HELP info quit 221 nms.home.org closing connection nms% The system administrator can test his or her configuration from the sendmail command directly. Unfortunately, this capability can also be used by the way the wily hacker to create a false mail message that looks like it came from somewhere else. getty The getty daemon is responsible for providing a login prompt on terminals and on serial devices directly connected to the system; getty is also responsible for providing a login prompton the console. The getty command is started by the init process, and is part of the login->shell->logout process. It is important to note that when you log in through telnet, getty is not involved in the process. The telnet server, telnetd, displays the login message and collects the user name from the user. rlogind The rlogind daemon is the server side to the client rlogin program. It provides a remote login facility with authentication based on priviledged port numbers and hostname-username pairs. rlogind is executed by the Internet daemon, inetd, when it receives a service request at the port indicated in the services database for login using the TCP/IP protocol. deliver The deliver daemon manges all mail delivery in the MMDF mail system. deliver does not only deliver mail directly, but instead calls on MMDF channel programs to handle actual delivery.deliver's actions are guided by the MMDF configuration file, /usr/mmdf/ mmdftailor, and by command-line options. This daemon also maintains a cache of host information on a perchannel basis, so that mail for unavailable hosts can be skipped until the host is available. inetd The inetd daemon listens on multiple ports for incoming connection requests. When it receives a request, inetd spawns the appropriate server. The use of a "super-server" allows other servers to be spawned only when needed and to terminate when they have satisfied a particular request. The following servers are normally started by inetd: fingerd, ftpd, rexecd, rlogind, rshd, talkd, telnetd, and tftpd. inetd can also start several internal services: these are described in inetd.conf, which is typically found in the /etc directory. Do not arrange for inetd to start named, routed, rwhod, sendmail, pppd, or any NFS server. routed The routed daemon is invoked by root at boot time to manage the Internet Routing Tables (usually during init 2). The routed daemon uses a variant of the Xerox NS routing Information Protocol to maintain up-to-date kernel Routing Table entries. If the host is an internetwork router, routed periodically supplies copies of its Routing Tables to hosts and networks that are directly connected. nfsd The nsfd daemon starts the NFS server daemons that hande client file system requests the nsfd daemon is a user application entry point into the kernel-based NFS server. mountd The mountd daemon is an RPC server that responds to file system mount requests. It reads the file /etc/exports to determine which file systems are available to which machines and users. This daemon also provides information regarding clients with mounted file systems. This information can be printed using the showmount command. pcnfsd The pcnfs daemon is an RPC server that supports ONC clients on PC (DOS, OS/2, and MAC) systems. There are two implementations of the PC-NFS protocol: Version 1 and Version 2. Version 2 supports extended printing features. It reads the configuration file /etc/pcnfsd.conf if present, and then services RPC requests directed to program number 150001. Many releases of the pcnfsd daemon support both version 1 and version 2 of the pcnfsd protocol. statd, rpc.statd The statd and rpc.statd daemons are RPC servers that function as the RPC status monitor. It interacts with the lockd server to provide crash and recovery functions for the locking services on NFS. It is common to see either statd or rpc.statd but not both on your system. lockd, rpc.lockd The lockd daemon processes lock requests that are either sent locally by the kernel or remotely by another lock daemon. lockd forwards lock requests for remote data to the server site's lock daemon. lockd then requests the status monitor daemon, statd or rpc.statd, for monitor service. The reply to the lock request will not be sent to the kernel until the status daemon and the server site's lock daemon have replied. Logging Off thanks for hearing me out...psyops@scientist.com. _______________________________________________________ 9. This Months News Links - Slider [slider@0blivion.org] _______________________________________________________ Oblivion Mag's news section is now sponsored by Help-Net Security. http://net-security.org All information is taken from Net-Sec mini letter. 1) General security news 2) Security issues 3) Security world General security news -------------------------------- HOW TO ELIMINATE SECURITY THREATS The majority of successful attacks on computer systems via the Internet can be traced to exploitation of one of a small number of security flaws. Most of the systems compromised in the Solar Sunrise Pentagon hacking incident were attacked through a single vulnerability. A related flaw was exploited to break into many of the computers later used in massive distributed denial of service attacks. Link: http://www.sans.org/topten.htm DNS SECURITY IN AUSTRALIA Australian Internet security company DeMorgan released a document which is revealing the state of DNS security within Australia at the present moment. The reult - "Of the total number of servers tested, 75% were discovered to be vulnerable to DoS attacks though misconfigurations and/or inappropriate version of bind being used whilst 52% were discovered to be vulnerable to root compromise from inappropriate version of bind being used". Thanks to Craig Wright for sending in the papers. Link: http://www.demorgan.com.au/ Whitepapers on DNS security in Australia: (doc version) http://www.net-security.org/cgi-bin/download.cgi?DNS-Scan-Results.doc (pdf version) http://www.net-security.org/cgi-bin/download.cgi?DNS-Scan-Results.pdf HACKERS AS A RESOURCE Earlier this month, Kevin Mitnick told CIO magazine that hiring hackers is the best way for companies to learn about security threats. The magazine says its poll of corporate CIOs found nearly one in three willing to hire Mitnick to advise them on security preparedness. Link: http://www.zdnet.com/zdtv/cybercrime/hackingandsecurity/story/0,9955,2583262,0 0. html TELEFONICA ON TELEFONICA WORM "The company has no reports of the existence of this virus, has not detected any type of problem in its systems and has not received any form of complaint from clients that has to do with the supposed virus". Link: http://www.zdnet.co.uk/news/2000/22/ns-15863.html MORE PROBLEMS FOR FREE E-MAIL PROVIDERS In the latest security breach besetting free Web-based email services, Lycos' WhoWhere said it had fixed a problem this week affecting millions of accounts, including those belonging to MailCity and iVillage members. Link: http://news.cnet.com/news/0-1005-200-2036086.html?tag=st.ne.1002.thed.ni VBS PLAN WORM Plan.A is a new e-mail spreading worm that has been seen in the wild in US. The worm spreads through e-mail using Microsoft Outlook. It arrives as an e-mail with either randomly generated text subject line or the following: "us president and fbi secrets =please visit => (http://www.2600.com)<=" (original message is in caps lock). Link: http://www.ca.com/virusinfo/virusalert.htm#vbsplanaworm LINUX 101: BASIC NETWORK SECURITY "Enterprise-wide security strategies require far more explanation than I can possibly include in a 101 series (or even a single article), so I'll just run through a simple method of locking down a machine on a LAN that is not behind a firewall and that needs quick and cheap protection from unwanted guests. Oh yes; I'll also keep in mind you'll be doing so with limited Linux knowledge." Link: http://www.techrepublic.com/article.jhtml?id=/column/r00220000607eje02.htm FIGHTING CYBERCRIME "It is essential to establish a swift and efficient system of international cooperation ... (in) the fight against crime in a computer environment," the ministers from 41 European nations including Russia said in a communique. Link: http://www.mercurycenter.com/svtech/news/breaking/merc/docs/021725.htm MEDIA PROMOTION The Register published a good rant on "the video trojan", where they speak of the company who found it as "an opportunistic security firm in quest of free advertising in the form of media attention". Link: http://www.theregister.co.uk/content/6/11290.html WINN's WAR AGAINST THE NET In a column on ZDNet's Interactive week, Lewis Z. Koch commented on Winn Schwartau's newest book called "Cybershock - Surviving Hackers, Phreakers, Identity Thieves, Internet Terrorists and Weapons of Mass Disruption". It is "slick attempt to terrorize the reader about the dangers of the Internet and the fearsome, loathsome 'hackers' who lurk within marks a new low" - Koch writes. Link: Koch's article http://www.zdnet.com/intweek/stories/columns/0,4164,2584807,00.html Link: Comments by Winn Schwartau http://www.zdnet.com/tlkbck/comment/321/0,7091,90988-466533,00.html CYBERAGENTS a.k.a BOTS In March 2000, Ray Parks, leader of Sandia's government and corporate computer defence testing, and his Red Team attacked a five computer network at Sandia protected by recently developed security bots known as cyberagents. The attack failed. The cyberagents, without outside assistance, held off four, experienced, human hackers for 16 hours. Link: http://www.beyond2000.com/news/story_652.html INTERVIEW WITH MARCUS RANUM CEO OF NFR "Recently I got an opportunity to speak with Marcus Ranum, Founder and Chief Technical Officer for Network Flight Recorder, developers of network intrusion detection products. He has specialized in Internet security since he built the first commercial firewall product in 1990." Link: http://www.linuxsecurity.com/feature_stories/feature_story-48.html Security issues ---------------------- IE 5 Cross-frame security vulnerability Internet Explorer 5.01 under Windows 98 (suppose all other versions are also vulnerable) allows circumventing "Cross frame security policy" by accessing the DOM of documents using JavaScript, IFRAME and WebBrowser control. This exposes the whole DOM of the target document and opens lots of security risks. This allows reading local files, reading files from any host, window spoofing, getting cookies, etc Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid960370966,4557, Kdelibs vulnerability for setuid KDE applications There is a very serious vulnerability in the way KDE starts applications that allows local users to take over any file in the system by exploiting setuid root KDE application. The only vulnerable application shipped with OpenLinux is kISDN, but third party software might be vulnerable too. Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid960371104,7613, ColdFusion Web Application Server DoS attack A denial of service vulnerability exists within the Allaire ColdFusion web application server which allows an attacker to overwhelm the web server and deny legitimate web page requests. Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid960482396,65647, Sendmail Workaround for Linux Capabilities Bug The Sendmail Consortium and Sendmail, Inc. has been informed of aserious problem in the Linux kernel that can be used to get rootaccess. This is not a sendmail security problem, although sendmailis one of the vectors for this attack. Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid960482545,38231, Allaire Security Bulletin (ASB00-14) Allaire has recently been notified by Foundstone, Inc. (see Revisions section below for contact information) of a denial of service attack against an unprotected installation of the ColdFusion Administrator. This issue only affects ColdFusion Servers that have not followed Allaire's recommendations in the Allaire Security Best Practices article 10954. The article is available at the link below. Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid960507656,98531, Patch Available for "Remote Registry Access Authentication" Vulnerability Microsoft has released a patch that eliminates a security vulnerability in Microsoft(r) Windows NT 4.0. Under certain conditions, the vulnerability could be used to cause a Windows NT 4.0 machine to fail. Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid960556276,81353, Reporting Security Issues to Microsoft Microsoft security staff posted to BugTraq some information about what you should do if you found a security vulnerability in one of their products. Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid960637775,67522, Flaws in the SSL transaction handling of Netscape There are some flaws in the SSL transaction handling of Netscape Version 4.72 which could compromise encrypted SSL sessions. This update upgrades Netscape to version 4.73, which also fixes some annoying crashes during common usage. Upgrade to the new version is recommended. Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid960637932,52288, Security world -------------- NEXT-GENERATION OF LEADING SECURE SHELL - [07.06.2000] SSH Communications Security (SSH), the world-leading developer of Internet security technologies and developer of the Secure Shell standard, today announced SSH(R) Secure Shell(TM) 2.2. SSH Secure Shell 2.2 Provides Compatibility with SSH1 and Makes SOCKS Configuration Easier. Press release: http://www.net-security.org/cgi-bin/press/fullnews.cgi?newsid960335497,12284, RSA SECURITY SOFTWARE IN AXENT PRODUCTS - [07.06.2000] RSA Security Inc. (Nasdaq: RSAS) today announced that AXENT Technologies, Inc. (Nasdaq: AXENT) has licensed the RSA BSAFE(R) Crypto-C encryption software. AXENT(R) has incorporated the RSA BSAFE Crypto-C software into its Raptor(R) Firewall-EC and Raptor VPN Server-EC products to provide the encryption technology required by these offerings. Press release: http://www.net-security.org/cgi-bin/press/fullnews.cgi?newsid960336073,87046, SYMANTEC ANNOUNCES FREE ONLINE SECURITY SEMINARS - [07.06.2000] F-Secure (Helsinki: FSC), a leading provider of centrally-managed, widely distributed security solutions, today announced a collaboration with GartnerGroup on a series of Security On-Line Seminars focused on wireless connectivity. The series presents a step-by-step approach to mobile, distributed security by addressing major issues and offering pragmatic advice on how to avoid threats and ensure policy compliance. Topics range from proactive protection against viruses, secure broadband connectivity, and the growing threat from wireless connectivity. Press release: http://www.net-security.org/cgi-bin/press/fullnews.cgi?newsid960398556,55749, SIEMENS INTRODUCES FINGERPRINT RECOGNITION PC MOUSE - [07.06.2000] To help thwart the growing threat of unauthorized access to personal computers that contributes to severe security breaches, Siemens' Program and System Engineering Technology Lab today introduced one of the first mouse pointing devices that uses fingerprint recognition to deliver high levels of protection. The announcement was made at Sun Microsystems' JavaOne(SM) 2000 conference, held in San Francisco. Press release: http://www.net-security.org/cgi-bin/press/fullnews.cgi?newsid960398759,20421, SMART CARD-BASED SECURITY FOR JAVA APPLICATIONS - [08.06.2000] Datakey, Inc. (Nasdaq: DKEY), an international leader in smart card solutions for Public Key Infrastructure (PKI), today announced that it is a member of Phaos Technology Corporation's PKCS 11 Partner Program for the Java(TM) platform. As a member of the program, Java developers can easily integrate and secure their applications with Datakey's industry-leading smart cards using code written in Java and Phaos' e-Security products for SSL, S/MIME and PKI protocols. Press release: http://www.net-security.org/cgi-bin/press/fullnews.cgi?newsid960469215,30896, SYMANTEC'S ANTI-VIRUS TECHNOLOGY FOR PALM OS - [09.06.2000] Symantec Corp. (Nasdaq: SYMC), a world leader in Internet security technology, today announced the development of the world's first anti-virus technology for the Palm OSR platform. This new security prototype incorporates Symantec's award-winning anti-virus engine technologies re-engineered to run efficiently on handheld computers and other portable applications. Press release: http://www.net-security.org/cgi-bin/press/fullnews.cgi?newsid960557110,27714, HP INTRODUCES SMART CARD SECURITY KITS - [10.06.2000] Hewlett-Packard Company (NYSE: HWP) today announced the availability of a new Smart Card kit for HP notebook PCs running Microsoft(R) Windows(R) 2000 that builds upon key security enhancements in the operating system to protect and authenticate sensitive user data. The HP Mobile ProtectTools 2000 Smart Card security kit - an accessory for all HP OmniBook notebook PCs - allows users to safeguard data in an encrypted, tamper-proof removable smart card. Press release: http://www.net-security.org/cgi-bin/press/fullnews.cgi?newsid960643738,89287, VERISIGN INTEGRATES QUALYS' ONLINE SECURITY AUDIT - [12.06.2000] VeriSign, Inc. (Nasdaq: VRSN), the leading provider of Internet trust services, and ualys, Inc., a leader in online network security services, today announced that VeriSign has integrated a free one-month subscription to Qualys' new online security auditing service, QualysGuard(TM), with VeriSign's Global Site and Global Site Plus website service offerings Press release: http://www.net-security.org/cgi-bin/press/fullnews.cgi?newsid960816485,16223, NEW SECURITY TECHNOLOGY, IV-CALLER FROM IVERIFY.COM - [12.06.2000] With online merchants under unprecedented pressure from Visa and MasterCard to keep credit card fraud under 1 percent of sales, a new service from iVerify.com enables Web sites to confirm that a customer truly can be reached at the telephone number he or she has supplied. Press release: http://www.net-security.org/cgi-bin/press/fullnews.cgi?newsid960815878,3322, Issue 16 - 07.05.2000 1) General security news 2) Security issues 3) Security world 4) Virus information General security news --------------------- BURGLAR ALARM CATCHES ATTACKERS ON THE NET The service gives European companies the opportunity to outsource network intrusion detection instead of relying on internal security experts. Defcom showed off its flagship European "alarm centre" in Stockholm Monday -- from which a company's network security can remotely monitored - and said that similar centres are currently being tested in London and Berlin, and will be operational there after the summer. Link: http://www.zdnet.co.uk/news/2000/21/ns-15659.html SENATE EYES GUARD FOR INFO SECURITY The Senate this month urged the Pentagon to study how it might use the Army National Guard to make up for the shortage of computer programmers and information security specialists. Link: http://www.idg.net/ic_184044_1794_9-10000.html NO PROBLEMS? Microsoft says there are no problems with its e-mail software, even as computer experts have come out in support of an Auckland software designer who says its e-mail programs are dangerously flawed. Link: http://www.nzherald.co.nz/storydisplay.cfm?storyID=138739&thesection=technology &thesubsection=general FOX's SECURITY AUDIT In the wake of highly publicized security breaches and denial-of-service attacks, the media conglomerate Fox Entertainment Group wanted to know how vulnerable it might be, so it conducted a vulnerability assessment. Link: http://www.techweb.com/wire/story/TWB20000602S0002 COMPATIBILITY PROBLEMS Outlook patch, which lets administrators selectively permit some attachments (connected with recent vbs worms), could cause compatibility problems with software meant to work with Outlook, Microsoft said last week. Link: http://www.techweb.com/wire/story/TWB20000602S0001 FEMALE HACKERS ABC has an article about female hackers. "They are queens of pirated software, anti-child-porn crusaders, political activists and leaders of private online vendettas." One of the mentioned people in the article is Natasha from our affiliates at Anti Child Porn Organization. Link: http://abcnews.go.com/sections/tech/dailynews/hackerwomen000602.html MICROSOFT BRASIL SITE DEFACED It looks like web site of Microsoft Brasil was defaced not long time ago. The message left on the page is on portuguese (I presume) and according to Altavista translator it says something like: "now it was the time of the Microsoft, a company who makes servers (IIS is said) ... to be defaced". Link: http://www.net-security.org/misc/sites/www.microsoft.com.br/ ECH0 SECURITY SCANNER OUT Our affiliates at ech0 security released eSS which is a remote security scanner for linux that scans remote nodes for known security flaws. It does some of the simple probing techni, automatically like banner grabbing, OS guessing and it includes a multithread TCP portscanner. Link: http://www.ech0.de LINUX SECURITY WEEK Issue number 5 of Linux Security Week has been released. Last week, the major topic of concern was The Top 10 System Security Threats released by SANS. Articles such as FBI, DOJ issue list of worst Internet threats and IT, Company Execs Add To Security Holes spawned from SANS' initial release. Link: http://www.linuxsecurity.com/articles/forums_article-800.html DOMAIN HIJACKERS TARGET INTERNET.COM The would-be hijackers succeeded in forcing a change in the public Internic record for internet.com. As of mid-day, the WHOIS record for internet.com incorrectly listed BCS Inc. of Montreal, QC as the domain name owner. The domain name root records were not changed and traffic to the site was not affected. internet.com technical staff was assured by NSI that the DNS records would not be re-directed and the mistake would be rectified within hours. Link: http://www.internetnews.com/wd-news/article/0,2171,10_387931,00.html Security issues --------------- Remote DoS attack in Real Networks Real Server The Ussr Labs team has recently discovered a memory problem in the RealServer 7 Server (patched and non-patched). What happens is, by performing an attack sending specially-malformed information to the RealServer HTTP Port(default is 8080), the process containing the services will stop responding Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid959866097,16888, Allegro-Software-RomPager vulnerable to DoS Allegro-Software-RomPager is an http server which is used in network hardware like switches to provide a web interface to remotely configure your hardware. It seems that sending an incorrect request to the switch will cause the http server to crash and then crashing the actual switch. I only tested this on a D-Link DES-3224+ however there are other companies which use the Allegro software for their devices. Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid959906417,99542, Patch and Tool Available for "Protected Store Key Length" Vulnerability Microsoft has released a patch and a tool that eliminate a security vulnerability in Microsoft Windows 2000. The vulnerability could make it easier for a malicious user who had complete control over a Windows 2000 machine to compromise users' sensitive information. Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid960034461,28982, Fix for DoS in Real Networks RealServer 7 "This afternoon a BugTraq/USSR Advisory notice was released announcing that a Denial of Service attack was found in the RealServer 7. We have found and fixed the problem. This particular exploit utilizes a bug in the URL parsing for the ViewSource feature. View Source allows source content and media file information on enabled RealServers to be displayed in a Web browser. The server's auto-restart feature will successfully determine that a problem has occurred and will restart the server in approximately120 seconds"... Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid960044205,2944, Majordomo removed from Debian The majordomo package as shipped in the non-free section accompanying Debian GNU/Linux 2.1/slink allows any local user to trick majordomo into executing arbitrary code or to create or write files as the majordomo user anywhere on the filesystem. This is a documented issue and the advised work around it to either have no untrusted users on a system running majordomo or to use a setuid wrapper that the MTA delivery agent can run. suboptimal solution. We feel that those options are not a good solution, but unfortunately the majordomo license does not allow us to fix these problems and distribute a fixed version. As a result we have decided to remove majordomo from our archives. Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid960083040,21626, Linux-Mandrake bind update Problem: By default bind is launched as user and group root. This setting can give the possibility to easily exploit vulnerabities in bind. Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid960210158,70244, Linux-Mandrake Xlockmore security update In order to perform the password-check xlock must be setuid root and have access to the shadowed passwd file. In the xlockmore distributions versions prior to 4.16.1, a buffer overflow vulnerability was present in xlock that permitted a user to view parts of the shadowed passwd file Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid960210254,39590, Patch Available for "SSL Certificate Validation" Vulnerabilities Microsoft has released a patch that eliminates two security vulnerabilities in Microsoft Internet Explorer. The vulnerabilities involve how IE handles digital certificates; under a very daunting set of circumstances, they could allow a malicious web site operator to pose as a trusted web site. Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid960293460,80221, FW-1 IP Fragmentation Vulnerability "...CPU mysteriously hits 100% utilization, system locks up. Some systems may also crash, depending on OS type... I have reason to believe that every installation of FW-1 is vulnerable, regardless of Operating System type or version/patch level of the FW-1 installation. However, this has only been tested and confirmed with ver 4.1 SP1 on the Nokia, and ver 4.1 on NT and Solarix x86 platform." Paper by Lance Spitzner. Link: http://net-security.org/cgi-bin/bugs/fullnews.cgi?newsid960293578,61024, Security world -------------- SANTA CLARA, Calif., (May 26, 2000)-Cylink Corporation (NASDAQ: CYLK), today announced that it plans a series of initiatives to provide increased security for data transmissions made over wireless mobile devices employing WAP (Wireless Application Protocol) technology. Cylink's new technologies will, for the first time, provide a single, end-to-end security solution, resolving vulnerabilities inherent in current WAP data transmission paths and greatly improving the security of e-business transacted over wireless devices. Press release: http://net-security.org/cgi-bin/press/fullnews.cgi?newsid959843600,87228, ATLANTA, Ga. May 31, 2000 Internet Security Systems (NASDAQ: ISSX) (ISS), the leading provider of security management solutions for the Internet, announced today the availability of the latest version of SAFEsuite« Database ScannerÖ. The latest version is the first and only product that fully automates the process of securing mission critical data stored in Oracle, Microsoft SQL Server, and Sybase database servers running on UNIX and Windows NT/2000 servers. Press release: http://net-security.org/cgi-bin/press/fullnews.cgi?newsid959904514,96792, SANTA CLARA, Calif., May 30 /PRNewswire/ -- myCIO.com, a Network Associates, Inc.(Nasdaq: NETA) business, today announced VPN ASaP, a complete family of managed security services designed to deliver fast, simple and cost-effective virtual private network (VPN) connections for companies of all sizes conducting business over the Internet. With VPN ASaP, myCIO.com brings VPN protection up-to-date by packaging proven technology with a host of managed services to secure on-line communications in an easy-to-use, Web-based format that allows for virtually immediate protection and continuous remote management. Pressrelease: http://net-security.org/cgi-bin/press/fullnews.cgi?newsid959905890,55782, CUPERTINO, Calif. - June 5, 2000 - Symantec Corp. (Nasdaq: SYMC) a world leader in Internet security technology, today announced Carey Nachenberg, chief researcher of the Symantec AntiVirus Research Center (SARC), will speak at the Gartner Group conference -- Information Security in an E-Business World: Coping with the Threats. In NachenbergÆs presentation today from 4 p.m. to 4:45 p.m. in New Orleans, titled "The Decade of the Worm," he will address the key factors contributing to the recent rash of worldwide computer worms and identify specific policy decisions corporations can enforce to limit the spread of these threats. Press release: http://net-security.org/cgi-bin/press/fullnews.cgi?newsid960244098,90490, CUPERTINO, Calif. - June 5, 2000 - Symantec Corporation today announced that Queen's University in Kingston, Ontario, has licensed Norton AntiVirus protection for more than 15,000 users on campus. This deal signifies the largest anti-virus software implementation at any Canadian University. Press release: http://net-security.org/cgi-bin/press/fullnews.cgi?newsid960244219,3499, SANTA CLARA, Calif., -- June 1, 2000 -- Cylink Corporation (NASDAQ: CYLK), a leading provider of security solutions for e-business, today announced it will work with Singapore-based StarHub to jointly offer secured network services to StarHub's corporate clients. As part of the agreement, StarHub will resell CylinkÆs comprehensive range of security appliances as a packaged offering to their customers. These appliances include NetHawk╘ and NetConneXion╘, CylinkÆs latest products providing LAN and WAN-based virtual private network (VPN) solutions. Press release: http://net-security.org/cgi-bin/press/fullnews.cgi?newsid959905890,55782, Virus information ----------------- VBS_GNUTELWORM Description: This is a nondestructive virus that executes if the path C:\PROGRAM FILES\GNUTELLA exists in the computer. This virus drops numerous .vbs files at /GNUTELLA and modifies gnutella.ini. This worm should not be confused with the GNUTella Search Tool and file sharing utility. Link: http://www.antivirus.com/pc-cillin/vinfo/virusencyclo/default5.asp?VName=VBS_GNUTELWORM VBS_TIMOFONICA Description: This VBS virus uses Microsoft Outlook to spam unsolicited emails to all address entries with itself as an attachment. The email has the subject: ôTIMOFONICAö and comes with the attachment TIMOFONICA.TXT.VBS.ö The body of the email is in Spanish. Link: http://www.antivirus.com/pc-cillin/vinfo/virusencyclo/default5.asp?VName=VBS_TIMOFONICA TROJ_MYPICVIEWER Description: This Trojan is disguised as a picture viewer. It overwrites WIN.COM in the Windows directory and deletes all files in the root and DOS directory. It also prints out messages from the victimÆs computer. If a PC is not connected to a printer, the Trojan does not execute its payload. Link: http://www.antivirus.com/pc-cillin/vinfo/virusencyclo/default5.asp?VName=TROJ_MYPICVIEWER Issue 15 - 30.05.2000 1) General security news 2) Security world 3) Virus information General security news -------------------------------- ANOTHER YAHOO GLITCH For the third time in recent months, Yahoo has acknowledged software glitches that have compromised the integrity of people's accounts. In the current instance, "My Yahoo" account holders found themselves shut out of their accounts, in some cases finding that other people had signed up successfully with their usernames. Link: http://news.cnet.com/news/0-1005-200-1933988.html SECURITY FLAW IN PGP 5.0 A flaw has been found in the randomness gathering code of PGP 5. PGP 5 will, under certain well-defined circumstances, generate public/private key pairs with no or only a small amount of randomness. Such keys are insecure. Link: http://net-security.org/cgi-bin/reports/fullnews.cgi?newsid959152226,98584, SETTING UP PORTSENTRY "So what exactly does this Portsentry do and why do you need it? Well, Portsentry is this very very cool security application.. Not good enough? Alright, that's fair. What Portsentry does is it listens on the ports you are not using for port scans. When it detects a scan, depending on how you set it up, it will then add them to your hosts.deny file and drop them through either ipchains or the route command. What this does is as soon as the person scanning you trips Portsentry, your computer stops responding to them..." Link: http://www.linuxnewbie.org/nhf/intel/security/portsentry1.html EXPERTS LECTURE FEDS ON CYBERSECURITY Congressional funding to curtail cybercrime has been focused on law enforcement and existing programs, but the real solution will come from education, research and development programs, federal officials said Tuesday. Link: http://www.fcw.com/fcw/articles/2000/0522/web-cyber-05-24-00.asp SECURITY PROFESSIONALS Mick is employed by IBM Global Services as a "white-hat" hacker. His days are spent trying to break into the computer networks of IBM's clients, either remotely on the Internet or in disguise by infiltrating the client's building and hacking into the computer system on site. Link: http://www.infowar.com/hacker/00/hack_052300a_j.shtml IS PKI SECURE ENOUGH? If e-commerce is a hot subject, then so is public key infrastructure (PKI). But what value does PKI really have? If you ask some experts, the answer is little value if any, and the cited reasons are many. Read the whole article on Win NT Magazine. Link: http://www.winntmag.com/Articles/Content/8843_01.html "THEORETICAL ISSUE" Microsoft responded to a security flaw reported by @Stake's L0pht Research Labs. Spokeswoman said the security hole "to date ... is a purely theoretical issue, and no customers have reported the problem to Microsoft." She added that the company "responded to this issue immediately" by providing the patch. Link: ComputerWorld article - http://www.infoworld.com/articles/hn/xml/00/05/25/000525hncert.xml Link: L0pht advisory - http://www.l0pht.com/advisories/msoua.txt Link: CERT advisory - http://www.cert.org/advisories/CA-2000-07.html Link: Microsoft's solution - http://www.net-security.org/cgi-bin/bugs/fullnews.cgi?newsid958236475,50914, SPEAKING BAN Kevin Mitnick will get some free high-powered legal help as he prepares to challenge a condition of his prison release that effectively bars him from writing or speaking about the computer industry. Link: http://news.cnet.com/news/0-1005-200-1951220.html?dtn.head TERRIBLE PRIVACY SITUATION If the Regulation of Investigatory Powers (RIP) Bill is passed in UK, internet service providers will be forced to install black boxes in their data centres that connect directly to an MI5 monitoring centre in London. Link: BBC article - http://news.bbc.co.uk/hi/english/sci/tech/newsid_762000/762514.stm Link: What is RIP bill? - http://net-security.org/cgi-bin/reports/fullnews.cgi?newsid957739742,92588, CURADOR CHARGED Raphael Gray, aka Curador has been charged this week with 10 offences under the UK's Computer Misuse Act. He also faces two charges of deception. Link: http://www.securitywatch.com/scripts/news/list.asp?AID=2854 WAP RELATED DEFACEMENT It looks like probably the first site created for usage with WAP (Wireless Application Protocol) was defaced. WAP version of Italian Wappi web site (http://wap.wappi.com) was changed by De Meestervervalser. Just a note - It cannot be seen by a normal browser, but you could see it from Gelon trough their emulator. Link: Site seen with Nokia GSM - http://www.gelon.net/cgi-bin/wapalize.cgi?url=http://wap.wappi.com Link: Screenshot (21kb) - http://www.net-security.org/misc/wap2805.jpg RUNNING A BSD-BASED FIREWALL Internet security is currently a hot topic. Because of that, many smaller networks are turning toward firewalls to give them some protection. Many of these networks do not have the money to pay for a commercial firewall product, so they are moving to free Unix-based firewalls such as IP Firewall, IP Filter or IPChains. Link: http://www.bsdtoday.com/2000/May/Features165.html FRANK VAN VLIET INTERVIEW by BHZ Tuesday 30 May 2000 on 4:34 PM LinuxSecurity.com has an interview with Frank van Vliet aka {}, the author of AuditFile and the man who recently pointed out to configuration errors on apache.org. Link: http://www.linuxsecurity.com/feature_stories/feature_story-47.html Security world -------------- LEESBURG, FL û May 22, 2000 û Network Associates McAfee Virus Scan, a leader in the anti-virus software industry, recently repealed its unjust ban of NetBus Pro 2.10, a remote administration tool by UltraAccess.net. McAfeeÆs change in attitude toward NetBus Pro 2.10 was not the result of backroom negotiations, but rather upon the advice of McAfeeÆs own legal counsel, according to Judd Spence, CEO of UltraAccess Networks Inc. Mr. Spence sees this as the first step in the vindication of NetBus Pro 2.10 among the anti-virus companies. Press release: http://net-security.org/cgi-bin/press/fullnews.cgi?newsid959014656,98635, LOS ALTOS, California, May 23, 2000 - InfoExpress, Inc., a leader in secure remote access and extranet solutions today announced an exclusive distribution agreement with U.K.-based Network Utilities (Systems) Ltd., a leading distributor of best-in-class enterprise security. The agreement names Network Utilities the sole provider of InfoExpress' marketing and technical support in the U.K. market. Press release: http://net-security.org/cgi-bin/press/fullnews.cgi?newsid959090959,5116, ISPCON Spring 2000ùOrlando, FLùMay 23ùIBM and Zero-Knowledge Systems today announced an agreement to provide the hardware platform for Zero-Knowledge's cryptographically assured global privacy infrastructure, the Freedom Network. Press release: http://net-security.org/cgi-bin/press/fullnews.cgi?newsid959214624,35970, SANTA CLARA, Calif., May 25 /PRNewswire/ -- McAfee Retail Software, a division of Network Associates, Inc. (Nasdaq: NETA), today announced McAfee Internet Guard Dog Pro, an all-in-one solution containing a personal firewall and parental controls to keep children safe while online. Parents are now able to protect their children from accessing questionable sites along with preventing unauthorized individuals from gaining access to their files. Press release: http://net-security.org/cgi-bin/press/fullnews.cgi?newsid959697420,11489, Note: If your company wants their press releases to be published on Help Net Security, please do mail your requests to press@net-security.org . All press releases could be found on: http://net-security.org/text/press/ Virus information ----------------- PE_KALA.15208 Risk rating: Low Virus type: File Infector Destructive: N Aliases: PE_KALA.15208, KALA.15208 Description: PE_KALA.15208 is a memory resident PE virus that appends 15,208 bytes to the files it infects. There are no visible symptoms of virus activity except the change in file size. More information: http://www.antivirus.com/pc-cillin/vinfo/virusencyclo/default5.asp?VName=PE_KALA.15208 O97M_CYBERNET.A Risk rating: Low Virus type: Macro Destructive: Y Aliases: CYBERNET.A, X97M/Cybernet@mm, CYBERNET, OF97/Cybernet-A Description: O97M_CYBERNET.A is a polymorphic, cross-infector macro virus that infects both Word documents and Excel worksheets and spreads via email as an attachment. SUBJECT: ôYouÆve GOT Mail !!!ö BODY: ôPlease, saved the document after you read and donÆt show to anyone else. The document is also VIRUS FREEà so DISREGARD the virus protection warning !!!ö On December 25 and August 17, this virus is triggered and it drops its various payloads: inserts figures in active document, inserts code in AUTOEXEC.BAT, modifies Config.sys and displays a message. More information: http://www.antivirus.com/pc-cillin/vinfo/virusencyclo/default5.asp?VName=O97M_CYBERNET.A VBS_FIREBURN.A Risk rating: Medium Destructive: N Description: This VB Script virus is currently in the wild. It spreads via Microsoft Outlook and mIRC and the email maybe in German or English. The email has the subject header: ôHi, how are you?ö and comes with an attachment that may have one of several file names. If the current system date is June 20th, the virus modifies registry and disables mouse and keyboards. It also displays a message before it modifies the registry. This virus runs using Windows Scripting Host (WSH). To execute, this virus uses the file WScript.EXE or CScript.EXE. Once this file has been disabled (eg. Deleted/Renamed/Moved), the virus no longer runs. More information: http://www.antivirus.com/pc-cillin/vinfo/virusencyclo/default5.asp?VName=VBS_FIREBURN.A W97M_RESUME.A Risk rating: Medium Virus type: Macro Destructive: Y Aliases: RESUME.A, RESUME, RESUME.WORM, W97M_MELISSA.BG, MELISSA.BG Description: W97M_RESUME.A is a Word macro virus that spreads via email using Microsoft Outlook. This macro virus does not infect document files and only acts as a worm. Once triggered it deletes all files in the root directories and sends out email to all addresses listed in the address book. The email has the subject: RESUME- JANET SIMONSö and comes with an attachment Explorer.doc, which contains this virus. Trend advises all email users to not open any email with above mentioned subject header and not click on any unsolicited attachments. More information: http://www.antivirus.com/pc-cillin/vinfo/virusencyclo/default5.asp?VName=W97M_RESUME.A Issue 13 - 20.05.2000 "New Love" is a new Visual Basic Script worm with a very damaging payload. Once executed, it tries to spam itself to all users in the Microsoft Outlook address book. When the worm is first run it drops a copy of itself in the Windows folder as either a name from the Recent Documents folder or a random Name and has a random extension chosen from Doc, Xls, Mdb, Bmp, Mp3, Txt, Jpg, Gif, Mov, Url, Htm, Txt and the real extension, ".vbs" The worm will modify that copy by adding random comments to its body. AV companies say that it is not spread around on the Internet (at least not yet). Information from Anti-Virus companies. Trend Micro (www.antivirus.com) Name: VBS_NEWLOVE.A More information: http://www.antivirus.com/pc-cillin/vinfo/virusencyclo/default5.asp?VName=VBS_NEWLOVE.A Latest virus pattern: http://pattern.download.antivirus.com/ftp/products/pattern/lpt708.zip AVP (www.avp.ch) Name: I-Worm.NewLove More information: http://www.avp.ch/avpve/worms/newlove.stm Latest virus pattern: http://www.avp.ch/E/updates.htm Sophos (www.sophos.com) Name: VBS/NewLove-A More information: http://www.sophos.com/virusinfo/analyses/vbsnewlovea.html Latest virus pattern: http://www.sophos.com/downloads/ide/newlovea.ide NAI (www.avertlabs.com) Name: VBS/Newlove.a More information: http://vil.nai.com/villib/dispvirus.asp?virus_k=98655 Latest virus pattern: http://download.nai.com/products/Mcafee-Avert/newlv4.zip F-Secure (www.f-secure.com) Name: VBS/Newlove.a More information: http://www.f-secure.com/v-descs/newlove.htm Latest virus pattern: http://www.f-secure.com/download-purchase/updates.html FInjan Software (www.finjan.com) Advisory: http://www.finjan.com/attack_release_detail.cfm?attack_release_id=37 Media outlets produced literally tons of articles about "New Love" worm: NewLove proves less costly http://www.cnnfn.com/2000/05/19/technology/virus/ New Love Virus Slow To Spread http://www.crn.com/dailies/digest/breakingnews.asp?ArticleID=16786 New virus hits computers http://news.ft.com/ft/gx.cgi/ftc?pagename=View&c=Article&cid=FT3ACD94G8C&live=true&tagid=ZZZC00L1B0C&subheading=information%20technology Deadlier virus does limited damage in aftermath of 'Love bug' http://news.cnet.com/news/0-1005-200-1902621.html?tag=st.ne.1430735..ni A New Virus Appears, Some Question the Fear http://dailynews.yahoo.com/h/nm/20000519/tc/tech_virus_2.html 'New Love' Virus Spawns Net Security Questions http://www.thestandard.com/article/display/0,1151,15306,00.html The Virus 'Ambulance Chasers' http://www.wired.com/news/technology/0,1282,36464,00.html "New Love" Threat http://www.nandotimes.com/technology/story/0,1643,500206111-500287071-501549577-0,00.html Network Associates downgrades "NewLove" threat http://news.cnet.com/news/0-1005-200-1903744.html?tag=st.ne.1430735..ni New Virus Shows Little Impact http://www.pcworld.com/pcwtoday/article/0,1510,16819,00.html Hacker Rails Against New Worm http://www.wired.com/news/technology/0,1282,36477,00.html New virus won't infect Macs http://www.idg.net/ic_179263_1794_9-10000.html Computer Associates Warns of New `Love Bug' Virus (Update2) http://quote.bloomberg.com/fgcgi.cgi?ptitle=Technology%20News&s1=blk&tp=ad_topright_ tech&T=markets_fgcgi_content99.ht&s2=blk&bt=ad_bottom_tech&s=AOSTy7hSiQ29tcHV0 Virus 'worse than Love Bug' on the loose http://www.vnunet.com/News/1101596 First British companies report NewLove virus http://www.zdnet.co.uk/news/2000/19/ns-15473.html Chameleon-like Virus Hits Internet http://www.apbnews.com/newscenter/internetcrime/2000/05/19/lovebug0519a_01.html New virus more vicious than Love Bug http://www.out-law.com/php/page.php3?page_id=newvirusmorevicio958745671 New Love: A Whole Lot of Nothing? http://www.wired.com/news/technology/0,1282,36455,00.html If you have any comments about the way th enews section is compiled, please direct them to me, because I compile it out of about 4 - 5 Net Sec issues - Slider. Well thats it folks.....The end of another great 0blivion production. Remember you can contact us in the following ways.... web: www.0blivioin.org email: cyberoptix@0blivion.org slider@0blivion.org IRD: #oblivionmag on Efnet