What command can you use to determine if a network service is listening on the correct port number

Listening Ports

The Listening Ports section of the Network tab gives you information about the services and processes on your system that are waiting to service network requests. These services are listening on either a TCP or a User Datagram Protocol (udp) port. This section shows process name, process ID, listening address, port, protocol, and firewall status.

The Listening Ports section of the Network tab can come in very handy. It can tell you what ports a given service is listening on. This is very useful if you are trying to figure out why a given service is not accepting requests. It can also help you resolve port conflicts. You may be trying to configure a service to start on a particular port, but you keep receiving a message about the port being in use. You can use the Listening Ports section to determine what service may be using the port you are trying to configure the new service with.

Examining Network Connections and Open Ports

In addition to examining the details relating to our suspect process, we'll also want to look at any established network connections and listening ports on the infected system. The information gained in the process will serve as a good guide for a number of items of investigative interest about our malicious code specimen. In particular, we'll gain some insight into the network protocols being used by the program, which may help to identify the purpose or requirements of the program and additionally serves as a good reference of what to look for in the network traffic capture. Further, the information gathered can be corroborated with data we've already collected, such as the network related system calls discovered with strace.

We can get an overview of the open network connections, including the local port, remote system address and port, and network state for each connection using the netstat-an command. Similarly, using –anp switches, the output will also display the associated process and pid responsible for opening the respective network sockets, as shown in Figure 10.23.

Correlate Open Ports with Running Processes and Programs

►

Examining open ports apart from active network connections is often inextricably intertwined with discoveries made during inspection of running processes on a subject system.

When examining active ports on a subject system, gather the following information, if available:

Local IP address and port

Remote IP address and port

Remote host name

Protocol

State of connection

Process name and PID

Executable program associated with process

Executable program path

Username associated with process/program.

Process-to-port correlation can be conducted by querying a subject system with a conjunction of the netstat, lsof, and fuser commands. For instance, consider a system that is observed to have unusual activity associated with UDP port 60556 and there is a need to determine whether this is due to malware on the system.

Fig. 1.44 shows the fuser command being used to determine that a process with PID 15096 (running under the “victim” user account) is bound to UDP port 60556. Fig. 1.45 also shows the name of the process “httpd” that is bound to UDP ports 60556 and 37611 using the netstat -anp command.

Ultimately, the executable that is associated with this suspicious process can be found using the lsof command as shown in Fig. 1.46. This output reveals that the malware named httpd is running in the/tmp/me directory.

In addition to providing information about open ports, the fuser command can show which processes are accessing a particular file or directory. Fig. 1.47 shows all processes that have the “/tmp/me” directory, suggesting that they are suspicious and require additional inspection.

Creating Custom Log Files

You can also create two types of custom log files that can be helpful in troubleshooting WFAS:

Network Statistics file: displays network statistics, listing all listening ports.

Task List file: lets you view the task lists of programs and services and provides the event PID (which you can then find in the Network Statistics file).

Here is how you create these two custom files:

At the command prompt, type netstat -ano > netstat.txt, and then press ENTER.

At the command prompt, type tasklist > tasklist.txt and then press ENTER or (to create a task list for services, type tasklist /svc > tasklist.txt).

Open the tasklist.txt and the netstat.txt files in a text editor such as Notepad.

In the tasklist.txt file, record the Process Identifier (PID) for the process you are troubleshooting and then compare the PID with the one in the Netstat.txt file. Also record the protocol that is used. This information can be useful when you review the information in the firewall log file.

Scanning and Spoofing

The term scanner, in the context of network security, refers to a software program that is used by hackers to remotely determine what TCP/UDP ports are open on a given system, and thus vulnerable to attack. Scanners are also used by administrators to detect vulnerabilities in their own systems in order to correct them before an intruder finds them. Network diagnostic tools such as the famous Security Administrator's Tool for Analyzing Networks (SATAN), a UNIX utility, include sophisticated port scanning capabilities.

A good scanning program can locate a target computer on the Internet (one that is vulnerable to attack), determine what TCP/IP services are running on the machine, and probe those services for security weaknesses.

NOTE

A common saying among hackers is: “A good port scanner is worth a thousand passwords.”

Many scanning programs are available as freeware on the Internet. An excellent resource for information about the history of scanning, how scanners work, and some popular scanning programs can be found at www.ladysharrow.ndirect.co.uk/Maximum%20Security/scanners.htm.

23.5.2 Tunnel network

In the second exercise, we showcase how to set up Wireguard with multiple peers and a configuration file using

The generation of the key pairs is already done, and the respective keys are stored in files on the hosts. We now can write a configuration file for each of the hosts that sets up the Wireguard interface. The configuration files are stored in /etc/wireguard and follow the naming scheme INTERFACE_NAME.conf. For example, for the wg0 interface, we get /etc/wireguard/wg0.conf.

The first part of the configuration describes the interface and can only appear once in the configuration. To replicate our setup from exercise 1, we need to specify the internal tunnel address, the listening port, and the private key of the interface. Additional options allow specifying DNS server and network configurations. Wireguard will also create its own routing table for the interface, which can be disabled via the options. All options can be found in the manpage of

The second part of the configuration specifies the peers of the interface. There can be multiple peers per interface, and all that is required to specify is the public key and the AllowedIPs. The endpoint is optional, but at least one side of the tunnel must specify one. The AllowedIPs specify which IPs are allowed to traverse the tunnel and are used to determine which peer is the recipient of a packet. Just like regular routing Wireguard looks up the shortest prefix match of its peers to decide which peer should receive the packet. This requires the AllowedIPs prefixes to be unique per peer, and hence you cannot have two peers with the same AllowedIPs.

With a complete configuration in hand, the creation of the interface boils down to calling

An additional benefit of interface configurations is that the creation of a Wireguard interface can be triggered on system boot by using the systemd service as

Port Forwarding Tunnel Mode

The port forwarding tunnel mode is used to communicate on specific ports without having to install or run a client.

Port Forwarding Tunnel Mode Highlights:

This function only works when accessing the web portal via the web mode SSL VPN.

This method may be configured in the Bookmark widget or dynamically launched via the Connection Tool widget.

Upon launching the port forwarding mode, a java applet is downloaded to the end user’s machine and generate a local listening port. Applications can then communicate on this port and the traffic can be proxied through the SSL VPN connection.

Only supports static TCP ports.

Syntax for the port forwarding configuration in both Connection Tool and Bookmark widgets:

config vpn ssl web portal

 edit <ssl vpn portal name>

  config widget

   // enabling the ability within the Connection Tool widget

   edit 1

    set type tool

    set name “My Connection Tool”

    set allow-apps portforward

   next

   // predefining a bookmark within the bookmark widget

   edit 2

    set type bookmark

    set name “My bookmarks”

    edit <name of bookmark>

    set apptype portforward

    set host <host IP address to portward trafic to>

    set remote-port <host listening port>

    set listening-port <local ssl vpn user listening port>

   next

  next

  end

 next

end

Resource Monitor Network Tab

The Resource Monitor Network Tab, as seen in Figure 6.13, gives information on network activity on the system. You can view network usage information, connection information, and port information. In the right pane, you can see total network usage, number of TCP connections, local LAN usage, and wireless network usage. This can help you figure out if a network bottleneck is occurring on a specific network or all networks.

The Resource Monitor Network Tab provides detailed information on what’s happening with your network connections. You can use this information to troubleshoot connection issues or port conflicts. The Resource Monitor Network Tab has four sections—Processes with Network Activity, Network Activity, TCP Connections, and Listening Ports:

Processes with Network Activity: The Processes with Network Activity section of the Network Tab gives general network activity information. You can see the processes that are running, process ID, bytes sent, bytes received, and total bytes. This can help you determine if a process is generating excess network activity.

Network Activity: The Network Activity section provides the same information that’s found in the Network section of the Overview tab. You can see process name, process ID, remote address, sent bytes, received bytes, and total bytes. You can use this information to determine what remote systems your system is communicating with, and how much data is being sent between the two systems.

TCP Connections: The TCP Connections section of the Network Tab shows active TCP connections. You can see what remote systems you are connected to and what TCP ports are being used. This section shows process name, process ID, local address and port, remote address and port, packet loss, and latency. The information in this section can help troubleshoot dropped connections, which are often a result of high latency and/or packet loss.

Listening Ports: The Listening Ports section of the Network tab gives you information about the services and processes on your system that are waiting to service network requests. These services are listening on either a TCP or a UDP port. This section shows process name, process ID, listening address, port, protocol, and firewall status. The Listening Port section of the Network tab can come in very handy. It can tell you what ports a given service is listening on. This is very useful if you are trying to figure out why a given service is not accepting requests. It can also help you resolve port conflicts. You may be trying to configure a service to start on a particular port, but keep getting a message about the port being in use. You can use the Listening Ports section to determine what service may be using the port you are trying to configure the new service with.

The Network tab supports the filtering option that allows you to filter based on a specific process. Simply check the box next to the desired process in the Processes with Network Activity section. The Network tab also includes the Search online feature to help make monitoring and troubleshooting easier. Simply right-click on the desired process and select Search online.

Netstat

Netstat is used to show protocol information and current connection information. You can use netstat to view which systems your system currently has a connection with. If you see a connection that you do not expect, there may be an issue. Also, if you see more open sockets than you expect, your system may be the target of a TCP SYN attack:

-a This option displays all current connections and listening ports.

-b This option displays the executable associated with a listening port.

-e This option is used to show Ethernet statistics.

-f This option displays the FQDN for foreign addresses.

-n This option displays IP addresses and ports in numeric format.

-o This option displays the process ID associated with each connection.

-p This option only displays connections for the specified protocol.

-r This option displays the routing table for the system.

-s This option displays per protocol statistics.

-t This option displays the current connection offload state.

-x This option displays NetworkDirect connections, listeners, and shared endpoints.

-y This options displays the TCP connection template for all connections.

Interval: This option displays the current statistics, pausing for a given interval between displays.

Port and Vulnerability Scanning the Compromised Host: “Virtual Penetration Testing”

▸ In addition to exploring the functionality of a malicious code specimen to assess the threat the program poses to the victim system, there are additional steps the digital investigator can take to explore the impact resulting to the system as of result executing the specimen.

First, a port scan can be conducted (from a different system) against the infected system to identify open/listening ports, using a utility such as nmap.109 To gain any insight in this regard, it is important to know the open/listening ports on the baseline instance of the system, making it easier to decipher which ports were potentially opened as a result of launching the suspect program.

Similarly, vulnerabilities created on the system by the malware can potentially be identified by probing the system with vulnerability assessment tools such as OpenVAS110 or Nessus.111

The digital investigator would typically not want to conduct a port or vulnerability scan of the infected host during the course of monitoring the system because the scans will manifest artifacts in the network traffic and NIDS alert logs, in turn, tainting the results of the monitoring. In particular the scans would make any network activity resulting from the specimen indecipherable or blended with the scan traffic.