The new parrot CDN


(Lorenzo "Palinuro" Faletra) #1

the Parrot CDN

Hello mates, i am proud to announce the release of our dedicated CDN (Content Delivery Network)

It consists of several servers all around the world that host a fully operational caching and delivery system of all the content of our website

This servers network is completely driven by us (no external services involved) and all the data goes directly to servers we own.

Thanks to very powerful technologies like GeoDNS and IP Anycast, if someone hits a parrot website, it is served automatically by the nearest servers according to the ip location of the client.

By having our own CDN we can move away from cloudflare and other third party services, provide fast content delivery, provide failover routes in case of network congestions, downtimes or attacks and offer a better and more private services to all our users.

how to test the CDN

test how the CDN sees your requests:

┌─[palinuro@parrot]─[~]
└──╼ $ dig -t txt @ns.parrotsec.io director.geo.parrotsec.org | grep country

director.geo.parrotsec.org. 30	IN	TXT	"ip 185.178.92.254 v4 city gavardo country it ita state eu region 09 name unknown as as206701"

test how the CDN resolves for you:

┌─[✗]─[palinuro@parrot]─[~]
└──╼ $ host director.geo.parrotsec.org

director.geo.parrotsec.org has address 89.36.210.176
director.geo.parrotsec.org has address 80.211.238.94
director.geo.parrotsec.org has IPv6 address 2a03:a140:10:10e6::1
director.geo.parrotsec.org has IPv6 address 2a03:b0c0:3:e0::105:5001

test how the CDN caches content:

┌─[palinuro@parrot]─[~]
└──╼ $ curl -I https://www.parrotsec.org/img/logo.png 2> /dev/null | grep X-Cache-Status

X-Cache-Status: HIT
  • MISS – The response was not found in the cache and so was fetched from an origin server. The response might then have been cached.
  • BYPASS – The response was fetched from the origin server instead of served from the cache because the request matched a specific cache directive. The response might then have been cached.
  • EXPIRED – The entry in the cache has expired. The response contains fresh content from the origin server.
  • STALE – The content is stale because the origin server is not responding correctly, and the edge server is providing cached content instead.
  • UPDATING – The content is stale because the entry is currently being updated in response to a previous request.
  • REVALIDATED – The CDN verified that the current cached content was still valid.
  • HIT – The response contains valid, fresh content direct from the cache.

The future

We are still working hard to optimize our setup and we will add new edge servers to scale up if needed.

We are also working on a big upgrade to our mirror servers (iso downloads and apt archive).

Stay tuned :slight_smile:


#2

This is awesome news! Few questions so that I may give correct answers,

  1. is the goal to migrate from parrotsec.org to parrotsec.io?
  2. I know that we had round Robin’s in place for our previous set up to harden the security and provide for failsafes in any event a server was brought down; the more mainstream and mature we become, and the more popular we become as a tool to circumvent censorship, we may become nuisances/annoyances to groups and governments seeking to limit what their citizens can access. Are we prepared for this and what is the plan should this happen (Let me know if you want that re worded as I’m reading it it sorta flows but also is kinda weird, sorry its early)?
  3. what are the new DNS servers if they changed at all?
  4. (while I have you here, I sent you a message privately, and I would also like to know if you could reccomend a good source to read in reference to tor and i2p and tor in China)

(Lorenzo "Palinuro" Faletra) #3

it would be awesome to use the parrotsec.io domain instead, but there is no plan to do it and we will keep parrotsec.org anyways

we had dns round robin in the dns configuration of the parrot os because some consumer ISP dns servers block some domains

a round robin configuration will let you use the isp dns anyways, so it was not meant to protect users privacy, but to circumvent censorship instead

we will make it better in the future as we better understand how to properly handle these things

dns servers in the parrot systems are edge dns relays used to resolve ANY domain into the proper ip address

what we did with our CDN was to set up some special auhoritative DNS servers that ONLY resolve parrotsec.org and parrotsec.io and answer with the proper records according to the geographic location of who made the request (geo dns instead of standard dns)

these special authoritative servers are then registered to the domain registrar of parrotsec.org and parrotsec.io

when someone asks any dns resolver where does something**.parrotsec.org point, the resolver asks to the dns root servers that return the authoritative servers that return the proper dns record

the dns resolver is what you have in /etc/resolv.conf

the dns root servers are special dns clusters that handle the various dns root zones (.org is a root zone, .io is another root zone)

the authoritative servers for a domain are theservers that handle the dns records for that specific domain, we currently have 9 of them and we plan to increase them in the future

no idea of how networking works in china, unfortunately i don’t have enough spare time to investigate, but i am pretty curious as well

the question you din’t make: what is an anycast ip :slight_smile:

an unicast ip address is announced by an AS number.

an AS number is assigned to a provider.

providers connect together all the datacenters around the world, and each of them makes peering.

connections with the other internet carriers exposing their AS numbers

if you want to connect to an ip address, you forward your request to your ISP, your ISP checks what AS number is announcing that ip subnet and then it calculates the fastest route to reach the infrastructure associated to that AS number (the BGP protocol does all the magic).

then the receiving provider routes the ip packet to the proper server with that ip address.

an unicast ip then resolves to one and only one server connected somewhere in some datacenter.

an anycast ip on the other hand is an ip address that is associated to an AS number that is being announced on several datacenters at once.

if you have a bgp router in the united states and another one in europe, and you announce the same AS number with the same ip netmasks on both, then european carriers will route the traffic to your european point of presence, while all the carriers in north america will find that the shortest path to that AS number is your datacenter in the states

with an anycast ip you can have several servers in different datacenters that announce the same ip address, and each of them will automatically receive the nearest traffic available because other carriers will find that server as the shortest path to resolve that IP.

here some additional interesting resources


(Nico Paul) #4

that leads me to a question 6 now haha

does anycast raise any privacy/content censorship issues and to what tactics are able to be used to counteract these concerns?

Thank you for both the links and the time it took to write all that! I learned/clarified a lot so I truly appreciate it!


(Lorenzo "Palinuro" Faletra) #5

privacy is a very complex and fluid topic, and what i’m going to say is just what i think right now.

an anycast infrastructure does not represent a privacy issue right now, and if an ISP bans an ip route, there is no differe ce between an anycast and an unicast address, and if the provider blocks a service at the dns level, then the censorship happened on a complete different layer that does not involve the ip layer.

having a server in most of the countries means that these servers are potentially in the hands of the local authorities.

the true question we should answer is: what do these servers actually do? what kind of private information is stored? how is it stored? what happens if an edge node is cloned and analyzed?

the edge nodes do not host private information of the users, the private information just transit (encrypted) from the provider to the edge host and then goes from the edge to the master (encrypted again).

the master is the only server that hosts private user information

the edge has a cache that stores static and public content as css/js files, pictures etc

additionally these edge servers are owned by us, we can delete servers, migrate them, deploy new ones, change provider etc. we can force users in a country to stay away from a particular node and transit the parrot network from a node in another country.

the infrastructure is pretry flexible, it is agnostic co the content it delivers and it is fucking awesome to have such a complex infrastructure self-hosted and conpletely in our hands

in the other hand there is a big thing i don’t really like but is mandatory for technical reasons: each edge node needs a copy of the ssl certificates for our domains. these certificates in the wrong hands can be used for ssl-validated mitm attacks to our network, but i still prefer to have our certificate on our servers than to have it on 90 cloudflare pops


(Amzker Pro Hacker) #6

And my Question
How you guys write loooonnnnggg Answer without get booring and laziness


(Abdel Rhman Anter) #7

lorenzo Copy & paste :joy:


(Lorenzo "Palinuro" Faletra) #8

interesting question

we log user activities from the web server logs and we use goaccess to monitor strange activities

i am the only person authorized to access the servers and eventually handle the logs

the logs are never handled directly (also they are too big for manual analysis)

goaccess analyzes the logs for us aggregated data such as page hits, unique visitors, most used browsers, origin country, most requested addresses, most accessed domains etc

the data we have is aggregated and does not reveal private user information.
the only private information directly visible from goaccess is the ip address of the users, but the servers already have automatic protections to ban misbehaving ip addresses, so we only store the ip addresses for technical reasons in case of cyberattack.

logs are disabled on the edge nodes, so we can keep them secure on the central infrastructure where authorities or third parties can’t take them without our approval.

we periodically delete logs from servers when we are sure that no attacks were received in that period of time, and we shred them for security before restarting the service.

we also provide free dns resolvers for the opennic network. these servers have logs disabled.
there is a tiny log buffer that hosts the latest service hits for debug purposes but this is just a buffer that keeps a bunch of recent elements that disappear automatically as new requests come and it is the standard behavior of the dns resolver we use (powerdns).

we have never received a warrant since we exist.


(Lorenzo "Palinuro" Faletra) #9

p.s.
now we have a warrant canary :slight_smile:
https://www.parrotsec.org/docs/warrant-canary/


#10

just to throw out a question and perhaps an avenue to consider with regard to securing connectivity in the event of any state agency or isp blocade or ban…

What about implementing a decentralized blockchain solution, using the hash to authenticate and validate. Decentralization could possibly be an add-on to the ParrotOS core enabling the userbase to essentially help provide the mirrors? Hash addressing is where we are heading anyway, and could possibly help with encrypting the decentralized communication and transfers.

  • or am I just crazy?

#11

canary means much to me, thanks, and all the work you and your team do selflessly, and the future projects you wrote about are admirable.

thanks to all parrot contributors too for keeping it alive.


(Lorenzo "Palinuro" Faletra) #13

the blockchain is an awesome technology that combines many many other technologies to strike a very specific goal

the goal of the blockchain is extremely far from what we need to protect users privacy, and the blockchain is a terrible technology when used in contexts where it was not designed to be used


(Nico Paul) #14

ok, so pretty much what I was attempting to ask was answered and then some. the canary is clever.

  • better composed thoughts/responses/questions coming tomorrow on the rest.

#15

Is there a script to auto check canary? Can you give examples of why we would force re route away from a node based on geo? New servers seem stable and very quick


(Lorenzo "Palinuro" Faletra) #16

some people used to maintain a canary watch website, but the website is no longer maintained
i don’t have a clear answer to your question. we just started doing this kind of stuff and we are free to develop whatever we want.
if you need an auto notification tool, you are free to do that, and maybe we can create a new canary watch website with automatic updates from several websites.

a good reason to dismiss a CDN node can be a government changing its privacy policy allowing a provider or a govt agency to inspect our server without any previous notice.


#17

Awesome! That is exactly the answer I was looking for in regards to canary. What would be a good starting point for the website? Would this be just for our canary or others as well? I think having Parrotsec “guard” the canary watch page would be very fitting and a good way to also get some PR as its insanely clever and would be easy to write about if we reached out to tech blogs, cyber security news sites etc after we have a simple solid site up. I am terribly inexperienced with what this would entail and how best to start other than the domain reservation and if I get some assistance I’d be happy to work on this (my docs thing fell flat on its face so I’m looking for a redeeming project of any kind lmao).


(Lorenzo "Palinuro" Faletra) #18

we could register canarywatch.io and create an open source software (django? nodejs? laravel? flask? plain php?) to automatically handle the website and the canary monitoring process for us.


(Nico Paul) #19

ok i can do that right now i have a 35% off coupon for godaddy unless you have another preference (or do you want to register it?) I seriously believe we could leverage this as some PR which would hopefully (hope with a capital OBAMA) help dredge up some donation revenue.


(Lorenzo "Palinuro" Faletra) #20

it is better to register the domain once we have a working website software to deploy


(Nico Paul) #21

this is true. i was just so worried that everybody else was gonna go snatch it up haha yeah I hear it now haha we will move this to private chat to move this forward and open up the dialogue here for our rockin awesome new CDN!!!