Site Security: Recommendations Part 1
Introduction of John's laws
Site Security: Recommendations Part 2
What security at University of Oregon?
John's Laws #2
What security at other Universities?
Security Policies
Host Security: Risks, the Most Common Attacks
John's Laws #3
Host Security: Solutions for Buffer Overflow
Host Security: Solutions for Clear-text Passwords
Host Security: More Solutions
Host Security: System Integrity Solutions
Host Security: Other Solutions
Review: A Checklist for Securing your Linux Box
Checklist for Securing your Solaris Box
*********************************************** SITE SECURITY AND UNIX HOST SECURITY ***********************************************
Site Security: Recommendations Part 1
What you should try for, a short list
site security: use Firewalling
site security: use NAT private addressing
site security: block remote ICMP probes
host security: stop buffer overflows
host security: stop password-in-the-clear applications
host security: block remote TCP connections
Introduction of John's laws
John's Laws #1, "Security is not pretty."
Site Security: Recommendations Part 2
What you should try for, the long list
- use ISOLATED LANS for "high sensitivity" machines/groups/services
- use FIREWALLS for "medium sensitivity" machines/groups/services
- use DMZ for "low sensitivity" public machines/groups/services
- use NAT to conserve addresses and for "medium sensitivity" machines
- use IP-SPOOFING access lists
- use SWITCHES instead of hubs
- use EAVESDROP PREVENTION on hubs
- use ICMP blocking
- use VPNS for secure remote access
- run VULNERABILITY SCANNERS to detect weaknesses
- run INTRUSTION DETECTION to log intrusions
- run SSH
- turn off UNUSED DAEMONS
- run BUFFER OVERFLOW prevention
- run CRACK to test password vulnerability
- run SYSLOG for centralized logging
- run BACKUPS
- run VIRUS DETECTION software on all pc's
- make a SECURITY MAILING LIST
- make a SECURITY POLICY GROUP
- make a SECURITY RESPONSE TEAM
- develop RELATIONSHIPS with law enforcement
- develop RELATIONSHIPS with other organizations
- develop a SECURITY POLICY
What security at University of Oregon?
- switches everywhere
- hub eavesdrop prevention in dormitories
- IP-address spoofing blocked at the border router
- IP-address net-directed broadcasts blocked on subnets
- network monitoring, router "flows"
- network monitoring, remote packet header logging
- network monitoring, ethernet-switchport tracking
- SSH on all major systems
- SSH on student PC software distribution
- PC Netscape 128-bit SSL on PC software distribution
- PC Anti-Virus software site license
- anti-relay on sendmail (SPAM, not really security)
- internal security mailing lists
- relationships with local/state/federal law enforcement
- acceptable use policy is everywhere
- very tough on local policy enforcement
John's Laws #2
"There are 2 kinds of people--
those who are un-happy, and
those who have firewalls."
What security at other Universities?
- FIREWALLS
- NAT Addressing
- Centralized Control
- VPNs
- VLANs
- Site Intrustion Detection
- Site Vulnerability Scanning
- Site Security Policy
- Software Installation Teams
- Security Evalution Teams
- Security Response Teams
- Network Security Officer
Security Policies
"Practical Unix and Internet Security", Chapter 2, "Policies and Guidelines"
"Building Internet Firewalls", Chapter 3, Security Strategies
"Building Internet Firewalls", Chapter 11, Security Policies
- developing a security policy
- what are you trying to protect?
- who do you trust?
- what benefits do you want to achieve?
- what costs are you willing to afford?
- who can make the decisions?
- who can implement the policy?
************************ HOST SECURITY ************************
Host Security: Risks, the Most Common Attacks
- subscribe to BugTraq, "Be afraid! Be very afraid!"
BUGTRAQ http://www.securityfocus.com/
mailto:LISTSERV@SECURITYFOCUS.COM
SUBSCRIBE BUGTRAQ
- buffer overflow (#1 by far, many per week)
Microsoft IIS
portmapper->statd
- passwords in the clear (#2 by far, sniffers always installed)
telnet
ftp
- PC Word Macro Virus
Melissa
Chernobyl
- password cracking
Unix "crack" dictionaries
the DES cracking machine
"NTcrack"
- too many daemons, default installations
RedHat default installation
Solaris default installation
NT default installation
- denial of service (D.O.S.)
Ping-of-Death
icmp packets in odd sizes/formats
SMURF attack
use net-directed-broadcast as spoofed icmp src/dest/both
http://netscan.org/papasmurf.c
http://netscan.org/broadcast/index.html
FRAGGLE attack
use net-directed-broadcast as spoofed udp src/dest/both
uses "udp echo" instead of "icmp reply"
SYN flooding
flood to use up all of the socket resources
- invasion of privacy
NFS
e-mail
- user accounts
too many users, > 1 = danger
too many uneducation users
John's Laws #3
"Host Security is not enough
(if you have a lot of hosts)."
Host Security: Solutions for Buffer Overflow
- on solaris, "no_exec" user stack
http://ns.uoregon.edu/security/
add these lines to /etc/system:
set noexec_user_stack = 1
set noexec_user_stack_log = 1
- on linux, "secure-linux", similar to above
http://www.openwall.com/linux/ ( demonstrate make xconfig, show options)
patch kernel
make xconfig, enable security options
install kernel
- or "stackguard", a full Redhat 5.1 distribution
http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
make CD from image
install from CD
- NFS "statd" is a primary target
- "imapd" also frequent targets
- "popd" also frequent targets
Host Security: Solutions for Clear-text Passwords
- use SSH, not telnet
ftp://ftp.cs.hut.fi/pub/ssh/
- use SSH SCP or sftp, not ftp
- use /etc/shadow passwords, MD5 passwords
- try to "crack" your own passwords
ftp://coast.cs.purdue.edu/pub/tools/unix/crack/
ftp://coast.cs.purdue.edu/pub/tools/unix/cracklib/
Host Security: More Solutions
- turn off those DAEMONS! ( demonstrate )
- TCP WRAPPER those DAEMONS! ( demonstrate )
ftp://coast.cs.purdue.edu/pub/tools/unix/tcp_wrappers
- sendmail as "send-only" ( demonstrate )
- run packet filtering
ipchains -p ICMP ( demonstrate )
- run SYN connection filtering
ipchains -p TCP -y ( demonstrate )
Host Security: System Integrity Solutions
- system integrity checking, fcheck or Tripwire
http://sites.netscape.net/fcheck/
ftp://coast.cs.purdue.edu/pub/tools/unix/Tripwire/
- system integrity using basic Unix commands:
find, xargs, ls, md5sum, sdiff
1. ckperms -- check mos
t file permissions
2. cksums -- check most
file checksums
3. ckdiffs -- compare m
ost recent run of both of above
Host Security: Other Solutions
- use NAT or IP MASQUERADE
- block IP-SPOOFING (firewall at the border)
- block known D.O.S. (firewall at the border)
- syslogging, locally or centralized
- backup
- patch known vulnerabilities
- PGP for e-mail
- SSL for WWW
- one man, one vote, one machine ( no untrusted users )
Review: A Checklist for Securing your Linux Box
- see http://ns.uoregon.edu/security/linux.html
Checklist for Securing your Solaris Box
- see http://ns.uoregon.edu/security
---