The most basic way to mitigate network attacks is to disable services which are not necessary for the operation of the specific system. Because so many software and OS vendors want their systems to work "out-of-the-box", they often enable every service by default, even if it isn't needed by the user. If users do not disable these services, an attacker can often glean a lot of information from them, and if a vulnerability is discovered in an extraneous service, the defender may not even know they are vulnerable to it, since they are not using it (even though it is running).
Identify two services running your Linux router which are not
currently needed. You can use netstat and
lsof to help you determine what is listening on
specific TCP/UDP ports and to determine what processes are holding
those sockets open. If you are not sure if a certain service is
needed, try searching the web to determine what its function is.
Once you have determined what two services aren't needed, try
stopping them via their /etc/init.d scripts. Verify
that you can still use your system (eg, can still SSH to it, can
still connect out to the internet with it...), and if everything is
still working as expected, permanently disable these services from
starting up by removing their /etc/rc?.d
symlinks. (If you aren't sure what these symlinks are for, see this
reference.)
Search the web for information on "Simple TCP/IP Services", which
is a service that can be configured to run on Windows. Learn about
the specific protocols provided by this service. Now, shut down
this service on your Windows server, and prevent it
from starting up again. You can use netstat at the
cmd prompt to verify the listening ports were closed.
Search the web for information on the Windows "Remote Registry Service". This service is rarely needed by administrators that already have remote access to the system (eg, via RDP). Disable this service, and prevent it from starting up at boot.
Search the web for information on "Hidden administrative shares". Learn about what they are for, how they may be useful, and why they might pose a security risk. Find a registry setting to disable these shares, and do so.
Read this article on Null sessions, and search the web for additional kinds of attacks or information gathering techniques that are possible if they are enabled.
Decide what level of Null sessions should be allowed on your system, and restrict them via the indicated registry setting(s).
NOTE: After making registry changes to your Windows server, you will likely need to reboot it. You needn't do this for your Linux router.
There are many forms of Denial of Service attacks. They fall mainly into two classes: resource-exhaustion attacks, and bug exploitation. This lab will focus on the former type, as these are often tied to difficult to change protocol specifications. The types of resources typically targeted are: processor, memory, and network bandwidth.
One popular attack which attempts to exhaust the memory resources of a host is a SYN flood. Read more about how this attack works here.
Next, read about SYN cookies and how they trade off the memory requirement of half-open connections for a bit more processing.
The Linux kernel has a built-in SYN cookies option. When enabled,
Linux will use SYN cookies if the TCP/IP stack detects it is
getting overwhelmed with half-open connections. Use the
/proc filesystem to enable SYN cookies on your Linux
router. (If you are not familiar with the /proc
filesystem, you may use
this
as a reference.)
Unfortunately, Microsoft has yet to integrate any kind of SYN cookies protection into Windows. Their suggested mitigations involve registry settings which decrease the time half-open connections are kept around, along with some other settings. Review this document on the subject, and apply the changes to your Windows server that seem reasonable to you for mitigating SYN floods.
Smurf and fraggle attacks are almost identical forms of an amplification attack. By sending a single spoofed broadcast packet to many hosts, many responses may be generated and directed at a victim. Search for references online and find out what the difference is between smurf and fraggle attacks.
Read the documentation in man icmp and find out how to
keep your Linux host from being an accomplice in these kinds of
attacks. Update the indicated /proc setting
accordingly.
Before learning about iptables, it is important to
understand what a
firewall
is, what the difference is between a
stateful
and
stateless
firewall, and
at what protocol layers firewalls typically operate. Please
research this if you have never worked with firewalls before or
don't feel comfortable with all of these definitions.
The native Linux firewalling software is part of the
netfilter project. The
bulk of this software is compiled as a part of the kernel, but
filter rules can be added and removed via the iptables
command. Recent versions (2.4+) of the Linux kernel support
stateful packet inspection, allowing one to configure a stateful
firewall. Read the man page on the iptables command
and become familiar
with the options. In addition,
these
references
may help. There are many other tutorials available online as well.
A set of shell scripts have been provided to get you started
building a proper firewall. These scripts are installed on your
system in the directory /etc/iptables. Become
familiar with these scripts. In particular, pay attention to the
way /etc/iptables/start.sh defines ethernet interfaces
through the variables OUTSIDE_IF and TRUSTED_IF, and how it kicks
off all the other scripts. Also, review the structure of
the /etc/iptables/ipv4/filter.sh script, as this is
the primary place you'll be making changes.
Make a backup copy of the /etc/iptables directory.
Then, edit the /etc/iptables/ipv4/start.sh script by
setting the correct TRUSTED and OUTSIDE_IP variables, based on your
team's number. (See the script for details.)
Next, add commands to the /etc/iptables/ipv4/start.sh
script, right after the network definitions, which set all of the
/proc changes that were made in section 2.
One of the most basic functions of a firewall is the mitigation of spoofing attacks. Since routers and firewalls sit in a unique position on the network, they are ideal for limiting the types of spoofing possible. Specifically, one can configure a firewall to allow packets from a network segment only if those packets have a source address which falls within the designated network IP range. In addition, when receiving traffic from the internet, where almost any source IP is allowed, one can drop packets which contain source IPs belonging to segments within a trusted network.
Open the script /etc/iptables/ipv4/filter.sh and make
three changes:
logdrop chain.
trusted-outside chain for further evaluation.
outside-trusted chain for further
evaluation.
trusted-outside
and
outside-trusted must not allow obviously
spoofed
traffic. In particular, an external attacker should not be able to
send packets in on the OUTSIDE_IF interface with a TRUSTED
address. Also, you should not allow your TRUSTED users to send
packets from something other than a TRUSTED IP address.
Add rules to the outside-trusted chain such that the
following kinds of traffic are allowed:
-m state)
Next, add a rule at the end of that chain which sends all
traffic to the logdrop chain.
Now, carefully review your firewall rules to be sure you didn't
make any typos. Once you are reasonably confident you have it
right, run the /etc/iptables/start.sh script to
install the rules. If you see the script spit out any error
messages, it is likely because of improper usage of the
iptables command, or due to syntax errors in the shell
script itself. Fix any of these before continuing, and re-run the
/etc/iptables/start.sh script each time to flush and
re-load all rules.
You should now test to make sure you can still access your Windows
server's RDP port. This is port 3389/TCP, and simply logging in
from the internet
while the firewall is running should be sufficient. If this
doesn't work for some reason, packets may be getting blocked. Log
messages to this effect will show up in
/var/log/kern.log Also, try pinging a system on the
10.0.0.0/24 network (besides your Fedora system) from
your Windows
server. Since you allowed all ICMP earlier, this should route just
fine still. If somehow you lock yourself out of
your Fedora system, contact the lab TA, and it will be rebooted.
Take a look at the
Smurf Amplifier Registry (SAR).
Set up rules in your outside-trusted chain before your
ICMP allow-all rule to block all ICMP echo-reply packets from these
networks.
Once you are SURE you are satisfied with your firewall rules, add
the /etc/iptables/start.sh script to your boot-up
scripts in runlevels 2, 3, 4, and 5 through symlinks in
/etc/rc?.d.
NOTE: The firewall rules you just setup are not complete, and this
shouldn't be considered a "secure" firewall. This lab is merely
intended to help you learn how to use iptables. Be
sure to consider the INPUT chain and what traffic you actually
need to have allowed if you use this firewall as a basis for the
competition.
Snort is an open source, signature-based network intrusion detection system (NIDS). Read a bit about Snort and the differences between anomaly-based and signature-based intrusion detection systems.
Snort is already installed on your system, but it isn't configured
and there aren't any signatures installed. First, create the
directory /usr/local/etc/snort and make a copy
of the sample snort configuration:
mkdir /usr/local/etc/snort
cp /usr/local/src/snort-2.4.3/etc/snort.conf /usr/local/etc/snort
Next, obtain the latest, non-subscription ruleset from
snort.org. (You may
register if you wish, but this isn't required. The rules for the
latest release version will be sufficient.) Once downloaded,
extract these rules in the /usr/local/etc/snort
directory.
Now edit your copy of snort.conf and customize it for your network. Read through the comments in the file to determine how you should set each variable. (This will take a significant amount of time if done correctly.) In the end your configuration should have the following:
include directives.
alert_syslog output plugin.
Once you are happy with your configuration and ruleset, try running
Snort as root:
snort -c /usr/local/etc/snort/snort.conf
Watch the output carefully, and address any errors in your config
file. (Continue re-running snort until you get it working
correctly.)
Now, read about Snort's signature syntax in the
Snort User's Manual.
In particular, be sure to review the meta-data options
reference and sid.
Once you are somewhat familiar with the rule language, read through
some of the web attacks rules files. These are files named in the
form web-*.rules. Follow the references listed in a
few of the rules and read about the type of attack the specific
signatures are designed to detect. Also, review the documentation
provided with your signatures. (Should be in the
/usr/local/etc/snort/doc/signatures directory.)
The signature documentation is broken up into files which are named
based on their signature IDs.
Now, select one web attack signature that seems straight-forward to
understand. (It would be best if you select a signature that looks
for "evil" data in an HTTP URL string.) Log into your Windows
server, and open a browser. Based on the documentation provided
with the signature you have selected, attempt to trigger the Snort
signature by making a request to the system
strawman-fedora.nslab.ccs.neu.edu which contains an
attack string which should be detected.
Now verify in your Snort logs (Hint: /var/log/messages
will probably have something.) that your attack triggered an alert
based on that signature.
/etc/iptables.
snort.conf, not the downloaded
signatures.) Also,
include information on which signature you selected in section 4.8
(including SID), and a snippet of the log showing when the alert was
triggered.