Firewalls and Network Security

Define  (Start list of terms on board):

·        Firewall  A firewall is a hardware or software solution to enforce security policies.  A system designed to prevent unauthorized access to or from a private network.

A proper firewall is not an off-the-shelf product you can buy, despite what some vendors (or bosses) claim!  Security is more of an on-going process, a proper attitude, that affects such things as installing new servers and determining user policies.  A number of components make up a common firewall: packet filter such as TCP Wrappers, ipchains, iptables, Cisco PICS, Check Point, ...;  proxy servers such as squid, ftp-proxy, JunkBuster, ...; these can be used to enforce an access policy and require little human interaction once set up, except to make changes as policies and services change, and to monitor the component to make sure an intruder hasn’t changed the access policy.  This low level of maintenance makes such products popular with both management and SAs.

Other components of a firewall include IDS (Intrusion detection systems) and vulnerability scanners.  Unlike firewalls these products can not be deployed and forgotten (despite claims to the contrary!)  These products watch the network packets, network device logs, and other indicators and generate warnings usually called alerts.  However it takes a human to interpret these alerts in context and decide if the incident is actually an intrusion that warrants further activities (escalation).

·        DMZ (a.k.a. Perimeter Network) Demilitarized zone, a part of the network that sits between an internal (private) network and the Internet.  A firewall or a router usually protects (isolates) this zone isolated as much as possible with network traffic filtering capabilities.  Typically, the DMZ contains devices accessible to Internet traffic, such as Web (HTTP ) servers, FTP servers, SMTP (e-mail) servers and DNS servers.

·        Bastion Hosts  A system that has been hardened to resist attack, and which is installed on a network in such a way that it is expected to potentially come under attack.  Typically part of a DMZ (and sometimes considered part of the firewall), a bastion host is a gateway between an inside network and an outside network.

·        NAT (Network Address Translation, a.k.a. PAT a.k.a. IP Masquerading and other terms, is an excellent security measure but makes routing more difficult, so IP purists don’t like it much).

·        Packet Scrubbing (normalization) removes covert channel opportunities that use packet headers to transmit information.  (The OpenBSD firewall, Pf, supports this.)  Such measures also make OS fingerprinting more difficult for intruders.

·        encryption and authentication (examples of these include GPG for email and files, passwords, public key systems such as ssh, VPNs, and others); and other tools and techniques including masquerading, logging (and log monitoring such as swatch), and monitoring (including SNMP).

Simple off-the-shelf products are usually just some sort of router (that supports NAT) with a packet filter, but may include other services such as VPN software, anti-virus (that can check all email messages and attachments), URL filtering (to protect the kiddies), or various proxy servers.

Security starts at the individual system:

·        Turn off unused services

·        Remove unneeded software (such as compilers, perl, ...)

·        Remove un-needed user accounts

·        Turn off un-needed privileges (no ftp or telnet for some users), and configure users, groups, and permissions correctly

·        Configure security policies with PAM,  sysctl (kernel settings, e.g., refuse source-routed packets over Ethernet; ndd on Solaris), xinetd, and per-system packet filtering, etc.

·        Use nmap and /etc/services to see what services (ports) are open on your systems.  Also netstat -nupan

·        Use Intrusion Detection Systems (IDS, a.k.a. HIDS for host IDS) such as tripwire or samhain to detect hackers modifying important files and infecting programs with viruses.  Others include AIDE and Integrit, and all are better than Tripwire in configurability documentation, and the ability to reduce the babble of these tools to a manageable level.  However most alternatives to tripwire lack strong cryptographic protection.

·        Use process accounting and auditing to monitor what users and servers do to your system.  Finally every server includes its own security system, so correctly configure FTP, Web, mail, DB, and other services.  (This takes expert knowledge, usually available on the Internet and in various books.)

Network security is used to monitor and control access to and from your hosts.  Given laptops, wireless LANs, modems, it is not sufficient to have a router at the border of your organization  (an ASBR) block some incoming packets.  The hosts must be protected from each other as well.

Egress filtering can be used to help protect some hosts from others, and to block popup ads.  (Your web browser runs the JavaScript in an HTML page, which causes it to request the banner/popup ads.  To stop the ads you must filter outgoing request packets.)

SNMP, RMON, argus (a network monitoring tool that provides network-level auditing), and other tools can be used to collect information you can use to monitor and control your networks.

Collect information (especially network log files) are often very large so use a tool such as swatch or MRTG to continually examine collected information and alert you when something interesting happens.

Common Architectures:

Internet (untrusted) -->ISP-->router-->all bastion hosts, intranet servers,
                                                          workstations

Internet-->ISP-->router-->DMZ
                              ^--->intranet servers and workstations

Internet-->ISP-->border router-->DMZ-->router-->intranet servers, workstations

Packet Filtering

Packet filters are lists of rules (sometimes called chains) of the form criteria action.  The criteria are items such as source or destination address, port numbers, the interface the packet arrived from or will go out of, and other items that usually can be found in the IP, TCP, or UDP packet headers.  The action is usually simple: drop the packet or allow the packet, but additional actions might be to reject the packet (with a message back to the sender), log the packet, or masquerade the packet.

When a packet arrives at the packet filter (either from the current host going out, from an outside host coming in, or a forwarded packet that is coming in and going out again), the packed is matched against every rule in order.  The first matching rule’s action is followed.  If no rules match the packet, some default policy determines what do to (the common default policy is to accept the packets, but this should be changed to drop the packets.)

Packet filters vary in what they can use for criteria.  TCP Wrappers for instance only can examine the source IP address, DNS name, and destination port (i.e., the service).  In addition it is not part of the kernel (this is often referred to as a userland packet filter) and is slower.

In contrast iptables is a kernel module (“netfilter”) that can examine all parts of the packet header.  (Remember those TCP/IP packet header diagrams in your intro to networking class?  That stuff is used here.)  For example to block incoming Telnet requests you can’t just block all incoming packets for port 23.  This will indeed stop incoming Telnet requests but will not block the other 64k ports.  To block any incoming TCP connections, but to allow outgoing connections, as well as incoming packets that are replies to (or part of) a session started from the inside, you must understand TCP in some detail:

SYN, ACK, RST, and other bits in the TCP headers (Three-way handshake with <SYN then  >SYN,ACK then <ACK).  So to block any incoming requests with ipchains you drop incoming packets with SYN set.

The internet is not the warm, fuzzy, friendly place it once was.  In the old days you could trust all users and hosts on the Internet to play by the rules and respect your policies.  Sadly those days are gone.  Many people claim that TCP/IP is poorly designed from a security point of view, and perhaps it is but that was not one of its design goals (which was to stay up in the event that one or more nodes was knocked out by nuclear bombs).  Newer standards such as IPsec, and the security in IPv6 will help but today use encryption and VPN/tunnels to protect the packets.  Use public keys, strong passwords, smart cards, etc. to authenticate users and hosts.  (SSL is used to this now, https.)  Because TCP creates virtual circuits that use packet sequence numbers, TCP is inherently a bit more secure than UDP and should be used whenever possible in preference to UDP.  (And never use RPC!)

What this boils down to is that some evil-doers (a.k.a. black hats) will send TCP packets to your system without setting SYN!  Ipchains has no way to detect this and will allow such packets right through.

What is needed is a packet filter that keeps track of all current sessions and other statics.  Such a packet filter is called stateful:  It can keep track of all conversations in a table and detect packets without SYN set but that aren’t part of some session.  By keeping statics for each session many DoS (discussed later) attacks can be detected as well.  For Unix and Linux systems the stateful iptables packet filter is available.  It is similar to ipchains but includes additional criteria and actions.  (Note the iptables kernel module is also known as netfilter, which you should have included as a module when you built the kernel.)

Creating good packet filtering rules is difficult.  Many good books available (show O’Reilly books).  To make this easier tools such as Firestarter and Shorewall are available GUIs that create iptables filter rule sets.  You can also find such rule sets (or iptables “scripts”) on the Internet that you can download and tweak.

To allow remote X window GUI access can be dangerous.  ssh can be used to provide a more secure tunnel for X, POP/ IMAP, etc.  To allow remote X for the local LAN only is still dangerous (because a black hat may spoof the IP address of some server on your LAN and open windows on your server or do other more nasty things).  X sessions start at port 6000 (for session 0), 6001, (for IP:1), etc.  Blocking all ports from 6000 – 6009 is often done to stop X but unfortunately this range overlaps other registered services, so you must be careful.  You might allow access to ports 6000 – 6004 to localhost (or the local LAN) only.

There was a posting about preventing SSH dictionary attacks on slashdot, and several people posted iptables methods of dealing with this, using the “recent” rule.

“Rundown on SSH Brute Force Attacks” at http://it.slashdot.org/article.pl?sid=05/07/16/1615233  This is what was posted (there was a more complicated one that allowed for ssh IP whitelisting too):

-A PREROUTING -m tcp -p tcp -d $EXTERNAL --dport 22 -m recent --rcheck \
    --hitcount 3 --seconds 600 -j LOG --log-prefix "SSH attack: "

-A PREROUTING -m tcp -p tcp -d $EXTERNAL --dport 22 -m recent --rcheck \
   --hitcount 3 --seconds 600 -j DROP

-A PREROUTING -m tcp -p tcp -d $EXTERNAL --dport 22 -m recent --set \
    -j DNAT --to-destination $INTERNAL:22

-A OUTPUT -m tcp -p tcp -d $EXTERNAL --dport 22 -j DNAT \
   --to-destination $INTERNAL:22

A simpler approach is to use the limit module. The following lines block SSH connections from the beginning:

$IPTABLES -i eth0 -A INPUT -p tcp --dport 22 -m state --state NEW -m limit \
    --limit 5/min -j ACCEPT

$IPTABLES -i eth0 -A INPUT -p tcp --dport 22 -m state \
  --state RELATED,ESTABLISHED -j ACCEPT

$IPTABLES -i eth0 -A INPUT -p tcp --dport 22 -j DROP

With these three rules, incoming SSH connections are limited to five, established connections are unaffected and otherwise the packets are dropped.

Proxy Servers

Simple relays for traffic.  Often the bastion hosts run proxy servers.  The router can send incoming port 80 (and 21 for FTP) request to squid, which can examine the HTTP headers within the packets (content filtering) and determine if the packet is a web request or IM or SOAP (both of which use port 80 to fool routers and packet filters!).  Web requests will be replied to from squid’s cache, or the request is forwarded to the real web server.  The simplicity of squid (verses apache) makes it much easier to configure and secure; any security holes in apache become moot since no black hats have any direct access to your server.  The same applies to other proxy servers for other services.  Proxies can greatly increase security (They usually come with excellent logging features) and improve performance (by having a large cache the proxy can return the results faster than a more fully featured server).

There are two types of proxy servers, Application-level and circuit- or wire-level.  An application-level proxy knows about a particular application or protocol (such as SMTP or Telnet).  Squid is an application level proxy that knows about HTTP and FTP. A circuit-level proxy just forwards traffic between the client and server without interpreting the application protocols used.  Examples are SOCKS and TIS FWTK (Trusted Information Systems’ Firewall Toolkit).  Circuit-level proxies can provide service for a number of protocols but by the same token they provide little control since that would require application layer knowledge.

Application-level proxies either require custom client software (An example is a web browser with a “proxy IP address” setting available), custom procedures with standard clients (e.g., using special URLs), or are transparent.  Transparent proxies use standard clients and no special procedures, but redirect the requests to the proxy server which in turn validates, logs, and either services the request from its cache or forwards the request to the real server, stores the reply in its cache, and then returns a result to the client.

Proxy servers are useless unless steps are taken to prevent users from bypassing them and talking directly to other servers.  Usually proxy servers are used in conjunction with routers and packet filters.

Types of Attacks and (Some) Remedies

1.     Unauthorized use

a.      permissions, users and groups (verify no login permitted for appropriate accounts), sudo (or Solaris roles and profiles)

b.     Many services, each has independent security configuration: www, ftp, sendmail, DB, ...  This is inefficient and hard to maintain to get exactly correct.  One answer is TCP Wrappers, a better one is a packet filter.  In any case, turn off unused services and remove unused s/w.

2.     Exploit known weaknesses  (common mis-configurations, known bugs in software that wasn’t updated or replaced, using insecure services such as rlogin.  Often such attacks are made by script kiddies using a rootkit (a program that systematically examines a target system for known weaknesses then breaks in, creating new accounts, replacing standard programs with dangerous look-alikes (e.g., a new ps that won’t reveal processes, a new who that doesn’t show the new account, ...), and reconfiguring permissions, firewalls, and servers with back-doors.
A common weakness is a buffer overflow, caused by sloppy C programming (usiing gets() and scanf() in dangerous ways).

Security Measures to Take:  Don’t run un-needed services.  Remove un-needed software (especially compliers and interpreters).  Update and maintain all servers.  Replace insecure servers with secure versions when possible (e.g., replace telnet for remote access with ssh).  Carefully configure services (and don’t be afraid to hire a consultant) according to your policy documents.  Monitor CERT.org and other sources for problems and patches.  Run servers in a chroot jail a BSD jail, a Solaris zone/container or a virtual server using Xen or VMware.  Run a security audit occasionally.

3.     SQL Injection, which attacks CGI, PHP, and similar scripts that perform SQL database commands using data supplied by a user from a form.  An example PHP-Nuke exploit allows an attacker to deface the website by obtaining the passwords needed to modify banners or other parts: (from Security Warrior by Cyrus Peikari & Anton Chuvakin, (C) 2004 O’Reilly & Assoc., pages 388-ff.  The authors report the attack was first publicized by Frogman at http://archives.neohapsi8s.com/archives/vulnwatch/2003-q1/0146.html )

http://127.0.0.1/nuke/html/banners.php?op=Change&cid=
'%20OP%201=1%20INTO%20OUTFILE&20'/tmp.secret.txt

The problem is the badly written (from a security standpoint, and since fixed) PHP code found in banners.php:

$sql = "SELECT passwd FROM " . $prefix
   . "_bannerclient WHERE cid='$cid';

The $cid variable is filled from the client request string (from the form).  With the string above (the “%20” is a space), the SQL command becomes:

SELECT passwd from nuke_bannerclient
  WHERE cid='' OR 1=1
  INTO OUTFILE '/tmp/secret.txt'

An interesting security feature of Perl is a taint mode, in which using client data this way would cause the script to fail to run

4.     DoS (Denial of Services) packet storm, SYN flood (Each SYN packet can use up some RAM even if the 3-way handshake is never completed.  By sending lots of SYN packets the server could crash), DDoS (from many bots or zombies at once), smurf attacks (send a ICMP echo (ping) or fraggle attack (a UDP ping), with fake src addr to a broadcast addr for your lan; worse: send ping to bastion host with fake lan broadcast addr, causing your host to flood your lan with packets)  Describe the ping of death.
To fix smurf and fraggle attacks turn off services from xinetd: echo, discard, daytime, chargen, and any others you don’t know you need.  Disable echo and echo replies to/from broadcast (or multicast or anycast) addresses.  You can’t stop packet storms yourself, you must contact your ISP and get them to stop the attack.  (Some ISPs don’t have plans or procedures for this; don’t use them!)  Use a stateful packet filter in your firewall and use a proper architecture (such as using a DMZ).  A modern TCP/IP stack should not use RAM per SYN packet.

5.     Spoofing (and replay and man in the middle) email, hostnames/domain names, IP addresses, port numbers, AS numbers, MAC addresses can all be faked.  A well-known spoofing attack is to hijack an rlogin session by guessing TCP sequence numbers.  Another common spoof attack is to trick your MTA into sending out spam that appears to come from a valid user.  The man in the middle attack is when your outgoing packets go to a black hat who has cut communications between you and some host, and they spoof that host to you and spoof you to that host.  In the process they can read, modify, or drop any packets.

Use ssh, VPNs, and GPG encryption to defeat this attack.  Other measures include reverse-DNS lookups to validate the hostnames.  Use a modern TCP/IP stack that uses hard-to-predict sequence numbers.  A common spoof attack is to fake email headers by using sendmail directly.  In this case (common in a university setting) using the identd server may identify the wrong-doer (your host sends a request to the identd server running on the client’s host, providing it with the port numbers used, and identd should respond with that user’s username.  Not all servers run identd, and you must not trust what they say blindly.)

6.     Eavesdropping is done by users or viruses (or worms) on the same host looking at things they shouldn’t, by users on other hosts listening to network traffic.  This is called packet sniffing.  To do this requires a NIC that supports promiscuous mode (sometime called debug mode).  In this mode the NIC will pass to an application all packets it sees, not just the ones addressed to it.  (Demo tcpdump.  Discuss sniffit, snort.)

To fix, make sure file permissions and umask setting are correct.  Remove un-used accounts.  To see which hosts have NICs in promiscuous mode use the ifstatus command.  Use switched Ethernet instead of hubs (discuss).

7.     Social Engineering is when a user is tricked into doing something a black hat couldn’t do alone.  A common example is to request userid, password, or creditcard information in a way that the user thinks is legitimite, say by popping up a window that states “You have been disconnected, enter your userid and password to continue”, or “login: read password: read login incorrect now run real login” and the user often thinks they just mistyped their password.  Another favorite is an attachment in an email with a name such as “claim-prize.com”.  This looks like a URL but is in fact a .com program that will run when you click on it.

The only solution is to not be fooled.  Continuous education and training of users is often a job of a system admin.

Spyware/Adware/Malware: BHO Demon for BHOs (plugins) in IE, Spybot Search & Destroy, Lavasoft Ad-aware

Other security tools and techniques:

Port knocking (fwknop): A series of packet connection requests to a specific series of (closed) ports define a secret knock that will unlock some port for the host doing the knocking.  the knock sequence may include different protocols (ICMP, UDP, TCP, various header attributes, and relative timings between knocks.  Note this may be more useful for rootkits to hide the backdoors they install.

http://www.cert.org, http://users.quadrunner.com/chuegen/smurf/, www.sans.org

Detailed security policy and procedures documents.  (These should be living documents, in the sense that they are frequently examined and updated.)

Monitoring (log files, resource use).  This can include using SNMP and RMON, ISS, SATAN, SAINT, COPS (Network Intrusion Detection Systems).

Use LDAP to centralize access control information (e.g., passwords).  Consider kerberos security too.  Use gpg to encrypt files and emails, and to verify downloaded files were not altered.  (See below.)

Use ssh to provide encrypted communications, VPNs (see freeS/WAN too).

Use PAM, correct permissions, limited use of SUID, liberal use of chroot, ..., to enforce security policies.

port scans (nmap host), nmapFE is GUI Front End to nmap

packet sniffing (tcpdump, snort, sniffit, snoop on Solaris):

tcpdump -X -s 0 ... # show contents of packets.
     tcpdump -e -t host ipaddr  # show headers of all packets to/from ipaddr.

Use lsof  to determine what files are open and what processes are using them.

Use ifstatus to determine what interfaces are in promiscuous (or debug) mode, often a sign of someone monitoring traffic to steal passwords or other valuable information.