My security primer - for peer review please

[johnsuth]

This system seems to work, but I will be grateful for your observations
and suggestions.

My Security Primer for school classroom.

Classroom internet access is for academic research, not entertainment and definitely not titillation.

HIERARCHY OF HARDWARE
WAN termination (campus boundary)
NAT router
Non-secure network
Bastion (multi-homed or spider PC router)
Secure classroom network(s) with no domain name service.
Win clients and IBM fileserver.

NAT ROUTER
Block of static IP addresses is reserved for Bastion non-secure gateway.
Routing table is unaware of secure networks.

BASTION SOFTWARE
NIC protocol is TCP/IP only.
TCP notebook defines gateways, and routes through them to LANs.
IP forwarding is off.
IBM firewall rules permit access to proxy.
Squid provides transparent HTTP and passive FTP proxy, ACL, cache, and DNS client.

IBM FIREWALL RULES
Deny through routing (redundant with IP forwarding off).
Deny fragmented packets.
Deny the usual suspects.
Permit requests to ISP DNS eq 53.
Permit requests to NIST servers eq 13.
Permit requests to http servers eq 80.
Permit requests to passive tcp servers eq 20, eq 21.
Permit pinging gateway by secure hosts eq 8.

SQUID ACL
Deny urlpath_regex -i "BlacklistFile" (file extensions & google search keys)
Allow dstdomain -i "WhitelistFile" (teacher approved domains)
Allow url_regex -i "UrlFile" (odds & ends)
Deny every dst

WIN CLIENTS
XP Home SP1.
NTFS.
Protocols TCP/IP, and Netbios for file & printer sharing.
Static IP address.
Students are Limited users (no password) with ACL restrictions.
Admin user has strong password.
Deinstalled Windows components include Windows Messenger, MSN Explorer.
Disabled services include Automatic updates, DHCP client, DNS client, ICF/ICS, IPSEC, Netmeeting, Portable media serial, Remote access, Remote desktop help, Routing and remote access, Secondary logon, SSDP, TCP/IP Netbios helper, Telephony, Wireless zero config.
Firefox proxy address is secure LAN gateway on Bastion.

 

[cquirke (MVP Windows shell/user)]

My Security Primer for school classroom.
Classroom internet access is for academic research, not entertainment and definitely not titillation.

WIN CLIENTS
XP Home SP1.
NTFS.
Protocols TCP/IP, and Netbios for file & printer sharing.
Static IP address.
Students are Limited users (no password) with ACL restrictions.
Admin user has strong password.
Deinstalled Windows components include Windows Messenger, MSN Explorer.
Disabled services include Automatic updates, DHCP client, DNS client, ICF/ICS,
IPSEC, Netmeeting, Portable media serial, Remote access, Remote desktop help,
Routing and remote access, Secondary logon, SSDP, TCP/IP Netbios helper,
Telephony, Wireless zero config.
Firefox proxy address is secure LAN gateway on Bastion.

OK. You'll probably need a way to automate the pushing of patches out
to the desktops, given they won't be pulling these from MS or from
your own patch server. As lead time between patch and exploit is
getting shorter and is sometimes negative, you may no longer have the
luxury of a day or few in-house testing before roll-out.

You're running File and Print Sharing, so I'd want to kill the hidden
admin shares if your network management strategies are compatible with
this. I'd share as little as possible, definitely no part of the
startup axis, and would consider a policy of no infectable code file
types permitted in these shares (sweep, remove and log offenders).

How are you managing sneakernet, i.e. USB sticks, 1.44M, CDR etc.?

Strong security is all very well, but most malware traction comes from
poor risk management, i.e. where the system does something stupid the
user had no intention of doing (clickless attacks) or the user takes
what is expected to be a small risk ("read a web page", "read an email
message", "read a document") and actually takes a larger one.

Choose settings and apps that at least show the user accurate risk
information, and as far as possible constrain the system and apps to
act only within this indicated risk. Where that is not possible, i.e.
you have an app that is known to mis-represent risk or act in risky
ways that exceed the displayed risk, then kill and replace those apps.

When the OS itself behaves in this way, well... do you know Linux well
enough to re-write the bits you don't like?

---------- ----- ---- --- -- - - - -

Gone to bloggery: http://cquirke.blogspot.com