Blog

Friday, July 11, 2014

WordPress Hardening Guide

WordPress is a great blog platform but like anything popular, it’s often targeted by hackers hence hardening your WordPress deployment is mandatory. Getting your WordPress site hacked can be very stressful and a potentially expensive problem.  It’s akin to getting your *insert something important here* stolen.  This is especially true if your WordPress site is critical to your online presence as downtime can destroy the traffic you’ve garnered not to mention it can hurt your website’s reputation.

NOTE: WordPress hardening is an intermediate to expert task.

This guide assumes you or your web host have already secured the server computer itself.  If this has not yet been done or you aren’t sure, then you should do it first or ask your web host to do it for you as your WordPress could still be hacked if your server is insecure. Search Google for guides like “hardening linux” and “securing /tmp”. Also check out SELinux, CSF and LFD. wordpress.org also publish an extensive hardening guide.

Step 1: Changing the WordPress Database Table Names

This one can be difficult to do but it is the absolute most critical.  By default, WordPress prefixes all its database tables “wp_”.  Changing the table prefix to a random string makes it difficult if not impossible for a hacker to execute remote SQL injection attacks.

Go to the random.org to generate a random database table prefix. If you haven’t installed WordPress yet, then during installation you can change the table prefix to the random string you generated previously.  Make sure you add an underscore ( _ )  after the string so your tables are easier to read.

If you have already installed Wordpress, then you will need to edit wp-config.php and enter the new database prefix.  Then export the entire database and using a text editor, replace the prefix of every table to the random string you generated above. Again, make sure you add an underscore ( _ )  after the string so your tables are easier to read.

Table names are stored in the CREATE TABLE `NAMEHERE` or CREATE TABLE IF NOT EXISTS `NAMEHERE` lines. After you do the edits to the exported database, you will need to drop the WordPress database on your web host and import your edited database.

Step 2: Update Your WordPress, Plugins and Themes

Keeping your WordPress, Plugins and Themes up to date is the single most critical thing you can do.  Exploits are discovered daily and if you leave your WordPress running an older version, you risk getting hacked. To update WordPress, login to the Dashboard and on the right hand side look for "Updates".

Step 3: Secure Your Plugins

Since plugins add new functionality, they can also add functionality you don’t want such as backdoors.  Before installing ANY plugin, do the following:

  1. Search the exploit databases such as Secunia and Exploit-DB to see if there's any security advisories for the plugin.  If there are, make sure they aren't for the current version.
  2. Check if the plugin is compatible with the current version of WordPress.
  3. Check how many support requests have been solved in the past few months. If it’s a low number (less than 50%), then look in the support forum to see what questions people were asking.  Plugins with poor or no support tend to not get updated often so avoid them if you can.
  4. Only if 1, 2 and 3 are OK then can the plugin be installed.

Here's a few plugins that should be avoided as they increase the attack surface of WordPress or are just generally malicious:

Additionally, if you have any plugins that are disabled and you don't intend to use them then delete them.

Step 4: Choosing a complex password

It is critical that you choose a complex and hard to guess password.  Choosing an easy to guess password makes as much sense as leaving your front door unlocked in a neighbourhood with lots of crime. If you must insist on using an easy to remember password then add a few symbols to it.  For example replace the letter S with a dollar ($) symbol, the letter O with a zero (0), the letter I with an exclamation point (!).  You should have at least 2 symbols and 1 number in your password and it should be at least 12 characters long (to increase entropy and make it even harder to guess or brute force).  If you still aren’t able to remember your password, then get a password manager application like KeePass or Any Password. Try and avoid browser based or browser integrated password managers as browser highjacking is common.  When using a password manager, use the random password feature with symbols.  The password will be impossible for you to remember, but it will also be very very difficult for hackers to guess.

Step 5: Folder and File Permissions

Using your FTP program or the command line (if you have access to it), chmod the permissions of all folders and files.  This is critical for security and while it is a long and boring process, you need to do it.

All directories should be 750 or if they require write access, then 755. All files should be 644. Exception: wp-config.php should be 600 to prevent other users on the server from reading it. File and group ownership (UID and GID) should be ideally set to what the webserver itself requires (eg. apache.apache).

Most FTP applications allow you to change the permissions of a folder and file simply by right click the object and selecting CHMOD, Attributes, Permissions or something similar.  Read the help file that came with your FTP application for more information.  If you’re using the command line, then use the following command:  chmod ### <folder or file name>

So for example let’s say you were chmod’ing the wp-admin directory which is located in /home/yoursite/wordpress/public_html, the commands would look like:

cd /home/yoursite/wordpress/public_html
chmod 750 wp-admin

Everytime you install a new plugin or theme; you will need to set the folder and file permissions for those new folders and files accordingly.

Step 6: Securing wp-config.php

Move wp-config.php outside of the web directory (eg. one directory up).  WordPress knows to look for the file in other directories if it can't find it in the web directory.

For extra security, add the following to wp-config.php:

define('DISALLOW_FILE_EDIT',true);

Choose new authentication keys and replace the old keys in wp-config.php with the new ones you generated.

Step 7: Securing Themes

Put the following in your theme’s function.php file:

add_filter('login_errors', create_function('$a', "return null;"));
remove_action('wp_head', 'wp_generator');

Search your theme's header file for the following and delete it:

<meta name="generator" content="WordPress <?php bloginfo('version'); ?>" />

If you have any themes that are not being used or are disabled, then delete them.

Step 8: Recommended Security Enhancing Plugins

The following plugins will enhance security and should be installed and configured:

For more information on securing and hardening WordPress please consult the extensive and comprehensive hardening guide over at wordpress.org.

Tuesday, July 08, 2014

Starting Interactive FireDaemon Services In Session via Automatic Logon and Scheduled Tasks

This article provides an alternate method of starting Interactive Windows Services under FireDaemon control in the currently logged in session. In our previous article we discussed how to do this using logon scripts. In this article we discuss how to automate your Windows login and run interactive services using Scheduled Tasks.

Step 1: Install FireDaemon Pro and Setup Your Services This is fairly straight forward:

  1. Download and install FireDaemon Pro
  2. Create your FireDaemon services. Ensure they are set to Manual Start and they are running as the LocalSystem account (ie. don't specify a user in your configuration). Check out our HOWTOs if you need a guidance setting up your app under FireDaemon control.

Step 2: Setup Automatic Login You now want to set automatic login for user you want to run your services as. To do this on Windows 7:

  1. Run netplwiz.exe
  2. Uncheck "Users must enter a username and password to use this computer" then click OK
  3. Supply the autologin username and password. If you want to use a domain user account see this article.
Step 3: Create a Schedule You now need to create a scheduled to auto elevate FireDaemon the starting of your services:
    1. Create a new Task (not a Basic Task) with the following attributes:
    2. Run shed.exe (Windows 7) or taskschd.msc /s (Windows 8). Then in the
      • General Tab
        • Name: FireDaemonServices
        • Check: Run only when user is logged on
        • Check: Run with highest privileges
        • Check: Hidden
        • Configure for: Windows 7, Windows Server 2008 R2 (change this to suite your app and version of Windows)
      • Actions Tab (add an action for each service to be elevated - click the New button. Replace ServiceA with the actual short name of your service)
        • Action: Start a Program
        • Settings / Program/Script: "C:\Program Files\FireDaemon\firedaemon.exe"
        • Settings / Add Arguments:  --start ServiceA --in-session
      • Conditions Tab
        • Uncheck Start the task only if the computer is on AC power
      • Settings Tab
        • Uncheck Stop the task if it runs longer than
        • Uncheck If the running task does not end when request
        • If the task is already running, then the following rules applies: Run a new instance in parallel
    Step 4: Create a Shortcut Lastly, create a shortcut in the Startup Folder of the user in question that points to: C:\Windows\System32\schtasks.exe /run /tn "FireDaemonServices" And that's it - when you boot/reboot your machine your machine will auto login and run all your nominated FireDaemon services interactively. Should a service crash or be terminated accidentally then FireDaemon will restart you app in session.
    Thursday, May 15, 2014

    Starting Interactive FireDaemon Services In Session At Login Using Login Scripts

    Windows Vista or later implements Session 0 isolation. What this means is that services with a GUI component that would normally interact with the Desktop are not visible if you RDP into your server or login via the console. You will have to switch to Session 0 via the Interactive Services Detection Service popup. You can run Interactive FireDaemon Services on your RDP session though. There are some caveats:

    1. The FireDaemon service must be configured to run as the LocalSystem account. When the service runs In Session it will run under the logged in users credentials
    2. If you log off the service will be killed. FireDaemon will restart the service for you but back on Session 0.

    You can write a Windows logon script to run your services interactively. To do this:

    1. Create all the necessary FireDaemon services using the FireDaemon GUI
    2. Decide whether you want these services to be Manual start (ie. let the login script start them) or Automatic start (ie. they are started when Windows starts)
    3. Write the logon script batch file and place it somewhere logical on your C: drive
    4. Configure the logon script to run at logon via the Local Group Policy Editor.

    Here's an example logon script - it uses the "call" directive to avoid UAC and elevate appropriately. Remember the user you login as in this instance must have the necessary privileges (eg. be a member of the Administrators group) in order to run FireDaemon effectively. Use this script if your services are manual start (ie. your services are started In Session and killed and stopped when you logoff).

    call "C:\Program Files\FireDaemon\FireDaemon.exe" --start Mercury --in-session > Log.txt
    call "C:\Program Files\FireDaemon\FireDaemon.exe" --start Runtime --in-session >> Log.txt
    call "C:\Program Files\FireDaemon\FireDaemon.exe" --start Taskmgr --in-session >> Log.txt
    call "C:\Program Files\FireDaemon\FireDaemon.exe" --start LST_Server --in-session >> Log.txt

    Use this script if your services are set to automatic (ie. your services are restarted In Session and killed and restarted on Session if you logoff):

    call "C:\Program Files\FireDaemon\FireDaemon.exe" --restart Mercury --in-session > Log.txt
    call "C:\Program Files\FireDaemon\FireDaemon.exe" --restart Runtime --in-session >> Log.txt
    call "C:\Program Files\FireDaemon\FireDaemon.exe" --restart Taskmgr --in-session >> Log.txt
    call "C:\Program Files\FireDaemon\FireDaemon.exe" --restart LST_Server --in-session >> Log.txt

    For more information on the FireDaemon Command Line Interface and various command syntax please see this section in the manual.

    Monday, September 30, 2013

    Installing Perl and the VMXNET3 driver retrospectively on a minimalist vSphere CentOS 6 virtual machine

    When installing a minimal CentOS 6.4 VM on vSphere 5.1 or later, Perl is not automatically installed. This means you can't install VMware tools and thus the VMXNET3 driver to enable networking. You could change the initial setup of your VM (eg. add the Perl packages during the install of CentOS or install an E1000 adapter in addition to the VMXNet3 adapter) but you might be in the situation that requires a nice clean install. The steps below allow you to retrospectively install Perl and VMware tools.

    Assumptions

    1. The VM was created with a single VMXNET3 adapter
    2. An x64 instance of CentOS 6.4 was installed using the "Minimal" default installation of CentOS
    3. The CentOS 6.4 ISO is still connected to the VM
    4. You can login as root via the Virtual Machine Console in the vSphere Client
    5. You have a DHCP server on your network

    Step 1: Mount the CentOS 6.4 ISO

    Ensure the ISO is connected to the VM. Then at the root prompt type:

    mount /dev/cdrom /mnt
    cd /mnt/Packages

    Step 2: Install the necessary Perl packages

    Now type using tab command completion (line is wrapped for readability):

    yum --disablerepo=* localinstall 
        perl-5.10.1-129.el6.x86_64.rpm 
        perl-libs-5.10.1-129.el6.x86_64.rpm 
        perl-version-0.77-129.el6.x86_64.rpm 
        perl-Module-Pluggable-3.90-129.el6.x86_64.rpm 
        perl-Pod-Simple-3.13-129.el6.x86_64.rpm 
        perl-Pod-Escapes-1.04-129.el6.x86_64.rpm

    6 packages should be installed.

    Step 3: Unmount the ISO

    Now type at the command prompt:

    cd
    umount /mnt

    Step 4: Install VMware Tools

    In the Virtual Machine Console go to the VM menu and choose Guest -> Install/Upgrade VMware Tools. Then at the command prompt:

    mount /dev/cdrom /mnt
    cd /tmp
    tar xvzf /mnt/VMwareTools-9.0.5-1137270.tar.gz
    cd vmware-tools-distrib
    ./vmware-install.pl
    cd
    umount /mnt

    Follow the prompts to install VMware Tools. The defaults usually suffice. Remember this only installs VMware tools for the currently running kernel. If you do a yum update you will need to reinstall VMware Tools. Additionally note that the exact VMwareTools tgz will depend on the version of the ESXi hypervisor you are running so you might have to adjust the file name to suite.

    Step 5: Check the VMXNET3 driver is loaded

    At the command prompt:

    lsmod | grep vmxnet

    You should see the following similar output - this means the driver is loaded and is unused.

    vmxnet3        42862   0

    Step 6: Edit the network settings

    Now edit the network settings:

    vi /etc/sysconfig/network-scripts/ifcfg-eth0

    Change your network settings as you see fit but minimally change the following line in ifcfg-eth0 in order to get a DHCP lease:

    ONBOOT=yes

    Step 7: Restart the network and get a lease

    At the command prompt type:

    service network restart

    The network will restart and you should have an IP address assigned via DHCP. Type:

    ifconfig
    eth0      Link encap:Ethernet  HWaddr 00:50:56:87:51:A9
              inet addr:10.0.0.163  Bcast:10.0.0.255  Mask:255.255.255.0
              inet6 addr: fe80::250:56ff:fe87:51a9/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:338 errors:0 dropped:0 overruns:0 frame:0
              TX packets:58 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:40438 (39.4 KiB)  TX bytes:7155 (6.9 KiB)

    That's it! All done.

    Addendum from Tristan at Aptira:

    A simpler way as the VMXNET3 driver is included with CentOS minimal for all 6.x versions.

    1. Install OS
    2. vi ifcfg-eth0 and set ONBOOT=yes
    3. Reboot and the network should come up.
    4. yum -y wget
    5. Grab the latest VMware repo from here http://packages.vmware.com/tools/esx/latest/repos/index.html. For example wget http://packages.vmware.com/tools/esx/latest/repos/vmware-tools-repo-RHEL6-9.4.5-1.el6.x86_64.rpm
    6. rpm -ivh vmware-tools-repo-RHEL6-9.4.5-1.el6.x86_64.rpm
    7. yum install -y vmware-tools-esx-nox
    8. Profit!

     

     

    Saturday, August 31, 2013

    Importing and Exporting FireDaemon Service Definitions

    FireDaemon gives you the ability to import and export service definitions. A service definitions is a text file containing XML. So, why would you want to import or export your service definitions? Well .... you might be rebuilding your server and need to backup your configs or migrating from an older server to new one. Alternately, you might want to replicate FireDaemon service configurations across multiple servers. FireDaemon gives you four methods by which you can import/export your service definitions:

    1. Drag and drop: simply click on a FireDaemon service in the GUI and then drag that service to your desktop or other folder
    2. Via the Service or right click menu: choose the services you want to export or XML files you want to import
    3. File open, save and view: in the FireDaemon Service Definition dialog click on the  four icons that allow you to Open, Save, Save As and View
    4. Via the command line: you can import, export and enumerate FireDaemon services at a command prompt
    A complete list of FireDaemon XML service definition tags can be found in the manual.
    Saturday, August 17, 2013

    Configuring a Clustered NetApp Filer as an NFS Datastore for VMware ESXi Implementing Multiple VLANs, MTUs and IPs

    On your NetApp filer you can easily configure multiple VLANs with differing MTU on the same LACP trunked 1GbE or 10GbE ports with stacked IPs on the storage VLAN network to assist with load balancing.  In this example, network 10.0.0/24 (VLAN 10, MTU 1500) is just the regular network. Network 10.0.1/24 (VLAN 20, MTU 9000) is the NFS storage network. On your switch create an LACP trunk to the filer's interfaces and then trunk VLANs 10 and 20. Your ESXi servers storage network would also be on VLAN 20 and use the load balancing policy of Route based on IP hash. On the switch you would create a static trunk (since ESXi 5 does not support LACP). The VMkernel port on the vSwitch would be untagged for the storage network. Here's /etc/rc:

    hostname filer1
    ifconfig e0a flowcontrol send
    ifconfig e0b flowcontrol send
    ifconfig e0c flowcontrol send
    ifconfig e0d flowcontrol send
    vif create lacp NETWORK -b ip e0a e0b e0c e0d
    vlan create NETWORK 10 20
    ifconfig NETWORK-10 `hostname`-NETWORK-10 netmask 255.255.255.0 mtusize 1500 -wins partner 10.0.0.51
    ifconfig NETWORK-20 `hostname`-NETWORK-20 netmask 255.255.255.0 mtusize 9000 -wins partner 10.0.1.54
    ifconfig NETWORK-20 alias `hostname`-NETWORK-20-ALIAS-1 netmask 255.255.255.0
    ifconfig NETWORK-20 alias `hostname`-NETWORK-20-ALIAS-2 netmask 255.255.255.0
    ifconfig NETWORK-20 alias `hostname`-NETWORK-20-ALIAS-3 netmask 255.255.255.0
    route add default 10.0.0.1
    routed on
    options dns.enable on
    options nis.enable off
    savecore

    Ensure /etc/hosts is populated correctly with the IP of both toasters in the event of failover/failback:

    127.0.0.1 localhost
    10.0.0.50 filer1 filer1-NETWORK-10   
    10.0.1.50 filer1-NETWORK-20
    10.0.1.51 filer1-NETWORK-20-ALIAS-1
    10.0.1.52 filer1-NETWORK-20-ALIAS-2
    10.0.1.53 filer1-NETWORK-20-ALIAS-3
    10.0.0.51 filer2 filer2-NETWORK-10
    10.0.1.54 filer2-NETWORK-20
    10.0.1.55 filer2-NETWORK-20-ALIAS-1
    10.0.1.56 filer2-NETWORK-20-ALIAS-2
    10.0.1.57 filer2-NETWORK-20-ALIAS-3

    Ensure your VM exports (/etc/exports) are secured ensuring only access from your ESXi VMKernel port on the storage switch of each ESXi host - in this case there are 3 ESXi hosts. Additionally, individual IPs don't necessarily need to be used if an entire subnet requires rw and root access to the VM volumes:

    /vol/root      -sec=sys,rw,anon=0,nosuid
    /vol/root/home -sec=sys,rw,nosuid
    /vol/downloads -sec=sys,rw,nosuid
    /vol/vm00      -sec=sys,rw=10.0.1.10:10.0.1.11:11.0.1.12,root=10.0.1.10:10.0.1.11:11.0.1.12
    /vol/vm01      -sec=sys,rw=10.0.1.10:10.0.1.11:11.0.1.12,root=10.0.1.10:10.0.1.11:11.0.1.12
    /vol/vm02      -sec=sys,rw=10.0.1.10:10.0.1.11:11.0.1.12,root=10.0.1.10:10.0.1.11:11.0.1.12
    /vol/vm03      -sec=sys,rw=10.0.1.10:10.0.1.11:11.0.1.12,root=10.0.1.10:10.0.1.11:11.0.1.12
    /vol/iso       -sec=sys,rw=10.0.1.10:10.0.1.11:11.0.1.12,root=10.0.1.10:10.0.1.11:11.0.1.12

    This configuration would be need to be made identically on filer1 and filer2 with the exception that on filer2 the hostname changes in /etc/rc.

    Saturday, July 27, 2013

    Passwordless root SSH Public Key Authentication on CentOS 6

    It's often useful to be able to SSH to other machines without being prompted for a password. Additionally, if you using tools such as Parallel SSH you will need to setup Public Key SSH Authentication. To set it up is relatively straight forward:

    On the client machine (ie. the one you are SSH'ing from) you will need to create an SSH RSA key. So run the following command - ensure you don't supply a password:

    [root@node01 ~]# ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (/root/.ssh/id_rsa):
    Created directory '/root/.ssh'.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /root/.ssh/id_rsa.
    Your public key has been saved in /root/.ssh/id_rsa.pub.
    The key fingerprint is:
    c6:66:93:16:73:0b:bf:46:46:28:7d:a5:38:a3:4d:6d root@node01
    The key's randomart image is:
    +--[ RSA 2048]----+
    |            .    |
    |       . + o     |
    |      . @ E      |
    |       * & .     |
    |      . S =      |
    |       = + .     |
    |          o      |
    |         .       |
    |                 |
    +-----------------+

    This will generate the following files:

    [root@node01 ~]# cd ~/.ssh
    [root@node02 .ssh]# ls -l
    total 8
    -rw-------. 1 root root 1675 Jul 27 15:01 id_rsa
    -rw-r--r--. 1 root root  406 Jul 27 15:01 id_rsa.pub

    On the client machine tighten up file system permissions thus:

    [root@node01 ~]# chmod 700 ~/.ssh
    [root@node01 ~]# chmod 600 ~/.ssh/*
    [root@node01 ~]# ls -ld ~/.ssh & ls -l ~/.ssh
    drwx------. 2 root root 4096 Jul 27 15:01 /root/.ssh
    -rw-------. 1 root root 1675 Jul 27 15:01 id_rsa
    -rw-------. 1 root root  406 Jul 27 15:01 id_rsa.pub

    Now copy the public key to the machine you want to SSH and fix permissions (you will be prompted for the root password):

    [root@node01 ~]# ssh root@node02 'mkdir -p /root/.ssh'
    [root@node01 ~]# scp /root/.ssh/id_rsa.pub root@node02:/root/.ssh/authorized_keys
    [root@node01 ~]# ssh root@node02 'chmod  700 /root/.ssh'
    [root@node01 ~]# ssh root@node02 'chmod  600 /root/.ssh/*'

    You can also use the utility ssh-copy-id to do the above steps. If you don't have scp on the remote machine you will need to install it:

    [root@node01 ~]# ssh root@node02 'yum install openssh-clients'

    You should now be able to ssh directory from node01 to node02 without providing a password:

    [root@node01 ~]# ssh node02
    Last login: Wed Jul 27 15:41:56 2011 from 10.255.5.57
    [root@node ~]#

    IMPORTANT There is a bug in CentOS 6 / SELinux that results in all client presented certificates to be ignored when SELinux is set to Enforcing. To fix this simply:

    [root@node01 ~]# ssh root@node02 'restorecon -R -v /root/.ssh'
    restorecon reset /root/.ssh context system_u:object_r:ssh_home_t:s0->system_u:object_r:home_ssh_t:s0
    restorecon reset /root/.ssh/authorized_keys context unconfined_u:object_r:ssh_home_t:s0->system_u:object_r:home_ssh_t:s0
    Sunday, July 21, 2013

    Fortinet Fortigate 300C Active Directory Integration

    We recently had to install a Fortinet Fortigate 300C cluster. You may wish to integrate your firewall cluster into Active Directory to facilitate AD based administrative and VPN logins. This guide is based on FortiOS v4.0 MR3 Patch 8 (v4.0,build0632,120705 (MR3 Patch 8)).

    Configure DNS

    First thing is to ensure your Fortigate's DNS is configured to point to your Active Directory servers. Go to Network -> DNS:

    Configure LDAP

    Then you need to configure LDAP. So go to User -> Remote -> LDAP and Create a new LDAP entry. You will need to create an LDAP entry for each domain controller:

     

    Windows Server uses sAMAccountName and the Common Name (CN) Identifier. Your Distinguished Name is typically your top level AD DN. You need to do a Regular bind to AD and as a result you will need to specify the user that has access to AD to make queries. In this case the user LDAPBindFortinet was created explicitly with a non-expiring password. The User DN is CN=LDAPBindFortinet,OU=Services,OU=FireDaemon,DC=firedaemon,DC=int. Make sure you test connectivity and that you can successfully browser the directory. If you are having trouble divining CNs and DNs try browsing your directory with Softerra's LDAP Administrator.

    Configure User Group

    You will now need to create a remote authentication user group. So go to User -> User Group -> User Group.  Name it appropriately then add in your two Active Directory servers. Your users will ideally need to be in a group to permit firewall or VPN access. In this example, the group the users are in is:  CN=FortinetUsers,OU=Groups,OU=FireDaemon,DC=firedaemon,DC=int. You can obtain this DN by browsing the user and looking at their MemberOf attribute.

    Add Remote Users

    Lastly, you will need to add remote users (in this case for firewall configuration). So go to System -> Admin -> Administrators and add remote users.

     

    You should now be able to login as a domain user to your Fortigate:

     

    Friday, June 28, 2013

    Arista Networks switch easter egg

    If you have an Arista Networks switch here's a little easter egg that you may find amusing. At the command prompt type show chickens. You will get the following output:

    Saturday, June 01, 2013

    Setting up DHCP on an Enslaved VLAN Bridge on CentOS Linux

    I had to setup a single interface on a server, with dual DHCP IP addresses that were obtained on the native untagged interface along with a tagged interface enslaved to VLAN bridge in order to rollout Enomaly SpotCloud. Thus the primary interface obtains its IP address via DHCP along with the bridged interface on a VLAN. To set this up :

    1. cd /etc/sysconfig/network-scripts

    2. vi ifcfg-eth0 so it looks like (change your MAC address accordingly):

    DEVICE=eth0
    BOOTPROTO=dhcp
    ONBOOT=yes
    HWADDR=f4:ce:46:82:55:f4 

    3. Then create your VLAN interface configuration. So vi ifcfg-eth0.1051:

    DEVICE=eth0.1051
    BOOTPROTO=dhcp
    VLAN=yes
    BRIDGE=virbr0
    ONBOOT=yes

    4. Then create your bridge interface configuration: So vi ifcfg-virbr0:

    DEVICE=virbr0
    TYPE=Bridge
    ONBOOT=yes
    DELAY=0
    BOOTPROTO=dhcp

    Note that TYPE must be Bridge with a capital B - otherwise it won't work. And there you have it - when the box boots it gets a DHCP lease on eth0 and on virbr0 which is on VLAN 1051.


    Recent Posts


    Tags


    Archive

    Sign up for Product Updates and Discounts
    Captcha Image
    ×