Tech/HowTo/Validating and Testing Your Firewall

Validating and Testing Your Linux Firewall

Quick overview, not too deep

Less technical topic for the whole group

We had a discussion at the Steering committee meeting about talks to keep everyone engaged. While speakers and topics are in demand the topics vary from deeply technical in one area to super deep. Does anyone have ideas for topics that interest them? Feel free to write it on the back of the sign in sheet any topics you really want to talk about or hear more about.

The term Firewall

• Automotive: isolate the driver from potential engine fire
• Architecture: Mitigate the spread of fire from building to building
• Hollywood: Magical unicorns tossed aside at will by verbally commanding
• Networking: Protection for poorly written services that can’t protect themselves
• Your family: Excuse for downloading that EXE to see if your last 2 minutes of work on their system made it bullet proof

Firewall types

At the various layers and stacks different firewalls might exist. You might limit access to SSH by having “Allowed” sources or limit access to a web page on Apache HTTPD by setting “Allow” and “Deny” settings in the application configuration. The Linux Kernel offers tools like routing and filters. Commonly the IPTABLEs tool is used to manage these filters. IPTABLEs is a large talk by itself. Stateful Firewall = Keeps track of connections (NAT)

Firewall Setup

Out of scope for this talk. Allow things in and out like a fly in the summer. You leave the door open and it gets in. You open a window and let it fly out. << Description you might give your family.

Application level filters are a burden to troubleshoot some times. The most common mistake with firewalls: Locking yourself out.

Input vs Output

Firewall Input vs Output is a very important context to understand. It can get confusing for some people but it is much like a conversation. Who started the conversation and what did they say. Your web browser makes an outbound connection to request a web page and is thus on the Output side of the Firewall. Don’t go too deep here, that is another talk.

TCP/UDP Ports

• Port range is 0-65536
• Don’t block Ephemeral ports 49152-65536
• Don’t host applications on Ephemeral ports 49152-65535
• man setcap

What makes a Port Open?

The common term of an Open Port means that there is a service/application that has requested a bind() so that it can listen on the port to accept input/inbound traffic. Often securing a system can be just a matter of limiting what is running on the system. A firewall is often incorrectly used to secure poor practices. Turning off unused services is both safer and easier to support. Do you need CUPS running on your webserver? A user can run python -m SimpleHTTPServer 1234 on a server, that is scary.

Local Discovery Services

Many services run an automatic discovery protocol to find like services on the wire. Some might use Multicast to find peers. This is very often a desktop or personal computer networking feature but should be kept in mind when configuring your network. Examples might be: ZeroConfig, IPv6, Printers, CIFS, Video over LAN

Fingerprinting

I may be to blame for this trend. The concept discussed about a decade ago.

• How does a system look over the wire when properly setup
• How does the system look over time, any changes?
• Honeypot on Vlan1

Local Testing

Netstat is your friend

• netstat -t for TCP ports
• netstat -u for UDP ports
• netstat -a for a great insight into how you system is really working.
• nmap -p 22 localhost (easier to show this off Andy)
• telnet localhost 22
• nc -zv localhost 22

Speed of scans

With thousands of ports speed is often an issue when scanning systems. Trust the software and follow the defaults as they are often the best. From nmap man page:

SYN scan is the default and most popular scan option for good reasons. It can be performed quickly, scanning thousands of ports per second on a fast network not hampered by restrictive firewalls.

Security Scanning

Tools like nmap and saint are built to scan large number of ports and systems. They are security scanners. Some commercial tools add fancy reporting. NIST is a good place to learn about security scanners.

Remote Testing

All of the non-netstat testing used in the Local Test examples.

Notes on Internet Etiquette

• Will you cause trouble
• Will you be locked out
• Will your ISP/Network Staff cut you off
• Could you accidently stop an entire office using the same gateway to be banned from a service.

Identifying Services

Many network services provide information about themselves. Your Internet browser for example will identify what it can or can’t do. Services like HTTP and SMTP often identify themselves and the examples before may have shared this.

• Exact version
• Determine OS + Update level
• Understand what is running on that port

Identifying Path Issues

In networking there is a path or route that any packet might take. When validating your firewall remotely always note that the path may pass routers or ISPs that limit rate, or ports that can be used. For example some coffee house might block SSH and when you test your firewall remotely it may falsely appear to be off.

Reporting

Actually reporting on the proper functionality of a firewall to non-technical people can be hard. When it comes to security it is very important to understand the scope of what you are reporting.

Monitoring

My favorite part is about how do you monitor a firewall. How do you monitor that you systems are staying secure. If a user has an account and runs a quick server to test something what happens.

Advanced Firewall Topics

• 2014-04-17 Fail2ban by Ken Johnson - SLUG talk
• Honeypot on VLAN1
• Dynamic Firewalls
• Port Knocking
• Port Triggering
• Persistent rules
  • apt install iptables-persistent
  • yum install iptables-save