After successfully setting up a base Linux server in the cloud using the Base ServerTemplate for Linux Tutorial, you may need to perform the following common administrative operations.
For more information on iptables, refer to Linux documentation.
Common Operational Tasks
Add or Remove a Firewall Rule
When iptables is enabled, which is the default behavior in all Linux-based v13 ServerTemplates, TCP ports 22, 80, and 443 are configured to be open to any IP address in order to enable minimum functionality and access. If you want to add or remove a firewall rule on a running (operational) server by opening or closing a port, you can set the following inputs accordingly and run the sys_firewall::setup_rule operational script.
If you want the firewall rules to be set at boot time, you can either add the Chef recipe to the end of the boot script list or update the sys_firewall::default recipe to change the list of default firewall permissions by explicitly opening up additional ports. However, you should only consider overriding the default recipe if you want to change the default behavior for all of your servers that use that cookbook.
If the cloud provider supports security groups, you must also open or close the appropriate ports in the security group resource.
- Go to the current server's Inputs tab and set the following inputs accordingly.
|Input Name||Description||Example Value|
|Firewall Rule Port||Specify the port number to open or close.||text: 8080|
|Firewall Rule||Defines whether you are creating or removing a firewall permission for the specified port (Firewall Rule Port) over the specified IP protocol (Firewall Rule Protocol), as restricted by the specified IP range (Firewall Rule IP Address).
* enable (default) - Enable access by adding a firewall permission that allows (ingress) access.
* disable - Disable access by removing an existing firewall permission.
|Firewall Rule IP Address||Use CIDR notation to define the range of IP addresses that will either be allowed or denied access to the specified port (Firewall Rule Port) over the specified IP protocol (Firewall Rule Protocol). Leave this value set to
any(default) to allow access from any IP address (0.0.0.0/0). Use an exclamation point (!) before the IP address specification to deny access (i.e.
blacklist) from a specific IP address (e.g. !184.108.40.206) or IP range (e.g. !220.127.116.11/24)
|Firewall Rule Protocol||Specify the Internet protocol for the specified port (Firewall Rule Port).
* tcp (default)
- Run the sys\firewall::setup\rule operational script to add the firewall permission to the running server(s).
List Current Firewall Rules
For troubleshooting and security purposes, you may want to list a server's current firewall rules to make sure that a server has the expected IP/port permissions. This script is especially useful if you want to check the firewall rules across all servers in a deployment to validate that all of them have the same iptables rules.
- Go to the running server's Scripts tab and run the sys_firewall::do_list_rules operational script.
- Go to the server's Audit Entries tab to view the output. The output will look similar to the following example.
22:25:03: ==================== do_list_rules : Firewall rules Begin ================== Chain INPUT (policy ACCEPT) target prot opt source destination FWR all -- 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain FWR (1 references) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 ACCEPT tcp -- 10.123.456.22 0.0.0.0/0 tcp dpt:8000 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x16/0x02 reject-with icmp-port-unreachable REJECT udp -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable ==================== do_list_rules : Firewall rules End ====================
If you want to perform the same action via SSH, follow the steps below.
- SSH into the running server. (Requires 'server_login' user role privileges.)
Switch to the 'root' user. Note: When using newer images (>5.8/13.4), ensure that you have the 'server_superuser' permission to the RightScale account where the server is running in order to gain root privileges using the sudo command (Settings > Account Settings > Users).
# sudo -i
Type the following Unix command.
# /sbin/iptables -L
Enable or Disable Iptables
Iptables is typically enabled by default ('Firewall' = enabled). However, you can use the following script to enable or disable Iptables on an instance.
You should only perform this action if you fully understand its implications. For example, if the cloud provider does not support cloud-level firewall services such as security groups, you could permanently lock yourself out of the instance if you disable Iptables.
To enable Iptables, follow the steps below.
- Set the 'Firewall' input to 'enabled'.
- Run the sys_firewall::default (boot script).
To disable Iptables, follow the steps below.
- Set the ' Firewall' input to 'disabled'.
- Run the sys_firewall::default (boot script).
Enable or Disable System Security Updates
Typically, ServerTemplates are configured with frozen software repositories that are locked down to a specific date to ensure that the same versions of software and packages are installed on a server at launch time. You also have the option to configure the server so that you can easily apply security patches from one of the related system software repositories as they become available. (Currently, only the Epel and Ubuntu Precise (v12.04) repositories are checked for security updates.) System security updates are disabled by default at the ServerTemplate level, as defined by the 'Enable security updates' input. As a best practice, you should determine whether or not you want to reserve the ability to apply security updates as an operational script before you launch the server. Changing this setting after a server is operational is not recommended.
To enable security updates, follow the steps below.
Once security updates are enabled, they cannot be disabled.
- Set 'Enable security updates' input to 'enable' at the deployment level, or at the (next) server level if you do not want this change to be applied to all future servers launched in the deployment.
- Launch or relaunch the server, if possible. Otherwise, you must update the input setting under the current server's Inputs tab and run the rightscale::setup_security_updates boot script.
Apply System Security Updates
If the server is enabled for system security updates (Enable security updates = enable), a server tag will be added to the server when a security update becomes available (
rs_monitoring:security_updates_available=true). By default, a triggered alert sends an email notification to the account owner as a reminder that a security update is available on a particular server. If a security update is available, follow the steps below to download and apply the security update.
- Check to make sure that a security update is available. All effected servers will have the following server tag: rs_monitoring:security_updates_available=true
- Run the rightscale::do_security_updates operational script. You can either apply the update on a per server basis under the
currentserver's Scripts tab. However, if you want to apply the update to some or all servers in a deployment, run the script at the deployment level instead (under the deployment's Scripts tab).
- A reboot may be required to apply the security update. If you see the following reboot tag on the server (
rs_monitoring:reboot_required=true), you must manually reboot the server at your convenience (View Server > More Actions > Reboot) to complete the security update.