Internet’s Noise

If you are following the daily IT news you have probably seen many articles claiming they have scanned the whole Internet for this or that. Indeed there are tools such as the ZMap Project “that enable researchers to perform large-scale studies of the hosts and services that compose the public Internet”.

This time I was not interested in scanning something, but in the question about “how many scans happen during one day on my home ISP connection?” Or in other words: What is the Internet background noise as seen by almost any customer? For this I sacrificed my Internet connection at home for 24 hours, while a factory-resetted router established a fresh Internet connection (IPv6 & IPv4) without any end devices behind it. No outgoing connections that could confuse or trigger any scans. That is: All incoming connections are really unsolicited and part of some third-party port scans, worm activities, or whatever. Using a network TAP device I captured these 24 hours and analyzed them with Wireshark.

In this blogpost I will present some stats about these incoming port scans. Furthermore I am publishing the pcap file so you can have a look at it by yourself.

TL;DR: In 24 hours, 1018 unique IPv4 addresses scanned 1167 different ports. Peaks are Telnet, SQL, and SSH. Few organizations, such as Shodan, are scanning in a structured way. Ping is only used by universities but not by port scanners at all. No single IPv6 scan.

Of course my lab scenario does not comply with a real study about Internet activity. For this you need a much longer duration with more ISP connections spread over the world. My test was just a small slice. However, at least it gives some basic knowledge about such Internet activities.

Lab

My setup was the following: An AVM FRITZ!Box 7270v3 with FRITZ!OS 06.06 behind a Deutsche Telekom Fiber connection with 50/10 Mbps. I captured with the ProfiShark 1G which was connected to my PC via USB 3.0. I placed the TAP between the fiber modem and the router, hence everything is encapsulated in VLAN 7 and PPP before the actual IP header. (Refer to my (german) blogpost about the dial-up of those dual-stack connections.)

Since I am only using a private contract, I don’t have static but dynamic (non-persistent) IP addresses. At least it is dual-stacked. During my test I got a single public IPv4 address (87.159.187.182) as well as a/64 IPv6 transfer segment (2003:50:aa7f:b2b5::/64 via RA, one address at the ISP facing interface) along with a /56 delegated IPv6 prefix (2003:50:aa32:b500::/56 via DHCPv6-PD). The four DNS servers (2x IPv6, 2x legacy IP) are not of interest here since no outgoing connections were established at all.

I cleaned the original pcapng file a bit to get rid of the following unnecessary packets:

  • Session establishment via PPPoE, PPP LCP, PPP PAP, PPP IPCP, PPP IPV6CP, ICMPv6 RS, ICMPv6 RA, and DHCPv6 ;)
  • PPP Keepalives (Echo Request and Echo Reply) every 10 seconds
  • Outgoing NTP time synchronization to three IPv4 servers (hard-coded since no DNS query was initiated) <- luckily Wireshark recognized them as three ongoing UDP streams so it was easy to delete them rather than using “not port 123” which would have deleted all incoming port scans to port 123 as well
  • In sum: !(pppoed) && !(lcp) && !(pap) && !(ipcp) && !(ipv6cp) && !(icmpv6.type == 133) && !(icmpv6.type == 134) && !(dhcpv6) && !(udp.stream == 2) && !(udp.stream == 3) && !(udp.stream == 4)

After that the total packet count decreased from 29056 to 5140. Furthermore, the Fritzbox sends an “ICMP destination unreachable (communication administratively filtered)” after every single TCP/UDP connection attempt. I removed them as well which gives a total amount of 2607 packets. The following two screenshots give an impression about the port scans with and without the ICMP messages:

Stats

Some stats out of the captured file:

  • No single incoming connection via IPv6! Neither to the single IPv6 in the transfer segment on the Internet facing interface, nor to any of the addresses out of the /56 delegated prefix. Haha, the final proof that IPv6 is much more secure than legacy IP.
  • 1018 source IPv4 addresses scanned:
    • 1120 different TCP ports via 2036 TCP connections and
    • 47 different UDP ports via 143 UDP connections
  • The distribution of packets per source address is: (Statistics -> IPv4 Statistics -> All Addresses)
    • 1x 833 packets
    • 1x 152 packets
    • 16x between 10-99 packets
    • 135x between 2-9 packets
    • 865x only one single packet
  • The distribution of packets to destination ports is: (Statistics -> IPv4 Statistics -> Destinations and Ports, since some scans used more than 1 packet these values differ slightly from the “UDP connections” above)
    • 385x TCP 23 = Telnet
    • 97x TCP 1433 = SQL
    • 92x TCP 22 = SSH
    • 70x TCP 2323 = Telnet alternative
    • 46x TCP 445 = SMB
    • 43x TCP 8545 (???)
    • 39x UDP 5060 = SIP
    • 36x TCP 3389 = RDP
    • 21x TCP 80 = HTTP
    • 20x TCP 81 = HTTP alternative
    • 15x TCP 8080 = HTTP alternative
    • 17x UDP 53413 (???)
    • 14x TCP 21 = FTP
    • 11x TCP 2222 = SSH alternative
    • 10x UDP 53 = DNS
    • 10x UDP 1900 = SSDP
    • 9x UDP 123 = NTP
    • 8x UDP 161 = SNMP
    • 8x TCP 9000 (???)
    • 7x TCP 443 = HTTPS
    • Rest TCP: 1106 different ports
    • Rest UDP: 41 different ports
  • A quick look at the reverse DNS PTR records reveals some structured search engines that are scanning for ports on a regular basis:
  • Ping (ICMP echo-request) was used 27 times by 9 different IP sources. Only 3 of those do not have a PTR record while the others all point to one of these projects/universities:
    • The ANT Lab: Analysis of Network Traffic (pinging from at least four different sources every 1-3 hours): https://ant.isi.edu/
    • Center for Applied Internet Data Analysis (pinging roughly every 6 hours): http://www.caida.org/
    • Athens University of Economics and Business (pinging roughly every 8 hours): https://aueb.gr/

So, what is the bandwidth that is used by those port scans at all? Having a look at the packets per minute (not per second!) reveals an almost uncritical value of about 2 incoming packets per minute. The interesting part is the equal distribution about the complete 24 hours:

The “Expert Information” of Wireshark also reveal some interesting notes e.g. about “suspected retransmissions” or “SYN+ACK” in the first packet:

One thing I did not quite understand was the behavior of one single host that sent 833 packets to different high ports (> 45000), each with SYN,ACK and/or as TCP Retransmission. Is this part of a port scan or just a misconfigured device? AbuseIPDB lists this IP as “Search Engine Spider” from Google LLC.

Analyze it yourself

This is the pcapng file, packed as zip. To be precise, there are two pcaps in it: One with all ICMP unreachables and one without, filtered with:  !(icmp.code == 13). Have fun:

Some Notes and Conclusions

No real surprises here. You are scanned all the time. Without a firewall (or a stupid NAT box in case of IPv4) your end devices will get lots of port scans every day. Here are some conclusions though:

  • I was not scanned like “one source scans all well-known ports” but rather “single sources scanning single ports” with peaks at Telnet and SQL.
  • There are a couple of organizations that regularly scan the whole Internet.
  • No single port scan was issued after a (successful) Ping. Ping was only used as a standalone “R U There” measurement mainly by university projects. This confirms my general approach that ping is no security flaw and must not be blocked by default anywhere.
  • Nobody scanned TCP port 25 (SMTP). This was unexpected to me.
  • Beside the ICMP unreachable messages my Fritzbox replied two times with a TCP RST, ACK (TCP stream 833 with dst.port 8089 and TCP stream 1003 with dst.port 1080). I don’t know why.
  • Again, no single IPv6 scan was coming in. This was kind of expected due to the immense address space. However, there are quite some researches about v6 scanning such as “Advances in IPv6 Network Reconnaissance” or RFC 7707 “Network Reconnaissance in IPv6 Networks” by Fernando Gont that propose many techniques to scan the IPv6 Internet as well. In my case, the /56 delegated prefix out of Deutsche Telekom comes from a known range. Hence it would be possible to scan certain addresses out of this range in the future.

To my mind it’s quite interesting to look at this Internet’s noise for a while. And I did not even analyze everything but only the tip of the iceberg. If you have something more to say about my trace, please write a comment. Cheers! ;)

Featured image “IMG_9162” by Tom Page is licensed under CC BY-SA 2.0.

5 thoughts on “Internet’s Noise

  1. Hi,

    Thanks for sharing your fascinating research!

    It’s most likely that your ISP is blocking TCP/25 and that’s why you didn’t see any scans on that port.

    I have some hints about those mystery ports: TCP/9000 is default for PHP-FPM, UDP/53413 could be some chinese CPE backdoor, and TCP/8545 could be related to Ethereum.

    PS. I’m interested in that Profishark TAP device. Do you happen to know how big jumbo frames it support? Didn’t find the info on a datasheet.

  2. Could this part
    “One thing I did not quite understand was the behavior of one single host that sent 833 packets to different high ports (> 45000), each with SYN,ACK and/or as TCP Retransmission.”

    Be some odd “brute force” port knocking procedure. Basically to see if any port knocking like functionality is available?

  3. Hi!
    Thanks for sharing all this.
    Can you tell what are the IP addresses of the following –

    security.ipip.net (?), scanning from 11 different sources

    Thank you in advance,

    Adam

    1. Hi Adams,

      that’s what the trace file is for. ;) You can download it and find it by yourself.

      The IPv4 addresses have PTR records to their names with a counter or the like. Here are those 11 IPs and PTR records out of my capture:
      139.162.65.76 scan-41.security.ipip.net
      106.186.119.244 scan-5.security.ipip.net
      139.162.90.220 scan-50.security.ipip.net
      139.162.124.90 scan-34.security.ipip.net
      106.187.45.144 scan-12.security.ipip.net
      139.162.109.43 scan-38.security.ipip.net
      103.29.70.204 scan-19.security.ipip.net
      106.184.4.52 scan-4.security.ipip.net
      139.162.121.251 scan-47.security.ipip.net
      139.162.111.138 scan-61.security.ipip.net
      106.186.20.183 scan-11.security.ipip.net

Leave a Reply

Your email address will not be published. Required fields are marked *