Stupid cargo cult with buzzwords and "Managing Servers in the Cloud" LOL. #clowncomputing #outsourcing #LetsBeSlaves #devOps #devOOPS https://linuxtechlab.com/top-5-devops-books-for-beginners-to-read/
#devops
This is referenced every now and then: Pets v Cattle. Hoping to help clear it up:
The History of Pets vs Cattle and How to Use the Analogy Properly
In the old way of doing things, we treat our servers like pets, for example Bob the mail server. If Bob goes down, it’s all hands on deck. The CEO can’t get his email and it’s the end of the world.
In the new way, servers are numbered, like cattle in a herd. For example, www001 to www100. When one server goes down, it’s taken out back, shot, and replaced on the line.
Systems Operations is a Risk Mitigation Practice
Having done ops for much of my professional life, one thing I've realised (largely since having stepped out of the role) is that:
- Ops is largely about risk mitigation and management.
- Running regular scenario drills should in fact be a large part of the role function.
- As is updating procedures with lessons learnt from the exercises.
That is, testing what happens when some eventuality occurs and how your organisation responds to it. Where those scenarios evolve as the landscape about your evolves. E.g., ransomware and associated threats are a major concern now, though they are only one of a number of potential risks.
I am not aware of any significant or widely-known guide to systems administration and operations which takes this viewpoint. The model does address many of the frustrations I've had with the role over my own career.
Keep in mind that a specific countermeasure may only address part of a risk. E.g., backups address the "we can get our data back" problem. Backups do not address the "we cannot unpublish that which has been made public" problem. So depending on your threat model, backups alone are not a complete mitigation.
#Sysadmin #DevOps #Operations #Risk #DrillBabyDrill #ScenarioPlanning #TrainingInPractice
Meow
#ElasticSearch, one of the database engines targeted by the #MeowDbAttack, has long had ZARRO authentication and security features in its free version.
(Security was added in only release 6.8, in May 2019, the database itself was released in 2010 https://www.elastic.co/guide/en/elasticsearch/reference/6.8/release-notes-6.8.0.html)
Instructions on securing the databse which remains unsecured by default are dated Februarry 2020:
https://www.elastic.co/blog/how-to-prevent-elasticsearch-server-breach-securing-elasticsearch
ElasticSearch is "trusted, used, and loved by" #Bayer, #Adobe, #Lenovo, #WalMart, and #Kroeger (https://www.elastic.co/elasticsearch/) and is the featured search utility on #AmazonAWS (https://aws.amazon.com/elasticsearch-service/)
The (strongly justified IMO) attack has removed nearly 4,000 unsecured databases since July 22:
One of the first publicly known examples of a Meow attack is an Elasticsearch database belonging to a VPN provider that claimed not to keep any logs.
I'd really like to hear from #ElasticNV or founder/CEO #ShayBanon. For now, crickets:
https://twitter.com/kimchy
https://twitter.com/elastic
HN: https://news.ycombinator.com/item?id=23957510
SO: https://stackoverflow.com/questions/63067062/elastic-search-indexes-gets-deleted-frequently
Vendor, service, client, and deployment bullshit like this is a major cause of my frustrations (and worse) with the IT industry.
Other targets include #MongoDB #Cassandra #CouchDB #Redis #Hadoop #Jenkins, and unsecured network-attached storage devices (NAS).
Hats off to Meow's authors.
#sysadmin #dbadmin #netadmin #devops #infosec #schadenfreude
