Uses for Nlog and Nmap

nlog

Uses for Nlog and Nmap

So now you can port scan with Nmap and sort and analyze the results with Nlog. what can you do with these programs? There are, indeed, some interesting applications for port scanners. Here are some examples for you to try on your network:

      1. Scan for the least common services: if you have a service or port number that is only showing up on one or two machines, chances are that it is not something that is standard for your network. It could be a Trojan horse or a banned service (e.g. a file-sharing application). It could also be a misconfigured machine running an FTP server or other type of public server. You can set Nlog to show the number of occurrences of each and sort them by the least often occurring. This will generate a list for you to check. You probably won’t want to include your company’s servers in this scan as the will have lots of one-of-a-kind services running. However, it would not hurt to scan these servers separately either to fine-tune or eliminate extraneous services.
      2. Hunt for illicit/unknown web servers: Chances are that if you run one or more web servers for your company, you will see the HTTP services showing up a few times on your network. However, it is also likely that you will see it on machines where you don’t expect it. Some manufacturers of desktop computers are now loading small web servers by default on their systems for use by their technical support personnel. Unfortunately, these web servers are often barebones programs with security holes in them. You will also find web servers running on printers, routers, firewalls, and even switches and other dedicated hardware. You may need these servers to configure the hardware, but if you aren’t using these servers, you should shut them off. These mini-servers are often configured with no password protection by default and can offer a hacker a foothold onto that machine. They can also offer access to the files on the machines if an intruder knows how to manipulate them. Scan for these hidden web servers, and either turn them off or properly protect them. you should also search for ports other than 80 that are commonly used for HTTP. At the end of this article, there is a table listing some of those ports.
      3. Scan for servers running on desktops: Going a step further with the last exercise, restrict the IP range to only those that are nonserver machines and set a port range from 1 to 1024. This will find desktop machines running services that are normally done by servers, such as mail, web and FTP. Unless there is a good reason for this (e.g. PCAnywhere), your desktop machines should not be running these types of services.
      4. Hunt for Trojan horses: To hunt for Trojan horses on your network, run a scan of your network and translate it into the Nlog database format. Open the Nlog search page, select the ports, and set the range from 30,000 and 65,400. This is the favored range for Trojan horses because it is out of the range of normal services and so they usually will go unnoticed – that is, unless you are port scanning your network. However, just because there are some services running on high-level ports doesn’t always mean you have Trojan horses, but it is worth paying attention to services running on these high port numbers. Once you’ve narrowed it down to the machine and port numbers, you can rule them out by checking the services running on those machines or by SSHing to those port numbers and seeing if you get a service banner.
      5. Check your external network exposure: Put your Nmap box outside your network, either on a dial-up or home broadband connection, and try scanning your company’s public IP addresses. By doing this you will see what services are accessible from the Internet (and thereby to any port scanner-wielding person). This is the most vulnerable part of your network, and you should take extra care to secure any services that are public-facing by using a vulnerability scanner, such as the one described in the next chapter. It will also show if your firewall is properly filtering ports that it is forwarding to internal LAN addresses.
        So you’ve seen all the cool things you can do with a port scanner like Nmap. These programs are useful for finding out what you have running and where your exposures might be. But how do you know if those exposed points might be vulnerable? Or if services that are supposed to be open are safe and secure? That goes beyond the function of a port scanner and into the realm of a vulnerability scanner.


Web Ports

Common Port Number Protocol
81 Alternate web
88 Web
443 HTTPS, secure web
8000-8002 Web
8080 Web
8888 Web

External Links:

Download Nlog at packetstormsecurity.com

2003 archive of secureaustin.com (the former official site of H.D. Moore, creator of Nlog)

Port Forwarding with NAT in pfSense

Firewall Configuration: NAT port forwarding

Firewall -> NAT configuration page in the pfSense web GUI.

In computer networking, Network Address Translation (NAT) is the process of modifying IP address information in IPv4 headers while in transit across a traffic routing device. In most cases, it involves translating from the WAN IP address to the 192.168.x.x addresses of your local network. In this article, I will describe how to set up NAT port forwarding.

NAT and firewall rules are distinct and separate. NAT rules forward traffic, while firewall rules block or allow traffic. In the next article, I will cover firewall rules, but for now keep in mind that just because a NAT rule is forwarding traffic does not mean the firewall rules will allow it.

NAT Port Forwarding

NAT port forwarding rules can differ in complexity, but in this example, let’s assume we set up an Apache server at 192.1.168.125 on the local network, and we want to direct all HTTP traffic (port 80) to that address. First, browse to Firewall -> NAT. The options are “Port Forward“, “1:1” and “Outbound“. Select the “Port Forward” tab. Click the “plus” button in order to create a new NAT port forward rule. “Disable the rule” and “No RDR” can be left unchanged. For “Interface” you can choose WAN and LAN; we are concerned about incoming requests from the Internet, so you can keep it as WAN.


For “Protocol”, there are five choices: TCP, UDP, TCP/UDP, GRE, and ESP. TCP stands for Transmission Control Protocol, and is the transport level protocol of the Internet protocol suite. This is usually what we want to use. Next is UDP, or User Datagram Protocol, another transport level protocol which is also part of the Internet protocol suite. It is suitable for purposes where error checking and correction are either not necessary or are performed in the application. GRE stands for Generic Routing Encapsulation, a tunneling protocol that can encapsulate a wide variety of network layer protocols inside virtual point-to-point links. It can be used, among other things, in conjunction with PPTP to create VPNs. ESP stands for Encapsulating Security Payload, a member of the IPsec protocol suite which provides authenticity, integrity and confidentiality protection of packets. In this port forwarding scenario, you can leave the protocol unchanged (TCP).

Firewall Configuration: NAT

Adding a NAT port forwarding rule.

For “Source“, you can specify the allowed client source. Typically you can leave it as “any”, but there are several choices: “Single host or alias“, “Network“, “PPTP clients“, “PPPoE clients“, “L2TP clients“, “WAN subnet“, “WAN address“, “LAN subnet“, and “LAN address“. In this case, you can leave the default (any) unchanged.

For “Source port range“, we want to redirect HTTP traffic (port 80), so choose HTTP for the from and to drop-down boxes. “Destination” offers the same choices as “Source” and can be left unchanged. “Destination port range” should be changed to HTTP for the from and to drop-down boxes. For “Redirect target IP“, specify the web server the traffic to be forwarded to (in our case, 192.168.1.125). For “Redirect target Port“, choose HTTP. Next is “No XMLRPC Sync“; enable this option to prevent this rule from being applied to any redundant firewalls using CARP. This option can be left unchecked now. “NAT Reflection” can be enabled or disabled, usually it is disabled. “Filter Rule association” will automatically create a firewall rule and associate it to this NAT rule. Check this box to avoid having to create a separate firewall rule. Add a description if you wish, and press “Save” to save the changes. The port forwarding rule set up should now be in effect.

NAT Port Redirection

In this case, we passed traffic from port 80 on the source to port 80 on the destination, which is the classic port forwarding scenario. But there’s no reason you can’t redirect traffic to a different port. There are two reasons you might want to do this:

[1] Security: A good way to thwart hackers is to put services on non-standard ports. For example, everyone knows the standard port for FTP is 21, but an outsider is unlikely to find your FTP server if you place it on port 69, or better yet, an even higher port number (e.g. 51782). The same can be said of SSH. Users will have to know the port in order to access it.

[2] Single Public IP Address, more than one computer with the same services: Smaller networks with only a single public IP address may be stuck if the want to expose a lot of public services. For example, imagine that we want to have two separate FTP servers, but on two separate computers. With port redirection, we create two different NAT rules: the first rule will redirect port 51782 to port 21 on FTPServer1, and the second will redirect port 51783 to port 21 on FTPServer2. We can then remote into two separate FTP servers on two different computers using the same IP address.


External Links:

Port Forwarding Troubleshooting at doc.pfsense.org

© 2013 David Zientara. All rights reserved. Privacy Policy