http://flipsidereality.com/Ghost v0.4.1Fri, 22 Feb 2019 16:34:41 GMT60Every now and then I find myself in a situation where I need to send data from one system to another and for one reason or another I'm unable to transmit using TCP or UDP. This is usually as a result of an over zealous security admin and some funny firewall rules, although I've used this trick on other occasions when I'm on an unauthenticated wireless lan with captive portal enabled but no credentials for network access. Strangely it seems that a lot of these captive portal systems allow both DNS requests and ICMP through.

Assuming you have a way to enter shell commands on both boxes and one can ping the other we can actually route data over ICMP to the destination host using the fantastic hping3

Installing hping

hping is in the standard apt repos for debian based systems (ubuntu, mint etc.) and can therefore be installed with the command:

although you'll need to compile it by hand if you want tcl scripting support on OS X.

Sending a file

Hping is a very versatile tool. It's been around for ages, it was actually the first implementation of the idle scan technique now used by nmap, but today we are using it to send data over ICMP.

configuring the listener

On the receiving end we need to start a listener, we also need to specify strings that make the beginning and of the interesting traffic (in this case the file we are sending). This is done with the --listen directive that takes the IP address of the sender and marks the start of the file, and the --sign directive that takes a custom string we can make up (it just has to match what we use on the other end) and marks the end of the interesting traffic (file). We also need to redirect the output to a file using the standard shell > filename syntax. Putting this together we get:

Succcess! we've just send a file from server A to Server B using ICMP as the data channel :)

]]>http://flipsidereality.com/2014/03/26/sending-data-using-icmp-and-hping/d6778682-0c0e-4ec7-9206-a8216466911dWed, 26 Mar 2014 16:25:58 GMTThe ghost blog project is pretty cool, it's also written in nodejs. This is not a bad thing but node is a relative newcomer to the world and can be a little intimidating to deploy to production, especially if you would like to share precious ports 80 and 443 (HTTP and HTTPS) on the server's IP with other sites.

To get this working requires virtualhosts to be setup, which is where your server looks at the URL of the site being requested and serves different content depending on what it sees. This way you can have www.needles.com on the same server as www.haystack.com without getting all mixed up.

To further complicate matters ghost needs to run in it's own node instance, on it's own port and it has no idea about virtualhosts, so in order to enable virtualhosts we have to either modify the ghost code (making future updates much harder as we'd have to port our modifications) or put a proxy server in front of ghost and node that understands URL based host header routing. This configuration is known as a reverse proxy.

In this walkthrough we'll setup ghost listening on the localhost ip 127.0.0.1 and then configure a reverse, virtualhost aware proxy using nginx to serve that content to the outside world.

Note that for virtualhosts to work you have to configure your DNS correctly as it's the domain name that is used by the server to select the correct content for your browser. There are lots of guides on how to configure DNS and it's a bit beyond the scope of this page, but none of this will work until you can:

ping yourhost.yourdomain.com

and get replies from the server at the IP where you are setting this up.

Installing node

Ghost requires node >= 0.10, the Ubuntu apt repo version (0.6.12 as of writing) is a little too old. The official instructions suggest installing node from source. Before we do that however we'll need to update the server and install some packages:

Installing ghost

To make ghost start automatically at boot we need to install an init script. We should use upstart, but as it's going away in favour of systemd, and becasue the older sysV scripts still work and ghost includes one lets be lazy and use that instead:

and finally start the service, which by default listens on localhost:2368

service ghost start

Virtual host proxy routing

To publish ghost to the internet on the same IP as other sites we needed a reverse proxy of some kind.

It seems that the node community hasn't yet settled on a solution for virtualhosts with Node. npm lists (npm search vhost) many options of which vhost, vhostd and vhostess seem to be some of the most current. Other suggestions include utilizing the connect framework, for which Jon Simon has an excellent writeup.

I had a quick go with vhostd, which was surprisingly easy to get up and running. A quick sudo npm install vhostd -g (the -g means install with global, machine level scope), followed by creating a /etc/vhostd.ini with the following content

[SERVER]
port = 80
[willsheldon.com]
address = 127.0.0.1
port = 2368

then vhostd start to start the service works like a charm.

I did like this option, but in the end I went for an nginx solution I could add https to more easily (for me), all be it with a self signed certificate for now:

First install nginx

apt-get install nginx -y

and set it to start at boot

update-rc.d nginx defaults

Then create a private key and certificate request. (Note: don't set a password here as you'll have to enter it every time the server starts, and you may not be around to do so)

Setup mail

Ghost needs to send mail. You have several options here, the simplest is probably to setup a gmail account. I needed to send mail from this box anyway so I decided to setup a local mail transport agent (mta). I chose exim becasue it's stable and has a light footprint. There is a great installation guide over at digital ocean.

Configure ghost

Using exim means that ghost keeps pestering you to setup mail unless you put a mail config stanza in the /var/www/ghost/config.js file. This is what my production section looks like

Note the addition of the forceAdminSSL: 'true'; directive. This tells ghost to redirect you to HTTPS when you visit the ghost admin page (found at http://hostname.yourdomain.com/ghost)

Conclusion

There you have it, a simple node setup on a server that can also be used to host other sites as well. We even have ghost running under it's own service account which can be locked down to have minimal permissions on the server. :-)

]]>http://flipsidereality.com/2014/03/26/setting-up-ghost-as-a-virtual-host-on-ubuntu/7a5c2b99-8964-4ccc-b359-44e0d67d3e7aWed, 26 Mar 2014 00:06:11 GMTIt's sometimes necessary to add a second IP address to a server for a new service, such as when configuring a STUN server (which requires two public IP's).

I've sometimes had to do this in situations where a hosting provider has no remaining free IP's in the server's current subnet and have therefore had to allocate an IP in another network. This is what to do when that happens.

Please note that it is almost always better to stick to a single network if you can as each network carries a certain amount of broadcast traffic which reduces your effective data throughput rates.

The trick here is to instantiate a virtual subinterface on the nic. This is done by configuring an interface that looks (to an administrator) very similar to a physical interface with a bit tacked on to the end of it's name, it's followed a colon then a number, e.g. eth1:4 for virtual interface 4 on eth1. Note that the actual virtual interface number used doesn't really matter, as far as I'm aware it's not used for anything other than to differentiate it from other (possible) virtual subinterfaces, although I'm sure strong arguments can be made to increment from 0.

Incidentally, this is quite similar to the method for adding an 802.1q vlan tagged virtual interfaces where a period is used instead of a colon, for example eth0.22 for an interface tagged as vlan 22 on physical port eth0)

This can be achieved on pretty much all linux boxes by the following otherwise standard use of the ifconfig command (substituting the correct IP and netmask of course):

ifconfig eth0:1 10.10.10.1 netmask 255.255.255.0 up

however to make the change persistent across reboots requires a little more and varies between ditros. I'll cover Debian and RHEL based distros here:

Debian based (inc. Ubuntu)

Edit /etc/network/interfaces and add a eth0:0 or such stanza to the end of the file:

You can add as many as you need. Officially you should be able to restart networking to apply the settings (using service networking restart or /etc/init.d/networking restart) but sometimes a full reboot is required, especially if your host is a VPS.

Redhat based (inc. CentOS)

The actual file you need to edit is based on the interface name. Look in /etc/sysconfig/network-scripts/ to identify current interfaces and then create another file in the same folder. For example if you need to add another IP on eth0 you would have to create /etc/sysconfig/network-scripts/ifcfg-eth0:0 (or 0:1) etc.. with the following content:

Finally, running service network restart to activate the change (with the same corollary about needing to reboot some VPS's)

And finally

A word of warning about in band changes to networking settings. Be careful when you change and restart networking settings if you are accessing the box over the network. Double check your settings, it's quite easy for a typo to prevent the network from coming back up and requiring you to do the walk of shame to the console. For remote servers I use a script that backs up network settings and then automagically restores them on next but one boot (most hosting has an ACPI power cycle opton on the control panel).