What is Port Scanning and What Types of Port Scans Are There?

Introduction To Port Scanning

One of the most popular methods for finding susceptible server hosts that may be running collaboration software is port scanning. Port scanning in general is a practice for ascertaining potential faults by transferring an asset called  port  probes. Port scanners are often used by SharePoint administrators for general network discovery, however port scanning can also be leveraged for malicious intent for various network vulnerabilities. Additionally, port scanning can result in other detrimental effects, such as contributing to network congestion as well as the introduction of false positives in IDS systems.

Three Types of Port Scanning

There are three main types of scans that a malicious user can use against a SharePoint environment, vertical scans, horizontal scans, and block scans.

  1. Vertical Scans – A vertical scan is a port scan that will in essence target numerous destination  ports on  a  singular host running SharePoint. This is an extremely broad scan and is typically easy to detect because only local detection mechanisms (those that will directly exist on the target server) are necessary in order to build up proper alerts and begin to mitigate threats from such a scan. The amount of valuable information that a malicious user gathers from a vertical scan can be defined as the size of the return packet from a particular probe. Vertical scans tend to predominate port scanning activity, mostly because when an exploit is made public it tends to arose the community.
  2. Horizontal Scans (also called a block scan) – A horizontal scan is a port scan that targets the same port on several hosts, effectively looking for a universal exploit that may exist. This is a fairly common when the attacker is privy to certain vulnerability information and seeks out within an arbitrary network susceptible host machines. The amount of valuable information that a malicious user gathers from a horizontal scan on a target can be defined as the amount of destination sets that the user receives.
  3. Block Scans – It is feasible to combine the above two methods to derive a new method which will, in essence, compose a large sweep of a network for either type of derived exploits, this is common when producing assets for future exploitations.

Why an SharePoint Administrator Would Use Port Scanning

Port scanning will in essence provide a SharePoint administrator the option of defining possibly exploitable SharePoint machines as well as providing a basis for defining a set of heuristics that will be able to educate an administrator between suspicious packets and those that compose legitimate traffic.  This is called the classification of packets, and is mainly done by inspecting probes that may originate from two or more IP address and port number pairs. Although this may be skewed if the port scanner origination host is concealing their origin, it can provide a rudimentary basis for determining the variations in traffic that may occur by  randomizing  the  order  of destination  IP  and  port  probes. As well, there have to be concessions that exist for variations in frame traffic.

The Most Commonly Scanned Ports

  • 137      NetBIOS name service (UDP)
  • 21        FTP
  • 25        SMTP
  • 53        DNS
  • 17        QOTD
  • 113      IDENTD/AUTH
  • 105      CSO
  • 33        DSP
  • 129      PWDGEN
  • 29        MSG-ICP
  • 1          TCPMUX
  • 13        daytime
  • 93        DCP
  • 41        RAT
  • 85        MIT ML Device
  • 97        Swift Remote Virtual File Protocol
  • 77        Private Remote Job Execution Services
  • 73        Remote Job Services
  • 121      Jammerkilla

The OSI Model and SharePoint

The OSI Model and SharePoint

The OSI model is the standard when it comes to routing, switching, and broad-spectrum application services, along with supporting conventional networked services. It spans the entire network computing infrastructure to provide a standard by which network and application engineers, as well as SharePoint architects can communicate pertinent information back and forth between each other leveraging a common standard. Although selected layers may prove to abstract for a SharePoint architect to be particularly concerned about, they nonetheless provide a positive insight into the network and application architecture that fabricate the backbone of how SharePoint operates and functions at a multiplicity of levels.

Layer 1 The Physical Layer

The first layer of the OSI model is the physical layer. Relative to SharePoint, the physical layer deals with the actual data rates and physical connectors while erect the inclusive collaboration environment. At the physical layer, there is the defining of how the actual bits that SharePoint creates (at a very high level, translated to a very low level) is converted into voltage and transmitted across a physical medium. This is a very granular level that SharePoint architects rarely see, since it will determine the transmission medium including whether it is a thinnet, thicknet, or Unshielded Twisted Pair (UTP) that SharePoint will employ. The overall concept, at a high level, is how SharePoint will function at the physical link in a networked environment.

There are several network devices that define the physical layer, such as:

  • Hubs
  • Repeaters
  • Multiplexers
  • Network Interface Cards

Along with these physical devices, there are several protocols that operate at this level, such as:

  • ATM
  • BRI
  • X.23
  • PRI
  • E1
  • E3
  • 10BaseT
  • 100BaseT
  • 10Base2
  • 10Base5
  • OC-3
  • OC-12
  • DS1
  • DS3

Layer 2 The DataLink Layer

The DataLink layer contracts predominantly with topology and frame handling. In this, there are certain other things defined such as the physical network addressing, line discipline, notification of network errors, delivery of frames in ordered pairs, and network data flow control. SharePoint architects will have relatively no interaction with the DataLink layer, since it is either handled by network engineers or through automation provided by network devices.

The DataLink layer will bestow the workings of certain resolution protocols such as the Address Resolution Protocol (ARP) and Reverse Address Resolution Protocol (RARP) which interrelate with the two sub-layers that the DataLink supplies, the Media Access Control layer (MAC) and the Logical Link Control (LLC) layer. MAC interacts with the Physical layer in that it provides physical addresses for resolution to transpire. The MAC address are 12 hexadecimal digits, the first 6 that defined by the IEEE, and the latter six defined by the vendor, all burned into Read Only Memory (ROM) of the arbitrary machine. The LLC talks up in the OSI model by instantiating a uniform interface that procures independent LAN media access to procure flow control and sequencing services.

The network devices that exist at the DataLink Layer of the OSI model are:

  • Bridges
  • Switches

The protocols that exist at the DataLink layer are:

  • SLIP
  • PPP
  • RARP
  • IARP
  • SNAP
  • BAP
  • CHAP
  • LCP
  • LZS
  • MLP
  • Frame Relay
  • HDLC
  • BPDU
  • LAPD
  • ISL
  • MAC
  • Ethernet
  • Token Ring
  • L2F
  • L2TP
  • ISDN

Layer 3 Network Layer

The Network Layer of the OSI model defines the injected information of the sent packets and frames so that they can be properly routed throughout the network to the correct destination sets. For SharePoint architects this is typically where content routers can be inserted. As well, securing routers is imperative to collaboration environments since compromising the router can eventually lead to concessions with the aggregate collaboration environment.

The Network Layer is fundamentally accountable for next-hop resolution and addressing, which build the principals of routing and switching. As broad network problems arise they are also resolved at this level, such as when there is network congestion (if multiple packet injections institutes a traffic bottleneck) that occurs that is affecting normal operations. After the segment are received from the Transport Level of the OSI model, it is pieced into Maximum Transmission Units (MTUs), which will consecutively classify the thresholds for the sized packets that are allowed to cross an arbitrary network medium. After the packet is sent, it is moreover reassembled at this level.

As well, the Network Level also has several duties related to the subnet, including how information packets are routed from the source to the destination, using an arbitrary set of routing logic that is up to the network architect to decide on, and the related node metrics.

The devices that operate at the network layer are:

  • Routers

The protocols that can execute at the network layer are:

  • IP
  • DHCP
  • OSPF
  • IPX
  • ICMP
  • RIP
  • ISIS
  • ZIP
  • DDP
  • X.25

Layer 4 The Transport Layer

The transport layer provides the essential transport services for end-to-end data movement, along with establishing the entail connections that are needed for the data transport to occur by establishing a logical link between the two. In essence, the transport layer is responsible for all activities related to the massaging of data between two endpoints by assimilating data from the Session Layer and breaking it into lesser units and passing it to the network layer, and then assuring that the data is routed correctly. SharePoint architects tend to have very little interaction with this layer since it is mostly automated by the appropriate network devices and for adjustments requires an understanding of the Cisco IOS. The transport layer provides another layer of abstraction in order to accommodate for changes to the physical network.

The Transport layer is most known for its function related to TCP. The transport layer will subdivide user-buffer datagrams, into network-buffer datagrams, and implement that necessary transport protocols for the data transmission to occur. As stated before, TCP exists at this level, as well as User Datagram Protocol (UDP). Between these two protocols, the largest difference is the concept of speed and reliability. UDP simply makes a handshake with low overhead transmission services and is essentially stateless with no error checking. The TCP protocol however keeps a running tally of the packets being delivered and the order that the packets are sent with granular error checking, sent via sockets. This in essence, means that TCP is a stateful protocol.

Protocols that are used at the transport level are:

  • TCP
  • UDP
  • SPX
  • ATP

Layer 5 The Session Layer

The session layer is mostly responsible for establishing and maintaining the inclusive connection between two network enabled hosts, providing the facilities for preserving the connection during the transport of the data as well as controlling the drop of the connection if it is needed. For SharePoint architects the session layer typically interacts with how relevant SharePoint frames and dropped and managed at the network level. This is not implying anything regarding session stating or viewstates, since this are application specific settings.

The Session Layer does three main actions related to sessions:

  1. Establishes the Session
  2. Maintains the Session
  3. Drops the Session

Involved with the session process are the recognition and identification of the parties involved in the packet inter-exchange so that participation of the session parties can be maintained. To promote the quality of the session (QoS) there is a synchronization check that occurs by injecting checkpoints into the transmitted data streams in order to detect whether a session fails so that the last checkpoint can be reloaded into the session stream for transmission, this provides a rudimentary form of fault-tolerance.

In a networked computing environment, the session layer enables two client machines to establish a germane session to implement conventional data transport as well as time-sharing and file transport between client machines. As opposed to the Transport Layer of the OSI model that can still provide ordinary data transport the session’s layer can also implement dialogue control in order to procure bi-directional traffic control and keep a tally of the clients that are involved in a traffic push.

The protocols that are used in the session layer are:

  • DNS
  • RPC
  • SQL
  • NFS
  • SSL
  • TLS
  • SSH
  • ASP

Layer 6 The Presentation Layer

Layer 6 of the OSI model, the Presentation Layer, is the primary means of representing data in a standard structure that can be translated into sensible data once it is received at the destination. The presentation layer is genuinely where the SharePoint architect will begin to interact with the OSI model since it is where relevant SharePoint frames are converted into the service that build the presentation layer of the application.

During this frame resolution process, there is a translation procedure that occurs between the format that is provided by the network and the format that is parsed by the application. This provides a uniform method of conversion, whereby all data passed through the OSI model can be translated into a common format through the use of protocol conversion, character conversion, data encryption services, graphic commands, and data compression.

Layer 7 The Application Layer

The Application Layer provides the support needed to provide support to services that will generate the user interface from relevant application services. The application layer should not be confused with the tangible user interface, but is instead the application interface that will in turn impart support to the user interface. This is where the ASP.NET framework will reside since it is the service that services the SharePoint framework, but does not actually generate the user interface.

The Application Layer will provide the network access flow, overall flow control, and general error recovery after the transmitted data has reached this level.

The protocols that are used in the Application layer are

  • HTTP
  • NNTP
  • DNS
  • SMTP
  • DNS
  • FTP
  • TFTP
  • SNMP
  • MIME
  • NFS
  • Finger
  • Telnet
  • NCP
  • SET
  • SMB

Building A Custom ASP.NET 2.0 Session State Provider

Session stating although considered not directly related to security, does encapsulate some security related points. Although there aren’t many session related configuration changes that you can make in SharePoint, understanding the concept of session stating and why it exists will help understand the aggregate concept of how security works in SharePoint, as well as the ASP.NET 2.0 model.

The provider model as detailed in other articles is evident in many facets of SharePoint, and through the use of the Universal Provider model one can gain membership, role, and provider pluggable architectures.

Building a Pluggable Session State Provider

At the conclusion of this article, you will see how to extend this concept further, and construct a custom session state provider that you can use in an ASP.NET application that uses factory design patterns so that it is database agnostic, and can be used by any ASP.NET 2.0 application. Because of this type of framework, we won’t have to build multiple providers to use the session state provider with, rather, one can simply use this agnostic architecture in order to orphan different application session data, promoting a high level of isolation.

Introduction to Sessions

Session stating is an important concept in SharePoint, as well as ASP.NET 2.0 security as a whole. In the new version of SharePoint, session stating is something that is always present and usable, in every page that you call within an ASP.NET 2.0 application. The backbone of session stating is the session object, which is the place where one can store various session information related to a specific application. In regards to session stating, there are several robust configuration options that are available, however some noteworthy limitations that exist as well. The Session objects core property is the SessionID (which is referred to as the session identifier, which is Session.SessionID), which becomes increasingly important when we begin looking at manipulating sessions, or sessionID’s.

The newest concept that exists in ASP.NET 2.0 is the option to use cookie-less sessions in regards to OOB session state providers and custom session state providers that are built on the ASP.NET 2.0 pluggable provider framework. There are obvious security concerns that exist with this type of functionality, because session states are relatively easy to hijack and are prone to be session reuse (as will be detailed more below in the comparison with login tickets, and the session reuse a little further down), storing things that would normally be stored in cookies such as usernames is typically a bad move.

Session stating has four main modes that are offered, In Process, SQL Server, State Server, and Custom (which will leverage the custom provider that we will see how to build shortly). When storing session data in a database, there are some implications that have to be taken into consideration before implementing it, and this becomes a concern when building a custom provider that will use an arbitrary data store. A major concepts that have to be taken into consideration are trust levels (to deal with CAS issues).

Sessions States Are Not Authentication Tickets

A common misconception about session states is that they are the same as a user login process and related login services. Session data is simply a numeric check against the 120-bit identifier that ASP.NET generates, in essence strongly checking the session identifier. In aggregate, a user enters a session enabled ASP.NET 2.0 application with will generate a session identifier, which is 120-bits, and is randomly generated, then the identifier can be sent back to ASP.NET which does some rudimentary syntax checks, and then the related data that was a available in that session is then available to the user. It would be pretty easy for a malicious user trying to hijack a session to generate a session identifier, send to ASP.NET, and then snatch a session. However, with authentication tickets (going back to the original point of the difference between session identifiers and authentication tickets), this would be near impossible, since the authentication tickets mathematical backbone is much more complex since it would require the guessing of several encryption keys.

Trust Levels and a Custom Session Provider

The first concept to take into consideration are the trust levels that need to be taken into consideration when implementing a custom session provider. For other types of session state modes, there are various required trust levels that are necessary that are not the same as those required by a custom provider. Meaning, if you are implementing SQL server session state mode then the trust level that is required is medium. For the other remaining sessions state modes, in process and state server, for the first there is the requirement of a minimal trust level, and for the latter, a medium trust level is required. For our custom provider, we require a trust level of minimal, however this can be modified if higher CAS security requirements are necessary within an arbitrary environment.

Why does the custom provider require a minimal trust level? The code stack for the provider as you will see is written in managed code, and lives instead the global assembly cache. Assuming that all the code that is going to be called from the provider also lives within the global assembly cache, there is no reason why there should be other trust level applied. Because we are going to deploy the custom provider to the GAC, it is important to pay attention to the code, and how the code will execute in terms of hooking into other .NET framework assets, since it will bypass several CAS concerns and will typically run without permission issues.

What is Session Partitioning?

Using a pluggable provider model allows a developer to approach sessions stating with a flexible backend data store whereby session data is easy to store. A common requirement is the sharing of session information across multiple session applications, or the lack thereof in order to prevent session collisions or unwanted session information sharing. When using a custom session state provider, the process is considered to be in-process , which is important to recognize because the relevant information will be stored in the cache object. Because of this, the level of isolation between the session information is high, and the session information will be segregated into the relevant application domains.

However, because we are using a custom session state provider, we get some benefits that will allow us to break this level of isolation if we choose in beneficial ways. Using a custom session state provider we can breakdown this concept of isolation into a central session state repository where we can store all application session state data whereby session information can be stored.

Reusing Session Information

Session ID information can optionally be reused, however in cookieless mode this options is disabled, instead new session information is applied (a new session object being instantiated) when session data expires or the SID is housed in the client URL, as detailed more exhaustively in the below section. In cookied mode, this is a very powerful concept however, since cookied mode allows the use of session information across multiple applications assuming that they are all under the same DNS host. Therefore, even if the session information is flushed on one application it can still be used on an arbitrary number of applications within an enterprise. This is not the case where the session is abandoned (literally, since one has to call Session.Abandon), meaning that if a session is abandoned in one application, new session information has to applied, however the session information can be valid across n number of other applications.

Session Expiration

One of the largest parts to consider about session stating is what happens when a session expires, and how sessions are managed through their lifecycle, particularly towards the latter end of the cycle. Expiration of sessions is handled differently in cookie –based and cookie-less session modes. When cookie-less sessions are used, new sessionID’s are generated when the sessions data is expired, or when there is a pre-existing SID, appended to the URL that the client is attempting to access. With cookie sessions enabled, this activity is much different operationally.

A concern revolving sessions is that a session can theoretically never expire, as long as there is activity within a specific SessionID, the ID will always be there. ASP.NET 2.0 deals with this however with an attribute called regenerateExpiredSessionId. regenerateExpiredSessionId relates to the concept introduced above where the session information is stored in the client URL. Because it would be bad security practice to allow sessionID’s to exist in the URL across browser sessions, this allows the SessionID to be regenerated when cookieless sessions state is enabled and the session information is housed in the client URL.

Utilizing a Pluggable Provider Model

Utilizing the pluggable provider model available to ASP.NET 2.0 is indeed a powerful mechanism that allows several layers of flexibility in the operational functionality of session stating. In this section, we will see how to use that model to build a session state provider that is based on pattern designs so that it ignores concrete provider bindings and is instead blind to the database backend that is being used. As stated in other portions of this article, there are added benefits to this, namely because with in-process session stating the session information will be segregated into application domains, it is quote isolated. If we wanted to establish a central repository that shared session information, an agnostic provider would help to achieve this.

ExampleSessionStateProvider.cs – View Online | Download Class File