External vulnerability test - deciphering the results

The vulnerability is likely with regards to TCP Window Scaling, as described neatly here, in Wikipedia .  Basically the vulnerability is a vulnerability to a denial of service.  
    The probability of someone actually targeting your customer and applying this vulnerability is pretty low, especially given that it is a denial of service exploit, not a method of snooping data.  The vulnerability is pretty open and easy, which is likely why the scanner showed it at a medium.  The vulnerability is 'open and easy' because it's in a ton of network implementations.  I would call this "not a big deal" for the customer as you described.

Other scanners would report the vulnerability severity rating as "low" -- the side effect of the vulnerability is that the up-time of the remote host may sometimes be computed, potentially aiding in further attacks.  Additionally, some operating systems may be fingerprinted based on the behavior of their TCP timestamps.

Solution

Cisco

    Disable TCP timestamp responses on Cisco

    Run the following command to disable TCP timestamps:

          no ip tcp timestamp
       

FreeBSD

    Disable TCP timestamp responses on FreeBSD

    Set the value of net.inet.tcp.rfc1323 to 0 by running the following command:

    sysctl -w net.inet.tcp.rfc1323=0
       

    Additionally, put the following value in the default sysctl configuration file, generally sysctl.conf:

          net.inet.tcp.rfc1323=0
       

Linux

    Disable TCP timestamp responses on Linux

    Set the value of net.ipv4.tcp_timestamps to 0 by running the following command:

          sysctl -w net.ipv4.tcp_timestamps=0
       

    Additionally, put the following value in the default sysctl configuration file, generally sysctl.conf:

          net.ipv4.tcp_timestamps=0
       

OpenBSD

    Disable TCP timestamp responses on OpenBSD

    Set the value of net.inet.tcp.rfc1323 to 0 by running the following command:

          sysctl -w net.inet.tcp.rfc1323=0
       

    Additionally, put the following value in the default sysctl configuration file, generally sysctl.conf:

          net.inet.tcp.rfc1323=0
       

    Microsoft Windows

    Disable TCP timestamp responses on Windows versions before Vista

    Set the Tcp1323Opts value in the following key to 1:

          HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
       

    Disable TCP timestamp responses on Windows versions since Vista

    TCP timestamps cannot be reliably disabled on this OS. If TCP timestamps present enough of a risk, put a firewall capable of blocking TCP timestamp packets in front of the affected assets.

Additionally, for Windows 2012 you may want to try testing the following PowerShell Cmdlet:

powershell -ep bypass -c "Set-netTCPsetting -SettingName InternetCustom -Timestamps disabled"

Select allOpen in new window

Here's my recommended topology for placement of the web server in a DMZ.  This adheres to the concept of least privilege.  The firewall would block all traffic except 80/TCP and 443/TCP.  The web application firewall (WAF) would drop all traffic on these ports except for approved GET/POST/HEAD requests.  Permitted requests would be subject to further inspection by the WAF for XSS, SQL injection, buffer overflow, insecure direct object references, etc.  In the case of TCP timestamping, the firewall could be capable of modifying packets to omit the vulnerability, and the only device responding to requests directly would be the reverse proxy, not the actual web server.  In this way the proxy can cache "approved" replies without incurring the overhead of the WAF and database activity monitoring and prevention (DAMP) inspections.


See http://www.experts-exchange.com/Programming/Languages/.NET/Q_28316569.html#a39714443 for more detail.

Thanks for all of your info - let me give you a little more detail on the office setup - they basically have 3 computers, a server (which is basically a Windows 7 PC) all connected to a standard Verizon router - no TRUE firewall in place, and a very simple, peer to peer network. When I ran the external vulnerability check, I believe it goes out to a server and I'm assuming tries to do port scans etc. I ran the scan from MY laptop, connected to the network assuming that being it was an external scan attempting to come INTO the network that it wouldn't matter, is this correct? This is @ x66_x72, on which PC would I make those TCP registry changes, all of them? Thanks again for all of your help!

If you performed the scan on the public side of the Verizon router, using a statically assigned public IP address (on your laptop), then your scan should be valid.  

Is the IP address assigned to the web server public or private?  Do you know if your web server is configured on the Verizon appliance as a Network Address Translation (NAT) or Port Address Translation (PAT) entry?  Any DMZ configured?

From my research, Windows 7

timestamps cannot be reliably disabled on this OS. If TCP timestamps present enough of a risk, put a firewall capable of blocking TCP timestamp packets in front of the affected assets.

My suggestion would be to recommend purchase of a firewall, such as a Cisco ASA 5505 (with the proper licensing), which not only takes care of your TCP timestamp issue, but can also segregate your web server from your other internal hosts, in an isolated DMZ.  The DMZ will be a new private non-routable network, and the firewall will take care of the PATs (e.g. 80/TCP and 443/TCP only) to the public side, public -> DMZ.  If you need to access the web server from the private side, you can also create PATs translating from the private LAN to the DMZ, private -> DMZ.  So if your web server is currently using a private IP address, you can still use that private IP address to connect to it on the private LAN, the firewall would simply host the IP and translate over the proper ports to the DMZ address.

If your current scenario, if the web server is compromised, access to your private network (and exposure of all other hosts) will be possible.  With the DMZ design, compromise of the web server will only effect the web server machine itself and all other hosts will remain protected, without further attacks on the application layer (e.g. waterhole your web server, etc.)

While it's probably more than you want to get into, my recommended topology actually provides for FREE operating systems (Ubuntu) and a FREE web application firewall (ModSecurity), and a FREE reverse proxy (Squid).  It's possible to configure one of these devices (either the proxy or WAF (if no proxy used)) as a hardened bastion host which acts like the Layer 2/3 firewall, in addition to the Layer 7 firewall features.  So your only cost (other than time) would be the physical/virtual hardware.

The way that I ran the scan was getting the public IP address (ipchicken.com) and running it against THAT ip address.

We dont have a webserver.

Like I mentioned this is a simple Verizon ISP router - no custom configuration, no NAT, no DMZ. Its basically the same setup that you'd find a normal home using. (unless there's a gamer in the house that would need specific ports open to play)

There's no other way to change us from a medium risk to a low risk? It seems that the problem with:

Medium -------- (CVSS: 2.6)
NVT: TCP timestamps (OID: 1.3.6.1.4.1........)
It was detected that the host implements RFC1323.  The following timestamps were retrieved with a delay of 1 seconds in-between: Paket 1: 127869255 Paket 2: 127870452

seems to be a low risk from what I'm reading. Is there anything I can do, without adding a firewall? I should also mention that the Verizon ISP routers do have a firewall built into it.

thanks for all of your info

Contact verizon and see if they have a setting to disable TCP timestamping on their router.  If you can SSH into it, perhaps one of the commands posted previously (for various linux distros) will point you in the right direction.

At the end of the day, this is an information leakage vulnerability.  It's low risk in and of itself, regardless of what a scanner reports.

Hi - I purchased a Cisco ASA 5505, and need to put this in front of a Verizon FIOS router. What is the easiest way to do this. This office does not have a static IP address. Any help would be appreciated!

You'll place the ASA5505 on the "private" side of the FIOS router, and your network hosts on the private side of the ASA5505.

ok, ASA-5505 in place - cannot seem to run the "no ip tcp timestamp" command. it tells me "unrecognizable command" - anyone have any ideas? any help would be appreciated!

Thank you so much, very helpful!