ABC
ABC
ABC
Semester: 5th
Shift: Morning
How to Install DHCP Server
This guide was created using Windows Server 2016. The steps should be similar for other server
versions.
On the server manager dashboard click “Add roles and features” This will start the add roles and features
wizard
On this page choose the server you want the DHCP service installed on. In this example, I’ll be choosing
the local server.
On this page, you want to select the DHCP server roles and click next.
When you select the roll you will get a pop up asking to add features that are required for DHCP server.
Click add features
Back on the
select server roles page click next
Step 7: Confirmation
On the confirmation page, you can select to automatically restart the server if required.
You will get an install progress page, it will say install succeeded when complete.
That completes the install of the DHCP role. Move onto the next section for steps on configuring the
DCHP server.
Configure DHCP Server
If you followed the steps above you should now have the DHCP service installed.
In the server manager dashboard, you will see a yellow notification at the top left.
Click on it.
On the authorization page use AD credentials if the server is joined to the domain.
Choose “Skip AD authorization” if the DHCP server is standalone and not joined to the domain.
Click commit
You will see a summary page of the configuration steps
Click close
Now you can open the DHCP management console to configure DHCP scopes and other options.
To access the DHCP management console click start -> Windows Administrative Tool -> DHCP
default-lease-time 600;
max-lease-time 7200;
Step 4 : Add the following lines at the end of the file (replace the IP
address to match your network):
host Server1 {
hardware ethernet 08:00:07:26:c0:a5;
fixed-address 192.168.1.88;
}
Step 6 : Save the configuration file and exit with Ctrl + O and Ctrl + X.
Step 7 : After changing the configuration file, restart dhcpd
sudo service isc-dhcp-server restart
Install Squid Proxy Server on
Ubuntu 22.04|20.04
First, update your system packages. Note that for all the commands, I will be
running them as root user
Next, install squid proxy on Ubuntu. Installing Squid proxy in Ubuntu is easy
because it is already available in Ubuntu 20 repositories. Confirm this with
the below command.
To install Squid proxy, run the below commands. Also enable to start on
system boot then check status
Now, do your custom settings in /etc/squid/squid.conf. Open the file with your
preferred file editor
The default Squid tcp port is 3128.To alter this, open squid.conf file and look
for http_port line. Change to your desired port number and save the file.
#http_port 3128
http_port 8080
To set your desired cache memory, use the settings below. For my case, I am
using 256 MB
cache_mem 256 MB
3. Specify DNS name-servers to use
Now, edit squid.conf to add rules of your choice. A proxy server is selective of
what goes through it. We can allow access from specific networks/ IP
addresses and deny others. It can also be used to filter traffic by restricting
access to certain sites or by blocking content based on certain keywords. This
is achieved by use of ACLs (Access Control Lists), which define what is
allowed and what is denied. Http_access define the allow or deny based on
an ACL.
The default defined ACL rules are as shown. Tou can choose to disable the by
adding # at the beginning of each line. To create new rules, follow the
examples below:
Now either allow or deny based on the defined rule, with the use
of http_access directive. In our case, we need to allow
http_access allow my_lan
Note that the last rule every time you create ACL access rules should be
the deny all. This should be done when you have allowed all the required
sites otherwise you might block yourselves from accessing some needed
sites.
Add the sites that you wish to deny access. For my case, I am using facebook
and youtube. Save the file after.
.facebook.com
.youtube.com
Now open squid.conf and create an acl rule for the denied sites and add a
deny rule then save the file.
Note that everytime you make changes, you must restart squid server
Create a file containing the key words. Use the file name to create an acl rule
the deny traffic.
gamble
nudes
xxx
Edit squid.conf to create acl and deny rule the save and remember to restart
squid.
To open ports in Squid proxy server, use the command syntax as shown
below
acl Safe_ports port <port-number>
# via on
via off
Also Proxy server should not append clients IP address in the http requests
which it forwards. Disable this by modifying the following lines
in squid.conf file.
The command below will point out where there could be errors in your
configuration file
First, let us create and allow users to authenticate through Squid proxy. We
need to enable http authentication in squid.conf file. Install apache2-utils.
Create a file that will be used to store users. Mine is called ‘passwd’. The file
should be owned by proxy which is the default Squid user.
New password:
Now add the following lines in squid.conf file. After adding, save and restart
squid.
Installation
At a terminal prompt, enter the following command to install dns:
sudo apt install bind9
A very useful package for testing and troubleshooting DNS issues is
the dnsutils package. Very often these tools will be installed already, but to
check and/or install dnsutils enter the following:
sudo apt install dnsutils
Configuration
There are many ways to configure BIND9. Some of the most common
configurations are a caching nameserver, primary server, and secondary
server.
When configured as a caching nameserver BIND9 will find the
answer to name queries and remember the answer when the domain
is queried again.
As a primary server, BIND9 reads the data for a zone from a file on
its host and is authoritative for that zone.
As a secondary server, BIND9 gets the zone data from another
nameserver that is authoritative for the zone.
Overview
The DNS configuration files are stored in the /etc/bind directory. The
primary configuration file is /etc/bind/named.conf, which in the layout
provided by the package just includes these files.
/etc/bind/named.conf.options: global DNS options
/etc/bind/named.conf.local: for your zones
/etc/bind/named.conf.default-zones: default zones such as
localhost, its reverse, and the root hints
The root nameservers used to be described in the file /etc/bind/db.root.
This is now provided instead by the /usr/share/dns/root.hints file shipped
with the dns-root-data package, and is referenced in
the named.conf.default-zones configuration file above.
It is possible to configure the same server to be a caching name server,
primary, and secondary: it all depends on the zones it is serving. A server
can be the Start of Authority (SOA) for one zone, while providing secondary
service for another zone. All the while providing caching services for hosts
on the local LAN.
Caching Nameserver
@ IN NS ns.example.com.
@ IN A 192.168.1.10
@ IN AAAA ::1
ns IN A 192.168.1.10
You must increment the Serial Number every time you make changes to
the zone file. If you make multiple changes before restarting BIND9, simply
increment the Serial once.
Now, you can add DNS records to the bottom of the zone file.
See Common Record Types for details.
Note
Many admins like to use the last date edited as the serial of a zone, such
as 2020012100 which is yyyymmddss (where ss is the Serial Number)
Once you have made changes to the zone file BIND9 needs to be restarted
for the changes to take effect:
sudo systemctl restart bind9.service
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192";
allow-transfer { 192.168.1.11; };
also-notify { 192.168.1.11; };
};
Note
The default directory for non-authoritative zone files is /var/cache/bind/.
This directory is also configured in AppArmor to allow the named daemon
to write to it. For more information on AppArmor see Security - AppArmor.
Troubleshooting
This section covers diagnosing problems with DNS and BIND9
configurations.
Testing
resolv.conf
The first step in testing BIND9 is to add the nameserver’s IP Address to a
hosts resolver. The Primary nameserver should be configured as well as
another host to double check things. Refer to DNS client configuration for
details on adding nameserver addresses to your network clients. In the end
your nameserver line in /etc/resolv.conf should be pointing
at 127.0.0.53 and you should have a search parameter for your domain.
Something like this:
nameserver 127.0.0.53
search example.com
To check which DNS server your local resolver is using, run:
resolvectl status
Note
You should also add the IP Address of the Secondary nameserver to your
client configuration in case the Primary becomes unavailable.
dig
If you installed the dnsutils package you can test your setup using the DNS
lookup utility dig:
After installing BIND9 use dig against the loopback interface to make
sure it is listening on port 53. From a terminal prompt:
dig -x 127.0.0.1
You should see lines similar to the following in the command output:
;; Query time: 1 msec
;; SERVER: 192.168.1.10#53(192.168.1.10)
If you have configured BIND9 as a Caching nameserver “dig” an
outside domain to check the query time:
dig ubuntu.com
Note the query time toward the end of the command output:
;; Query time: 49 msec
After a second dig there should be improvement:
;; Query time: 1 msec
ping
Now to demonstrate how applications make use of DNS to resolve a host
name use the ping utility to send an ICMP echo request:
ping example.com
This tests if the nameserver can resolve the name ns.example.com to an IP
Address. The command output should resemble:
PING ns.example.com (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=0.800 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=64 time=0.813 ms
named-checkzone
A great way to test your zone files is by using the named-checkzone utility
installed with the bind9 package. This utility allows you to make sure the
configuration is correct before restarting BIND9 and making the changes
live.
To test our example Forward zone file enter the following from a
command prompt:
named-checkzone example.com /etc/bind/db.example.com
If everything is configured correctly you should see output similar to:
zone example.com/IN: loaded serial 6
OK
Similarly, to test the Reverse zone file enter the following:
named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192
The output should be similar to:
zone 1.168.192.in-addr.arpa/IN: loaded serial 3
OK
Note
The Serial Number of your zone file will probably be different.
Quick temporary query logging
With the rndc tool, you can quickly turn query logging on and off, without
restarting the service or changing the configuration file.
To turn query logging on, run:
sudo rndc querylog on
Likewise, to turn it off, run:
sudo rndc querylog off
The logs will be sent to syslog and will show up in /var/log/syslog by
default:
Jan 20 19:40:50 new-n1 named[816]: received control channel command
'querylog on'
Jan 20 19:40:50 new-n1 named[816]: query logging is now on
Jan 20 19:40:57 new-n1 named[816]: client @0x7f48ec101480
192.168.1.10#36139 (ubuntu.com): query: ubuntu.com IN A +E(0)K
(192.168.1.10)
Note
The amount of logs generated by enabling querylog could be huge!
Logging
BIND9 has a wide variety of logging configuration options available, but the
two main ones are channel and category, which configure where logs go,
and what information gets logged, respectively.
If no logging options are configured the default configuration is:
logging {
category default { default_syslog; default_debug; };
category unmatched { null; };
};
Let’s instead configure BIND9 to send debug messages related to DNS
queries to a separate file.
We need to configure a channel to specify which file to send the messages
to, and a category. In this example, the category will log all queries.
Edit /etc/bind/named.conf.local and add the following:
logging {
channel query.log {
file "/var/log/named/query.log";
severity debug 3;
};
category queries { query.log; };
};
Note
The debug option can be set from 1 to 3. If a level isn’t specified, level 1 is
the default.
Since the named daemon runs as the bind user
the /var/log/named directory must be created and the ownership
changed:
sudo mkdir /var/log/named
sudo chown bind:bind /var/log/named
Now restart BIND9 for the changes to take effect:
sudo systemctl restart bind9.service
You should see the file /var/log/named/query.log fill with query information. This is a
simple example of the BIND9 logging options.
Once again, the above configuration gives full access to any client on
the local network. For a more secure configuration see Share Access
Control.
From a Windows client you should now be able to browse to the
Ubuntu file server and see the shared directory. If your client doesn’t
show your share automatically, try to access your server by its IP
address, e.g. \\192.168.1.1, in a Windows Explorer window. To check
that everything is working try creating a directory from Windows.
To create additional shares simply create new [sharename] sections
in /etc/samba/smb.conf, and restart Samba. Just make sure that the
directory you want to share actually exists and the permissions are
correct.
The file share named [share] and the path /srv/samba/share used in
this example can be adjusted to fit your environment. It is a good idea
to name a share after a directory on the file system. Another example
would be a share name of [qa] with a path of /srv/samba/qa.
After letting the command run, all required packages are installed and we
can test it out by typing in our IP address for the web server.
Creating Your Own Website
By default, Apache comes with a basic site (the one that we saw in the
previous step) enabled. We can modify its content in /var/www/html or
settings by editing its Virtual Host file found in /etc/apache2/sites-
enabled/000-default.conf.
We can modify how Apache handles incoming requests and have multiple
sites running on the same server by editing its Virtual Hosts file.
Today, we’re going to leave the default Apache virtual host configuration
pointing to www.example.com and set up our own at gci.example.com.
So let’s start by creating a folder for our new website in /var/www/ by
running
sudo mkdir /var/www/gci/
We have it named gci here but any name will work, as long as we point to it
in the virtual hosts configuration file later.
Now that we have a directory created for our site, lets have an HTML file in
it. Let’s go into our newly created directory and create one by typing:
cd /var/www/gci/
nano index.html
Paste the following code in the index.html file:
<html>
<head>
<title> Ubuntu rocks! </title>
</head>
<body>
<p> I'm running this website on an Ubuntu Server server!
</body>
</html>
Since Apache came with a default VirtualHost file, let’s use that as a base.
(gci.conf is used here to match our subdomain name):
sudo cp 000-default.conf gci.conf
We should have our email in ServerAdmin so users can reach you in case
Apache experiences any error:
ServerAdmin yourname@example.com
We also want the DocumentRoot directive to point to the directory our site
files are hosted on:
DocumentRoot /var/www/gci/
The default file doesn’t come with a ServerName directive so we’ll have to
add and define it by adding this line below the last directive:
ServerName gci.example.com
This ensures people reach the right site instead of the default one when
they type in gci.example.com.
Activating VirtualHost file
4.A Network Proxy dialogue appears. Choose Manual and enter your proxy info into the
fields below.
5. Exit the dialogue and Ubuntu will automatically apply the proxy settings.
2. Now add the following lines at the bottom of the .bashrc file:
export HTTP_PROXY="[username]:[password]@[proxy-web-or-IP-address]:[port-number]"
export HTTPS_PROXY="[username]:[password]@[proxy-web-or-IP-address]:[port-number]"
export FTP_PROXY="[username]:[password]@ [proxy-web-or-IP-address]:[port-number]"
...
export NO_PROXY="localhost,127.0.0.1,::1"
2. Next, update the file with the same information you added to
the .bashrc file in the previous scenario:
export HTTP_PROXY="[username]:[password]@[proxy-web-or-IP-address]:[port-number]"
export HTTPS_PROXY="[username]:[password]@[proxy-web-or-IP-address]:[port-number]"
export FTP_PROXY="[username]:[password]@ [proxy-web-or-IP-address]:[port-number]"
...
export NO_PROXY="localhost,127.0.0.1,::1"
3. Save the file and exit. The changes will be applied the next time you log
in.
Setting Up Proxy for APT
On some systems, the apt command-line utility needs a separate proxy
configuration, because it does not use system environment variables.
1. To define proxy settings for apt, create or edit (if it already exists) a file
named apt.conf in /etc/apt directory:
sudo nano /etc/apt/apt.conf
3. Save the file and exit. The configuration will be applied after a reboot.