When you give access to developers to create firewall rules, they generally open all sorts of ports to the internet. All they need to do / expected to do is get the product working. The rest doesn’t matter. This was the same with the company I worked with. There were tonnes of firewall rules in the GCP projects which opened many ports to the public internet. One could think of deleting firewall rules straight away and check if something is breaking on production.

If your company uses AWS Route53 to manage DNS records of its domains, there might a situation where you want to find which IAM user created / modified which DNS record. The reason for this could be anything: asset management, to find root cause of a security incident (like subdomain takeover) or simply to cleanup unused DNS records. This could be done with ease if you have CloudTrail logging enabled (atleast for us-east-1 region) and stored on an S3 bucket.

Starting Vault serverMost documentations give an example of using Hashicorp Consul / AWS S3 / GCS storage as the backend of Vault server. But vault server could also run with local file system as its backend. Config used to start the server : config.hcl 1 2 3 4 5 6 7 8 9 10 storage "file" { path = "/mnt/vault/data" } listener "tcp" { address = "192.168.0.101:8200" tls_disable = "true" } disable_mlock = true Make sure that the path /mnt/vault/ is owned / accessible by the Linux user which is used to host Vault server.

You don’t know what you got until it’s gone. And unfortunately it’s the same with data. The importance of backup is mostly realised after loosing the data. After a few data incidents, I have made backups of all my ElasticSearch clusters. I have also made it a habit to create backups and then go ahead with using ES cluster to store data. In this article I will be using Google Cloud Storage (GCS) buckets for backup.

Wait. I know what you are thinking now. Who on earth would do such a crazy thing ? Why would a person even host a DNS server on AWS when one could use Route53 to efficiently manage DNS records. The answer is simple: I’ve been a user of DNS since my first interaction with the internet, but have no clear idea on how DNS works. So I started learning how DNS works and more on how DNS server works.

Setting up a pentest environment for a single Android application to test its functionalities is simple. The process involves just setting up an Android emulator, installing the app, sending the traffic through a proxy tool like BurpSuite and playing with the traffic to find interesting behaviour. When it comes to setting up pentest environment for an Android chat application, the setup slightly differs. This is not the case only for chat apps but also for other apps whose functionality (like multi-user authorization) could be completely understood only when running the app in two or more devices simultaneously.