DEV Community: Liz Benton

Building a professional website with Splunk integration on AWS (Part 1)

Liz Benton — Sun, 02 Jul 2023 20:37:21 +0000

Goal: To set up a Dashboard in Splunk where I can monitor network activity and alerts regarding the security of my professional website hosted on AWS.

List of AWS services and how they will be used:

Visual Studio Code: HTML/CSS for website
AWS S3 buckets - where files and policies for the website will be stored and served, as well as CloudTrail logs for Splunk to pull from
AWS Route 53 - Used to handle Domain Name Service assignment (Domain name purchased originally on Cloudflare)
AWS CloudFront - Used to host the S3 hosted website, enabling HTTPS protocol with added benefits and authentication certificate for both www version and non-www version redirects for the web page
Splunk - installed on an AWS EC2 instance and configured to accept logs generated from AWS CloudTrail
AWS CloudTrail - Generate logs whenever an API call is made. Logs files will be in JSON format and configured to be sent to an S3 bucket for storing and analyzing via Splunk using add-on.

Before beginning any project, it's always nice to have a simple diagram or idea jotted down or drawn somewhere so that we have a good grasp of what we will need to achieve our goal.

Since I am admittedly still learning, I did not opt to use anything fancy here, and just built a simple architecture diagram over on the free web UI app, draw.io.

Isn't it pretty?

I explained a bit above how each of these services will be used, so I hope it makes sense! We'll dive into each individual part as well.

First, I needed to code my website! For this, I used Visual Studio Code, a free coding application provided by Microsoft. If you're looking for a solid program to build your next web application on, I highly recommend it.

Since I had only ever used HTML before and never CSS, this was quite the learning process and took me a few days and tons of googling. I even asked the help of chatGPT but by the end, I had taught myself divs and CSS to the point where I could build the last remaining parts all on my own, which felt like an amazing achievement all on its own!

Once my code was ready, I headed over to AWS, opened up the management console and opened up S3, where I would need to upload all my files.

Important note:
For added security, at this point in the project, I made sure not to use my root account and instead created an IAM user, added rules and permissions needed for the services I would be using, and added MFA to login. It's very important to add MFA since if anyone were to gain access to your account, they could abuse services and you may be surprised by a very high bill!

I would also encourage you to add a billing alert with a threshold of $5 or so, so that if any of your costs go above $5, you are sent an email or however you would like to be alerted. It takes little to no time to set up and could save you the pain of paying hundreds, if not thousands of dollars.

I'm assuming if you're wanting to build your own website, you'll already have a domain name purchased. In some cases, a domain can be transferred to Route53 for authentication, but in the event it cannot be transferred, you may need to purchase a new domain on Route53. Sadly, I had to go this route since the domain I had paid for on Cloudflare could not be transferred. It was only $13 to purchase a new domain on Route53, so not too bad, but something to keep in mind if you've already purchased a domain you want to use elsewhere.

Once that is sorted, we'll create the bucket that stores the files that will make-up our webpage.

Creating a bucket is really simple, first click on "create bucket". You'll be presented with a form to fill out:

Service Overview: S3 (Simple Storage Service)
S3 is really nice file storage service that costs little to nothing to store files and data. There are many ways to utilize it, depending on the size and/or types of files being stored, as well as the frequency the files need to be accessed. It's great for large databases and for files that only exist for auditing or law-abiding purposes, but can also be used for everyday, secure file storage, like some often use things like google drive for. Today, we'll be using it to host the files for our website using the static website hosting option in the settings for the bucket.

Be sure to set your bucket to PUBLIC so that people will be able to view the literal contents of your website. It will give you a bunch of scary messages warning you that it's public, but don't worry about it!

All other settings for your bucket can be customized if need-be, but I chose to keep them all default. For example, if you want to enable versioning, to be able to go back and retrieve older versions of files, that is an option available to you. Just know that often times when adding additional functionality to a service, the useage cost will increase. I'm not sure if versioning adds any additional cost and sadly, I did not look into it since I won't be using it, but if you're planning on using S3 for development purposes, it doesn't sound like a bad idea to have the option to access all added versions of a file.

Once your bucket is created, it will show up in a list. You can access the properties and other fun things about your bucket by clicking on its name.

Next we need to add a policy to our bucket, so once your bucket is created, go ahead and click on the bucket name > Permissions > where it says "Bucket Policy" you'll need to click "Edit" and add your own policy.

I'll add the one I used here for convenience, but essentially it allows the public to be able to read/view the contents of your bucket, which we need for people to be able to view our website once it goes live!

Bucket Policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::[YOURBUCKETNAMEHERE]/"
}
]
}

The above is known as a JSON format policy. Where it says "[YOURBUCKETNAMEHERE]" you'll enter your bucket name that's hosting your site files, just remove the brackets (but keep the "/*" so that it applies to all files inside the bucket)!

Save the new bucket policy and then return to the bucket overview at the top of the page. You should see a tab called "Properties" and at the very bottom of that tab, you should see a section where it says, "Static Website Hosting".

We will need to click on "Edit" here as well and enable the static website hosting.

Toggle the enable option and then add the index.html file for your website in the field that requests it. You don't need to worry about adding an error document or redirect.

After this, your files should be hosted live via the S3 bucket static hosting, so open up your favorite web browser and enter your domain.

Problem is, while the files are hosted, the domain tied to it is the S3 bucket's own, unalterable, directory. Obviously, we took the time to think of and purchase our own domain and we want that to be the way our visitors access our site, so in order to configure this addressing, we will need to use our next service, Route53!

Service Overview: Route53 (DNS or Domain Name management service)
Route53 is possibly named after the routing protocol, 53, used for DNS. Regardless, it makes assigning a valid certificate to your website a breeze! We'll also be using a service called Certificate Manager later to manage our TLS/SSL certificates that will verify that the website being displayed is our own and not someone else's. For now, we just need to prove that the domain we are planning on applying to our S3 bucket page as a new address of sorts, is owned by us!

You can get to Route53 by searching for it in the search bar at the top of the AWS management console. I would recommend opening a new tab for each service so that if you need to go back and forth to copy-paste, it makes life easier.

Once there, you'll need to register a domain. Just follow the process as it is a simple step-by-step to either transfer an existing domain (if applicable--it will let you know via search) or process to purchase a new domain.

Take the time to make your domain your own! Give it a name that is unique and not complex, something easily remembered, fits on a business card easily, and you can tell what its purpose is just by reading it.

"io" is often used by those in the developer industry, but can be a bit more expensive to purchase. There's nothing wrong with starting off as a commercial, ".com" so don't feel bad if you're not ready or prepared to make that investment on your first webpage.

Someday, when you've become a master of your class, you can even apply ".ninja"! I can only ever hope to achieve something so cool...but I'm working toward it!

Once your Domain has been created (this may take a few minutes) you are ready to create some DNS records in Route53!

Click on your domain and then click on "create record". The process is pretty straight-forward and at the end you'll have 2 recorded by default, SOA and NS. These are basic requirements when it comes to record management.

We'll need to add a new "A" type record for our S3 bucket domain, so be sure to go to your bucket and copy the ARN and add it to the new record.

Once your domain is all set up, open your favorite web browser and test it out! Does it work? If it does, then you've successfully hosted a website on AWS using S3 and Route53!

You may be noticing however, that the site is not secure and you may have even been warned about this when visiting it for the first time. Maybe you even needed to allow an exception. We obviously don't want that and want to keep ourselves and our visitors safe, so we will now go through the process of adding HTTPS instead of HTTP protocol to our domain via two services: Certificate Manager and AWS CloudFront.

Service Overview: AWS CloudFront
CloudFront is a global distribution service or content delivery network that utilizes Edge Locations within designated regions to make the performance of applications more expedient, while also increasing security through the use of HTTPS, rather than HTTP protocol for web traffic, which basically means that network traffic is encrypted and not easily read by prying eyes. This is crucial when handling usernames, passwords, and any other sensitive data. It also enables the use of a WAF, or Web Application Firewall. More on this in a moment.

Before we can have something as awesome as HTTPS for our application, we'll need to request certificates from the Certificate Manager. This can be found by searching for it at the top of the management console.

Once there, you'll click on "Request Certificate" and follow the instructions to create a "public" certificate, then you will be given the steps to apply the certificate with your Route53 configurations. The result desired at the end will be what is known as a "CNAME" or "Canonical Name" record that will help us route the domain we chose to the CloudFront distribution.

Once the certificate(s) have been created, we'll head on over to CloudFront and complete the configuration process.

Click on "Create CloudFront distribution" to begin. Now, there are a LOT of bubbles and boxes here, but don't let it intimidate you. You've come this far, you can't lose now!

I'll walk you through each section:

For this section, "Origin" it will try to auto-populate the domain based on the bucket you previously created, but DON'T USE THIS! Instead, manually type your FULL domain (www.example.com).

The rest of the fields should auto-populate after adding the domain. Unless you're expecting a lot of demand that taxes your website's availability, I wouldn't worry about enabling Origin Shield, so feel free to say no.

For this section, the only things we need to make sure we have selected are "HTTPS only" and "GET, HEAD" options. The rest can be set as default.

Leave the "Function Association" alone and enable a WAF if you'd like the added layer of protection (just keep in mind, it will result in additional costs..I pay around $8/month to maintain mine).

This section is very important. Price class can be chosen based on your own preferences, but having global edge locations accessible will increase cost, as it increases performance. Everything has a price, remember!

Next, we'll click on "Add item" to add the CNAME record we created earlier to the form. And immediately after that, we'll want to include the certificate we created using the Certificate Manager. It should be visible to you in the dropdown menu, so just click to add it.

For supported HTTP versions, either is fine, I just went with the default HTTP/2. Everything else was left on default.

Once everything looks good, click on "Create distribution" and wait for it to go live. You should be able to see the status on the far right when the page loads and you can check the most recent status by clicking on the little refresh button on the page.

Once the status is "Enabled" you are good to go! You should now be able to access your secure webpage. Give it a go! I hope you're feeling proud about what you've been able to accomplish. I know I did/do!

You did it! You made your very own website and hosted it, securely, on AWS! It's in the cloud now for everyone to enjoy, so be sure to share your accomplishment with all your friends and family!

If you'd like to see the site I built during this project, be sure to check it out over at Lizbuildsgames.com! And of course, I'd love to see any of your websites you've created, my dear readers!

Stay tuned for part 2 of this project where we'll be adding Splunk log integration using AWS CloudTrail, SNS (Simple Notification Service), as well as SQS (Simple Queue Service).

And of course, if you find yourself stuck or have any questions, comments or concerns, feel welcome to comment and I will respond as quickly as I can. (I am very busy, so apologies if you're left hanging for a bit--honestly, google is your best friend when developing anything imo--and it always feels amazing when you are able to troubleshoot things on your own!)

Until next time~! :)

Splunk: Building a Secure Monitoring Solution (Part 2)

Liz Benton — Thu, 08 Jun 2023 17:09:00 +0000

Welcome to part 2 of building a secure monitoring solution in Splunk!

In this part of the project, I'll be going over the analysis of the reports, alerts and dashboard visualizations before and after the addition of the attack logs.

I'll be using the following formatting to make things more efficient, since this is a lot to dive into:

Results before attack > Results after attack > Conclusion

Let's begin!

We'll start with our Windows Server and then move onto Apache.

-Windows Server Reports-

Severity Report Analysis

Results before attack:

Results after attack:

Conclusion:
Informational count from 11k to 4k, while high severity reports increased from 987 to 1k. Since the drop from informational server requests fell 7k by count, it could indicate that for some reason accounts that should be using the information are unable to, due to lockout or some other reason that should be investigated.

Success and Failure of Windows activities Report Analysis

Results before attack:

Results after attack:

Conclusion:
Successful events decreased from 13,848 to 5,854, while failures decreased from 426 to only 93. The difference seems most jarring for the successful events and may indicate abnormal activity on accounts.

-Windows Server Alerts-

-Alert for Failed Windows Activities-

Results before attack:

Results after attack:

Conclusion:
At 8AM there was a very large number of failed activities, totaling 35 for the hour.
Since the threshold we set was to create an alert for anything > 18, this alert would have picked up on this suspicious activity.
Whether or not this was a false-positive remains to be seen.

-Alert for successful logins-

Results before attack:

Results after attack:

Conclusion:
My Alert was also triggered for suspicious activities taking place at 2AM, 9AM and 10AM. Anything > 26 would trigger an alert, so the successful logins from user_a equaling 91 counts at 2AM would have definitely triggered. The others would have also triggered the alert--70 logins, 67 of which were by user_k at 9AM, followed by 54 logins at 10AM, 52 of which were by user_k.
This tells us that user_k may be compromised, and a security admin may need to step in to temporarily disable access to the account until they can isolate and remove any malicious entity.

-Alert for account deletions-

Results before attack:

Results after attack:

Conclusion:
A large number of accounts appear to have been deleted at the same times we previously saw a suspicious login activity from user_a and user_k.
We can see 45 events of account deletion at 2AM, with 42 of them originating from user_a. We also see 75 events at 9AM, 72 of which were by user_k, followed by 44 events, 43 of which were also by user_k at 10AM.

It would appear that action may need to be taken to temporarily cut off access from user_a and user_k to prevent any potential damage until the cause of this activity can be determined and eradicated.

-Dashboard Analysis-

Full-view before attack:

Full-view after attack:

Conclusion:
As our previous data showed via our alerts and reports, users user_a and user_k had the most hourly activity. The activities specifically outlined via signature monitoring being attempts to reset account passwords and locking out other users.

The hourly activity monitoring dashboards also paint an accurate depiction of the activity that was occurring during 2AM and 8AM.
We can see an attack taking place between 12AM and 2AM locking users out of their accounts. Based on what we already know, this was done by user_a, or someone compromising their account to lock out other users.

We can also see between 8AM and 10AM where user_a and user_k made a combined 761 attempts to reset account passwords.

This data tells us that a brute force attack may have taken place during the hours of 12AM and 2AM that resulted in users being locked out due to security concerns due to failed login attempts, which eventually led to successful login attempts once the passwords were successfully cracked by the attackers.

The password resets may be in response to the mass account lock outs, since all of the affected accounts would require password resets before they could be used again.

-Individual Dashboard panel comparisons-

-User Analysis-

Results before attack:

Results after attack:

Conclusion:
User_a and User_k dominated and may have been compromised.

-Source Domain-

Results before attack:

Results after attack:

Conclusion:
This chart confirms the activity by user_a and user_k during the hours summarized earlier.

-Windows Activities (based on signatures)-

Results before attack:

Results after attack:

Conclusion:
This chart change shows the activities conducted in response to the behaviors of user_a and user_k: user accounts being locked out and attempts made to change account passwords.

As you can see above, there is definitely some abnormal activity originating from user_a and user_k.

Now we will analyze our Apache server log data...

-Reports-

-HTTP Methods Report-

Results before attack:

Results after attack:

Conclusion:
GET requests fell from 30k to around 3k, which is a huge difference. POST requests did the opposite and increased from around 400 to well over 1000.

-Report Analysis for Referrer Domains-

Results before attack:

Results after attack:

Conclusion:
The numbers across all traffic decreased substantially, going from the high thousands to mere hundreds, which could indicate that systems are not working as intended or are being brought down/inaccessible.

-Report Analysis for HTTP Response Codes-

Results before attack:

Results after attack:

Conclusion:
Once again we see numbers falling drastically. This may be indicative of a Denial of Service attack, since these numbers are not within the normal expected range.

-Alerts-

-HTTP POST Alert-

Results before attack:

Results after attack:

Conclusion:
1,296 POST method requests came in at 9AM. Our alert was anything higher than 10, so this was definitely caught, though I do see other alerts with much lower numbers.
Considering the POST method requests outside of 9AM were in the single digits, I may increase from 10 to something a bit higher. I think anything greater than 100 within the span of 1 hour may be a better threshold.

-Dashboard Analysis-

-HTTP Methods per hour-

Results before attack:

Results after attack:

Conclusion:
A high number of POST requests seem to have occurred around 8PM, while GET requests fell tremendously. This maybe be indicative of an attack meaning to deny service but will need to correlate with other data points to confirm.

-Geolocation Cluster Map Analysis-

Results before attack:

Results after attack:

Conclusion:
We can clearly see a noticeable uptick in requests coming from Ukraine and Sweden, as well as within the US, with the majority coming in from the East Coast.

-Dashboard Analysis of URI data-

Results before attack:

Results after attack:

Conclusion:
Malicious actor may be running a script coded in java (php) to automate login attempts, possible indicating a brute force attack. We also see a large number of access to an archive, which may be an effort on someone’s part to exfiltrate log data or other important records.

-HTTP POST Requests-

Results before attack:

Results after attack:

Conclusion:
This POST method increase matches what we saw in our HTTP Method bar graph.

-HTTP GET Requests-

Results before attack:

Results after attack:

Conclusion:
The number of GET requests decreased, which may be indicative of an attack limiting access to resources. Will need to correlate with other data to confirm.

-User Agents Analysis-

Results before attack:

Results after attack:

Conclusion:
A dominant user agent arose as illustrated in our pie chart: Mozilla/4.0 –possibly using a downgraded browser version vulnerability.

If you made it to the end of this report, I appreciate you!

This was a lot of work, but I felt happy at what I was able to create and how I was able to give myself a glimpse of what a day-in-the-life of a SOC Analyst might be like. That said, I know I still have a lot to learn!

Stay tuned~!

Splunk: Building a Secure Monitoring Solution (Part 1)

Liz Benton — Thu, 08 Jun 2023 03:54:06 +0000

During the last several weeks of my Cybersecurity boot camp, one of our final projects was to build a secure monitoring environment for a fictitious organization called VSI (Virtual Space Industries) using Splunk Enterprise, which for those who may not know, is a SIEM (Security Information and Event Manager). SIEMs are essential tools that companies can use to detect, analyze, and respond to potential threats against their organization.

Since this was a big project with a lot of steps, I'll be breaking it up into 2 parts:

Part 1:
Creating Reports, Alerts, and Dashboards for Windows server log data as well as Apache webserver log data that can help point out any abnormal activity.

Part 2:
Checking to see if the solutions created in part 1 were effective against a fictitious attack by uploading the attack log data and seeing if our reports, alerts, and dashboards, picked up anything that would have helped the organization take the appropriate action as quickly as possible.

Part 1
I started by launching Splunk, which had been pre-installed in my ubuntu VM. I logged into the application and uploaded the files I would be using to create reports, alerts and Dashboards for.

Once the logs were uploaded, I briefly took notice of and analyzed the following fields:
o signature
o signature_id
o user
o status
o severity

Apologies that some images might be a bit small and difficult to read. Luckily, I also took some screenshots of the data inside each individual field as well:

signature:

signature_id:

user:

status:

severity:

These would be the main points of interest we will be using to create our reports, alerts, and dashboard. Let's start with the reports!

Report 1: A report with a table of signatures and their associated signature_id. This would allow VSI to view reports that show the ID number associated with each specific signature for a Windows activity.

Report 2: A report that displays severity levels and the count and percentage of each. This would allow VSI to quickly understand the severity levels of Windows logs being viewed.

Report 3: A report that provides a comparison between the success and failure of Windows activities. This would show VSI is there is any suspicious level of failed activities on their Windows server.

Now that those were done, it was time to move onto creating the Alerts!

Alerts would all trigger an email to be sent to the fictitious company at SOC@VSI-company.com

Alert 1: An alert that is triggered when a threshold for hourly failed Windows activities has been reached. This would help VSI see if any failed logins or any other activities occurred an excessive amount of times within an hour, which could be indicative of someone trying to do something they shouldn't be able to do, such as trying to login and failing repeatedly.

The threshold for this alert I chose was > 18 per hour.

Alert 2: An alert that is triggered when a threshold has been reached for the amount of successful logins per hour.

The threshold I chose for this alert was anything > 26 per hour.

Alert 3: An alert that is triggered when a threshold is met for the signature count when a user's account has been deleted, once again in an hourly window.

For this alert, I chose anything > 35 within one hour.

Now for the fun part, creating Dashboards to monitor Windows Server Activity at a quick glance!

I always have a lot of fun creating dashboards in Splunk, this project being no exception. I made:

A line chart that displays account deletion signatures over time within the span of 1h.
A line char that displays the different user field values over time.
A pie chart of the different signatures based on windows activities.
Another pie chart showing the different users who are active.
A final pie chart that tracks the source domain.

Line charts 1 & 2:

Pie Charts:

Full-view Windows Server Monitoring Dashboard:

Next, we needed to repeat this process, but for the Apache log data. I went ahead and uploaded the log files and got to work on the reports first.

This time, the important fields we wanted to pay special attention to were:
o method
o referrer_domain
o status
o clientip
o useragent

Report 1: A report that shows a table of the different HTTP Methods (GET, POST, HEAD, etc.). This would show VSI the types of HTTP requests being made to the VSI webserver.

Report 2: A report that displays the top 10 domains that refer to VSI's website, to help VSI identify any suspicious referrers.

Note: I found it kind of funny that 'referer' was spelled incorrectly (should be 'referrer' in the fields list), but knew it had to match the data, so spelled it incorrectly to match when I had to.

Report 3: A report that shows the count of each HTTP response code. This will help VSI to quickly gauge the overall health of their webserver and activities taking place on it.

With that, it was time to create some Alerts!

Alert 1: The project called for an alert that triggers whenever a connection is made from any IP address outside of the United States. I chose France for this example, which had an IP Address of 176.31.39.30 (Roubaix, France).

Alert 2: An alert that triggers whenever a threshold was met for the count of HTTP POST methods within the span of 1 Hour.

The threshold I chose for HTTP POST requests was anything > 10 within 1 hour.

And now back to the fun of creating visuals for our Dashboard!

HTTP GET Method requests per hour:

HTTP POST Method requests per hour:

HTTP Methods by type per hour:

Top Countries connecting to the server:

Top User agents:

Top URI:

Full-view Apache Server Monitoring Dashboard:

So there you have it! I created Reports, Alerts, and Monitoring Dashboards for VSI's Windows and Apache servers.

In Part 2 we will see whether or not the solutions I made protected VSI.

Part 2: https://dev.to/r33keeper/splunk-building-a-secure-monitoring-solution-part-2-208m

Project: AWS containerized webserver management using Docker and Ansible

Liz Benton — Wed, 07 Jun 2023 00:32:35 +0000

Goal:
To run an Ansible Playbook on top of a Bastion Host Server to configure two EC2 instances into webservers on AWS. We want to use our host machine’s IP for the bastion host, and we want to make sure everything is connected securely over SSH. We will also secure our setup through the use of firewalls AKA security group policies.

Terminology to be familiar with for this project:

What is a Bastion Host?
Also known as a ‘jump box’, a bastion host is a dedicated server that lets authorized users access a private network from an external network, such as the internet. Because of its exposure to potential attack, a bastion host must minimize the chances of penetration.

What is Ansible?
Ansible is a tool used to provision the underlying infrastructure of an environment, virtualized hosts and hypervisors, network devices, and bare metal servers.

What is an Ansible Playbook?
Ansible playbooks are used as a way to repeat, re-usable, simple configurations and multi-machine deployment systems. It is well suited to deploying complex applications. If you need to execute a task more than once, write a playbook and put it under source control.

What is Docker & Docker Hub?
Docker is the world’s largest repository of container images.
Docker Hub is a container image library where you can create an account and access the repository.

You can also be cool and create your own libraries and upload them to add to the repository for other people to use!

NOTE:
Before building any project, you want to plan out and understand what it is you’re trying to do and not only how to make it happen, but how to do it right. Security is job zero and it starts from the beginning of a project.

How do we fulfill our goal?

Create our Bastion Host Server using AWS EC2 instance creation
Connect our Host Machine to the Bastion Host Server using Gitbash and allow the Bastion Host to use our Host machine’s IP Address
We will have a private key made for us and saved to our Host machine when we create our first instance on EC2. We will need to share the private key access with our Bastion Host in order to communicate. The CSP takes care of handling our public key for the pair.
We will need to install Docker on our Bastion Host so that we can obtain a specific Ansible container from the repository as well as accessing our playbook.
Once Docker is installed and we have installed our Ansible ISO image file, we need to share our private key with our Ansible container so that it can securely communicate with our two EC2 instances/VMs and configure them into webservers.
We need to establish connection from our Ansible container to our two VMs and once that is done via ping, then we can run our Ansible Playbook to do whatever we need it to do (in this case, just to install a couple applications and convert our two instances into webservers).

Now that we have a pretty clear idea about what we want to accomplish, it's always helpful to create a nice little diagram for visual reference. I used draw.io since I'm a noob, but you can use whatever you're familiar with.

We start by launching our Bastion Host using Amazon EC2, which is as easy as searching for 'EC2' from the management console and clicking 'Launch Instance'. During the process I also set up our first firewall/security group rule of allowing only my IP to be able to SSH into the instance over port 22 and create a new key pair for security.

Once that's done, we add two more rules to the same security group:
1 allowing HTTP traffic over port 80 from anywhere (IPv4)
and another allowing All ICMP IPv4 traffic from anywhere

Now that our Bastion Host Server has been created and our security group is configured appropriately, we will click 'connect' to open up a page with connection options. We'll be using SSH, so we copy our SSH address info from the instance SSH tab and open Gitbash to connect to it from our Host Machine.

CMD: ssh -i “[key-name.pem” ec2-user@[copied instance ID from SSH tab]

Pretty bird~

Note: Make sure you are in the directory where your private key is stored on your host machine so that it can be accessed to establish the connection.

Next, we’ll open a new terminal so that we maintain connection with our Bastion Host in one window and use our Host machine in the other.

On our Host machine, we’ll use ‘secure copy’ to copy our private key over to our Bastion Host server. While doing so, we will also create a directory for the key to exist inside its new location.

CMD: scp -i “key-name.pem” key-name.pem ec2-user@[copied instance ID]:/home/ec2-user

Note: Be sure not to forget the new directory at the end of the command. You may name the directories however you'd like. This is just what I used.

If this worked, when we go back to our connected Bastion Host window, we should see the key when we use ‘ls’ to search the directory.

Before we close our Host terminal, let's check our IP address using ipconfig command and make a note of it. It should match our Private IPv4 Address on the instance home page.

Returning to our Bastion Host, we will now install Docker and start it on our machine!

Commands to update VM and install Docker package:
CMD: sudo yum update
CMD: sudo yum install docker -y

Once complete, we can start Docker:
CMD: sudo service docker start

Now that docker is installed and started, we can check the networks on it:

CMD: sudo docker network ls

Since we want Ansible to run inside of our host network and we want our Bastion Host to be running off of the same IP address as our machine we’re hosting the instance on, we should check the addresses associated with it as well.

Once the networks match, it's time to pull our Ansible container from docker.

CMD: sudo docker run -it --network host cyberxsecurity/ansible /bin/bash

To break this command down, ‘docker run’ means to create the ansible container using the docker image we define later in the command (cybersecurity/ansible), connect to or initialize it (it), place it within this specified network (--network host), and run it for me (run).

We’re downloading the provided ISO image file for our Ansible container that someone else created in Docker as a container and running it—in this case ‘cyberxsecurity/ansible’. –network host tells it which network we want to add Ansible under and ‘bin/bash’ tells it what programming language we want to use to communicate with Ansible when we want to run configuration commands on our machines.

Once the image is added on top of our Bastion Host within our designated network, we should automatically see that our username has changed to the root of the Ansible container.

It should also be followed by the network address we provided. Let’s check and see if they match!

CMD: ifconfig

In the terminal, the root should show the IP of your host machine. If it doesn't, you'll have to re-do the previous steps.

Now that our Host machine and our Bastion Host machine are (hopefully) on the same network along with our Ansible container, if we were to add additional servers, they should all be able to communicate with each other over SSH using our security group firewall settings, right? At least, that's the idea!

Before that can happen though, we need to copy our private key into our newly added Ansible container, so that it can communicate with our servers.

Keeping our Ansible window open and connected, if we open up a new terminal via command prompt and type in the command to copy our private key and then using another specific command, we can check the containerID for our new Ansible container that we added on top of our Bastion Host inside of our network.

First, we'll open a new gitbash terminal to connect once again using SSH to our Bastion Host.

We will then use a command to check our Container ID:
CMD: sudo docker ps

Now we need to use a command to copy our key into our Ansible container (using the ID above). We will also define the path it gets copied to.

CMD: sudo docker cp key-name.pem [container ID goes here]:/root/key-name.pem

To check if the key made it to our container, we can return to our terminal window running Ansible and use ‘ls’.

Now the fun part! Let’s create our two servers that we'll be configuring using our Ansible playbook!

The two servers will be the same as our Bastion Host, with the same private key pair and security group, just different names.

Note:
If you want to save time, create a new instance and then while you're in the window viewing your instances, check the box for the one you just created, click on the 'Actions' Dropdown, then click 'Image and Templates' then click 'Launch More Like this'. Just remember to change the name of the instance and ensure it has the same key pair and security group, then create!

You should have something like this:

Now that we have our new servers, we need to test their connectivity within our network and if our Ansible container can communicate with them.

We’ll start with testing out our first server, aptly named, ‘Server1’.

We’ll do this by copying the private IPv4 address from the instances page after checking the box for our instance.

Then we will return to our Ansible machine and from root, we will ping our machine!

CMD: ping [IPv4 address of 1st machine]

You should know right away if it worked or not.

Now we just need to SSH from our Ansible root to 'Server1'.

CMD: ssh -i key-name.pem ec2-user@[IPv4 private server address]

Huh, it isn't connecting, is it? Any idea why that might be?

If you guessed it had something to do with our security group aka firewall configurations, then you’d be correct!

Let’s fix that!

As of now, our inbound rules say that anything trying to connect with our network via SSH outside of our own IP address will be denied.

We need to add a new inbound rule that allows traffic traveling through SSH from our Ansible container. For that, we will need to find out the IP address tied to Ansible. We can see the IP right after the root, so just copy that. We'll also add '/32' to the end of it to make sure we have enough ground to cover.

Now we can try again!

CMD: ssh -i key-name.pem ec2-user@[IPv4 private Server1 address]

Success!

Repeat this process until you are able to SSH into all servers you wish to connect.

Everything Ansible does is through SSH, so the procedure of connecting to each individual server using SSH cannot be skipped. As demonstrated, just because you can ping something, doesn’t mean it is going to be able to communicate across the network.

We were able to SSH successfully into our two instances! So now we can use ansible to configure our servers into webservers for hosting whatever we want!

Let’s return to our Bastion Host and Ansible machine terminals.

In the Ansible terminal, we’ll look at two important files that we need to configure. Remember to back out of the Server using the 'exit' command to get back to ansible root before using the following command.

CMD: ls /etc/ansible

You should see a hosts file. We need to edit this file...

CMD: nano /etc/ansible/hosts

Let’s locate the header ‘[webservers]’, remove the hashtag so that it isn’t ignored, and paste the two Private IPv4 addresses from our servers on their own lines below the header.

Adding these addresses tells Ansible which machines will receive the configurations we add to Ansible’s configuration file.

It should end up looking like this:

Remember to save the changes made to the hosts and configuration files! You can do so multiple ways, but I like to use CTRL+X (exit), Y (yes) and then Enter.

Next, we’ll try a special ping command unique to ansible to make sure our settings are correct:

CMD: ansible -m ping all --key-name.pem

You should get an error, because we haven’t edited the configuration file. Let’s do that now.

CMD: nano /etc/ansible/ansible.cfg

We are going to locate ‘remote user’ and change it from ‘root’ to our AWS username, ‘ec2-user’

Before:

After:

Save and exit.

Try to run the command again. If successful, you should now be able to create a Playbook and run it on your connected machines!

Note:
It’s important to know that the commands associated with playbooks change depending on the Operating System and the configurations you want to perform. Keep this in mind whenever working with Ansible Playbooks on different operating systems and cloud environments!

Let’s use our playbook command to run our code that will convert our two instances into webservers!

First, we’ll create a file called webservers.yml in the /etc/ansible directory:
CMD: nano /etc/ansible/webservers.yml

The following will be copied and pasted into our new yml file:

This is all we need to do here, so we can save the file, and now we are ready to convert our servers!

Before that, let’s check and see the results of what we have done so far!

Go ahead and copy-paste the PUBLIC IP addresses for each of your servers into your web browser to check and see if they are Apache webservers.

They aren’t, right? But they are about to be with a single command that runs our playbook!

CMD: ansible-playbook /etc/ansible/webservers.yml --key-name.pem -u ec2-user

Congratulations! You have just used Ansible to configure two EC2 instance servers into webservers to host a website or other fun stuff on AWS! Do with it what you will! Or delete all your resources and do it all over again for practice!

NOTE: If you don't plan on using them right away, I would suggest deleting your resources so that you do not incur an unwanted bill. :)

Cloud Resume Challenge - Parts 2 & 3: Building the Front End (HTML/CSS)

Liz Benton — Thu, 27 Apr 2023 23:29:56 +0000

I'm probably spending way too much time on this part of the challenge, but I see this website as an extension of myself, so I felt very strongly that it needed to come from me. I could have easily gone and purchased someone else's website code layout as a base and gotten this step over and done with and on to the actual challenge (the back end), but I wanted to see if I could build my resume site with my own two hands!

I had ChatGPT to help too, of course, so I confidently dove into the 2nd part of this challenge.

First, I carefully wrote out what I envisioned on a notepad and gave ChatGPT step-by-step instructions that were as clear and as literal as I could make them. I've studied a bit of HTML and CSS on Mimo before and written a bit of code back in middle school on Neopets, so I could at least speak the language, even if I hadn't attempted building my own webpage before.

After a bit of back and forth with Chat, I had something that looked a bit like what I wanted, but needed some major tweaking. For one, my navigation bar was obstructing the rest of the page's contents and not everything was lining up the same way or with the same text stylings, since each section had been executed in different batches instead of from one cohesive standpoint. No longer in love with my initial concept, I ended up completely scrapping the first attempt and starting over completely. By the end of our secondary back-and-forth, I once again encountered navigation bar, text, sizing and section alignment issues.

After hours of studying my code, getting frustrated, going out to dinner, coming back with a fresh mind and learning about padding, margins and divs, things finally started clicking. The feeling I got when I figured out the solution and saw everything was positioned exactly how I had imagined was beyond happiness. I couldn't help but smile and bask in what I had been able to create from nothing!

It took one failed iteration and more time than I wanted, but the results were worth every second! I'm excited to create something like this again someday and already have some ideas, but that needs to be put on the backburner for now.

I spent at least 3 ~ 4 days working on these steps, on and off. On the 3rd day, I was so close to calling for help, for reaching out to one of my web developer friends for an easy way out, but I didn't! I wanted to prove to myself that I could figure it out and I did!

It's also amazing to me how such small changes can impact the entire structure in such large ways. There were many times where I would erase something to test its impact, only to find multiple sections were now broken. At the end of this project, I saw it all like a delicate house of cards. It took me a while, but this one was built to endure, just like its creator.

The most satisfying moment of all for me was when I realized what I liked on the page and started erasing and writing HTML and CSS to get the same results for each section using div tags WITHOUT needing to consult ChatGPT! I was ACTUALLY coding my own site! :D That was the greatest reward.

This is only the beginning of this project, but I'm already so proud of myself!

Now let's see what else I can do~

Cloud Resume Challenge - Part 1: Earning my AWS Cloud Practitioner Certification

Liz Benton — Thu, 27 Apr 2023 22:57:53 +0000

Back around October of 2022, I did something that I could never have seen myself doing, which was to sign up for the UCI Continuing Education Division's Cybersecurity Boot Camp.

Before the class began I did a lot of research in the different areas of Cybersecurity and learned a lot of new terminology, like "pentesting" and "white hat".

Seeing some sources siting the need for coding in some of the roles and not wanting to be intimidated by this, I started studying python on the Mimo app and got my entry-level PCEP certificate in November.

Wanting to have a good idea of what I was getting myself into, I reached out to some friends who were already in the industry, who strongly urged me to focus on Cloud.

While doing more research, I came across the Cloud Resume Challenge by Forrest Brazeal, and it peaked my interest. Though I completely forgot about it once my course began, I did make a mental note that the first step was to obtain the AWS CCP.

In December, I studied as much as I could for about 2 months between my course work and my full-time job using the extremely fun and helpful AWS Skill Builder Cloud Practitioner Essentials Course and was able to secure the CCP last month on March 16th!

I remember being incredibly nervous, but confident on the day of the exam and was smiling ear-to-ear when I walked back to my car, victorious.

(If you ever need a confidence boost, I highly recommend passing a certification exam!)

I'm currently studying for my Security+ exam now and look forward to graduating in June!

After doing more research, specifically into Cloud roles, I followed a little activity I found on youtube by a channel called, "Open Up The Cloud" and started feeling more and more that Cloud Engineering with a strong Cybersecurity foundation was the path for me.

Highly recommend the video (and the channel in general) if you too are struggling with choosing a role in Cloud. It really helped me wrap my head around things and gave me some much-needed insight and perspective: https://youtu.be/E0haz6mymxY

While looking through my saved bookmarks a couple weeks ago, I once again stumbled upon the Cloud Resume Project and decided to try and complete it before graduation.

After all, I have the first step done, and how cool would it be to have my own little happy home on the internet where I can display all the things I've learned and all the certificates I've earned at the end of the program?!

The steps for the challenge are as follows (AWS Version):

~~Earn the AWS Cloud Practitioner Certification and add it to the website.~~
Write your resume in HTML.
Add CSS to add styling to your web-page.
Add the resources of the website to an S3 bucket on AWS and deploy it as a static website.
Utilize Amazon CloudFront to ensure you are using HTTPS instead of HTTP so that data is transferred securely between the webserver and the user's browser.
Obtain a domain from any provider and use Amazon Route 53 to set up the DNS registry.
Use Javascript to add a visitor counter to your website.
In order for the visitor counter to function, we will be using a database. I have chosen to use DynamoDB.
Using AWS API Gateway and Lambda, we will communicate with DynamoDB using an API that accepts requests from the web app and communicates them to the database.
Our Lambda function will require either more Javascript or Python, but honestly I would rather do this entire thing in Python, so I will use Python and its boto3 library in AWS.
Write some good Python tests...guess I will learn what that means! lol
Learning Infrastructure as Code--the challenge asks that we do not configure our API resources (DynamoDB, API Gateway, and the Lambda function) manually in our AWS Management Console. Instead we will define them in AWS SAM (Serverless Application Model) and deploy them using the CLI (Command-Line Interface).
Creating a GitHub Repo for our backend code.
Setting up Github Actions in order to start working with CI/CD (Continuous Integration and Deployment) for the back end of the project. It should work to where when you push updates to SAM or in Python, the Python tests get run. If the tests pass, SAM should get the packages from the repo and deploy to AWS.
Creating a second GitHub Repo for the front end code so that when new code gets pushed, the S3 bucket's front end contents get updated. *There's a note in this step: "You may need to invalidate your AWS CloudFront cache in the code. And DO NOT commit AWS credentials to source control. Bad hats will find them and use them against you!"
Blog Post--the step mentions to wait until the end to write a short blog post describing what you learned while working on the project. But I want to write about my experience, frustrations, obstacles, etc. for each major step in the challenge and then wrap up with a summary blog post.

Anyway...

Challenge Accepted! Let's do this! >:)

If you would also like to take the challenge, it can be found here: https://cloudresumechallenge.dev/docs/the-challenge/

My Hack The Box Cyber Apocalypse 2023 CTF Experience

Liz Benton — Tue, 25 Apr 2023 18:23:57 +0000

Hello, World!

Between March 18th ~ March 23rd 2023, I formed a team composed of myself and a few of my classmates to participate in the HTB Cyber Apocalypse 2023 Capture the Flag competition—our first ever CTF, in fact(aside from one member)!

Together, we formed “DR34M_CH@$ERS”!

Our motto:
“All our dreams can come true if we have the courage to pursue them.” – Walt Disney

As Team Captain, I was up bright and early at 6AM PST and was able to secure our first flag! Which honestly wasn’t too challenging, since you just needed to join the HackTheBox discord channel.

It wasn’t exactly a requirement, per se, but it did add points to the grand total, so that has to count for something, right?

I then skipped over the beginner challenges and got a bit more adventurous by diving right into the first Hardware challenge. It took me a couple hours to figure out what was being asked of me, and even a support ticket to ensure that things were working as intended, (read up on that funny story in my Critical Flight Walkthrough) but before I knew it, I had found a 2nd flag for us!

After that, I helped one of my teammates in the ‘Pwn’ category solve the ‘Questionnaire’ and then went on to solve ‘Getting Started’.

Feeling comfortable in the ‘Web’ category, I solved ‘Trapped Source’ with little difficulty for my 5th and final flag of this competition--half the total amount we obtained by the end.

I spent most of my time trying to solve the Web challenge, “Passman” and the Blockchain challenge, “Navigating the Unknown”. In the end, I was unable to break through and complete those challenges, but I still plan on reading up on them so that I have the knowledge needed to conquer them next time!

Closing thoughts:
This competition was really fun, but more than anything, it really gave me a much wider perspective of how little I know about the world of Cybersecurity and technology. I expected mostly hacking challenges, but ‘pwn’ was only a single category! Sure, you used Linux and VMs with hacking tools for a lot of the challenges, but a lot of them involved just knowing different programming languages, or areas of study. They had a Hardware category, and even one for Machine Learning!

I think it’s fantastic that there was such a broad range of knowledge to dive into and get more familiar with. I enjoy learning in general, so this was very enjoyable, even if I felt a bit lost for the most part and unsure of what to do next.

That eagerness to know the ‘how’ and ‘why’ drives me ever onward in my pursuit of knowledge!

Final Stats:
Total Players: 12,543
Total Teams: 6,482
Our Team: 8/20

Team Ranking | Solved Challenges | Total Points
2,070 / 6,483 | 10/74 | 2,725 / 23,125

Overall, I am SO proud of our team and of myself! Not too bad for our very first Capture the Flag!

I also quite enjoyed being Team Captain, making sure my team stayed confident, well-rested, and hydrated throughout the competition.

My Collection of Captured Flags:
HTB{l3t_th3_tr3asur3_hunt1ng_b3g1n!}
HTB{533_7h3_1nn32_w02k1n95_0f_313c720n1c5#$@}
HTB{th30ry_bef0r3_4cti0n}
HTB{b0f_s33m5_3z_r1ght?}
HTB{V13w_50urc3_c4n_b3_u53ful!!!}

I know the above is just text, but they all mean so much to me. Like little mini, serotonin-infused, digital trophies that I can look at whenever I feel like I can’t do something. Haha! Proof that with a little grit and persistence, you can get to the bottom of anything! :)