Making files immutable by Linux 'chattr' command

After all those years working in Linux env and studying on application hardening, I don't know how did I miss "chattr" command.

chattr - change file attributes on a Linux file system

Specially the attribute "i" is interesting for me, as it allows you to make a file immutable.

"A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed,  no  link  can  be created  to  this  file and no data can be written to the file.  Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute."

From man page of chattr, other attributes you can change are,
 -    append  only  (a),
 -    no  atime updates  (A),
 -    compressed  (c),
 -    no copy on write (C),
 -    no dump (d),
 -    synchronous directory updates (D),
 -    extent format (e),
 -    immutable (i),
 -    data journalling (j),
 -    secure deletion (s),
 -    synchronous updates (S),
 -    no tail-merging (t),
 -    top of directory hierarchy (T), and
 -    undeletable (u).


Following article explains many interesting usage of this command (including disabling user creation by making /etc/passwd file immutable)

https://www.tecmint.com/chattr-command-examples/


You can use lsattr command to see the attributes of the files/folders.

Threat Agents: Insider Threats: Motivations

Insider threat actors can be motivated by different factors. I try to summarize possible motivations in the following table, and it is not a complete list.

Also the attackers can gain access to a workstation of an employee through mechanism like phishing, and if there are controls to prevent insider threats, the damage that could be done by this attacker can be minimized.

Threat Agent		motivated by		Possible Motivations
Insider		Government		Patriotism, Blackmail, Financial gain, Legal gain, Psychological manipulation
Insider		Criminal Organization		Blackmail, Financial gain, Psychological manipulation
Insider		Criminal Organization - Criminal Community		Blackmail, Financial gain, reputation on sharing with community
Insider		Criminal Organization - Hacktivist groups		supporting a ideological cause, reputation on sharing with community, guilt/remorse
Insider		Criminal Organization - Terrorists		supporting a ideological cause, reputation in a like-minded community,
Insider		Competitor		Financial gain
Insider		Hacker		Financial gain, Blackmail
Insider		family/friend		Financial gain, helping family/friend from difficult situation
Insider		own-self		revenge, remorse/guilt, financial reward, patriotism, ideological cause, fame
Criminal Organization		Government		Financial gain, blackmail, patriotism
Criminal Organization		Competitor		Financial gain
Hacktivist		Government		Manipulation of facts

Accessing AWS metadata from EC2 instance

Recently I found few alternative ways to access EC2 metadata, during my studies for AWS Security Specialty exam.

Using http://169.254.169.254/latest/meta-data/
 This is the most popular way to access the metadata from an EC2 instance.


Using http://instance-data/latest/meta-data/ 
But did you know, you can use "instance-data" instead of 169.254.169.254 IP address, and use it to access same information?


Using ec2-metadata command 
If you have logged in as ec2-user, you can run "ec2-metadata" command to access the same set of data. This command has lots of options to filter the information you need. If you have logged in as another user, you will have to add "/opt/aws/bin" to your path, or use full path (/opt/aws/bin/ec2-metadata) to run the command.
You can find lots of such cli tool to access aws services in /opt/aws/bin/ . (My test was done in a Amazon Linux AMI).

Securing access to this service is important, as it allow anyone to get temporary credentials to AWS role assigned to EC2 instance. We have seen the name of this service appears in many security incidents happen in AWS infrastructure.

Possible mitigation on SSRF attacks on metadata service
Netflix security team has created a good solution, "a metadata proxy", to mitigate compromise of AWS credentials through metadata service by SSRF attacks. You can find the details here https://github.com/Netflix-Skunkworks/aws-metadata-proxy   Nice thing about this tool is, it is transparent to existing services and users who access AWS metadata URLs.

If you can direct the log output of the proxy to a CloudWatch group, Then you will be able to create alerts to detect malicious attempts on accessing metadata URL.

("ec2-metadata" command line tool calls the above URLs via curl.)

UPDATE (19-NOV-2019):
Finally AWS has added some changes to mitigate the abuse of metadata service by attackers. See https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/