Infrastructure Machines: Difference between revisions

From JCWiki
Jump to navigation Jump to search
Line 103: Line 103:
This script will create <tt>/etc/firewall.sh</tt> which contains all the firewall and pipe rules in place at the time the script was run.
This script will create <tt>/etc/firewall.sh</tt> which contains all the firewall and pipe rules in place at the time the script was run.


== Doswatch ==
== DOS attacks ==
 
See [[FreeBSD_Reference#Handling_a_DoS_attack]] regarding how to handle a DOS attack.
 
Theres a background process (running from user shell) that monitors the firewall for incoming UDP DoS attacks. When it notices packets above a certain level it will
Theres a background process (running from user shell) that monitors the firewall for incoming UDP DoS attacks. When it notices packets above a certain level it will
# enter a rule that allows all UDP to go through
# enter a rule that allows all UDP to go through

Revision as of 17:06, 9 November 2012

firewall (newgateway)

Located at castle, this machine is the primary (only) firewall for the entire network at castle. It has 3 network connections (2 onboard, 1 PCI) connecting to the external, internal and private networks. If you're looking at the back of the server, the internal-network-facing nic is on the TODO, and the external-facing-network (3750) is on the TODO.

The server is running FreeBSD 4.11 x86, has a 36 GB (2 x 36GB) RAID1 array running on an Adaptec 2120S PCI RAID card. Both drives are hotswap. Server has dual-power supplies. Priv IP: 10.1.4.223, Pub IPs: 69.55.233.164 (external), 69.55.233.156 (internal).

Services Provided

  • firewall (ipfw)
  • snmp

Firewall Rule Configuration

See FreeBSD_Reference#Firewall_Rule_Configuration for more discussion on how to actually manipulate firewall rules.

Disaster Recovery

If there is ever an outage with the firewall, the old firewall "gate" is located just below and is running with the proper network configuration, but with no firewall rules in place (to facilitate good throughput). Have castle move the cable on the left on the current firewall to the left port in the old firewall and the right cable to the right port.

Here's what you need to put in /etc/rc.conf to get a firewall going (as far as routes and IPs)

hostname="newgateway.johncompanies.com"
firewall_script="/etc/firewall.sh"
firewall_enable="NO"
sendmail_enable="NONE"
sshd_enable="YES"
inetd_enable="NO"
xntpd_enable="YES"
snmpd_enable="YES"
#snmpd_flags="-as -p /var/run/snmpd.pid"
#ipnat_enable="YES"
#ipnat_rules="/etc/ipnat.rules"
gateway_enable="YES"

defaultrouter="69.55.233.161"

ifconfig_xl0="inet 10.1.4.223 netmask 255.255.255.0"
ifconfig_em0="inet 69.55.233.164 netmask 255.255.255.248"

#
# Original JohnCompanies 69.55.224.0/20
#
ifconfig_em1="inet 69.55.233.156 netmask 255.255.255.248"

static_routes="route1 route2 route3 route4 route5 route6 route7 route8 route9 route10 route11 route1
2 route13 route14 route15 route16 route17 route18"

route_route1="-net 69.55.224.0 69.55.233.153"
route_route2="-net 69.55.225.0 69.55.233.153"
route_route3="-net 69.55.226.0 69.55.233.153"
route_route4="-net 69.55.227.0 69.55.233.153"
route_route5="-net 69.55.228.0 69.55.233.153"
route_route6="-net 69.55.229.0 69.55.233.153"
route_route7="-net 69.55.230.0 69.55.233.153"
route_route8="-net 69.55.231.0 69.55.233.153"
route_route9="-net 69.55.232.0 69.55.233.153"
route_route10="-net 69.55.233.0 69.55.233.153"
route_route11="-net 69.55.234.0 69.55.233.153"
route_route12="-net 69.55.235.0 69.55.233.153"
route_route13="-net 69.55.236.0 69.55.233.153"
route_route14="-net 69.55.237.0 69.55.233.153"
route_route15="-net 69.55.238.0 69.55.233.153"
route_route16="-net 69.55.239.0 69.55.233.153"
route_route17="-net 10.1.5.0 10.1.4.2"
route_route18="-net 10.1.6.0 10.1.4.2"


#In case of 3750 failure:
#defaultrouter="69.43.128.81"
#ifconfig_em0="inet 69.43.129.84 netmask 255.255.255.248"

#bind .1's here:
#ifconfig_em1="inet 69.55.224.1 netmask 255.255.255.0"
#ifconfig_em1_alias0="inet 69.55.225.1 netmask 255.255.255.0"
#ifconfig_em1_alias1="inet 69.55.226.1 netmask 255.255.255.0"
#ifconfig_em1_alias2="inet 69.55.227.1 netmask 255.255.255.0"
#ifconfig_em1_alias3="inet 69.55.228.1 netmask 255.255.255.0"
#ifconfig_em1_alias4="inet 69.55.229.1 netmask 255.255.255.0"
#ifconfig_em1_alias5="inet 69.55.230.1 netmask 255.255.255.0"
#ifconfig_em1_alias6="inet 69.55.231.1 netmask 255.255.255.0"
#ifconfig_em1_alias7="inet 69.55.232.1 netmask 255.255.255.0"
#ifconfig_em1_alias8="inet 69.55.233.1 netmask 255.255.255.0"
#ifconfig_em1_alias9="inet 69.55.234.1 netmask 255.255.255.0"
#ifconfig_em1_alias10="inet 69.55.235.1 netmask 255.255.255.0"
#ifconfig_em1_alias11="inet 69.55.236.1 netmask 255.255.255.0"
#ifconfig_em1_alias12="inet 69.55.237.1 netmask 255.255.255.0"
#ifconfig_em1_alias13="inet 69.55.238.1 netmask 255.255.255.0"
#ifconfig_em1_alias14="inet 69.55.239.1 netmask 255.255.255.0"

#bulk:
# reassign 69.55.231.1 to the int iface on the firewall
# set the DG on the firewall to 69.43.138.9
# set the ext firewall IP to 69.43.138.12, NM: 255.255.255.248

Cronjobs

1 0 * * * /usr/local/etc/rsync.backup

Backup to backup1

0 0 1 * * /sbin/ipfw zero
0 0 1 * * /sbin/ipfw del 3  4 5 17331

Reset counters and remove pipe rules on the 1st of the month. Pay attention when setting up a rule as 3 4 5 (that's not a temporary traffic cap).

Inside /etc/daily.local you will see a call to /etc/makepiperules.pl This script will create /etc/firewall.sh which contains all the firewall and pipe rules in place at the time the script was run.

DOS attacks

See FreeBSD_Reference#Handling_a_DoS_attack regarding how to handle a DOS attack.

Theres a background process (running from user shell) that monitors the firewall for incoming UDP DoS attacks. When it notices packets above a certain level it will

  1. enter a rule that allows all UDP to go through
  2. send an emergency email to support and indicating an attack is in progress
  3. send an email to castle (nocstaff@castleaccess.com and jcsupport@castleaccess.com) telling them to investigate and put up a null if warranted
  4. wait for a couple minutes to see if the attack subsides- if so it will remove the pass-all UDP rule, if not it will repeat the process from #1

This file lives under /usr/home/user/doswatch.pl To run:

cd /usr/home/user
./doswatch.pl &

To kill;

fg
^C

It writes its findings to /usr/home/user/doswatch.log

backup1

Located at castle, this machine acts as the primary backup location for all VPS-based customers. No customer directly accesses this server to perform their backups. We also store cancelled customers on this server. It is running Ubuntu-Server 8.04 x86, and has a 4.5 TB (6 x 1TB) RAID5 array running on a 3ware 9650SE-8LPML (8-port) card. Its drives are hot-swap. Priv IP: 10.1.4.8, Pub IP: 69.55.230.11 (firewalled from all but JC infrastructure @ i2b)

Services provided

  • backup via rsync
  • mysql
  • nfs
  • snmp

Usage and Notes

  • all data is stored under /data
  • virtually all jc infrastructure, and all VPS machines are setup to mount to backup1 via nfs (mountpoint: /backup1), and they all have their ssh keys setup to allow passwordless rsync's
  • each virt or jail backs up each evening to backup1. Each server has it's own directory (named for the server). Under those directories are 7 daily snapshots (0-6)
  • at the time of writing, the mysql server running here is replicating from (slave to) the mysql instance on bwdb. Requests for bandwidth data usage for customers (coming from management, account manager, and accounting scripts running on mail) all direct towards the database "traffic" running on this server.
  • cancelled customer systems are compressed and stored under /data/deprecated
  • archived bwdb2 flow files are stored under /data/bwdb2
  • critical files from backup2 are stored under /data/backup2

Cronjobs

00 5 * * * /usr/local/sbin/backupwatch.pl 2>&1 > /dev/null
35 5 * * * /usr/local/sbin/usage_check; /usr/local/sbin/snapshot_archive; /usr/local/sbin/snapshot_rotate  /data/backuplog.log

this runs daily the scripts to report on how much disk space each customer system occupies and how long their backups took. Then it rotates backups for each system, removing the oldest backup.

10,25,40,55 * * * * /usr/local/sbin/processsql.pl

this processes prepared sql command files sent from/by bwdb2 (@ i2b) and imports them into the traffic database.

0 0 * * * /usr/local/sbin/3wraidchk

checks the health of the RAID array

Regular maintenance

backup2

Located at castle, this machine is used for archiving data and is a backup server for colo customers. It was the former primary backup location for all VPS-based customers before backup1 was installed. Only dedicated customers directly accesses this server to perform their backups. It is running FreeBSD 6.1 x86, and has the following arrays and controllers:

3ware 7500-8:

  • 200 GB JBOD (1 x 200G) labeled 0-0
  • 500 GB RAID5 (3 x 250G) 0-1 thru 0-3
  • 700 GB RAID5 (4 x 250G) 0-4 thru 0-7

3ware 7500-8:

  • 700 GB RAID5 (4 x 250G) 1-0 thru 1-3
  • 700 GB RAID5 (4 x 250G) 1-4 thru 1-7

All drives MUST be western digital IDE drives. Other brands will not fit. All are hot-swap. Priv IP: 10.1.4.3, Pub IP: 69.55.230.10 (firewalled from all but JC network at i2b and castle)

Services provided

  • backup via rsync and nfs
  • samba
  • nfs
  • snmp

Usage

  • all data is stored under 4 mount points, corresponding to the 4 large RAID5 arrays: /mnt/data1 /mnt/data2 /mnt/data3 /mnt/data4
  • iso images provided for customers wanting to mount an ISO as a CDROM via the IPKVM are provided via samba on this server. Images live under /mnt/data2/iso
  • this used to be our primary backup server so you will see old backups from virt and jails around- missing customer data though, just the machine's data
  • this server serves as an archive for exported db data from bwdb and old flow files.
  • isys backs up here
  • customers are nfs-moutned under /mnt/data3/customers as file-backed md devices
  • in /mnt/data4 there are lots of useful things used for building our vps servers, customer servers, and management scripts:
    • /bin: the master repository of scripts and custom binaries we use on jails and virts. Each night every virt and jail rsync's what's in here to update the local files. So any global updates to scripts would need to be made here (or will be overwritten with what's in here)
    • /build: files we use for setting up big brother, 3ware cli and scripts for colo's, vzcp customized setup files and so on
    • /vzrpms: contains the OS templates for many-to-most of the OS's we offer on vz systems

Cronjobs

  • backs itself up nightly to nfs-mounted backup1 (mountpoint: /backup2)

Regular maintenance