Friday, January 15, 2016

The Rising Sophistication of Network Scanning

Gone are the days when computers didn't need firewalls. We are now living in an internet security arms race and your personal information lies in the balance. A good firewall can go a long way but they aren't infallible.

In this article I would like to show you a hidden system that is hard at work scanning thousands, maybe millions, of unsuspecting devices. And I'll show how this system efficiently harvests each device's personal IP address and hands it off to a scanner, which proceeds to run a port/security scan against each unsuspecting victim for vulnerabilities.

The first red flag came when I noticed a steady flow of unsolicited network scans being hurtled at my devices. What was most puzzling was the fact that the devices that were targeted had randomized IPv6 addresses and were not published in DNS or any public record. For all intents and purposes they were hidden safely within my lab network. 

Imagine my surprise when the firewall started logging swaths of packets, from distant internet addresses, aimed directly at my hidden devices. They were being directly targeted.

So how did they know the unpublished IP addresses? These addresses are 128 bits in length, which is an unimaginable range of numbers. Unguessable is the only way to describe the randomized addresses that were in use on the devices.

My next move was to search the firewall logs for any outbound traffic sent to these scanners that may have triggered the scans. Nothing—not a single outbound packet was sent to the scanners. The scanners had my hidden addresses even though my devices had never connected to them.

In this article I'll retrace my steps as I dissected this advanced system that harvests ip addresses and then passes them to another system for scanning at lightning speed.


If you're one of the billions of Debian, Ubuntu, or Raspbian users, or if you have servers running these operating systems, and you have an IPv6 address, then it's pretty likely your device has already been scanned. The devices in my lab network that were targeted were all running the Debian based Raspbian distribution of Linux.

Debian is a distribution of the Linux operating system. It’s known for its minimalist approach and huge success in supporting the ARM computer architecture. It runs on cloud servers, routers, and the newly popular $35 credit-card sized Raspberry Pi computers (they run Raspbian). It comes packaged with the “NTP time daemon”, preconfigured to query a specific set of time providers. 

As of recently I also learned the other parts of the pool contained harvesters, including the RedHat NTP pool.

From Harvesting to Scan - how long does it take?

It takes less than five seconds for your address to be harvested and scanned. The entire scan takes less than one second and scans over 100 common TCP and UDP ports.

How did they get my randomized IPv6 address?

Is it registered in DNS? No. Guessable? No. Here’s how: My computer made a normal request to the public Network Time Protocol (NTP) pool to set its clock. Alongside NTP, the server must also run some sort of application or script that grabs source IPs of inbound packets. But I’m getting ahead of myself, and I still need to describe how I came to this conclusion.

How common is it to use the NTP?

Pretty much every computer these days sets it’s time to the atomic standard. Most often, a computer will use NTP to synchronize its clock to a public NTP server, as defined by the computer’s configuration.

The address of the NTP server for each computer is typically preconfigured by the manufacturer or, in the case of a Raspberry Pi, it's spun into the Raspbian firmware image (/etc/ntp.conf).

Using IPv6 to get NTP time from Debian? You're probably getting scanned by Shodan.

NTP uses a concept of pools or groups of servers. aggregates the public pools and makes them available with names such as

What is port scanning? It’s akin to walking through a parking lot and pulling on door handles to see which doors are unlocked.  Just as cars can contain valuables, computers can also contain valuables, including personal data.

Port scans can be used ethically, but they can also be used maliciously. For example, evil hackers use port scan results to identify potential victims based on the software they detected during the port scan. Researchers, on the other hand, use port scan data to compile reports about the internet as a whole, As seen on Shodan (link). These are the two main reasons to initiate a port scan.

Do these scans target me specifically? Well, no, not exactly. These scans do target Debian systems, but they do not specifically target individuals.

Millions of devices use the Debian NTP servers. A rising percentage of those devices have IPv6 addresses.

What's IPv6?

Internet Protocol version 6 (IPv6) is the latest version of the network protocol that carries your data across your home or office network and across the internet as a whole. It's a very important upgrade for the internet and it will enable the unbounded growth of network connected devices that has continued to accelerate over the last two decades or more.

Adoption of the new protocol is ramping up behind the scenes on networks around the world. For the most part, it is a transparent upgrade. You know there’s a sidewalk under your feet while you’re walking and you probably don’t care much whether it’s made of concrete or something else. Its biggest selling point is the vast number of addresses that are available with IP version 6. So you can connect your thermostat and refrigerator to the internet.

Ipv6 offers a number of security features. Randomized host addressing is one - also known as temporary addresses or privacy extensions.

Randomized Addressing?

This refers to the so-called "privacy extensions" which provides a means for devices to assign themselves an IP address that is half home/network prefix and half random bits. This is supposed to offer a means to cloak the device by making its address nearly unguessable. but as we all know, security through obscurity is no security at all. The operators of this scanner network are exploiting the fact that these privacy addresses are exposed any time the device makes an outgoing connection (such as setting its clock to an NTP server)

But temporary addresses are secure, right?

yes and no. They certainly help, and having a temporary, somewhat random IPv6 address that doesn't contain your MAC address is a step in the right direction, it's still possible to receive traffic on that temporary address, during its lifetime. Both devices had temporary addresses assigned. Both devices are behind a firewall and not used by users for internet communication. The only services running were NTP, and an occasional package manager update.
Also see RFC5157 ("IPv6 Implications for Network Scanning")

Make Shodan Do The Dirty Work

It seems the scans are being carried out by way of the Shodan’s scan API. The IPs that perform the scans are registered to Shodan hostnames. Below are a few examples (these are some of the scanners that spewed scan packets at my firewall:

2604:a880:0800:0010:0000:0000:0970:a001 =
2604:a880:0800:0010:0000:0000:00fe:d001 =
2604:a880:0800:0010:0000:0000:0092:2001 =
2604:a880:0800:0010:0000:0000:00fd:7001 =
2604:a880:0800:0010:0000:0000:0089:c001 =
2607:ff10:00c5:0509:bcde:00d0:fde8:e28d = ? Carinet ISP. This one is an oddball, only seen twice.

How exactly are the addresses harvested?

So clearly we can see that performing an ntp time sync against a harvester will result in a follow-up scan, but how are the harvesters capturing my IP information? Are they scraping the ntp log file, or perhaps a firewall log? Well in the interest of narrowing down the list of possibilities, I tried probing the ntp port directly, using netcat, against a known harvester. The result? I got scanned! So it seems a real NTP request is not even needed and a simple empty packet to the harvester’s ntp port is sufficient to get harvested. This suggests the possibility of a firewall log scraper, scapy script, or another low level means of IP harvesting, and also suggests that the ntp application itself on these time servers was probably not customized in any way.

New: On a whim I tried sending an empty packet to port 321 on an affected server (2604:a880:0400:00d0:0000:0000:0009:b00d) and lo and behold, it triggered a scan. So the harvesting seems to be completely independent of the NTP service that runs on the servers.

What Can People Do With The Scan Data?

For starters, they can glean the ratio of IPv6 addresses which do and do not have a firewall - because if they have a firewall, none of the scan probes will be responded to (and without a firewall, some or all packets will be responded to, if nothing else with a port-closed response). Furthermore, they know which services are not protected by a firewall on the clients. And finally, and most disconcerting is the possibility that they are also probing for vulnerabilities in the clients, in which case they would have a good idea how to load spyware/malware/virus onto the client should they choose to do so.

Progression of log analysis

Initially I had been correlating scans with harvesters using an embedded Splunk query, but I found it difficult and nearly impossible to take certain attributes of the primary query, adjust them slightly, and feed them into the phase-2 query that searches for outgoing packets that triggered the scanner. By using the Splunk API interface and writing a small Python script, I was able to do exactly what I needed, and in relatively short time. The script took two days to write, and it runs for about 10 seconds for every day of firewall logs it analysis. The results that it generates save me hours of manual work, and that’s a win in my book!

What method are they using for harvesting?

Most of my testing focuses on using the free NTP servers to get time and then analyzing the following scan. I went a little further though and attempted to find out whether or not real NTP traffic on the port was required or not. As it turns out, it's not. Simply sending an empty packet to port 123 is enough to trigger a scan. So, we can conclude that it's likely that the IP harvesting operation is looking for targets at a packet level, as opposed to some sort of custom NTP application. Chances are there is a Scapy script running or a firewall log scraper, which is collecting the IP Addresses of incoming connections and then passing that to the port scanner which resides elsewhere.

Test Server Setup

How did i configure my test server so that it uses unique ipv6 addresses each time it contacts a harvester?  This part is a bit technical and I'll provide samples below, but in general I increased the rate at which random IPv6 addresses expired and thus were re-generated and assigned. This is quite easy on Linux and Mac by tweaking sysctl. I don't recommend these settings on your desktop however because they might lead to your connections being disrupted of you're using an IP when its validity timer expires.


# BH - for testing. Turn off SLAAC.

# BH - privacy extensions - override the default 1-day long tempaddr validity time with something much smaller.
# This should help narrow down ipv6 address harvesting servers, among other things.

The settings above result in addresses being expired and allocated once every 20 minutes. This is just above the lowest recommended values where the protocols could start to act wonky. This rate lends itself well to running tests once every 30 minutes and each test getting its own unique ipv6 address.

And of course having a unique source address for each of my time requests made it trivial to backtrack which one triggered the scan - because the target of the scan would match the source of a time request, and the destination of the time request is the harvester.

Which NTP Servers Are Harvesting?

By default, a system running Debian comes pre-configured with five time server address pools: It’s the hostname that currently offers a few ipv6 addresses:

$ host
<snip> has IPv6 address 2604:a880:400:d0::9:b002 has IPv6 address 2604:a880:400:d0::9:b00e has IPv6 address 2001:470:e949:a::1 has IPv6 address 2604:a880:1:20::a7:f004

The address ending in f004 is a known harvester. There are many more. Below I confirmed over a dozen. I have another script running as we speak that is walking through every address in the pool and making a time request, to see if it triggers a scan.

Only a few IPv6 addresses are returned by a DNS lookup against the pool, but they all get returned eventually. There are literally hundreds, maybe thousands of IPs that can be returned. This is an effective means of distributing ntp clients across the large number of available servers and is quite normal in networking. It does however make it somewhat difficult to gain the full list of IPv6 NTP servers so we can check each one for harvesting behavior.

NTP is a funny protocol. In order to get the most accurate time reading, it visits a handful of different servers before making its final adjustment to the clock. This means that in a given synchronization period, it may visit half a dozen different time servers. This made it somewhat more difficult to identify which ntp server was harvesting and triggering the scans. I did my best to mitigate this challenge by using short tempaddr lifetimes and my nifty Detective script to do some heavy lifting.

The Detective Script

I wrote a Python script called (github link) to help do some of the heavy lifting and log analysis. It performs firewall log analysis to uncover scan operations. It then transforms attributes from the primary search and executes a second query to uncover which outbound packets most likely triggered the scan with great accuracy.

Sample application output:

SCAN DETECTED: startTime=2016-01-13T19:33:10.000+00:00 numPortsScanned=117 SRC=2604:a880:0800:0010:0000:0000:0970:a001 DST=my:prefix:my:prefix:7c0d:e6cb:8719:7d94 durationSeconds=0.0 startTimeEpoch=1452713590.0
One or more of these packets may have triggered the scan...
 lag=47.0s @2016-01-13T19:32:25.000+00:00 epoch=1452713545  my:prefix:my:prefix:7c0d:e6cb:8719:7d94:42539 -> 2604:a880:0001:0020:0000:0000:00a7:f007:123
 lag=7.0s @2016-01-13T19:33:05.000+00:00 epoch=1452713585  my:prefix:my:prefix:7c0d:e6cb:8719:7d94:59081 -> 2604:a880:0001:0020:0000:0000:00a7:f009:123

SCAN DETECTED: startTime=2016-01-13T20:01:19.000+00:00 numPortsScanned=110 SRC=2604:a880:0800:0010:0000:0000:0089:c001 DST=my:prefix:my:prefix:c10a:acd0:af40:c259 durationSeconds=0.0 startTimeEpoch=1452715279.0
One or more of these packets may have triggered the scan...
 lag=8.0s @2016-01-13T20:01:13.000+00:00 epoch=1452715273  my:prefix:my:prefix:c10a:acd0:af40:c259:58417 -> 2604:a880:0001:0020:0000:0000:00a7:f00c:123

SCAN DETECTED: startTime=2016-01-13T19:12:02.000+00:00 numPortsScanned=114 SRC=2604:a880:0800:0010:0000:0000:00ba:4001 DST=my:prefix:my:prefix:95b4:83a9:31a7:02e6 durationSeconds=0.0 startTimeEpoch=1452712322.0
One or more of these packets may have triggered the scan...
 lag=6.0s @2016-01-13T19:11:58.000+00:00 epoch=1452712318  my:prefix:my:prefix:95b4:83a9:31a7:02e6:52382 -> 2604:a880:0001:0020:0000:0000:00a7:f005:123

Confirming Each Harvester

After using my handy Python script (Github link) to get a list of likely harvesters, I confirmed each one individually by requesting the time from them, using ntpdate and checking for an immediate follow-up scan that ensues when harvesters are queried.

I also came up with some basic bash code to surgically probe each suspect while not letting ntp make other connections:

ip6tables -I OUTPUT -j DROP

for I in 0 1 2 3 4 5 6 7 8 9 A B C D E F ; do
 export IPADDR=2604:a880:0001:0020:0000:0000:00a7:f00${I}
 echo Triggering $I
 ip6tables -I OUTPUT -m state --state NEW ! -d $I -j DROP
 ip6tables -L OUTPUT -v -n;  
 ntpdate $I
 ip6tables -D OUTPUT 1
 sleep 1205 # Wait long enough for IPv6 temp address to refresh

Which helped confirm a bunch of suspected harvesters. I came up with the following list:

 2604:a880:0400:00d0:0000:0000:0009:b001 (DNS:

 2604:a880:0001:0020:0000:0000:00a7:f001  (DNS:

 2a03:b0c0:0003:00d0:0000:0000:0018:b001  (DNS:


The harvesters are using Digital Ocean IP ranges. By default, Digital Ocean provides "droplets" (their name for server or service instances) with an address range of 1-F (15 addresses) of which a server may assign one or all of the addresses. 

Each of the blocks of 15 above is probably a single server, each in a different network region.

GeoIP lookups (link) show the "robot" server(s) to be in San Francisco, the "abend" server(s) to be in New York, and the "analog" servers to be in Frankfurt Germany.
What is the Intention Behind the Scans?
Unclear at this time. You could set up a honeypot server and trigger a scan against it and see what happens after it discovers one or more vulnerable services. If you do, please come back and tell me about your results :)

It’s quite likely the scan results are being saved to a massive database such as Shodan does in the IPv4 world. Check out the website to see for yourself.

Until we know the true intentions of those behind this operation we can assume at very least that the data can and will be reported on, and at worst exploited and injected with malware.

How do I tell if I'm getting scanned?

It depends - do you have a firewall? If so, hopefully it logs dropped packets. There are typically two places a firewall would be installed to protect your computer: on the computer itself or on your gateway device. Comcast and other ISPs only certify hardware that blocks inbound IPv6, to protect you from this sort of attack. You would have to explicitly allow inbound connections in the router settings or be using an uncertified device that doesn't offer the same protection by default.

Further Work

I’m working with the NTP pool maintainers to dig into this and follow the appropriate channels to ferret out any activity that’s against policies.


I can be reached by email at name linuxbrad. 

Please leave feedback, suggestions, criticisms, etc. I would love to hear from you. 


  1. Have you reached out to Ask Bjørn Hansen at the NTP pool project (his first name at I suspect he would be up for giving you access to the full list of IP6 servers and working to remove the offenders from the pool.

    1. Hi John - yes I have been in contact with Ask regarding the scanning for a week or two now. Thanks for checking!

  2. So could 'bad people' use this to do DoS amplification or do Shodan and friends have some scan/rate limiting intelligence?

    1. One could certainly query Shodan for a list of NTP servers and go after them directly. This is the biggest downside to having a central database of open ports and service details.

  3. I have seen a recent (20160102T155313Z) instance of this (a Shodan scan targeting an RFC 4941 address) that was proximate with an NTP query from same address to a Digital Ocean address. Wife's Android phone on my home network was the target. The scan began three seconds after the NTP request. The scan got bounced at the edge as unsolicited IPv6 is dropped. Shodan also stops by once a day to (attempt to) scan the resident RIPE Atlas probe.

    Have times and addresses for those interested. There may be more of these — I just happened to notice that one as it went by.

    1. Yes please do share - I'm curious which NTP server triggered the scan, and what IP did the scanning. On a related note, I have seen some other, lower profile IPv6 scans that seem to be triggered by applications like Skype and BitTorrent, so I think there are more harvesters out there waiting to be discovered.

    2. 20160102T155313Z: Destination NTP address 2604:a880:0001:0020:0000:0000:00a7:f006

      20160102T155316Z: Scan origin address 2604:a880:0800:0010:0000:0000:0092:2001

    3. Hi Gary - yup - definitely got scanned by Shodan, and the NTP IP you listed is a harvester. Any chance you can back track in your logs to see when the first scan occurred? Each target is only scanned once as far as I can tell.

    4. I checked my logs and found the first NTP-related scan from Shodan happened 8/31/2015. 115 ports were scanned following an NTP request to a server within the New York harvester IP range.

    5. I had only then set up log preservation, and since all outbound connections are logged, the base logs rotate out rather quickly. I do have traffic since January 2. I checked the device that triggered the scan, and the set of all NTP destinations since January 2 is dominated by, though there are 19 other destinations. I'll send the others via email. Unfortunately, finding the origins of the NTP requests on the phone itself is not an easy task, nor have I had time to correlate with DNS requests, etc. Have you observed any NTP requests (that trigger a scan) from devices other than smart phones?

  4. Don't you think that's just a servers with MONLIST command which give away all the recently connected IPs to anyone?

    1. That's a good idea and others have also echoed this potential misuse of MONLIST as well. However in the scenario reported about in this post we can see that the harvesters are registered as Shodan hostnames, in DNS.

    2. I think you missed ValdikSS's point, he was saying that anyone (including shodan) could use a MONLIST command to query any (vulnerable) NTP server in order to get a listing of all the IP's that previously recently connected to that NTP server (like your server IP)

  5. This comment has been removed by a blog administrator.

  6. This short article posted only at the web site is truly good.

    Cate Blatt

  7. Thanks a lot for sharing such a good sources with all, i appreciative your efforts taken for the each. I find this worth sharing and must share this with all. Internet Marketing Company Bangalore | Digital Marketing Company Bangalore

  8. It is truly a great and useful piece of information. I am satisfied that you just shared this helpful info with us. Please keep us up to date like this. Thank you for sharing. Local SEO Services Company India

  9. Great content material and great layout. Your website deserves all of the positive feedback it’s been getting.

  10. Very informative article which is about the My IP and i must bookmark it, keep posting interesting articles.
    IP address

  11. Great! Thanks to sharing with us this information! Good job! ;)

    cordless landline

  12. Configure the router settings using default ip address to 192.168.l.254 login

  13. Really a great post. Appreciate the effort in educating us. We do provide Digital Marketing Company in Bangalore

  14. Hey Blogger, you have written a masterpiece with lots of information and I must say that you should post daily. Visit Us too kroger feedback


  15. Configure the router settings using default ip address to

  16. Hi! Thanks for sharing this very interesting article
    Check out our products: Solenoid valve (van điện từ) , butterfly valve (van bướm), balance valve (van cân bằng).

  17. I think you missed ValdikSS's point, he was saying that anyone (including shodan) could use a MONLIST command to query any (vulnerable) NTP server in order to get a listing of all the IP's that previously recently connected to that NTP server (like your server IP) tellthebell portal.

  18. As you grow, you will(nhà khung thép giá rẻ) realize that arguing right and wrong more than(so sánh gạch nung và gạch không nung) losing to others is sometimes not important anymore.(tam san be tong sieu nhe) Most importantly, just want peace.

  19. एक चांगला लेख. एक चांगला लेख सामायिक केल्याबद्दल धन्यवाद.

    Bệnh ve ký sinh trên chó Bul Pháp

    Bệnh mò bao lông trên chó Poodle

    Phân biệt chó Alaska và chó Husky

    Những kinh nghiệm nuôi chó Bull Pháp

  20. Never share(dịch vụ phun thuốc muỗi chất lượng) your secrets with anyone because it can ruin you(diệt mối ở chung cư cao tầng như thế nào). This is probably the most(dịch vụ diệt gián) important advice in life.

  21. No matter how big your house is(đá quý sapphire) , whether you have just bought a brand new car(Tìm hiểu về đá quý sapphire) , or even how much money you have in(chàng trai tiết lộ giá của đá ruby đỏ)  your bank account, your grave is just that much. ruler. Be humble.

  22. Ақпарат өте жақсы. Бөлінгеніңіз үшін рақмет. Барлық табыстар тілейміз!

    Phối giống chó phốc sóc

    phối mèo Ba Tư

    Phối giống mèo anh lông ngắn

    Phối mèo Scottish

  23. Балким, келечектеги макалалар же жакшы болот. жакшы күнү бар

    chó Corgi

    bán chó Corgi

    chó Corgi giá bao nhiêu

    mua chó Corgi

  24. Энэ бол зууны хамгийн сайхан өгүүллүүдийн нэг юм. Хуваалцахдаа баярлалаа. Амжилт хүсье, амжилт хүсье!

    C.ty bán cửa lưới tại huyện Đông Anh

    Đại lý cửa lưới chống muỗi tại Quảng Ninh

    Siêu thị cửa lưới chống muỗi tại Linh Đàm

    Siêu thị bán cửa chống muỗi phường Phương Mai

  25. Bài viết bạn rất hay:

    Chúng tôi là đơn vị cung cấp các sản phẩm chất lượng như:

    lều xông hơi

    lều xông hơi sau sinh

    lều xông hơi giá bao nhiêu

  26. Bài viết bạn rất hay:

    Chúng tôi là đơn vị cung cấp các sản phẩm chất lượng như:

    Giảo cổ lam

    giảo cổ lam giải độc gan

    giảo cổ lam giảm béo

  27. Il tempo è gratis ( Đá sapphire ) non ha prezzo. Non puoi possederlo,( vòng đá ruby đỏ ) ma puoi usarlo. Puoi usarlo, ma non puoi tenerlo.( đá spinel ) Una volta perso, non sarai( đá ruby đỏ lục yên ) in grado di recuperarlo.

  28. Bài viết rất hay: Chúng tôi chuyên cung cấp các sản phẩm chất lượng sau:

    bồn massage

    bon ngam chan

    máy massage chân

    Cảm ơn các bạn!

  29. Ina so in gode. Yana son ka ko da yaushe farin ciki da farin ciki da nasara a kan hanyar da ka zaba

    bán chó corgi cái

    chỗ bán chó corgi

    ở đâu bán chó corgi

    bán chó corgi nhập

  30. Дээд чанар бол зүгээр л( đá spinel vàng ) санаатай биш юм. Энэ нь өндөр( đá spinel ) түвшний төвлөрөл, тусгай хүчин( Đá Sapphire ) чармайлт, ухаалаг чиг баримжаа, чадварлаг туршлага, саад тотгорыг даван туулах( bán đá sapphire thô ) боломжийг хардаг.

  31. Si el agua cae al lago, desaparecerá( phụ kiện tủ bếp ). Pero si cae a la hoja de( phụ kiện tủ áo ) loto, brillará como una joya. Caer igual pero( thùng gạo thông minh ) estar con alguien es importante.

  32. Good.

    Freshpani is providing online water delivery service currently in BTM, Bangalore you can find more details at
    Online Water Delivery | Bangalore Drinking Water Home Delivery Service | Packaged Drinking Water | Bottled Water Supplier

  33. Një artikull shumë interesant dhe interesant. Faleminderit për ndarjen

    Phụ kiện tủ bếp
    Phụ kiện tủ bếp cao cấp

  34. Your article is very interesting. Also visit our website at:
    web design company in chennai

  35. This is a nice Site to watch out for and we provided information on
    vidmate make sure you can check it out and keep on visiting our Site.

  36. Vidmate is one of the best known applications currently available for downloading videos and songs from online services like Vimeo, Dailymotion, YouTube, Instagram, FunnyorDie, Tumblr, Soundcloud, Metacafe, and tons of other multimedia portals. With this highly recommended app, you’ll get to download from practically any video site.A free application for Windows users that allows you to download online

    An entertaining application
    Vidmate latest update in pie
    Amazing features of Vidmate
    How to download movies from internet,
    Watching movie is good for time pass ,
    Watch movies at home,
    How to download movies through "Vidmate".

  37. Nội Thất Trẻ Em Bảo An Kids là doanh nghiệp chuyên thiết kế và thi công các sản phẩm nội thất trẻ em tốt nhất bao gồm: Phòng ngủ trẻ em, Giường tầng, bàn học đẹp, kệ sách, bàn học bé trai, tủ treo quần áo…

  38. Nice Post! Thanks for sharing such an amazing article, really informative,it helps me a lot. For latest Marathi news and updates please visit our website:Marathi Media News

  39. Nice Post! Thanks for sharing such an amazing article, really informative,it helps me a lot. For latest Hindi news and updates please visit our website:Hindi Media News

  40. Nice Post! Thanks for sharing such an amazing article, really informative,it helps me a lot. For latest Hindi news and updates please visit our website:Hindi Media News

  41. Nice Post! Thanks for sharing such an amazing article, really informative,it helps me a lot. For latest Telugu news and updates please visit our website:Telugu Media News

  42. Nice Post! Thanks for sharing such an amazing article, really informative,it helps me a lot. For Latest Telugu News and Updates please visit: Tolivelugu Media News

  43. Awesome content.Thanks for sharing such a informative post.PPC Company in Bangalore.

  44. Great post I would like to thank you for the efforts you have made in writing this interesting and knowledgeable article. We are top CRM Software | CRM Software Mumbai | CRM Software Provider | CRM Software Pune

  45. 192.168.l.254 is a Private IP address and most powerful universal IP addresses, this is used in the Linksys router.

  46. Really i found this article more informative, thanks for sharing this article! Also Check here

    Download and install Vidmate App which is the best HD video downloader software available for Android. Get free latest HD movies, songs, and your favorite TV shows

    Vidmate App Download

    Vidmate apk for Android devices

    Vidmate App

    download Vidmate for Windows PC

    download Vidmate for Windows PC Free

    Vidmate Download for Windows 10

    Download Vidmate for iOS

    Download Vidmate for Blackberry

    Vidmate For IOS and Blackberry OS

  47. It is amazing and wonderful to visit your Blog.Thanks for sharing this information,this is useful to me.
    Our Services are:- Digital Marketing Company | SEO Company | PPC Company | Mobile App Development Company | Mobile App Development Company Lucknow | Website Designing Company