Spring

2016

AWS Network Security

Audit & Attack
Geography
Amanda Weldon
It 263-601: Networks and Security
June 7, 2016

Introduction: AWS Configuration

During our ten weeks in IT 263, we each configured a VPC network and created an EC2 instance through
Amazon Web Services. This allowed us to set up a virtual server (EC2) on a virtual network (VPC), and test
different security configurations for it. The diagram below shows the main components of my VPC.

10.0.0.157
52.53.209.41 (EIP)
Igw-65b90300

This is a Scenario 1 Type network, which includes a VPC of size /16 (CIDR: 10.0.0.016) with a single
public subnet of size /24 (10.0.0/24). The Internet gateway (igw-65b90300) enables connection of the
VPC to the Internet. The EC2 instance I created has a private IP address of 10.0.0.157, a public IP
address of 52.52.209.41, and an Elastic IP address of 52.8.158.3. Creating this network naturally brings
security issues along with it, which is why I have set up security groups and Access Control Lists (ACLs) to
act as firewalls at the instance and subnet levels. I will discuss the potential problems caused by the
configuration of these firewalls, audit the instance to see identify actual security issues, and propose
solutions to the problems identified.

Security Groups and ACLs

Below is the security group I assigned to my instance. Security groups act as a firewall at an instance level.
The two screenshots show the inbound and outbound rules I currently have set to control traffic to the
instance.

Security Group Rules:

The inbound security rules indicate that inbound packets from the following protocol types are allowed from
anywhere (Source: 0.0.0.0/0)

HTTP (web servers)

HTTPS (web servers)
RDP (remote desktop)
ICMP (error/control messaging)

The outbound security rules indicate that outbound TCP and ICMP packets are also allowed access to
anywhere (Destination: 0.0.0.0/0) HTTP, HTTPS, and RDP are all TCP protocols.

Because the security group only controls traffic at the instance level, I created an additional layer of security
through the network Access Control List (ACL) to act as a firewall at the subnet level as well. However, I
currently am allowing all traffic access from all ports, which may eventually pose a threat. Below are the
current inbound and outbound rules for my network ACL:

Network ACL Rules:

Potential Security Issues in Configuration:

Allowing all inbound/outbound traffic from certain protocols may leave the instance open to security
issues. Allowing HTTP and RDP access from anywhere can leave the instance vulnerable to untrusted IP
addresses, which may allow attackers to be able to steal data and plant malware. I will discuss how to
prevent these issues further in the audit.

Instance Audit
This audit will determine if there are any issues in the security configuration for this instance, specifically
for the HTTP/RDP protocols. Through flow logs, daily web server log files, and a security events log, we will
be able to identify the problems and determine the sources and type of attacks.

Flow Logs
Flow logs can be used to find out what communication was rejected by the firewalls I created for this
instance. By creating pivot tables from the flow logs, we are able to sort the data into meaningful
information. For example, the table on the left shows the ports that were trying to be accessed, along with
how many times they were accepted or rejected. 10.0.0.157 is the private IP address for my instance,
explaining the high number of accepted attempts. The table on the right is filtered to show which IPs were
rejected access, meaning the firewalls set up for the instance are working to reject certain ports. The
columns labeled 6 and 17 represent the protocol used, 6 being TCP and 17 being UDP. After running the
IP addresses through IPNetInfo, we are able to analyze where these rejected IP addresses are located.

Flow Log Summaries:

Result
Sum of T
Row Labels
10.0.0.157
109.197.75.229
111.59.182.152
123.249.76.107
134.196.111.188
169.228.66.91
177.43.157.154
180.97.239.31
184.105.139.122
185.56.80.136
185.93.185.250
199.115.117.99
207.244.76.204
208.100.26.228
216.218.206.120
216.218.206.123
217.77.221.85
221.9.251.229

(All)
Result

REJECT

Sum of T

Column
Labels

Column Labels
6
46
4
2
2
2
2
2
2

17
4

2
4
14
2
2
4
2
4
2
2

Grand Total
50
4
2
2
2
2
2
2
2
4
14
2
2
4
2
4
2
2

Row Labels
10.0.0.157
109.197.75.229
111.59.182.152
123.249.76.107
134.196.111.188
169.228.66.91
177.43.157.154
180.97.239.31
184.105.139.122
199.115.117.99
207.244.76.204
208.100.26.228
216.218.206.123
217.77.221.85
221.9.251.229
40.114.10.102
60.190.136.138

17
4

4
2
2
2
2
2
2
2
2
2
4
4
2
2
6
2

Grand
Total
4
4
2
2
2
2
2
2
2
2
2
4
4
2
2
6
2

40.114.10.102
60.190.136.138
64.16.209.177
66.240.236.119
74.82.47.5
74.82.47.58
80.11.81.65
80.55.124.29
88.249.201.228
91.197.232.85
91.214.114.97
93.174.93.94
94.226.175.219
Grand Total

6
2
4
2
2
2
4
8
2
4
16
6
4
154

12

6
2
4
2
2
2
4
8
2
4
16
6
4
168

66.240.236.119
74.82.47.5
74.82.47.58
80.11.81.65
88.249.201.228
93.174.93.94
94.226.175.219
Grand Total

2
2
2
4
2
6
4
56

12

Rejected IP Geography:
Country
Belgium
Brazil
China
France
Russian Federation

Seychelles
Thailand
Turkey
Ukraine
USA - California
USA - Illinois
USA - Virginia
USA - Washington
Grand Total

Count of IP Address

1
1
5
1
1
1
1
1
1
6
1
2
1
23

As the table shows, the majority of rejected IPs are coming from China (5) and California (6). It is
important to note that every IP address requesting UDP access was denied, because the security rules
dont allow UDP access. Still, there are plenty of IP addresses being accepted, many of which may pose a
threat to the system.

2
2
2
4
2
6
4
68

Daily Web Server Log Files

Web server log files are another way to see packet activity from IPs trying to access the network. This
table summarizes my instances log files from May 30th, 2016 June 5th, 2016. The column labels 200,
403, 404, and 500 correspond to the sc-status and the numbers under them correspond to the amount
of times this message occurred from each source address. The sc-status labels mean the following: 200client request has succeeded. 403- client request forbidden. 404-client request not found. 500- internal
server error.

Log File Summary:

Row Labels
101.251.229.133
104.223.253.135
104.223.253.136
104.223.253.137
104.223.253.138
104.223.253.141
123.59.59.52
131.162.130.180
141.212.122.145
151.80.242.201
169.54.233.123
169.54.244.84
172.245.10.116
173.208.197.252
176.62.189.215
177.224.224.90
180.97.106.37
182.118.60.49
183.129.148.86
184.105.139.70
184.105.247.195
184.105.247.196
185.103.109.225
185.25.148.240
185.25.151.159
185.49.14.190
188.42.255.244
192.169.191.19
193.109.69.2
195.2.252.223
195.2.252.67

Column Labels
200

Count of s-ip
403
2
1091
794
757
641
549
1
1
1
3104
1
1
1
1
2
2
1
1
1

404

500

2
2
2
1
2
3
3
1
3490
1
18
1

1
1

Grand Total
2
1091
794
757
641
549
1
1
1
3104
1
1
1
1
2
2
1
1
1
2
2
2
1
3
4
3
1
3490
1
18
1

195.62.52.15
195.62.52.177
195.62.52.182
195.88.208.135
195.88.208.232
199.115.117.99
202.116.234.16
207.244.76.204
209.58.178.165
210.56.212.18
212.83.179.44
213.128.81.66
216.218.206.67
218.2.22.121
222.174.5.37
222.187.222.35
23.94.234.50
5.189.160.89
5.189.183.210
58.221.46.206
62.138.1.137
62.75.160.140
64.16.209.177
74.82.47.2
74.82.47.3
85.207.155.215
91.196.50.33
91.214.114.97
92.222.246.137
99.110.32.147
Grand Total

1
37
1
1
1
2
1

1
6

1
1
1
1
2
1
1
1
212
3
136
1
10
421
1

279

2
2
54
3
2890
1
6
14

14251

3
297

2
16

1
37
1
1
1
3
2
6
1
1
1
1
2
1
1
1
212
3
136
1
289
421
1
2
2
54
3
2890
1
11
14578

After running these IP addresses through IPNetInfo, we are able to see the sources of these attacks. I
specifically searched for those that succeeded, IPs in Texas, China, and Russia. I then searched for the
IPs that had been rejected access over 1000 times: IPs in California, France, Arizona and Ukraine. The
table on the following page shows the number of different IPs coming from each country.

Log File IP Geography:

Row Labels
Canada
China
Czech Republic
France
Germany
Mexico
Netherlands
Poland
Russian Federation
Singapore
Turkey
Ukraine
United States
USA - Arizona
USA - California
USA - Florida
USA - Michigan
USA - Missouri
USA - New York
USA - Texas
USA - Virginia
Grand Total

Count of Country
1
11
1
3
4
1
1
4
9
2
1
1
2
1
12
1
1
1
1
1
2
61

The table above shows that most addresses came from China and the US, with most of the US located in
California. In one week, IPs from a total of 61 locations tried to gain access to my instance.

Security Events Log

The security events log contains records of security-related events, mainly login/logout attempts in this
case. I filtered the data to show event ID 4625, representing when an account failed to logon. This simple
table below shows the days covered by the events log, and the large amount of times a logon attempt
failed each day.
Row Labels
4625
2-Jun
3-Jun
4-Jun
5-Jun
6-Jun
Grand Total

Count of Event ID
28953
2521
2655
1610
1430
20737
28953

Conclusions and Recommendations

Based on the security issues exposed through this audit, it is apparent that security changes must be
made in order to secure the server/network. It is possible to eliminate attacks based on geography.
However, this would most likely be tedious and wouldnt result in a significant drop in attacks. Instead,
based on this audit, the following changes should be made to the configuration of the instance:

1. More restrictive inbound security group rules

Restricting RDP access to only the addresses that need access will significantly cut down the
number of attacks to the machine. To ensure this, I edited the inbound RDP rule to only allow for
access from my IP. The new rules are listed below. HTTP & HTTPS access are still allowed from
anywhere.
Type

Protocol

Port Range

Source

HTTP

TCP

80

0.0.0.0/0

RDP

TCP

3389

99.110.32.147/32

HTTPS

TCP

443

0.0.0.0/0

2. More restrictive inbound ACL rules

Similar changes were made to the ACL rules to limit inbound RDP access only to trusted IP
addresses (my IP).
Type

Protocol

Port Range

Source

HTTP

TCP

80

0.0.0.0/0

RDP

TCP

3389

99.110.32.147/32

HTTPS

TCP

443

0.0.0.0/0

3. Make changes to the local security policy

Another way to ensure a more secure instance is to configure the local security policies,
specifically the NTLM security settings. Disabling NTLM access with exceptions only for trusted
IPs, similar to the security group rules, will also limit the amount of addresses attempting access
to the server.

4. Change SSL settings

Earlier versions of SSL have been associated with protocol weaknesses. However, Microsoft only
disables SSL 2.0, so more protocols like 3.0 need to be added in the registry editor to ensure
security for the instance. Disabling SSL 2.0 and 3.0 wont limit connectivity as long as the sites
being visited support TLS protocols.