Security Best Practices: Servers and the Network
Results 1 to 2 of 2

Thread: Security Best Practices: Servers and the Network

  1. #1
    Senior Member
    Join Date
    Nov 2001
    Posts
    1,255

    Security Best Practices: Servers and the Network

    This thread is the direct descendant of the thread Security Best Practices: The Desktop.

    For the purposes of this discussion, assume the following:
    Setup A: Small mixed network of 10 Windows 2000 Pro desktops + Linux box w/Samba as a dc/file/print server.
    - Desktops run Windows 2000 Professional SP4, with Norton AntiVirus Corporate Edition configured to update defs every wednesday night at 6 PM, and to scan for viruses every day at 6 AM. Standard software includes Office 2000. The mail client is Outlook Express.
    - Mail services are provided by their ISP.
    - The Linux box also serves out an Apache webserver for staffers situated at staff.domain.com. The webserver only handles Basic auth over HTTPS, and is there only so staff can retrieve documents in their personal folders remotely. It has only the httpd and mod_ssl installed, no extra packages. Apache is 1.3.29
    - A firewall exists between the network and the internet (which is piped in via Business DSL). This is configured so that it only forwards port 443 (HTTPS) to the web server, and everything incoming connection is blocked. Desktops are permitted to surf and FTP and so forth.
    - There are three printers on the network: A LexMark Optra S series with NIC installed, and two HP LaserJet IIIs hooked up to two of the desktops.
    - Never been targeted for attack by a cracker/hacker.

    Setup B: Mid-sized contract developer's network of mixed operating systems. 10 Desktop developer boxes, and 14 servers.
    - 5 of the Developer boxes run Slackware 9.1, the other 5 run Windows XP Pro SP1a.
    - 4 of the servers are linux boxes dedicated to tasks other than development:
    - - One box is running OpenBSD 3.3 serving DHCP, DNS (internal), and acting as the firewall.
    - - - Firewall is configured to allow external access only via the web to the Slackware box housing webmail, and the two Windows servers dedicated to client app. testing, both on TCP/80 and TCP/443. Surfing is allowed similarly to the network above.
    - - Another is running Slackware 8.1 serves mail services only for a webmail client on the same box via Apache and PHP. This is the mail server, as well as doubling as the unix based production test site, where clients having web development done can login to their accounts and see notes from the developers about progress, as well as test the latest copy of the application.
    - - The third box is running Windows 2003 Server, serving out all ASP.NET web applications for clients in similar fashion to the second box.
    - - The fourth box is a Windows 2000 Server box, serving out domain services and file/print sharing.
    - The other 10 servers are
    - - 2 Windows 2003 Servers
    - - 3 Windows 2000 SP3 Servers
    - - 2 Linux Slackware 8.1 Servers
    - - 1 Linux RedHat 6.2 Server
    - - 2 Linux Debian 3.0 Servers
    - All servers are running on a mix of Pentium III/Pentium 4 servers from Dell, with the exception of the 2 Debian servers, which are running on completely new PowerPC 970 servers from IBM.
    - CVS is handled by one of the debian servers, which is still also a nix dev box.
    - There are two printers on the network: an Epson EPL6200 connected directly to the lan and shared by the Windows 2000 print sharing server, and a Lexmark Z22 Inkjet printer, which is hooked up to the print sharing server via USB.
    - Has been the target of a hack once before.
    - Note: The client app testing logins are handled via custom-designed software, which for the purposes of this excercise is impenetrable.

    The goal here is to provide advice and recommendations on how to secure this network, as well as any and all patching you might do. There is no budget to target here, as the goal is to make this as secure an environment as possible.
    Chris Shepherd
    The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
    \"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
    Is your whole family retarded, or did they just catch it from you?

  2. #2
    Senior Member
    Join Date
    Sep 2001
    Posts
    144
    splitting the servers into another network segment separating them from any workstations on the network and further separating web services, from internal services (FS/dc...), from development and sandbox systems.

    With IDS sensors on these segments with rulesets defined for each focusing on traffic that shouldn't exist such as.. there shouldn't be any network share browsing towards the e-mail server and no web traffic towards the DC (they are duel purpose machines).

    Along with strict firewalling between these segments, where only the required port/protocol's are passed to the appropriate systems. http and https only to systems that are supposed to offer http(s) to an external segment and such rules.

    These would apply to both setups.. allowing access to only what is supposed to be available, and raising flags on traffic that doesn't match the normal profile. As long as the services are kept up to date, and the flags are noticed, then this would allow for a decently secure network. But it would require active administration, not just a fix what's broken admin staff.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •