This command should be executed from the command line.

This diagnostic command displays protocol statistics and current TCP/IP connections
using NBT (NetBIOS over TCP/IP).

This means that Windows networking (ie: file and print sharing) is possible
between your computer and a remote computer, even though the connection is being
made across the 'net.



NetBIOS is a non-routable but very fast means of networking two or more computers.
Since 'routing' is impossible a network configuration known as peer-to-peer
will result. TCP/IP is a combined network protocol that is fully routable.



Wrapping net BIOS packets WITHIN TCP/IP packets allows the net BIOS packet to
be routed across a WAN, i.e. two or more LAN's can be connected via a WAN.

Nbtstat confirms that the remote computer is capable of connecting to your
machine, and indicates the scope of that connection.

If, whilst port scanning a remote machine, you find port 139 to be open, then
the 'nbtstat' command can be used to gain information from that machine.

Parameters:

If you need help with a virus infection or want more advanced information about
viruses, please see 'Dealing with virus infections:' and 'Sources of additional
information: near the end of this FAQ.

And if you don't read anything else, at least read the very first topic: "Why
should I care...".

Why should I care?[top]

Why should I care about computer viruses? Isn't all this just a bunch of hype
drummed up by marketing departments for anti-virus software companies?

I'm writing this in early May 1999. For the past week, the alt.comp.virus
newsgroup has been flooded with pleas for help from people whose computers were
clobbered by the CIH virus, which activated on April 26. Many of those people
wound up having to put in large amounts of time and effort to get their computers
operational; some people have had to buy replacement chips or pay for a repair
shop to get their systems back in operation. And some of those people have lost
data they will never be able to replace.



Yet the CIH virus was well-known almost a year before it activated, and virtually
every single current anti-virus program could handle it. But a lot of people
didn't have a-v software, and many of those who did have it didn't use it regularly
or keep it updated.



So a lot of people lost time, money, and irreplaceable data when the CIH virus
activated simply because they didn't take basic precautions to protect themselves.



The virus threat is not going away: from reading the alt.comp.virus newsgroup,
it's obvious that there are lots of people who would just love to create the
same kind of havoc with their own virus creations.

------------------------

1. What is a computer virus? [top]

A computer virus is a program designed to spread itself by first infecting
executable files or the system areas of hard and floppy disks and then making
copies of itself. Viruses usually operate without the knowledge or desire of
the computer user.

2. What kind of files can spread viruses?
[top]

Viruses have the potential to infect any type of executable code, not just
the files that are commonly called 'program files'. For example, some viruses
infect executable code in the boot sector of floppy disks or in system areas
of hard drives. Another type of virus, known as a 'macro' virus, can infect
word processing and spreadsheet documents that use macros. And it's possible
for HTML documents containing JavaScript or other types of executable code to
spread viruses or other malicious code.

Since virus code must be executed to have any effect, files that the computer
treats as pure data are safe. This includes graphics and sound files such as
.gif, .jpg, .mp3, .wav, etc., as well as plain text in .txt files. For example,
just viewing picture files won't infect your computer with a virus. The virus
code has to be in a form, such as an .exe program file or a Word .doc file,
that the computer will actually try to execute.

3. How do viruses spread? [top]

When you execute program code that's infected by a virus, the virus code will
also run and try to infect other programs, either on the same computer or on
other computers connected to it over a network . And the newly infected programs
will try to infect yet more programs.

When you share a copy of an infected file with other computer users, running
the file may also infect their computers; and files from those computers may
spread the infection to yet more computers.

If your computer is infected with a boot sector virus, the virus tries to write
copies of itself to the system areas of floppy disks and hard disks. Then the
infected floppy disks may infect other computers that boot from them, and the
virus copy on the hard disk will try to infect still more floppies.

Some viruses, known as 'multipartite' viruses, can spread both by infecting
files and by infecting the boot areas of floppy disks.

4. What do viruses do to computers? [top]

Viruses are software programs, and they can do the same things as any other
programs running on a computer. The actual effect of any particular virus depends
on how it was programmed by the person who wrote the virus.

Some viruses are deliberately designed to damage files or otherwise interfere
with your computer's operation, while others don't do anything but try to spread
themselves around. But even the ones that just spread themselves are harmful,
since they damage files and may cause other problems in the process of spreading.

Note that viruses can't do any damage to hardware: they won't melt down your
CPU, burn out your hard drive, cause your monitor to explode, etc. Warnings
about viruses that will physically destroy your computer are usually hoaxes,
not legitimate virus warnings.

5. What is a Trojan horse program? [top]

A type of program that is often confused with viruses is a 'Trojan horse' program.
This is not a virus, but simply a program (often harmful) that pretends to be
something else.

For example, you might download what you think is a new game; but when you
run it, it deletes files on your hard drive. Or the third time you start the
game, the program E-mails your saved passwords to another person.

Note: simply downloading a file to your computer won't activate a virus or
Trojan horse; you have to execute the code in the file to trigger it. This could
mean running a program file, or opening a Word/Excel document in a program (such
as Word or Excel) that can execute any macros in the document.

6. What's the story on viruses and E-mail? [top]

You can't get a virus just by reading a plain-text E-mail message or Usenet
post. What you have to watch out for are encoded messages containing embedded
executable code (i.e., JavaScript in an HTML message) or messages that include
an executable file attachment (i.e., an encoded program file or a Word document
containing macros).

In order to activate a virus or Trojan horse program, your computer has to
execute some type of code. This could be a program attached to an E-mail, a
Word document you downloaded from the Internet, or something received on a floppy
disk. There's no special hazard in files attached to Usenet posts or E-mail
messages: they're no more dangerous than any other file.

7. What can I do to reduce the chance of getting viruses
from E-mail? [top]

Treat any file attachments that might contain executable code as carefully
as you would any other new files: save the attachment to disk and then check
it with an up-to-date virus scanner before opening the file.

If your E-mail or news software has the ability to automatically execute JavaScript,
Word macros, or other executable code contained in or attached to a message,
I strongly recommend that you disable this feature.

My personal feeling is that if an executable file shows up unexpectedly attached
to an E-mail, you should delete it unless you can positively verify what it
is, who it came from, and why it was sent to you.

The recent outbreak of the Melissa virus was a vivid demonstration of the need
to be extremely careful when you receive E-mail with attached files or documents.
Just because an E-mail appears to come from someone you trust, this does NOT
mean the file is safe or that the supposed sender had anything to do with it.

------------------------

Some general tips on avoiding virus infections: [top]

1. Install anti-virus software from a well-known, reputable company, UPDATE
it regularly, and USE it regularly.

New viruses come out every single day; an a-v program that hasn't been updated
for several months will not provide much protection against current viruses.

2. In addition to scanning for viruses on a regular basis, install an 'on access'
scanner (included in most good a-v software packages) and configure it to start
automatically each time you boot your system. This will protect your system
by checking for viruses each time your computer accesses an executable file.

3. Virus scan any new programs or other files that may contain executable code
before you run or open them, no matter where they come from. There have been
cases of commercially distributed floppy disks and CD-ROMs spreading virus infections.

4. Anti-virus programs aren't very good at detecting Trojan horse programs,
so be extremely careful about opening binary files and Word/Excel documents
from unknown or 'dubious' sources. This includes posts in binary newsgroups,
downloads from web/ftp sites that aren't well-known or don't have a good reputation,
and executable files unexpectedly received as attachments to E-mail or during
an on-line chat session.

5. If your E-mail or news software has the ability to automatically execute
JavaScript, Word macros, or other executable code contained in or attached to
a message, I strongly recommend that you disable this feature.

6. Be _extremely_ careful about accepting programs or other files during on-line
chat sessions: this seems to be one of the more common means that people wind
up with virus or Trojan horse problems. And if any other family members (especially
younger ones) use the computer, make sure they know not to accept any files
while using chat.

7. Do regular backups. Some viruses and Trojan horse programs will erase or
corrupt files on your hard drive, and a recent backup may be the only way to
recover your data.

Ideally, you should back up your entire system on a regular basis. If this
isn't practical, at least backup files that you can't afford to lose or that
would be difficult to replace: documents, bookmark files, address books, important
E-mail, etc.

------------------------

Dealing with virus infections: [top]

First, keep in mind "Nick's First Law of Computer Virus Complaints":

"Just because your computer is acting strangely or one of your programs
doesn't work right, this does NOT mean that your computer has a virus."

1. If you haven't used a good, up-to-date anti-virus program on your computer,
do that first. Many problems blamed on viruses are actually caused by software
configuration errors or other problems that have nothing to do with a virus.

2. If you do get infected by a virus, follow the directions in your anti-virus
program for cleaning it. If you have backup copies of the infected files, use
those to restore the files. Check the files you restore to make sure your backups
weren't infected.

3. For assistance, check the web site and support services for your anti-virus
software.

4. The "[alt.comp.virus] FAQ Part 1/4" (see below) includes an excellent
section on initial steps for dealing with a suspected virus infection.

5. For discussions about viruses and help dealing with them, visit <news:alt.comp.virus>
or <news:comp.virus>; please
check the newsgroup FAQs before posting. Keep in mind that posters in c.v and
in a.c.v, like posters in any newsgroup, have a wide range of technical expertise
and motivations.

Note: in general, drastic measures such as formatting your hard drive or using
FDISK should be avoided. They are frequently useless at cleaning a virus infection,
and may do more harm than good unless you're very knowledgeable about the effects
of the particular virus you're dealing with.

------------------------

What is the best anti-virus software available? [top]

Posters in the alt.comp.virus newsgroup have been discussing that for years
and still haven't reached a consensus. :-)

The following web sites have sections with reviews of various a-v programs:

<http://www.zdnet.com/pcmag/features/utilities98/antivirus/index.html>;


<http://www.uta.fi/laitokset/virus/>;


<http://agn-www.informatik.uni-hamburg.de/vtc/naveng.htm>>

------------------------

Sources of additional information: [top]

For more information, and advice on avoiding and dealing with virus infections,
see the FAQs for <news:comp.virus>
and <news:alt.comp.virus>:

"VIRUS-L/comp.virus Frequently Asked Questions (FAQ)" "[alt.comp.virus]
FAQ" (currently parts 1 to 4) "ALT.COMP.VIRUS MINI-FAQ - READ BEFORE
POSTING" "Viruses and the Mac FAQ"

You can find the FAQs in the above newsgroups, in <news:news.answers>,
or in the Usenet FAQ archive at <http://www.faqs.org/faqs/computer-virus>.>

Another source of information is the data on the web sites of anti-virus software
companies. You can find many anti-virus software companies listed in the Virus' Target='_BLANK'>http://www.yahoo.com/Business_and_Economy/Companies/Computers/Software/System_Utilities/Utilities/Virus_Protection/">irus
Protection section of the Yahoo directory, at

Links to a variety of pages with virus-related information can be found in
the
Virus section of Yahoo, at

A useful site for Macintosh virus information is <http://www.macvirus.com/>.>

The newsgroups <news:comp.virus>
and <news:alt.comp.virus>
are available for information, assistance, and discussions of all aspects of
computer viruses. Please check the FAQs before posting.

For information about some of the virus hoaxes and bogus warnings that you
may run into on-line, see my 'Scams and Hoaxes FAQ', available at <http://www.faqs.org/faqs/net-abuse-faq/scams/>;
or in the newsgroup <news:news.newusers.questions>.

Note: this FAQ is updated occasionally. Copies posted to the new user newsgroups
should be current, but if you found this FAQ somewhere else, please see <http://www.faqs.org/faqs/computer-virus/new-users>;
for the latest version

Websites today are more complex than ever, containing a lot of dynamic content
making the experience for the user more enjoyable. Dynamic content is achieved
through the use of web applications which can deliver different output to
a user depending on their settings and needs. Dynamic websites have a threat
that static websites don't, called "Cross Site Scripting" (or XSS dubbed by
other security professionals). Currently small informational tidbits about
Cross Site Scripting holes exist but none really explain them to an average
person or administrator. This FAQ was written to provide a better understanding
of this emerging threat, and to give guidance on detection and prevention.

"What is Cross Site Scripting?"

Cross site scripting (also known as XSS) occurs when a web application gathers
malicious data from a user. The data is usually gathered in the form of a
hyperlink which contains malicious content within it. The user will most likely
click on this link from another website, web board, email, or from an instant
message. Usually the attacker will encode the malicious portion of the link
to the site in HEX (or other encoding methods) so the request is less suspicious
looking to the user when clicked on. After the data is collected by the web
application, it creates an output page for the user containing the malicious
data that was originally sent to it, but in a manner to make it appear as
valid content from the website.

"What does XSS and CSS mean?"

Often people refer to Cross Site Scripting as CSS. There has been a lot
of confusion with Cascading Style Sheets (CSS) and cross site scripting. Some
security people refer to Cross Site Scripting as XSS. If you hear someone
say "I found a XSS hole", they are talking about Cross Site Scripting for
certain.

"What are the threats of Cross Site Scripting?"

Version 1.3

Last Modified on: Thu Nov 11 18:18:19 PST 1999

The master copy of this FAQ is currently kept at

http://www.whitefang.com/rin/

The webpage also contains material that supplements this FAQ, along
with a very spiffy html version.

If you wish to mirror it officially, please contact me for details.

Copyright

I, Thamer Al-Herbish reserve a collective copyright on this FAQ. Individual
contributions made to this FAQ are the intellectual property of the contributor.

I am responsible for the validity of all information found in this FAQ.

This FAQ may contain errors, or inaccurate material. Use it at your
own risk. Although an effort is made to keep all the material presented
here accurate, the contributors and maintainer of this FAQ will not be
held responsible for any damage -- direct or indirect -- which may result
from inaccuracies.

You may redistribute this document as long as you keep it in its current
form, without any modifications. Please keep it updated if you decide
to place it on a publicly accessible server.

Introduction

The following FAQ attempts to answer questions regarding raw IP or low
level IP networking, including raw sockets, and network monitoring APIs
such as BPF and DLPI.

Additions and Contributions

If you find anything you can add, have some corrections for me or would
like a question answered, please send email to:

Thamer Al-Herbish href="mailto:shadows@whitefang.com"> &lt;shadows@whitefang.com>;

Please remember to include whether or not you want your email address
reproduced on the FAQ (if you're contributing). Also remember that you
may want to post your question to Usenet, instead of sending it to me.
If you get a response which is not found on this FAQ, and you feel is
relevant, mail me both copies and I'll attempt to include it.

Also a word on raw socket bugs. I get approximately a couple of emails
a month about them, and sometimes I just can't verify if the bug exists
on a said system. Before mailing in the report, double check with my example
source code. If it looks like it's a definite bug, then mail it in.

Special thanks to John W. Temples href="mailto:john@whitefang.com">
&lt;john@whitefang.com>; for his constant healthy criticism and
editing of the FAQ.

Credit is given to the contributor as his/her contribution appears in
the FAQ, along with a list of all contributors at the end of this document.

A final note, a Raw IP Networking mailing list is up. You can join by
sending an empty message to href="mailto:rawip-subscribe@whitefang.com">
rawip-subscribe@whitefang.com

Caveat

This FAQ covers only information relevant to the UNIX environment.

Table of Contents

• 1) General Questions:








• 1.1) What tools/sniffers can I use to monitor my network?
  



• 1.2) What packet capturing facilities are available?
  



• 1.3) Is there a portable API I can use to capture
  packets?



• 1.4) How does a packet capturing facility work?
  



• 1.5) How do I limit packet loss when sniffing a network?
  



• 1.6) What is packet capturing usually used for?
  



• 1.7) Will I have to replace any packets captured
  off the network?



• 1.8) Is there a portable API to send raw packets
  into a network?



• 1.9) Are there any high level language APIs (Not
  C) for raw IP access?







• 2) RAW socket questions:








• 2.1) What is a RAW socket?



• 2.2) How do I use a raw socket?








• 2.2.1) How do I send a TCP/IP packet through a
  raw socket?



• 2.2.2) How do I build a TCP/IP packet?



• 2.2.3) How can I listen for packets with a raw
  socket?







• 2.3) What bugs should I look out for when using a
  raw socket?








• 2.3.1) IP header length/offset host/network byte
  order (feature/bug?)



• 2.3.2) Unwanted packet processing on some systems.
  





• 2.4) What are raw sockets commonly used for?
  







• 3) libpcap (A Portable Packet Capturing Library)
  








• 3.1) Why should I use libpcap, instead of using the
  native API on my operating system for packet capturing?



• 3.2) Does libpcap have any disadvantages which I
  should be aware of?



• 3.3) Where can I find example libpcap source code?
  







• 4) List of contributors

• 
  
  

  1) General Questions:

  
  
  
  
  • 
    
    

    1.1) What tools/sniffers can I use to monitor
    my network?

    
    
    

    Depending on your operating system, the following is an incomplete
    list of available tools:

    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    tcpdump:

    Found out-of-the-box on most BSD variants, and also available separately from ftp://ftp.ee.lbl.gov/tcpdump.tar.Z along with libpcap (see below) and various other tools. This tool, in particular, has been ported to multiple platforms thanks to libpcap.

    ipgrab

    Compatible with many systems. ipgrab displays link level, transport level, and network level information on packets captured verbosely. http://www.xnet.com/~cathmike/MSB/Software/

    Ethereal

    (GUI) A network packet analyzer (uses GTK+). Supports many systems. Available at: http://ethereal.zing.org/

    tcptrace:

    http://jarok.cs.ohiou.edu/software/tcptrace/tcptrace.html Not an actual sniffer, but can read from the logs produced by many other well known sniffers to produce output in different formats and in adjustable details (includes diagnostics).

    tcpflow

    http://www.circlemud.org/~jelson/software/tcpflow/ tcpflow is a program that captures data transmitted as part of TCP connections (flows), and stores the data in a way that is convenient for protocol analysis or debugging.

    snoop:

    Solaris, IRIX.

    etherfind:

    SunOS.

    Packetman:

    SunOS, DEC-MIPS, SGI, DEC-Alpha, and Solaris. Available at ftp://ftp.cs.curtin.edu.au:/pub/netman/

    nettl/ntfmt:

    HP/UX

    
    
  
  
  
  
  
  • 
    
    

    1.2) What packet capturing facilities are available?
    

    
    
    

    Depending on your operating system (different versions may vary):
    

    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    BPF:

    Berkeley Packet Filter. Commonly found on BSD variants.

    DLPI:

    Data Link Provider Interface. Solaris, HP-UX, SCO Openserver.

    NIT:

    Network Interface Tap. SunOS 3.

    SNOOP:

    (???). IRIX.

    SNIT:

    STREAMS Network Interface Tap. SunOS 4.

    SOCK_PACKET:

    Linux.

    LSF:

    Linux Socket Filter. Is available on Linux 2.1.75 onwards.

    drain:

    Used to snoop packets dropped by the OS. IRIX.

    
    
  
  
  
  
  
  • 
    
    

    1.3) Is there a portable API I can use to capture
    packets?

    
    
    

    Yes. libpcap from
    ftp://ftp.ee.lbl.gov/libpcap.tar.Z attempts to provide a
    single API that interfaces with different OS-dependent packet
    capturing APIs. It's always best, of course, to learn the underlying
    APIs in case this library might hide some interesting features.
    It's important to warn the reader that I have seen different versions
    of libpcap break backward compatibility.

    
    
  
  
  • 
    
    

    1.4) How does a packet capturing facility work?
    

    
    
    

    The exact details are dependent on the operating system. However,
    the following will attempt to illustrate the usual technique used
    in various implementations:

    
    
    

    The user process opens a device or issues a system call which
    gives it a descriptor with which it can read packets off the wire.
    The kernel then passes the packets straight to the process.

    
    
    

    However, this wouldn't work too well on a busy network or a
    slow machine. The user process has to read the packets as fast
    as they appear on the network. That's where buffering and packet
    filtering come in.

    
    
    

    The kernel will buffer up to X bytes of packet data, and pass
    the packets one by one at the user's request. If the amount exceeds
    a certain limit (resources are finite), the packets are dropped
    and are not placed in the buffer.

    
    
    

    Packet filters allow a process to dictate which packets it's
    interested in. The usual way is to have a set of opcodes for routines
    to perform on the packet, reading values off it, and deciding
    whether or not it's wanted. These opcodes usually perform very
    simple operations, allowing powerful filters to be constructed.
    

    
    
    

    BPF filters and then buffers; this is optimal since the buffer
    only contains packets that are interesting to the process. It's
    hoped that the filter cuts down the amount of packets buffered
    to stop overflowing the buffer, which leads to packet loss.

    
    
    

    NIT, unfortunately, does not do this; it applies the filter
    after buffering, when the user process starts to read from the
    buffered data.

    
    
    

    According to route href="mailto:route@infonexus.com"> &lt;route@infonexus.com>;
    Linux' SOCK_PACKET does not do any buffering and has no kernel
    filtering.

    
    
    

    Your mileage may vary with other packet capturing facilities.
    

    
    
  
  
  • 
    
    

    1.5) How do I limit packet loss when sniffing
    a network?

    
    
    

    If you're experiencing a lot of packet loss, you may want to
    limit the scope of the packets read by using filters. This will
    only work if the filtering is done before any buffering. If this
    still doesn't work because your packet capturing facility is broken
    like NIT, you'll have to read the packets faster in a user process
    and send them to another process -- basically attempt to do additional
    buffering in user space.

    
    
    

    Another way of improving performance, is by using a larger buffer.
    On Irix using SNOOP, the man page recommends using SO_RCVBUF.
    On BSD with BPF one can use the BIOCSBLEN ioctl call to increase
    the buffer size. On Solaris bufmod and pfmod can be used for altering
    buffer size and filters respectively.

    
    
    

    Remember, the longer your process is busy and not attending
    the incoming packets, the quicker they'll be dropped by the kernel.
    

    
    
  
  
  • 
    
    

    1.6) What is packet capturing usually used for?
    

    
    
    

    (Question suggested by Michael T. Stolarchuk href="mailto:mts@rare.net">
    &lt;mts@rare.net>; along with some suggestions for the
    answer.)

    
    

    
    

    
    
    • 
      
      

      Network diagnostics such as the verification of a network's
      setup, examples are tools like arp, that report the ARP messages
      sent from hosts.

      
      
    
    
    • 
      
      

      Reconstruction of end to end sessions. tcpshow attempts to
      do this, but more sophisticated examples are the array of
      security tools which try to keep tabs on network connections.
      

      
      
    
    
    • 
      
      

      Monitoring network load. Probably one of the most practical
      uses, a lot of commercial products usually use specialized
      hardware to accomplish this.

      
      
    
    
    
    
  
  
  • 
    
    

    1.7) Will I have to replace any packets captured
    off the network?

    
    
    

    No, the packet capturing facilities mentioned make copies of
    the packets, and do not remove them from the system's TCP/IP stack.
    If you wish to prevent packets from reaching the TCP/IP stack
    you need to use a firewall, (which should be able to do packet
    filtering). Don't confuse the packet filtering done by packet
    capturing facilities with those done by firewalls. They serve
    different purposes.

    
    
  
  
  • 
    
    

    1.8) Is there a portable API to send raw packets
    into a network?

    
    
    

    Yes, route href="mailto:routeroute@infonexus.com"> &lt;route@infonexus.com>;
    maintains Libnet, a library that provides an API for low
    level packet writing and handling. It serves as a good compliment
    for libpcap, if you wish to read and write packets. The project's
    webpage can be found at:

    
    
    

    http://www.packetfactory.net/libnet/
    

    
    
  
  
  • 
    
    

    1.9) Are there any high level language APIs
    (Not C) for raw IP access?

    
    
    

    A PERL module that gives access to raw sockets is available at:
    

    
    
    

    http://quake.skif.net/RawIP/