DEV Community: Vitali

AWS 🔒 How to restrict access by IP

Vitali — Sun, 05 Jul 2020 22:09:38 +0000

Hi there!

In today's post, I would like to show you how you can restrict access to your AWS Account. Very often companies use static IP addresses to access the Internet. So if you know that access to your AWS account has to happen from specific IP, why allow it from the whole Internet.
Here is a logic schema of how we are going to make restriction:

⚠The most important part is an IAM policy that will enforce our restriction. The policy denies any user's actions made from untrusted IP. To make so, we have to create a condition and specify two keys:

aws:SourceIp
aws:ViaAWSService

By the first one, we allow access from our IPs, by the second one we allow AWS Services to access our resources without the restriction.
Your policy may look like it:

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*",
        "Condition": {
            "NotIpAddress": {
                "aws:SourceIp": [
                    "XXX.XXX.XXX.0/24",
                    "YYY.YYY.YYY.0/24"
                ]
            },
            "Bool": {"aws:ViaAWSService": "false"}
        }
    }
}

The good way to apply our restriction is to use IAM users' groups. IAM users groups usage is a good practice to handle permissions. But our approach will work with a single user as well. Depends on your case you may or may not use IAM groups.

So next, create a group, attach a policy with necessary accesses and with IP restriction.

Now even if API keys or a user's credentials will be compromised, an attacker has to avoid one more security mechanism in your AWS Account.
Bye!👋

Photo by Markus Spiske on Unsplash

Extra bullet against Phishing

Vitali — Tue, 14 Jan 2020 16:18:18 +0000

In this short article, I want to share with you a very simple script that may save the day.

Intro

It is not a secret that attackers prepare for the phishing attacks, especially for spear phishing. Spear phishing is a phishing attack specifically designed against an individual or business. Usually, the aim of an attack to make you act as an attacker wanted to (e.g. click a link, open an attachment, etc). To achieve it an attacker tries to imitate a legitimate activity as good as possible. For example, the common case is using a company's official email signature format or even a mail template from an internal company portal.

Also, I am sure you already know, attackers love to use domain names indistinguishable from the company's domain name. This is the thing we can use to be a step ahead. We have to generate the list of possible domains that an attacker may register for usage and periodically check DNS records of the domains from the list. Once we find a new domain, we have good chances to be prepared for an attack.

Function

I made a simple Lambda function that checks domains and sends a notification via SNS once a valid record was found (link). To simply deploy the function I also made a CloudFormation stack. You may use the link as Amazon S3 template URL.

https://s3.eu-central-1.amazonaws.com/securityblog.cloud/cf_files/template.yaml

After the stack is created, in function environment variables you have to specify the following:

SNS Topic ARN
Add domains to the list. You may use dnstwist to generate such a list.

$ dnstwist.py --format idle domain.name > out.txt

Other ways

I already mentioned dnstwist, it has much more functionality you may utilize for your needs.
Also, there is a web version of the tool - dnstwister.report. You may easily subscribe to new dnstwist findings.

Someday such a simple thing may save a lot of time in the future which you spend on an investigation.

Have a good day! ☀️

Photo by Sebastian Pena Lambarri on Unsplash

Log Management solutions in Clouds☁️(AWS Part1)

Vitali — Sun, 12 Jan 2020 19:31:08 +0000

Hey there!👋

As a Security Engineer, I work with logs all the time and there is no need to explain how important it is to have the right logs from the right system at the right time. The volume of logs is dramatically increasing each year. And we have to handle that volume, we have to collect/store/correlate/precess them.
Whatever who you are in IT, you work with logs and the more logs you have the more you want to store them in some fast, reliable, convenient solution. You know what would be better if your team cares only about applications and all server issues stay on cloud providers.
In the series of articles, I want to show you what main cloud providers may offer.

AWS

AWS Solutions Portfolio has Centralized Logging Solution. You can deploy it in your account in a few minutes. But you don't need to think about it as an only one way to have log management in AWS, think about it as one of the hundreds of ways how to combine together AWS services.
I want to show you the AWS services that you can use to create the best solution for you.

CloudWatch

CloudWatch is the main monitoring service in AWS. It has amazing functionality like log metrics, dashboards, advanced log searching, and many others. Also, it has a lot of integrations with other AWS services. You can stream logs directly from ec2 instances as well as from on-premises servers via CloudWatch agent. It is possible to export logs to S3/Elasticsearch services if you want to have a copy or long term storage.

pros:

Build-in functionality
Easy to get started to use
Serverless

cons:

Cost. You will literally pay for everything. As an example, just for sending logs to CloudWatch you will pay for Data Ingestion about $0.60 per GB. It actually stopped me to use CloudWatch as a main log management solution.

Amazon Elasticsearch Service

Many of us already know ElasticSearch and love it. But, what is the point to pay extra money to AWS when you can do the same on your own? Honestly, I love ElasticSearch in AWS even more. You don't need to be an expert in ElasticSearch to have full advantage of it. You are in charge only of the application level. Imagine, you've deployed your ElasticSearch cluster a couple of months ago and suddenly someone says that you will have more logs then you planned...😱

How long does it take to scale your cluster up or maybe after some time scale it down? In AWS it takes minutes and all that you have to do is a few clicks or API calls.

pros:

Solution that we already love
Сluster management and updates without headaches

cons:

You still need to manage indexes and define all application-level things like a number of shards and replicas. Also, you have to care about free storage space, but you already have a good friend for this - CloudWatch. A good practice is to create CloudWatch Alarm to follow the free space and make a notification or scale Elasticsearch Domain up if the free space goes below a certain threshold.

Amazon Kinesis

Amazon Kinesis is not one service, it is a family of four. All Kinesis services were built to help you out with streaming data. Kinesis services may become a very important part of your dataflow. I what to show you two of them that you may use for your own log management solution.
Kinesis data stream is a real-time data streaming service. You can put data into a stream via API using your own code, third-party products or Kinesis Agent. To get data from a stream you may use Kinesis Firehose, Lambda or other applications. The good thing about Kinesis Data Stream is you pay for Shard Hours. It means that you don't pay for data ingestion and together with a custom producer, it gives you amazing flexibility. You may aggregate short massages or compress before sending them to stream. Then a consumer processes your data on the fly, especially if you've chosen a lambda function as a consumer. I found a combination of Kinesis Data Stream and Lambda function as very powerful because they both are highly scalable, highly available and you keep everything as a code.

pros:

Predictable cost
Amazing flexibility
Serverless

cons:

Require software development skills and it takes more time to get started to use

Kinesis Data Firehose is the easy way to upload your streaming data to data lakes. Perhaps, AWS has implemented one of the common scenarios for us. You don't need to develop your own application if you want to store streaming data in one of the services that Kinesis Data Firehose supports(S3/Redshift/ElasticSearch/Splunk). The worth thing to mention that with Firehos you can transform source records before it stores to data lakes. It gives you the ability to pre-process data, but such a feature has its limits.

pros:

Easy to get started to use
Serverless

cons:

Solve a narrow, specific task.

In the next article, I will show other useful AWS services that you may use. Also, I will try to show examples of how you may combine services to solve some common scenarios.

Practice with AWS Access analyzer

Vitali — Sun, 29 Dec 2019 10:25:23 +0000

Hey there!

Have you ever asked yourself who has access to my AWS resources? or who outside of my account has access? Honestly, the second one most important, because nobody wants to be a subject of news about a new data breach :). AWS made a tool for us to figure it out. It is called IAM Access analyzer. You can find it in the IAM Service.

Short overview

In a few words, what it does, it evaluates your resource policies and finds all external principal that has access to resources in your account. It takes your account as the zone of trust and informs you about everything outside of the zone, but has access to the zone.
Other important things worth to mention:

Access analyzer is region-specific, so you have to enable it for each region, where you want to use it.
Access analyzer currently supports a limited list of resource types

Ok, enough for theory, time to practice.

Practice

You can find the Access analyzer in IAM. For creating a new Analyzer just press create and provide a name or use default one.

Once the scan is done, you may see all the findings. Yes, it is such simple. At first, you have to go through all findings and either archive or resolve them. Archiving means that access is intended, once you archive a finding it will not appear till resource policy will be changed again. The resolve status appears only after you fix unintended access and it obviously means that found access does not exist anymore.
After you are done, you probably would like to receive notification about new findings. You can do it via CloudWatch Events. Just create a new rule and define necessary action for new findings. I've used SNS topic to send an email once new findings appear.

If you want to white-list some resources or external principal you can use archive rules for it. Go to Archive rules click add and define a condition.

Access analyzer is fast to implement and simple to use tool that you definitely need to check out.

Links

Official Documentation