= Installation instructions =

IMPORTANT!!! Do not plug the power cable in until step 5. If you plug the power in before connecting the management network cable, then the IPMI module will not initialize properly and remote management/KVM will not work.

Before you begin, please make sure you have met the [http://www.reddnet.org/mwiki/index.php/REDDNet_Site_Requirements basic site requirements]

[[image:2010-depot-back.jpeg|thumb|480px|Back of depot]]

# Unpack the machine, install the rails, and mount in your rack as you normally would.
# Plug in an ethernet cable to the management port.
# Plug in an appropriate network cables to the data ports (depends on whether you are using 10 Gb or 1 Gb)
# Plug in the REDDNet USB key into a free USB port. It is recommended to plug the key into the external USB port on the back. However, if you cannot for whatever reason, there are two USB ports inside the chassis on the motherboard.
# Plug in the two power cables.
# Turn on depot.

[[image:2010-depot-motherboard-usb.jpg|thumb|480px|Motherboard with onboard USB ports highlighted]]

= Configuring the depot for remote management =

You will need to log into the BIOS on the depot and set up the remote IPMI function so we can administer it.

# Power on the depot.
# Hit the "Del" button during boot to get to the BIOS
# Push the right arrow button to tabe to the "Advanced" setting
# Scroll down to "IPMI Configuration" and hit "Enter"
# Scroll down to "Set LAN Configuration" and hit "Enter"
# Select DHCP or Static IP addresses depending on which you will be using
# If you use static IP's enter the IP address, subnet mask, and gateway address for the management port
# Take note of the IP address for this box. We will need it so we can log into it.
# Hit "Esc" twice to return you to the main BIOS screen.
# Click on "Exit", then "Save Changes and Exit"
# Finally, please email the IP address to REDDNet staff.

2010-03-30T21:01:37Z

Wikiadmin: Created page with '==Security overview== REDDNet's current security plan maintains a level of security that balances security requirements with the service and academic freedom our users expect. …'

==Security overview==

REDDNet's current security plan maintains a level of security that balances security requirements with the service and academic freedom our users expect. We are capable of enforcing stricter security measures than those outlined in this document should a specific need arise.

==Security contacts==

{|
!style="background:#000000;color:#ff8888"|Role
!style="background:#000000;color:#ff8888"|Name
!style="background:#000000;color:#ff8888"|Email
!style="background:#000000;color:#ff8888"|Phone
|-
|Primary
|Mathew Binkley
|Mathew.Binkley@vanderbilt.edu
|Phone: (615) 322-5857
|-
|Secondary
|Alan Tackett
|Alan.Tackett@accre.vanderbilt.edu
|Phone: (615) 322-1028
|}

==Data Encryption==

L-Store is currently under development. At the moment, data is not encrypted in transit or in storage. If the user desires, they may use common encryption tools such as OpenSSL or GnuPG to encrypt their data before uploading.

Cursory work on an OpenSSL-encrypted upload/download has been done, but is not yet ready for public consumption.

==Data Integrity==

When the client uploads a file to the depots, it computes a MD5 hash of the file and stores that information in the metadata on the server. Downloaded files can be hashed and compared with the stored value to verify integrity (though this is not yet automated).

We intended to make the choice of hash user-selectable in the future. We intend to support SHA-1, SHA-256, SHA-512 hashes, and other hashes supported by the base SSL library.

==Data Redundancy==

Data stored on depots is encoded with RAID 5 redundancy. The user may specify this redundancy across hard drives, across depots, and/or across sites. REDDNet monitors depots for drive failures using Nagios, and if a loss of redundancy is detected we correct the error on our end.

In addition, we are working on a generalized Reed-Solomon code that will allow users to specify an arbitrary amount of redundancy. For example, you could have 10 drives and have 4 of them fail before you lost redundancy. We expect this generalized redundancy code to be completed in summer 2010.

==Access Permissions==

We implement a generic policy framework that allows for custom security policies (role-based, Unix ACL and permissions).

REDDnet Remote Site Security Overview

2010-03-30T20:58:57Z

==Security overview==

REDDNet's current security plan maintains a level of security that balances security requirements with the service and academic freedom our users expect. We are capable of enforcing stricter security measures than those outlined in this document should a specific need arise.

==Security contacts==

{|
!style="background:#000000;color:#ff8888"|Role
!style="background:#000000;color:#ff8888"|Name
!style="background:#000000;color:#ff8888"|Email
!style="background:#000000;color:#ff8888"|Phone
|-
|Primary
|Mathew Binkley
|Mathew.Binkley@vanderbilt.edu
|Phone: (615) 322-5857
|-
|Secondary
|Alan Tackett
|Alan.Tackett@accre.vanderbilt.edu
|Phone: (615) 322-1028
|}

==Physical security==

Locations at remote sites depend on user requirements. It is strongly suggested that access to the room be restricted by key, pass card, or another token. The room should not be accessible to the general public. Only administrative and technical contacts as defined in the MoU will be granted restricted login rights to the depots for maintenance purposes.

==Network security==

Remote depots require several network ports open to either Vanderbilt or the world for proper functioning and monitoring. A list of required ports may be found at:

http://www.reddnet.org/mwiki/index.php/REDDNet_Site_Requirements

Remote sites must ensure that these ports are open as described, both at a departmental level and at your organization's perimeter firewall.

Remote depots will have an IPTables firewall to limit connections by port and by source/destination to only those required for operation. This will be maintained by REDDNet staff.

==OS security==

REDDNet monitors CERT, CryptoGram, and other security forums daily for new security errata. We use apt-get to keep all depots up-to-date with security fixes at least once a week (and usually every 1-2 days). All machines are updated as soon as Ubuntu/Debian releases a security update.

When critical vulnerabilities are discovered, we may disable services or install our own custom update until such time as the vendor releases their own update.

==Application security==

Due to firewall restrictions we cannot perform Nessus scans of remote depots. We encourage local sites (either departmentally or globally) to perform their own regular Nessus scans on remote depots. When a weakness is discovered at any depot, REDDNet staff will propagate the fix to all other depots.

REDDnet Vanderbilt Security Overview

2010-03-30T20:56:21Z

Wikiadmin:

==Security overview==

REDDNet's current security plan maintains a level of security that balances security requirements with the service and academic freedom our users expect. We are capable of enforcing stricter security measures than those outlined in this document should a specific need arise.

==Security contacts==

{|
!style="background:#000000;color:#ff8888"|Role
!style="background:#000000;color:#ff8888"|Name
!style="background:#000000;color:#ff8888"|Email
!style="background:#000000;color:#ff8888"|Phone
|-
|Primary
|Mathew Binkley
|Mathew.Binkley@vanderbilt.edu
|Phone: (615) 322-5857
|-
|Secondary
|Alan Tackett
|Alan.Tackett@accre.vanderbilt.edu
|Phone: (615) 322-1028
|}

==Physical security==

Core REDDNet hardware at Vanderbilt University is located in Vanderbilt's Network Operations Center (NOC). The NOC command center is staffed 24/7/365 by VU's Information Technology Services (ITS) staff. The facility is secured by card access and access is limited to ITS, VU Management Information Systems staff, and owners of the systems housed in the NOC. All visitors to the NOC must sign in and are under constant video surveillance while inside.

==Network security==

REDDNet core equipment is secured by a FreeBSD firewall operating as a transparent bridge. As a transparent bridge, the firewall does not have an IP address, and is not detectable from the outside world. All off-campus access is logged to aid in forensic analysis should that proves necessary.

All Vanderbilt core equipment also has IPTables firewalls. Rulesets on both local IPTables and the primary FreeBSD firewall are kept in sync to allow them to perform failover security if one layer should be down.
Network traffic is limited by port and by source/destination to only those necessary for proper functioning and monitoring. A complete list of ports opened may be found at:

http://www.reddnet.org/mwiki/index.php/REDDNet_Site_Requirements

==OS security==

REDDNet monitors CERT, CryptoGram, and other security forums daily for new security errata. We use apt-get to keep all Vanderbilt core hardware up-to-date with security fixes at least once a week (and usually every 1-2 days). All machines are updated as soon as Ubuntu/Debian releases a security update.

When critical vulnerabilities are discovered, we may disable services or install our own custom update until such time as the vendor releases their own update.

==Application security==

All REDDNet core infrastructure and storage depots are scanned monthly using Nessus to search for potential exploits. Hardware and services are monitored via Nagios and SNMP.

REDDnet Vanderbilt Security Overview

2010-03-30T20:55:54Z

Wikiadmin:

==Security overview==

REDDNet's current security plan maintains a level of security that balances security requirements with the service and academic freedom our users expect. We are capable of enforcing stricter security measures than those outlined in this document should a specific need arise.

==Security contacts==

{|
!Role
!Name
!Email
!Phone
|-
|Primary
|Mathew Binkley
|Mathew.Binkley@vanderbilt.edu
|Phone: (615) 322-5857
|-
|Secondary
|Alan Tackett
|Alan.Tackett@accre.vanderbilt.edu
|Phone: (615) 322-1028
|}

==Physical security==

Core REDDNet hardware at Vanderbilt University is located in Vanderbilt's Network Operations Center (NOC). The NOC command center is staffed 24/7/365 by VU's Information Technology Services (ITS) staff. The facility is secured by card access and access is limited to ITS, VU Management Information Systems staff, and owners of the systems housed in the NOC. All visitors to the NOC must sign in and are under constant video surveillance while inside.

==Network security==

REDDNet core equipment is secured by a FreeBSD firewall operating as a transparent bridge. As a transparent bridge, the firewall does not have an IP address, and is not detectable from the outside world. All off-campus access is logged to aid in forensic analysis should that proves necessary.

All Vanderbilt core equipment also has IPTables firewalls. Rulesets on both local IPTables and the primary FreeBSD firewall are kept in sync to allow them to perform failover security if one layer should be down.
Network traffic is limited by port and by source/destination to only those necessary for proper functioning and monitoring. A complete list of ports opened may be found at:

http://www.reddnet.org/mwiki/index.php/REDDNet_Site_Requirements

==OS security==

REDDNet monitors CERT, CryptoGram, and other security forums daily for new security errata. We use apt-get to keep all Vanderbilt core hardware up-to-date with security fixes at least once a week (and usually every 1-2 days). All machines are updated as soon as Ubuntu/Debian releases a security update.

When critical vulnerabilities are discovered, we may disable services or install our own custom update until such time as the vendor releases their own update.

==Application security==

All REDDNet core infrastructure and storage depots are scanned monthly using Nessus to search for potential exploits. Hardware and services are monitored via Nagios and SNMP.

2010-03-04T20:44:32Z

Wikiadmin:

=== Depots ===

Our standard depot contains one dual-core AMD Athlon CPU, 4 GB of RAM, two 1 Gb network ports, and 4-8 TB of storage space. The standard depot draws approximately 300 W.

We are evaluating a new depot configuration with one 8-core Intel I7, 12 GB of RAM, two 1 Gb network ports, and 23 TB of storage space. This depot may optionally connect to the network via 10 Gb ethernet (via an add-on adapter). We will provide power requirements for this box at a later date.

=== Network Ports on your Switch ===

Each depot has two network interfaces, so if supported by your switch, we would like to use both interfaces in 802.3ad bonding mode for increased performance. This requires two switch ports and two ethernet cables per depot.

If not supported, then each depot only requires one port/cable.

=== IP Addresses ===

We require one externally-visible IP address for each depot, PDU, or KVM.

=== Remote PDU ===

We provide an APC PDU unit for every 4 depots. This allows us to power-cycle a hard-locked machine and do other forms of maintenance that aren't possible using the KVM alone.

Each PDU requires a 110 V power connection and a network connection with either static or DHCP-issued IP address.

=== Remote KVM ===

We provide a KVM unit for every 8 depots to allow us to manage the depot remotely. The KVM requires a 110 V power connection (usually supplied by one of our PDU units) as well as a network connection with a externally-visible IP address.

=== Required Network Ports ===

These ports should be opened on your perimeter firewall (or firewalls if you have both organizational and departmental firewalls).

* tcp/22 (ssh) : from all local depots/PDUs to 129.59.197.60 and 129.59.197.90
* tcp/5666 (nagios) : from all local depots to 129.59.197.60 and 129.59.197.90
* tcp/6714 (ibp) : from all local depots to world
* tcp/4823 (bwctl) : from 1st local depot to world
* tcp/861 (owamp) : from 2nd local depot to world
* tcp/80 (http) : from KVM and PDU's to 129.59/16
* tcp/443 (https) : from KVM to 129.59/16
* tcp/21 (ftp) : from PDU's to 129.59.197.90 (for firmware upgrades)
* tcp/5900 (vnc) : from KVM to 129.59/16
* udp/123 (ntp) : allow outbound from local depots
* udp/161 (snmpv3) : from all to 129.59.197.60 and 129.59.197.90