reflection.tex

\subsection{TCP \& IP Attacks}

Many of the attacks in this lab take advantage of old, or bad, default configurations for network stacks. Even the
SYN-FLOOD task description explains the countermeasures you must disable for the attack to have any effect at all. ICMP
redirection is largely preventable with nothing more than proper configuration\cite{sysctl}.
ARP poisoning is easily detectable as well, with tools such as Snort freely available\cite{snort}\cite{snort_arp}.
Sending TCP reset attacks in response to any traffic can still cause some issues in hosts, however RFC4953 (2007) lists
various potential countermeasures, including requiring that an RST packet contains the SEQ number of the initial SYN-ACK
exchange. Since RST attacks tend to be made against ongoing connections, an adversary would have to sniff the state of
every single packet in the connection before launching such a packet, making this an effective countermeasure. This is
not yet a standard, merely a suggestion of what might become one. TCP RST attacks remain a problem. ICMP hard error
packets and source quench packets are, however, deprecated, and ignored by most applications, so these attacks are
currently only possible against legacy systems.

TCP session hijacking merely highlights the need for encryption whilst managing a system remotely. Using telnet and ftp
is currently highly discouraged -- indeed an internet search for how to set these services up generally results in a
large warning at the start of the tutorial suggesting that SSH and scp are used instead -- though some real-world
systems still use these old unencrypted methods of communication. It is worth noting that the IPSEC protocol, whether
implemented in v4 or v6, protects against man-in-the-middle attacks, and makes it harder for attackers to spoof their
IP addresses, which aids in preventing Denial Of Service attacks.\cite{rfc2401}
IPv6 itself is only more secure than IPv4 because conformant implementations must include IPSEC, which
is not the case for IPv4.

\subsection{XSS Attacks}

Attacks such as XSS are easily mitigated\cite{cheatsheet}, and are largely found in badly maintained, old or poorly
written web sites and applications. If they are not mitigated, however, then relying on measures such as sandboxing or
client-side security is not always feasible. XSS exploits the trust a user's browser has in the website it is viewing,
and the more powerful the javascript engines and browsers become, the more essential it is that websites are
trustworthy. Various popular internet forums take countermeasures of varying levels of sophistication against attempts
at XSS attacks -- some forums have scripts running which immediately ban users for posting replies containing
anything that might be used for code injection whilst others replace such attempts with amusing strings of text. Indeed,
the attack itself contains code that can be used to prevent it -- calling the {\tt escape()} function over any strings
that are submitted to the server will replace unsafe characters such as {\tt <} with escaped variants, which cannot be
used to inject code into a web page. Newer versions of phpBB do this as standard, and even contain code checking tools
that make it difficult for a webmaster to allow these issues to occur. The fact that various posts on the phpBB support
forums seem confused by this suggest that there may be some niche forums run by more naive admins who are not aware of
this, but the potential impact of these vulnerabilities is hard to judge.