en.osm.town is one of the many independent Mastodon servers you can use to participate in the fediverse.
An independent, community of OpenStreetMap people on the Fediverse/Mastodon. Funding graciously provided by the OpenStreetMap Foundation.

Server stats:

257
active users

#domainname

0 posts0 participants0 posts today

> " What country level domain name extensions are available for everyone?! "

The following, should be available to anyone to register. However, some (see list) will require a "domain agent" if you do not live or own a business in these countries. Many domain registers are happy to be your "domain agent", but you should check first with the register.

.ai – Anguilla

.am – Armenia

.co – Colombia

.fm – Micronesia

.io – British Indian Ocean Territory

.me – Montenegro

.tv – Tuvalu

.cc – Cocos (Keeling) Islands

.ws – Samoa

.in – India

.to – Tonga

.bz – Belize

.uk – United Kingdom (will need a domain agent)

.de – Germany (will need a domain agent)

.nl – Netherlands

.eu – European Union (will need a domain agent)

.ca – Canada (will need a domain agent)

" What country level domain name extensions are available for everyone?! "
The following, should be available to anyone to register. However, some (see list) will require a "domain agent" if you do not live or own a business in these countries. Many domain registers are happy to be your "domain agent", but you should check first with the register.

.ai – Anguilla

.am – Armenia

.co – Colombia

.fm – Micronesia

.io – British Indian Ocean Territory

.me – Montenegro

.tv – Tuvalu

.cc – Cocos (Keeling) Islands

.ws – Samoa

.in – India

.to – Tonga

.bz – Belize

.uk – United Kingdom (will need a domain agent)

.de – Germany (will need a domain agent)

.nl – Netherlands

.eu – European Union (will need a domain agent)

.ca – Canada (will need a domain agent)

#Domain #DomainName #Fediverse #ActivityPub #UsJurisdiction

This is how you run a Fedi website outside Us Jurisdiction.

mk.absturztau.be = Domain (.be) name is Belgium, while hosted in Switzerland, and the hosting provider is governed under the laws of Switzerland.

mastodon.au = Domain (.au) name is Australia, while hosted in Australia, and the hosting provider is governed under the laws of Australia.

Remember, Dot Com, Net, Org, Info, Us, and Edu is governed by the United States of America. Most word-based domain names, for example, Dot Social, managed by Corporations within the USA.

#Fediverse #ActivityPub #Mastodon #Misskey #DomainName #Domain #WebHosting

#linuxguru #help #questions

Looking for anyone who knows #networking. Specifically, #domains and nslookups. I wrote a domain analysis #script, but I did it quickly for myself and some collages. Does anyone have any suggestions for the best #language to use to do extensive domain record lookups? I was thinking #Python, but some where I work use #Ruby. I know I do not wish to stay using #PHP. That was thrown together quick and works, but it is not ideal.

So basically, what language is considered to have the most libraries/tools for #domainname #analysis? Mostly #dns64
stuff.

Basically, this is a simple tool that combines a bunch of what could just be bash commands to get a good overview of a domain name, it's records, and the status of those hosts/ips. Open to any suggestions!

I can go into specifics if anyone bites on this topic.

Replied in thread

W.r.t. password managers (pw mgrs):

1) Make sure that you *NEVER* forget your master password.

2) Make an *OFFLINE* backup of the (encrypted) pw database after each modification. For example, rotate between multiple USB storage media.

3) Use a pw mgr that can generate strong (random, long, unguessable) passwords. Use that functionality to generate a unique pw for each account.

LAST BUT NOT LEAST
4) At least on mobile devices, configure the OS and pw mgr to locate your credentials *automatically* based on the domain name of the website you're visiting (using "autofill", which lets the OS pass the domain name –as used by the browser– to the pw mgr).

EXAMPLE WHY
If you receive an email (with SPF, DKIM and DMARC all fine) from:

    whomever@circle-ci.com

that instructs you to revalidate your 2FA settings in, e.g.:

    https:⧸⧸circle-ci.com/revalidate

Then a properly configured pw mgr will not come up with ANYTHING - because the record is for (without the dash):

    https:⧸⧸circleci.com

The deja vu after the 2022 attack (github.blog/news-insights/comp), described in discuss.circleci.com/t/circlec, is still alive and kicking since March this year (see crt.sh/?q=circle-ci.com and virustotal.com/gui/domain/circ). The fake site even looks better than the original one (I don't know whether it is actually malicious, or will just warn users who attempt to log in).

NOTE: if your pw mgr does not find a matching record in the pw mgr database, do NOT manually locate the "circleci.com" record. If you do: do NOT autofill or copy/paste your credentials for https:⧸⧸circleci.com to https:⧸⧸circle-ci.com! Using those creds, the fake site may immediately log in to the authentic website AS YOU - pwning your account.

WHAT I'M USING
I'm using KeePassium on iOS and KeePassDX on Android; they work just fine (disclaimer: I'm not in any way related to their authors, and do no warrant their reliability).

@steelefortress

The GitHub Blog · Security alert: new phishing campaign targets GitHub usersOn September 16, GitHub Security learned that threat actors were targeting GitHub users with a phishing campaign by impersonating CircleCI to harvest user credentials and two-factor codes. While GitHub itself was not affected, the campaign has impacted many victim organizations.

@tasket wrote:
<<< Using password managers is great. But having them directly interact with web browsers is a dubious proposition [...] >>>

Most people nowadays use smartphones (in particular in airplanes and in airports where these attacks happened).

Both iOS and Android have an autofill feature that works great. The user can use any PWM (password manager) they want; no browser plugins are required. The OS takes care of interfacing between the browser (or any app that shows a page with fields apparently meant for supplying user credentials) and the PWM.

I've been testing KeePassDX on Android and KeePassium on iOS, and I'm getting more and more comfortable with them (disclaimer: use at your own risk). They work fine with every browser on those OSes that I tested.

Compared to passkeys, there are some caveats:

1) If the user tries to log in to a fake site, the PWM will not find the domain name of the fake site in it's database. In that case the user should NOT be tempted to search the database for the domain name of the real site and have the PWM fill in those credentials on the phishing site (passkeys simply will not allow you to do that, but they have a zillion of disadvantages that PWMs do not have).

2) The user must confirm that an https connection is used (passkeys mandate this by themselves). If not, then the domain name shown in the browser's address bar may be spoofed.

3) Obviously the user must also make sure that the PWM's database is backed up after each change, and that unlocking it requires a strong password that the user does not forget - in particular when not typing it regularly, because of using Touch ID or Face ID to unlock said database (effectively retrieving the actual password from secure storage in the phone - after authenticating with biometrics or, alternatively, a screen unlock code).

@tasket wrote:

<<< Users have been infantalized to the point where they are never given advice to check for https + domain spelling, which was supposed to be the actual bedrock of Web security. >>>

I came to understand that it's too hard for most users to understand domain names - in such a way that they will not be fooled (domain names *are* complicated: infosec.exchange/@ErikvanStrat).

And it is not just end users, look at the zillions of domain names that Microsoft has registered. Some idiot decided that users have to log in to login.microsoftONLINE.com. And in NL there are lots of domain names such as ("werken bij" means "work at" or "get a job at"):

    werkenbijexample.com

or

    werkenbij-example.com

instead of

    werkenbij.example.com

Users are also easily fooled by IDN's or by inserting a dash. For example, a lot of developers were tricked into entering 2FA credentials into a page on "circle-ci.com" instead of the original "circleci.com" (more on that, and passkeys, here: infosec.exchange/@ErikvanStrat).

However, passkeys and PWM's (password managers) that check domain names solve only PART of the problem: they don't help if you're creating an account or enter credit card data on a fake website.

Therefore I strongly believe that we should reintroduce reliable certificates that contain additional, human readable, identifying information of the owner of a website (see infosec.exchange/@ErikvanStrat and follow-ups).

In the end a domain name is just an (often meaningless) alias to an IP-address (or more than one address, but you get the point). They're incredibly cheap and DV certificates are free, which results in what you can see under "Passive DNS Replication" in, for example, virustotal.com/gui/ip-address/ (tap ••• at the bottom of the list to see more domain names of mostly malicious websites, proxied by Cloudflare and often using Google certs).

@kasperd @agl @rmondello @BleepingComputer

Infosec ExchangeErik van Straten (@ErikvanStraten@infosec.exchange)David, more and more I tend to think that a block list is mostly useless: scanmers continuously register new domain names (or buy cleansed old ones), and IPv4 addresses do regularly change as well (IPv6 may may make block lists even longer). I guess we should consider to use allow lists. However, predicting which sites a person, such as your father, may want to visit in future, may be far from simple. Unfortunately I'm not aware of a simple and (near-) perfect solution. CYBERSECURITY AWARENESS The best I can come up with is to teach people, when visiting a website: 1) Don't look at the page. It may be fake but identical to the one you expect. It is pointless and a waste of time to look for visual differences. 2) Make sure that you have a https connection. Chrome no longer shows a padlock, while most browsers hide "https://" or even "https://www.". 3) Inspect the address bar and locate the domain name of the website (Safari usually hides the rest, which sometimes is unfortunate if they click on a misleading link like: https://twitter.com/realDonaldTrump/status/890617797956456448 (this is NOT a tweet by Donald Trump). 4) The domainname is the part that follows after "https://" (often hidden) and usually ends right before the NEXT forward slash '/' Note: there are some rare exceptions, such as   https://twitter.com:443/samykamkar (more on Samy later), and/or:   https://user:password@x.com If, after https://, no more forward slashes are shown in the address bar, then the domain name ends with the right-most character. 5) Its best to interpret domain names from right to left - if it were a "home" address written as follows:   10.downingstreet.london.uk 6) IMPORTANT: • The TLD (Top Level Domain name), at the full right, usually does not imply that the owner of a domain name - like samy.pl - is Polish or lives in Poland. Also, the server may be located anywhere on our globe, and may "move" without notice. BTW, the owner of https://samy.pl/ , Samy Kamkar, is a well known LA-based hacker (and a terrific speaker!). • The dot '.' is the (only) SEPARATOR that splits the domain name into multiple "segments" or subdomains; • The minus sign "-" is the only permitted non-alphanumeric character in regular (ASCII) domain names (see also "IDNs" below). Officially underscores '_' are forbidden, but know and then they make it through the registration process. *IMPORTANT*, the second of the following two domain names does NOT belong to Google (the first one does):   accounts.google.com   accounts-google.com It is essential to be aware of this, as it is a typical trick used by scammers. • Regular (ASCII) domain names are converted to lower case before being used. Note that, when I write:   security.nI , that this is not the same as:   security.nl (the latter ends with a lower case 'L', while the first domain name ends with an upper case 'i' - which would lead to a domain name registered in Nicaragua). Therefore it's best to read the domain name from the browser's address bar AFTER opening the site (and hope that there's no malware that infects your browser, or a screaming pop up "your computer is infected with a virus"). If possible, use an ad-blocker or NoScript. See also IDNs below. 7) Usually, if someone registers a domain name like google.com, they will automatically own ALL POSSIBLE SUBDOMAINS. This means that attackers CANNOT REGISTER A SUBDOMAIN of, for example, google.com (they'd have to hack the domain owner's DNS records, which may happen: https://www.bleepingcomputer.com/news/security/domain-shadowing-becoming-more-popular-among-cybercriminals/ ). Note that, therefore, it would make EXTREME sense if you'd have to log in to:   login.microsoft.com instead of to:   login.microsoftonline.com (what are they smoking in Redmond?) There are notable exceptions though, where domain owners SUBRENT subdomain names to (potentially malicious) third parties. This includes, but is not limited to *.workers.dev and *.pages.dev (see https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/its-raining-phish-and-scams-how-cloudflare-pages-dev-and-workers-dev-domains-get-abused/ ) But also *vercel.app, *.weebly.com, *.my.id, *.000webhostapp.com, *.github.io. and *.blogspot.TLD (TLD can be anything) are often used for scam sites. Furthermore, domain names such as sites.google.com typically contain USER GENERATED CONTENT - which may be misleading. NOTE: the above list is not complete! You may want to regularly check block lists like this one: https://raw.githubusercontent.com/mitchellkrogza/Phishing.Database/master/phishing-links-NEW-today.txt 8) IDNs (International Domain Names) make Unicode domain names possible, benefitting huge amounts of people around the globe. For example, a valid (German) IDN is:   https://hopfenhöhle.de/ However, IDNs are also used by scammers in order to deceive people, or by security people in order to warn us. For example, opening   https://www.аррӏе.com/ will not show the expected apple.com website (as of this writing, that site is not malicious). In fact, its actual link is:   https://www.xn--80ak6aa92e.com/ If a "segment" of a domain name begins with "xn--", the entire name is called a Punycode domain name (Punycode uses a subset of ASCII characters permitted in DNS). If browsers "suspect" a malicious website, most of them will, as a warning, show the Punycode alternative instead of the IDN. Unfortunately this trick is not reliable. OTOH, Firefox seems to always show "apple.com" in the example above. If you (or your dad) uses Firefox (desktop) or Nightly on Android, you can make Firefox always display the Punycode variant (locate about:config in https://krebsonsecurity.com/2018/03/look-alike-domains-and-visual-confusion/comment-page-1/ for instructions). One can, for example, use   https://www.punycoder.com/ to translate between IDN and Punycode, and vice versa. CONCLUSION Of course this is only a fraction of what every internet-user should know to reasonably stay safe online. HTH! P.S. The text above was adapted from (in Dutch) https://tweakers.net/nieuws/216878/ministerraad-stemt-in-met-gebruik-gov-punt-nl-als-domein-voor-overheidswebsites.html?showReaction=19450852#r_19450852 @sassdawe cc: @briankrebs cc: @samykamkar@bird.makeup (an automated account) #cyberSecurityAwareness #securityAwareness #awareness #domainNames #DNS #malicious #phishing #fake #fakeSites #fakeWebSites #IDN #IDNs #punycode #safeonline #deceptive #misleading