Anda di halaman 1dari 13

ITIS 3110 Lab 03/04

NTP, Syslog, and Secure Shell/DNS


Overview
Goals
In the first part of the lab, you will configure a NTP server on your Debian VM that syncs time from the
lab time source. Your CentOS VM and Pi will be configured to sync to your Debian VM. Secondly, you
will set up a syslog server on your Debian VM and send logs to it from your CentOS VM and Pi. Finally,
you will deploy and configuration a secure shell (SSH) environment. You will learn how to install SSH,
generate keys, edit the sshd configuration file to specify different types of authentication, and configure
denyhosts. You will then use your client VM to log on to the server VM using SSH.
Note: Italicized sections refer to destination/locations or file on the VMs, bolded sections are user
information needed, and sections with the Courier New font are commands for the command line.

Deliverables (printed copy with cover and a backup to Moodle)


The printed copy of the lab will be as usual. Include introductory and concluding paragraphs, be sure to
document all entities with ** and answer all questions. Upload copies of your configuration files and the
authorized_keys and sshd_config files to Moodle.
Reminder: all information should be text files except when a screenshot is required!

Information tables**
This lab will use a Debian Virtual machine as the secure shell server and your host machine as the client.
Throughout this document, the terms host and client are used interchangeably to refer to a terminal on
your physical host machine. The first information table is to aid documenting the NTP and Syslog setup,
the second table is for the SSH setup.
Description

Formula

Used in Lab

Assigned Subnet (See 3110 Web)

Debian VM

172.16.(n).10

DEBIAN_IP

Raspberry Pi

172.16.(n).20

PI_IP

CentOS VM

172.16.(n).50

CENTOS_IP

NTP Source

172.16.1.253

172.16.1.253

Answer

Table 1: NTP and Syslog

Description
Debian
Username
Debian Password
Debian IP
Address

Used in Lab

Value

DEBIAN_USER
DEBIAN_IP

Table 2: SSH Data

4/25/2016 3:02:00 PM

Page 1 of 13

ITIS 3110 Lab 03/04


NTP, Syslog, and Secure Shell/DNS
Lab
Before starting make sure that network configuration for eth0 and lo interfaces are
valid. Also, make sure your Linux has a valid DNS server configuration. Remember
eth0 and lo are typical names, they may vary on your systems.

NTP
Check the Labs NTP server
1. Install packages ntp and ntpdate
aptitude R install ntp ntpdate
2. Run ntpdate
/usr/sbin/ntpdate q 172.16.1.253
3. An example report from ntpdate is shown below. The stratum is highlighted in the report below.
prompt$ ntpdate -q clock1.unc.edu
server 152.2.21.1, stratum 2, offset 0.002288, delay 0.05145
17 Jan 21:47:01 ntpdate[800]: adjust time server 152.2.21.1 offset 0.002288 sec

Configuring Debian VM NTP Daemon


1. Edit /etc/ntp.conf file
a Allow servers on local subnet to query our server
b Comment out all lines beginning with server
c Add a new line for the Labs NTP source
# Allow clients on 127.16.1.0/24 to query this server
restrict 172.16.(n).0 mask 255.255.255.0 nomodify notrap
# Commented out these servers
#server 0.debian.pool.ntp.org
#server 1.debian.pool.ntp.org
#server 2.debian.pool.ntp.org
#server 3.debian.pool.ntp.org
# Added a line for the Labs NTP source
server 172.16.1.253

Stop the NTP service


/etc/init.d/ntp stop
Set the clock manually
/usr/sbin/ntpdate 172.16.1.253
This step is not necessary but it should help your VMs clock synchronize with the labs time source more
quickly
4. Start the NTP service
a /etc/init.d/ntp start
5. ** Check NTP server
a ntpdate q DEBIAN_IP
b
Note: As long as you see a non-zero value for stratum, it is working fine and you can ignore any
warning. However, it may take several minutes for your NTP server to synchronize and report its stratum
correctly
2.
a
3.
a
b

Configuring CentOS VM NTP Daemon


4/25/2016 3:02:00 PM

Page 2 of 13

ITIS 3110 Lab 03/04


NTP, Syslog, and Secure Shell/DNS
1.
2.
a
b

You should not configure the CentOS NTP daemon until the Debian NTP daemon has synchronized.
Edit /etc/ntp.conf file
Comment out all lines beginning with server
Add a new line for your Debian VMs NTP source
# Commented out these servers
server 0.rhel.pool.ntp.org
server 1.rhel.pool.ntp.org
server 2.rhel.pool.ntp.org
# Added a line for my Debian VMs NTP source
server DEBIAN_IP

3.
a
b
c
4.

Stop NTP service


/etc/init.d/ntpd stop
service ntpd stop
Note: stop, start, restart and status are all options that can be used by service
Set the clock manually

/usr/sbin/ntpdate DEBIAN_IP

This step is not normally necessary but it should help your VMs clock synchronize to your Debian time
source more quickly
5. Start NTP service
b

/etc/init.d/ntpd start

6.

** Check NTP

/usr/sbin/ntpdate q CENTOS_IP

Note: As long as you see a non-zero value for stratum, it is working fine and you can ignore any
warning. However, it may take several minutes for your NTP server to synchronize and report its stratum
correctly. If your CentOS VM is having trouble synchronizing, try commenting out the dummy stratum
10 server from the ntp.conf file.
Configuring the Raspberry Pi NTP Daemon
By this time, you should be an NTP pro. Find the Raspbian NTP configuration file and configure it to use
the Debian NTP service. After restarting the daemon, check that the Pi is getting the time from the Debian
server.
Note: if ntpdate is not found on your Pi iInstall ntpdate from http://lab302-repo.hades.lab. If you are at
home, download ntpdate deb file from an appropriate source and install it using following command:
dpkg i ntpdate_4.2.6.p5+dfsg-3_armhf.deb

Syslog
Configuring Debian VM Syslog Daemon
Debian uses rsyslogd, an enhanced replacement for the venerable syslog package. We will not be using
all of its advanced features for this lab.
1. Edit /etc/rsyslog.conf file
a. Enable Logging of remote syslog messages
b. Send all log messages to a remote syslog server
# Uncommented the following lines. These enable
# Logging of incoming UDP messages from the network.
# This is normally achieved with the -r option to syslog
$ModLoad imudp
$UDPServerRun 514

2. Restart syslog server


a. /etc/init.d/rsyslog restart

4/25/2016 3:02:00 PM

Page 3 of 13

ITIS 3110 Lab 03/04


NTP, Syslog, and Secure Shell/DNS
Configuring CentOS VM Syslog Daemon
1. Edit /etc/rsyslog.conf file
a. Send all log messages to your Debian VM. Ensure the following is in the file.
# Transmit all logs to my Debian VM
*.* @@DEBIAN_IP
2.
a.
b.
3.
a.
b.
c.
d.

Restart syslog server


/etc/init.d/syslog restart
Service rsyslog restart
** Test syslog
logger hello from userid on CentOS VM
Substitute your userid in the above command
The above message should appear in /var/log/syslog on your Debian VM.
** Document files in report
Configure the Pi Syslog Daemon
Follow the steps for the CentOS Syslog configuration. Dont forget to test with logger.

SSH
Installing Secure Shell
Note: Hopefully, you have used ssh server from both your Debian server VM and your CentOS client
VM. In case you have not completed the openssh server install, follow this step:
To install the secure shell daemon on your server, you will use aptitude. As root on your Debian VM,
execute:
# aptitude -R install openssh-server
This installs the daemon, generates server keys, and starts sshd automatically.
Determining Server IP Address
With your Debian VM, verify your IP address with the following command:
$ /sbin/ifconfig
Record this IP address in the Information table at the beginning of this document. You will need to use
this IP address when using SSH to log in to your server .
Testing Login with SSH
With the default sshd configuration file, password authentication will be enabled. From your hostmachine (client), try to log in to your server VM using SSH.
$ ssh DEBIAN_USER@DEBIAN_IP
You can type a few commands to verify you have access to the server. Type exit to close the session.
Installing DenyHosts
DenyHosts monitors the secure log (/var/log/auth.log on Debian) for failed login attempts. Its
configuration file is in /etc/denyhosts.conf, but the default configuration is acceptable for our uses.
# aptitude R install denyhosts
This installs the daemon and starts denyhosts automatically.
Testing DenyHosts
DenyHosts has different policies depending on whether a failed attempt is for a non-existent account, a
normal account, or the root account. Access to the root account is the strictest and therefore the easiest to
test.
Run the SSH command twice and simply hit enter at the password prompts.
$ ssh root@DEBIAN_IP
Wait a moment, as blocking IP addresses is not instantaneous and then try to log in again using SSH. You
should see the error below.
4/25/2016 3:02:00 PM

Page 4 of 13

ITIS 3110 Lab 03/04


NTP, Syslog, and Secure Shell/DNS
$ ssh root@DEBIAN_IP
ssh_exchange_identification: Connection closed by remote host

Note: You can also see the blocked IP address in /etc/hosts.deny on the server.
White-Listing an IP Address or Network
Occasionally you will need to white-list an IP address or network to prevent DenyHosts from blocking it.
This can be achieved by editing /etc/hosts.allow. In this lab, it makes sense to white-list the entire labs
network, as below.
# White-list the Labs network
sshd: 172.16.0.0/255.255.0.0

After white-listing the network, you should be able to log in from your client again. This step is
required to continue the lab.
Generating Keys
We will next create a public/private key pair so we can connect more securely. On your client, execute the
following command.
$ ssh-keygen -t rsa -b 4096
This step requests a password that will be used to encrypt your private key on disk. It is not essential to
set a password, but it adds an extra layer of security. For this lab, DO NOT enter a password here.
This command will create two keys: id_rsa and id_rsa.pub in ~/.ssh/.
Copying Public Key to Server
We need to copy our public key to the server. The simplest method is to use secure shell to transfer the
key. Run the following command on the client to copy your public key to the server.
$ scp ~/.ssh/id_rsa.pub DEBIAN_USER@DEBIAN_IP:.
The above command transfers your public key to your home directory on the server. In UNIX parlance,
. is the current directory, which defaults to your home directory when doing a secure copy.
Authorizing Public Key on the Server
Next, we will authorize your public key to authenticate your user on the server. We first need to create an
empty authorized_keys file and configure its permissions correctly.
$
$
$
$

mkdir
touch
chmod
chmod

~/.ssh
~/.ssh/authorized_keys
700 ~/.ssh
600 ~/.ssh/authorized_keys

Reminder: The chmod command configures permissions for files and directories in Linux. The above
example is using the octal notation. 7=RWX, 6-RW-, 5=R-X, etc. First group is owner, then group, then
world.
Once the authorized_keys file has been created, we need to append our public key to it.
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Keys should always be appended to the authorized_keys file as you may have multiple keys for multiple
machines.

4/25/2016 3:02:00 PM

Page 5 of 13

ITIS 3110 Lab 03/04


NTP, Syslog, and Secure Shell/DNS
Modifying sshd_config
The configuration file for the SSH daemon is located in /etc/ssh/sshd_config on your server. We will be
modifying lines relating to authentication. Using your editor of choice, you will need to locate and modify
certain lines as follows:
# Make sure that we can authenticate using our public/private key pair
PubkeyAuthentication yes
# Disable logins using standard passwords
PasswordAuthentication no

You will need to restart sshd after your modifications to enable these changes. Execute the command:
# /etc/init.d/ssh restart
Testing Key-Based Login
From your client, try to log on to your server using SSH. You can also log on using the normal method:
$ ssh DEBIAN_USER@DEBIAN_IP
Assuming that you did not set a password on your private key, you should now have a shell on your
Debian VM. If your private key was not located in ~/.ssh/id_dsa or ~/.ssh/id_rsa, you would need to
specify its location with as follows:
$ ssh USER@HOST -i KEYFILE
SSH and the Pi
An ssh client should be part of the Raspbian Linux. Try logging onto the Debian SSH Server with ssh on
the PI.
What error occurs?
What change to the Debain SSH server configuration do you need to make to allow the Pi to ssh
to the Debian server using standard passwords?
Make the change to the Debian SSH configuration file and test. Document it working.**
Depending on your preference, you may leave the change when done or remove the change.

Questions
1. What does nanos -w option do?
2. What does aptitudes -R option do? Use the man (manual) page for aptitude to answer this
question.
3. What is the stratum of the Labs NTP source?
4. What is the stratum of your Debians NTP server?
5. What is the stratum of your CentOS client?
6. What does the *.* stand for when configuring the syslog destination?
7. If you do not create a passphrase for your ssh private key, what would happen if someone were
able to copy your private key file?
8. Using key based authentication with SSH and having no passphrases for the private key is very
helpful in some circumstances. What is one of these circumstances? (Think about using scp)
9. What, if any, are the security concerns of someone stealing your public key?

4/25/2016 3:02:00 PM

Page 6 of 13

ITIS 3110 Lab 03/04


NTP, Syslog, and Secure Shell/DNS
Overview
Goals
Stage one of the lab involves the installation of a DNS server that is authoritative for a sub domain of
hades.lab. This DNS server should be capable of answering any query of the hades.lab domain and its
sub domains. It should also be able to answer any queries made of its sub domain by the name server for
the entire domain.
Stage two involves taking the working DNS server for the sub domain and making it DNSSEC aware.
This lab will not show how integrate DNSSEC with other DNS servers as the lab's DNS server is not
capable of speaking DNSSEC.
Note: Italicized sections refer to destination/locations or file on the VMs, bolded sections are user
information needed, and sections with the Courier New font are commands for the command line.

Deliverables

The Lab Report should including the following for full credit
All the completed information sections throughout the lab
Description of the lab steps completed and the results
Any errors you encountered and the steps you took to resolve them
Any mistakes found or corrections made to the lab steps
Answers to the questions posed at the end of this lab
Text copies of the following in the report:
/etc/bind/named.conf.local
Zone file (e.g. /var/cache/bind/db.SUBZONE)
Text file containing the results of 'dig +dnssec t soa
SUBZONE@DEBIAN_IP'

Information
Description
Assigned Subnet Number:
Your Last Name:
Debian VM IP:
Raspbian Pi IP:
CentOS VM IP:
DNS Forwarder:
Subzone:

Formula
n
<last_name>
172.16.n.10
172.16.n.20
172.16.n.50
<last_name>.hades.lab

Used in Lab
DEBIAN_IP
PI_IP
CENTOS_IP
172.16.1.252
SUBZONE

Answer

172.16.1.252

Table 3: Information for VMs

If your last name is Jones, your SUBZONE would be jones.hades.lab. Use the last name as it appears (no
uppercase letters) on the IP subnet assignment page on Moodle. REMEMBER - as of this lab your
DEBIAN_IP needs to end in 10. The DNS glue records on the lab server have been set to point to
172.16.n.10. Any number other than 10 will not function properly.

4/25/2016 3:02:00 PM

Page 7 of 13

ITIS 3110 Lab 03/04


NTP, Syslog, and Secure Shell/DNS

Stage 1: DNS Server Installation & Configuration


Getting Started
1. Load the Debian VM
2. Verify the VMs IP Address matches the IP address you calculated in the Information section above (Refer

to Lab 1 for information on viewing and modifying your IP address)

Initial Installation and Configuration


Install the bind9 package
aptitude R install bind9
Edit /etc/bind/named.conf.options file
Debian splits the standard named.conf into three separate files
i named.conf boiler plate file. Contains some standard configuration and references the two files listed
below. This file almost never needs to be changed
ii named.conf.options contains site-specific configuration options to the name server
iii named.conf.local contains references to the local zones that this server controls
b Uncomment the forwarders section and replace 0.0.0.0 with IP of the Labs DNS forwarder noted in the
Information section above.
3.
a
4.
a

forwarders {
172.16.1.252;
};
5.
a
6.
a
b

Restart DNS Server with the following command


/etc/init.d/bind9 restart
Verify server is responding correctly
dig mirror.hades.lab @DEBIAN_IP
Note: You should see a non-zero value for the section labeled "Answer" in the report when you do a dig
command. If you see a zero, there is an error. This is generally true for all digs you do.

Creating a Sub Zone


1.
a

Edit /etc/bind/named.conf.local file


Add a zone for your subzone you calculated in the Information section above

zone "SUBZONE" IN {
type master;
file "/var/cache/bind/db.SUBZONE";
allow-update { none; };
};
2.
a
b
c
d

Create a zone file for your subzone


e.g. /var/cache/bind/db.SUBZONE
The file name must match the file name referenced in named.conf.local
Use the IP addresses you calculated in the Information Section above
$TTL and Negative Cache TTL are both set to 2 minutes so any mistakes can be corrected quickly. In a
real site, you would want $TTL set to a minimum of one day and the Negative Cache TTL set to 15
minutes.

4/25/2016 3:02:00 PM

Page 8 of 13

ITIS 3110 Lab 03/04


NTP, Syslog, and Secure Shell/DNS
e

Use standard convention for the Serial, e.g. yyyymmddnn. Note that if you make any mistakes in this file,
update the serial number before reloading it
$ORIGIN SUBZONE.
$TTL
2m
@ IN SOA ns.SUBZONE. jwatso8.uncc.edu. (
2011091201
; Serial
1w
; Refresh
1d
; Retry
28d
; Expire
2m )
; Negative Cache TTL
;
@
IN
NS
ns.SUBZONE.
@
IN
A
DEBIAN_IP
ns.SUBZONE.
IN
A
DEBIAN_IP
debian
IN
A
DEBIAN_IP
raspbian
IN
A
PI-IP
centos
IN
A
CENTOS_IP
test.SUBZONE.

IN

CNAME

Debian

Figure 1: /var/cache/bind/db.SUBZONE file

3. Verify the zone file you just wrote


a named-checkzone SUBZONE /var/cache/bind/db.SUBZONE
b Should return a statement saying everything is well. Correct any errors in your zone file before
4.
a
5.
a
b
c

continuing.
Reload the DNS server using the following command
rndc reload
Verify that the server is responding correctly
dig debian.SUBZONE @DEBIAN_IP
dig debian.SUBZONE @172.16.1.252
Both dig commands should return the same information

Troubleshooting

The system log may contain useful error messages


/var/log/syslog
less is a useful command to view the log file
<shift>-G jumps to the last line of the log file
<shift>-F will monitor the log file
<ctrl>-C to stop monitor mode
q to quit

4/25/2016 3:02:00 PM

Page 9 of 13

ITIS 3110 Lab 03/04


NTP, Syslog, and Secure Shell/DNS
Stage 2: DNSSEC
Initial Configuration
1
a

Edit /etc/bind/named.conf.options file


Enable DNSSEC
// Add this inside the options {} statement
dnssec-enable true;

2
a
b
3
a
b

i
c
4
a
b
c

Create /etc/bind/keys and change current directories to it


mkdir /etc/bind/keys
cd /etc/bind/keys
Generate DNSSEC Zone Signing Key for your domain
This step needs to be run from the /etc/bind/keys directory
dnssec-keygen r /dev/urandom a NSEC3RSASHA1 b 1024 n ZONE SUBZONE
Never use the -r /dev/urandom on a real server. It is included here to speed up this process.
Note the name of your Zone Signing Key in the table below. Be aware that dnssec-keygen returns
the key name without the .key extension. Add the .key extension when recording the key file name
Generate DNSSEC Key Signing Key
This step needs to be run from the /etc/bind/keys directory
dnssec-keygen r /dev/urandom f KSK a NSEC3RSASHA1 b 2048 n ZONE
SUBZONE
Note the name of your Key Signing Key in the table below. Be aware that dnssec-keygen returns the
key name without the .key extension. Add the .key extension when recording the key file name
Key Name
Zone Signing Key
Key Signing Key

5
a
b

Used in Lab
ZONE_SIGNING_KEY
KEY_SIGNING_KEY

File Name

Edit your zone file and $INCLUDE the two keys you noted in the table above
e.g. /var/cache/bind/db.SUBZONE
Remember to increment the zones serial number
; Append these two lines to your zone file.
$INCLUDE /etc/bind/keys/ZONE_SIGNING_KEY

6
a

7
a
b
c

Create a signed zone file


This step needs to be run from the /etc/bind/keys directory. It is all on one line.
dnssec-signzone r /dev/urandom -k KEY_SIGNING_KEY -o SUBZONE -t -A
/var/cache/bind/db.SUBZONE ZONE_SIGNING_KEY
Verify the zone file is signed correctly
named-checkzone SUBZONE /var/cache/bind/db.SUBZONE.signed
Should mention that the zone is signed
Update /etc/bind/named.conf.local to use signed zone file
zone "SUBZONE" IN {
type master;
file "/var/cache/bind/db.SUBZONE.signed";
allow-update { none; };
};

4/25/2016 3:02:00 PM

Page 10 of 13

ITIS 3110 Lab 03/04


NTP, Syslog, and Secure Shell/DNS
8
a
9
a
b

Reload the DNS server with the following command


rndc reload
Verify DNSSEC is working correctly
dig +dnssec centos.SUBZONE @DEBIAN_IP
The dig output should contain a number of RRSIGS that contain long alphanumeric strings. These
are the signatures for each record

Questions
1
2

a
3

Nowhere in this lab exercise did we modify the /etc/resolv.conf file to use the DNS server we created.
Why does this work?
Can you look up a host name in your sub domain from your host workstation? Please explain your answer
and why you think it does or does not work.
E.g. does dig debian.SUBZONE work on your host workstation.
Why is using /dev/urandom in the real world a bad idea? The manual page for random will likely help
with answering this question. (man 4 random) Explain in your own words how this could be exploited in
practice.

Project Assessment
4/25/2016 3:02:00 PM

Page 11 of 13

ITIS 3110 Lab 03/04


NTP, Syslog, and Secure Shell/DNS
This project assessment was done to reflect on the different edits and changes done for the fourth
and final project. With the ability to choose what type and kind of digital media we were allowed to edit, I
reflect on different classes Ive taken over the years and the type of work I may find myself working on.
With this in mind, I chose to edit Lab guides from an IT (Information Technology) Infrastructure class I
took a few semesters ago. Although these guides were enough to complete the task at hand, there were
many inconsistences in them, in regards to font types, sizes, alignments, typos, etc. With these guides
including tons of technical information, it was easy to initially miss steps or misunderstand instructions
and thus, many changes and edits were made to improve the readability and consistency of these lab
guides for future students.
The major issue I noticed in these guides were many inconsistences throughout the instructions.
The author, known that the reports included many technical terms, used different stylistics emphasis
during the different sections of the labs guides to make it easier to distinguish what needed to be
accomplished in different sections. Unfortunately, this led to the guide looking fairly disjointed as some
parts were in Times New Roman, while other sections would suddenly change to Calibri font, with
different sizes or italics and bolded areas. Due to this, I added a small reminder at the top that specified
what the different emphasis of the font meant in terms of the guide. For example, while editing the lab
reports, I made sure to make all of the terms regarding a specific directory or file in the computer to be
italicized, while specific information that was needed from the user was bolded and commands that were
input were in a different font, Courier New. After these changes, it was easier to know what needed to be
done and in what manner. There were also many spacing discrepancies throughout the reports, so I made
sure to keep all the alignments and indentations of the different list, tables, and figures consistent
throughout the reports.
There werent many grammatical mistakes, aside from a few missing commas and proper tense
changes but, while the reports were technical in nature and terminology, the written was relatively simple
and straight forward so typos were scarce. Also, taking into considerations that these were some of the
earlier lab guides in the course (labs 3 and 4), I added more notes/disclaimers and clarified specific parts
to make sure that items or instructions were not overlooked. There were no graphics present in this
projects but there were some tables and textboxes holding text that the user needed to input or edit. Many
did not contain a caption so I decided to add captions on the tables and the more important textboxes that
did not have their name or directory referenced in the immediate surrounding text. Finally, the font on the
reports were relatively small compared to standard reports written, so I made the bulk of the text, aside
from titles, font 11 to make it more readable for the user. This, along with the reports having different
margins before they were combined, made for some issues in alignments and lists/instructions being split
into different pages so it was for the reports to be revised an additional time to make sure that spacing was
not an issue. Some paragraphs were spaced out accordingly so that it helped to stop splitting the
instructions, as well as pushing certain sections into the next page if it was a new sections with a
relatively new topic. However, this left to some pages being oddly shorter than others and in order but I
4/25/2016 3:02:00 PM

Page 12 of 13

ITIS 3110 Lab 03/04


NTP, Syslog, and Secure Shell/DNS
believe it was better to have sections grouped appropriately at the cost of small areas of some extra white
space.
Overall, the reports proved to have small but numerous revisions to be made. Many of these
revisions were very small in scale, such as making sure that certain words or sentences were emphasis
with either being bolded or italicized. However, they add up make an easier lab guide that flows well and
where the users can better recognized their assignments based on the emphasis on the font. Along with
changes made to the margins, font sizes and spacing, the lab reports are easier to digest without
compromising the information or lessons thought.

4/25/2016 3:02:00 PM

Page 13 of 13

Anda mungkin juga menyukai