Ports and Packets, Securing services in a Unix

Download Report

Transcript Ports and Packets, Securing services in a Unix

Ports and Packets
S E CU R ING S E R V I CES I N A U N I X -BAS ED E N V IR ONMENT
Zach Garcia
Overview
• Why Linux and not Windows?
• Why is this important?
• What are some things we can do to be more secure?
• Firewalling
• TCP Wrappers
• Port Knocking
• Mitigating weaknesses
• Conclusion
Why Linux and not Windows?
• Short answer: Most internet/web
services operate out of UNIX-based
environments
• Different approaches to client and
server security.
Why is this important?
• There is a lot of attack surface
• Various businesses and entities rely on web accessible
services
• There is a necessity for both accessibility and security
• Balance
• We don’t personally code everything we run
How can we be safe?
• Paid services
• Free/open-source software
• Experience
• Baseline procedures
• Customer precautions
Updating
• Pretty simple: stay up to date!
• Subscribe to vulnerability sites and social media
• Patch problems ASAP
• Backups
• Backups of backups
• Offsite backups of the backups of the backups…
Downloading updates…………………………………………………………………………………………………/
[76%]
Good security policies
• Know what you’re securing
• Who needs access?
• AV/ AV filtering
• Run light
Firewall
• Iptables
• Built into almost every recent Linux kernel.
• Fairly easy to manage
• Made up of “Chains” with different types and rules
• Rules can be made for one IP, many IPs, based on
connection state, port, TCP vs UDP, etc.
Firewall -- Set Default Behaviours
• Iptables --policy INPUT DROP
• Request timed out
• Iptables --policy OUTPUT ACCEPT
• Reply from *
• Iptables --policy FORWARD REJECT
• Destination not reachable
Iptables isn’t perfect
• Don’t keep logs on their own
• Can falsely reject if not careful
• Can falsely accept if not careful
• Accountability
Enter: The TCP Wrappers
• So close to being a firewall…
• Keep logs
• Fairly easy to make rules
• Requires programs are specially compiled against libwrap
• Broad rules
• Transparent to user for the most part
TCP wrapping isn’t perfect either
• Act upon data POST-entry
• VERY broad rules
Port Knocking
• Desired port is closed
• Packets are sent to a specific sequence of ports
• When the port-knocking software detects that the correct
sequence is entered, desired port opens for connections
• Pretty cool, huh?
• There are 65535 ports!
Sample Knockd Configuration
• [openSSH]
•
sequence
= 7000,8000,9000
•
seq_timeout = 5
•
command
•
tcpflags
= /sbin/iptables -I INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
= syn
• [closeSSH]
•
sequence
= 9000,8000,7000
•
seq_timeout = 5
•
command
•
tcpflags
= /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
= syn
Getting in and out of SSH
• To open SSH port
• for x in 7000 8000 9000; do nmap -Pn --host_timeout 201 --max-retries
0 -p $x 192.168.0.2; done
• To close the SSH port
• for x in 9000 8000 7000; do nmap -Pn --host_timeout 201 --max-retries
0 -p $x 192.168.0.2; done
• Or you can use a utility called knock ;)
The problem with port knocking
• Vulnerable to discovery by traffic analysis
• Not cryptographically sound
• Programmatically breaking in with port knocking alone is
easy, and just a little time consuming.
• Any port can be described with 16 bits. Or 2 bytes.
• That’s 2 ASCII characters. Or one Unicode character.
• Being that most people who use port knocking only use 3
ports, that means around 6 ASCII characters need to be
guessed, essentially.
So is there no way to be safe?
Conclusion:
• Layer security
• Maintain high security standards
• Watch logs
• Use log management software, automation, emailing, etc.
• Fail2Ban
• Be paranoid
Bibliography
• Hansteen, Peter N. "Why Not Use Port Knocking." That Grumpy BSD Guy. N.p., 11
Apr. 2012. Web. 20 Feb. 2015. <http://bsdly.blogspot.com/2012/04/why-not-useport-knocking.html>.
• "Web Server Survey." Security Space. E-Soft Inc., 1 Dec. 2012. Web. 20 Feb. 2015.
<https://secure1.securityspace.com/s_survey/data/201211/index.html>.
• "OS/Linux Distributions using Apache." Security Space. E-Soft Inc., 1 Dec. 2012.
Web. 20 Feb. 2015.
<https://secure1.securityspace.com/s_survey/data/man.201211/apacheos.html>