annlee wrote:
>
> Since the original question related to virus and certain ports,
> etc., here's
> a good reference to keep an eye on:
>
> http://isc.incidents.org/
Great! There you have it. NetBIOS port 137 at the top of the list. Since
broadcasts aren't carried across a router, the attackers don't send as
broadcasts, as a real Windows station would. But who says the attackers have
to behave like real stations? :-0
I'm sure most personal firewall default to blocking the NetBIOS ports. I
think it's a good idea to block on global firewalls too.
I wish I hadn't published my Windows troubleshooting information exclusively
with a company that essentially swallowed it and made it disappear. Here's
an excerpt from it, FYI. It was mostly written by my co-author, Joe Bardwell.
The terminology of NetBIOS communication can be confusing. This is because
the NetBIOS acronym has been used to describe more than one thing. NetBIOS
refers to the programming interface in all implementations. In the
NetBIOS/TCP environment, the term NetBIOS also refers to the portion of the
packet that carries NetBIOS commands, replies, and data. In the
NetBIOS/NetBEUI environment, the term NetBIOS refers only to the API, and
the term NetBEUI refers to the protocol. In the NetBIOS/IPX environment, the
term NetBIOS refers to both the API and to the protocol. To understand the
details of terminology use, it’s worthwhile to examine the three different
frame structures for TCP, NetBEUI, and IPX.
A Windows Internet Name Service Query Carried on UDP
The NetBIOS/TCP implementation includes NetBIOS commands, replies, and data
carried on both TCP and UDP. When a station wants to determine the IP
address associated with a particular NetBIOS name, it sends a Windows
Internet Name Service (WINS) query which is carried on top of UDP. In this
case, there is no specific NetBIOS header in the packet, as seen in the
following analyzer output. The packet simply carries a NetBIOS Name Service
command directly above UDP.
Ethernet Header
Destination: FF:FF:FF:FF:FF:FF Ethernet Broadcast
Source: 00:60:08:15:A6:9B
Protocol Type:0x0800 IP
IP Header - Internet Protocol Datagram
Version: 4
Header Length: 5 (20 bytes)
Type of Service: %00000000
Precedence: Routine,Normal Delay,Normal Throughput,Normal
Reliability
Total Length: 78
Identifier: 43062
Fragmentation Flags: %000 May Fragment Last Fragment
Fragment Offset: 0 (0 bytes)
Time To Live: 128
Protocol: 17 UDP
Header Checksum: 0x1781
Source IP Address: 192.216.124.55
Dest. IP Address: 192.216.124.255
No IP Options
UDP - User Datagram Protocol
Source Port: 137 NETBIOS Name Service
Destination Port: 137
Length: 58
Checksum: 0x8FD2
NetBIOS Name Service - Network Basic Input/Output System
Identification: 0x883A
Parameter: 0x0110
Request
Standard Query
Recursion Desired
Packet Was Broadcast
Number of Questions: 1
Number of Answers: 0
Number of Authority: 0
Number of Additional: 0
Query Domain Name: MIKE-PC Server Service
Query Type: 32 NetBIOS General Name Service
Query Class: 1 Internet
Frame Check Sequence: 0x59DF750B
A TCP NetBIOS Session Setup Request
After determining the IP address of a target node, a NetBIOS/TCP station
resolves the IP address to a data-link-layer address by sending an Address
Resolution Protocol (ARP) frame. (The station uses the data-link-layer
address of the Default Gateway for remote targets). Next, the station
establishes a TCP session with the target in the normal manner with a TCP
three-way handshake. Using the established TCP session, the originator must
now create a NetBIOS session. The following packet is an example of a
NetBIOS Session Setup request.
Flags: 0x00
Status: 0x01
Packet Length:130
Ethernet Header
Destination: 00:40:95:96:30:07
Source: 00:60:08:15:A6:9B
Protocol Type:0x0800 IP
IP Header - Internet Protocol Datagram
Version: 4
Header Length: 5 (20 bytes)
Type of Service: %00000000
Precedence: Routine, Normal Delay, Normal Throughput, Normal
Reliability
Total Length: 112
Identifier: 43830
Fragmentation Flags: %010 Do Not Fragment Last Fragment
Fragment Offset: 0 (0 bytes)
Time To Live: 128
Protocol: 6 TCP
Header Checksum: 0xD53B
Source IP Address: 192.216.124.55
Dest. IP Address: 192.216.124.45
No IP Options
TCP - Transport Control Protocol
Source Port: 2882 ndtp
Destination Port: 139 netbios-ssn
Sequence Number: 324647931
Ack Number: 350227873
Offset: 5
Reserved: %000000
Code: %011000
Ack is valid
Push Request
Window: 8760
Checksum: 0xBBCD
Urgent Pointer: 0
No TCP Options
NetBIOS Session Service - Network Basic Input/Output System
Packet Type: 0x81 Session Request
Flags: 0x00 Length Extension Off
Length: 68
Called Name: MIKE-PC Server Service
Calling Name: MOUNIR Workstation
Frame Check Sequence: 0x0AA945E1
If the WINS query and the NetBIOS Session Setup packets are compared, it can
be seen that the behavior desired by the NetBIOS programming interface in
the sending machine is manifested as information in the WINS or NetBIOS
Session Service header. In these cases, the NetBIOS portion of the stack
actually has a job to perform outside the specific needs of the host
application program. The application program may simply want to download a
file, but the underlying mechanism of the NetBIOS interface has needs of its
own, and protocol operations to fulfill those needs. After NetBIOS has done
its setup work, then the NetBIOS aspect of the packets cease to manifest any
behavior. NetBIOS simply forms a thin layer inside the packet, as
illustrated by the protocol analyzer output in the next section.
TCP NetBIOS Data
Notice in the next packet that the NetBIOS header does not contain any verb.
It isn’t a command or a reply; it simply conveys a length and some simple
control information. The management of the data exchange is handled by TCP.
TCP sequences the bytes, sends acknowledgments, recovers corrupted or lost
frames with retransmissions, and manages memory with flow control. All of
the behavior is relegated to TCP and is not handled by NetBIOS.
Flags: 0x00
Status: 0x01
Packet Length:180
Ethernet Header
Destination: 00:40:95:96:30:07
Source: 00:60:08:15:A6:9B
Protocol Type:0x0800 IP
IP Header - Internet Protocol Datagram
Version: 4
Header Length: 5 (20 bytes)
Type of Service: %00000000
Precedence: Routine, Normal Delay, Normal Throughput, Normal
Reliability
Total Length: 162
Identifier: 44598
Fragmentation Flags: %010 Do Not Fragment Last Fragment
Fragment Offset: 0 (0 bytes)
Time To Live: 128
Protocol: 6 TCP
Header Checksum: 0xD209
Source IP Address: 192.216.124.55
Dest. IP Address: 192.216.124.45
No IP Options
TCP - Transport Control Protocol
Source Port: 2882 ndtp
Destination Port: 139 netbios-ssn
Sequence Number: 324648359
Ack Number: 350228140
Offset: 5
Reserved: %000000
Code: %011000
Ack is valid
Push Request
Window: 8493
Checksum: 0xFEFB
Urgent Pointer: 0
No TCP Options
NetBIOS Session Service - Network Basic Input/Output System
Packet Type: 0x00 Session Message
Flags: 0x00 Length Extension Off
Length: 118
SMB - Server Message Block
Protocol ID: SMB
Command Code: 37 Transaction - Name, Bytes In/Out
Error Code Class: 0x00 Success
Reserved: 0x00
Error Code: 0 Success
Flags: 0x18
Request
Pathnames Are Without Case
Pathnames Are Already In Canonicalized Format
Flags2: 0x8003
Application Understands Long File Names
Application Understands Extended Attributes
Application Understands Unicode Strings
Reserved:
............ 8D 80 00 00 00 00 00 00 00 00 00 00
Tree ID (TID): 0x0800
Process ID (PID): 0xDCA0
User ID (UID): 0x0800
Multiplex ID (MID): 0x0040
SMB Transaction - Name, Bytes In/OutRequest
Word Count: 14
Total Param Bytes: 26
Total Data Bytes: 0
Param Bytes To Recv: 8
Data Bytes To Recv: 4200
Setup Bytes To Recv: 0
Reserved: 0x00
Flags: 0x0000
Timeout (millisec.): 5000
Reserved: 0x0000
Params This Buffer: 26
Params Bytes Offset: 92
Data This Buffer: 0
Data Bytes Offset: 0
Setup Word Count: 0
Reserved: 0x00
Byte Count: 55
File Pathname:
Parameter And Data Bytes:
..h.WrLehDO.B16B 00 00 68 00 57 72 4C 65 68 44 4F 00 42 31 36 42
BDz...h.....z 42 44 7A 00 01 00 68 10 FF FF FF FF 7A
According to NetBIOS, the preceding packet contains 118 bytes of NetBIOS
data, as seen by the value of the Length field in the NetBIOS header. IP is
carrying a total length of 162 bytes, which can be broken down as follows:
20 bytes for the IP header
20 bytes for the TCP header
4 bytes for the NetBIOS header
118 bytes of NetBIOS data
162 Total Bytes carried by IP
When the 14-byte Ethernet header is added in, along with the 4-byte
checksum, the value reported by the EtherPeek protocol analyzer (Packet
Length: 180) is obtained. The 118 bytes of NetBIOS data are actually the
bytes making up the Server Message Block (SMB) session data.
NetBEUI Data Exchange (a Browse Packet)
The next packet is a NetBEUI packet that contains 44 bytes of NetBIOS data.
In this case, the data is also SMB data, as it was with the TCP example, but
it happens to be a Browse frame. Nonetheless, the commonality with
NetBIOS/TCP remains; both implementations are carrying some amount of
NetBIOS data. It’s important to note that the NetBEUI portion of the packet
is carried directly on top of the Layer-2 LLC header. There is no Layer 3
identifier (such as an IP address) in a NetBEUI packet. This is why NetBEUI
is non-routable. Notice, also, that the NetBEUI/NetBIOS header is not simply
a thin, behaviorless layer as was seen with NetBIOS/TCP. There is a command
code in the header. There’s also a sequence and acknowledgment mechanism
(the Xmit/Resp Correlator number) in the header. The NetBEUI implementation
doesn’t use any lower-layer protocols to perform part of the work. The
NetBEUI protocol stack handles all of the communication work relative to
NetBIOS.
Flags: 0x80 802.3
Status: 0x01
Packet Length:184
802.3 Header
Destination: 03:00:00:00:00:01
Source: 00:40:95:11:56:DE
LLC Length: 166
802.2 Logical Link Control (LLC) Header
Dest. SAP: 0xF0 NetBEUI/NetBIOS
Source SAP: 0xF0 NetBEUI/NetBIOS
Command: 0x03 Unnumbered Information
NetBEUI/NetBIOS - Network Basic Input/Output System
Length: 44
NetBIOS Delimiter: 0xEFFF
Command: 0x08 Datagram(Wait)
Option Data 1: 0x00 Reserved
Option Data 2: 0x0000 Reserved
Xmit/Resp Correlator: 0x00000000
Destination Name: AG-TRAIN
Source Name: SOCRATES
SMB - Server Message Block
Protocol ID: SMB
Command Code: 37 Transaction - Name, Bytes In/Out
Error Code Class: 0x00 Success
Reserved: 0x00
Error Code: 0 Success
Flags: 0x00
Request
Pathnames Are Case Sensitive
Flags2: 0x0000
Reserved:
............ 00 00 00 00 00 00 00 00 00 00 00 00
Tree ID (TID): 0x0000
Process ID (PID): 0x0000
User ID (UID): 0x0000
Multiplex ID (MID): 0x0000
SMB Transaction - Name, Bytes In/OutRequest
Word Count: 17
Total Param Bytes: 0
Total Data Bytes: 33
Param Bytes To Recv: 0
Data Bytes To Recv: 0
Setup Bytes To Recv: 0
Reserved: 0x00
Flags: 0x0000
Timeout (millisec.): 1000
Reserved: 0x0000
Params This Buffer: 0
Params Bytes Offset: 0
Data This Buffer: 33
Data Bytes Offset: 86
Setup Word Count: 3
Reserved: 0x00
Additional Setup Bytes:
...... 01 00 00 00 02 00
Byte Count: 50
Transaction Name: \MAILSLOT\BROWSE
Parameter And Data Bytes:
......SOCRATES.. 0F 00 80 FC 0A 00 53 4F 43 52 41 54 45 53 00 00
........K.....U. 00 00 00 00 00 00 04 00 4B 10 04 00 0F 01 55 AA
.. 00 04
IPX Name Query
In the NetBEUI and IPX implementations, there is nothing corresponding to
the centralized name server concept embodied in WINS. All name queries must
be broadcast. Following is an example of a NetWare NetBIOS packet. The
NetBIOS header is carried directly on top of IPX and includes a number of
reserved (padding) bytes. This packet structure is different from the
NetBEUI and TCP implementations of NetBIOS.
An optional (and not present in this packet) field at the beginning of the
NetBIOS header can list up to seven different networks that have been
crossed by a broadcast NetBIOS packet. An IPX router knows how to update
this field and to limit the scope of the Novell NetBIOS broadcast range.
Flags: 0x80 802.3
Status: 0x01
Packet Length:98
802.3 Header
Destination: FF:FF:FF:FF:FF:FF Ethernet Broadcast
Source: 00:40:95:11:56:DE
Length: 80
IPX - NetWare Protocol
Checksum: 0xFFFF
Length: 80
Transport Control:
Reserved: %0000
Hop Count: %0000
Packet Type: 20 NetBIOS
Destination Network: 0x00000000
Destination Node: FF:FF:FF:FF:FF:FF Ethernet Broadcast
Destination Socket: 0x0455 NetBIOS
Source Network: 0x00050000
Source Node: 00:40:95:11:56:DE
Source Socket: 0x0455
NetWare NetBIOS
Reserved:
................ 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Name Type Flag: 0x00
Datastream Type: 1 Name Query
Name String: AG-TRAIN
IPX NetBIOS Data
Like NetBEUI, Novell NetBIOS is responsible for carrying out all of the
NetBIOS work. For this reason, there’s a Connection ID and Sequence Number
in the NetBIOS header. Novell chose to carry its NetBIOS on top of the IPX
network layer.
Flags: 0x80 802.3
Status: 0x01
Packet Length:66
802.3 Header
Destination: 00:60:08:15:A6:9B
Source: 00:40:95:96:30:07
Length: 48
IPX - NetWare Protocol
Checksum: 0xFFFF
Length: 48
Transport Control:
Reserved: %0000
Hop Count: %0000
Packet Type: 4 SAP
Destination Network: 0x00000000
Destination Node: 00:60:08:15:A6:9B
Destination Socket: 0x0455 NetBIOS
Source Network: 0x00050000
Source Node: 00:40:95:96:30:07
Source Socket: 0x0455
NetWare NetBIOS
Control Flag: 0xC0
Send ACK
System Packet
Datastream Type: 6 Session Data
Source Connection ID: 8669
Dest Connection ID: 8629
Send Sequence: 4
Send Total Length: 0
Fragment Offset: 0
Fragment Length: 0
ACK Sequence: 5
ACK Fragment Offset: 10
Remaining NetBIOS Data:
..V. 9D B1 56 C8
Concluding Thoughts on NetBIOS Terminology
In the NetBIOS/TCP environment, the term NetBIOS refers to the API and to
the portion of the packet that carries the NetBIOS API commands, replies,
and data. In the NetBIOS/NetBEUI environment, the term NetBIOS refers only
to the API, and the term NetBEUI refers to the protocol and associated
header information. In the NetBIOS/IPX environment, the term NetBIOS refers
to both the API and to the protocol. Of course, when the term NetBIOS is
used relative to TCP, it’s referring to the thin, behaviorless header, but
in the Novell world it refers to a protocol that has many different
behaviors. Perhaps if these three implementations had been given
dramatically different names, there would be less confusion. In fact, in the
1980s, a Novell expert would have referred to NetWare’s implementation as a
NetBIOS Emulator, alluding to the fact that NetBEUI was the actual protocol
that implemented NetBIOS and Novell was emulating the functions in NetBEUI,
but using Novell-proprietary protocols.
NOTE
On Cisco routers, you need to configure the ipx type-20 propagation command
to cause the router to forward NetBIOS/IPX broadcast packets. The IPX Packet
Type for NetBIOS is 20, as you can see in the IPX Name Query section
earlier. (Chapter 10 showed the IPX Packet Type for NetBIOS in hexadecimal
as 0x14). You should configure the command on the input interface that
receives the broadcast packets. To control which broadcasts are forwarded
based on the NetBIOS name being queried, you can use the ipx netbios
input-access filter command.
_______________________________
Priscilla Oppenheimer
www.priscilla.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=71270&t=71084
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
