I run this site! I write debatably opinionated articles about most tech-related topics and occasional philosophical ramblings. Besides electrons, I also like music.
I’ll document my experiences with SynergyCP on my blog to help future network- and sysadmins with their SyCP mishaps.
As a system and network administrator for a hosting company, SynergyCP is a well-known name to me. Considering the price, it’s a pretty good deal for managing dedicated servers for various clients. However, it definitely isn’t without its quirks which can quickly grind one’s workflow to a wondering halt. Like a proper boomer, I prefer to run my networks on Cisco switches, which, while very fast, don’t always play nicely with SyCP’s temperament. I’ll document them here on my blog to help future network- and sysadmins with their SyCP mishaps.
block-for intolerance
My installation of SynergyCP really doesn’t like the block-for feature on my 3750-X Catalysts and raises SSH offset errors on every single connection attempt. I tried raising the threshold on the login attempts, but I didn’t look into it very deply (yet).
The solution: disable any block-for statements. I am aware that this impacts switch security, but you have SSH ACLs on your switches, don’t you? :^)
Public IPs have been replaced with TEST-NET equivalents for obvious reasons. Enjoy!
I have a rather nice ISP which allows me to use two public IPv4 addresses: one is dynamic and routed through their gateway at 192.168.64.1 and the other one is static, bridged directly to the internet through an extra port on the modem. On the interface connected there I have to configure the provided IP address (203.0.113.52/24) and the default gateway of 203.0.113.52.
Nobody’s perfect, so locking yourself out with a bad pf rule isn’t so much a possibility but more an eventuality. Thankfully, the modem itself is also capable of performing NAT on the dynamic IP, so a backup connection is also available, right?
Well, no. Trying to connect through modem NAT times out. A bit of tcpdump clearly shows the packets do arrive at my firewall but due to the way NAT works, my firewall sends its replies to the external static IP gateway instead of the modem.
Why did this happen?
Port forwarding or Destination NAT – DNAT works by – you guessed it – overwriting the destination address and optionally port of receieved packages. This means that a packet arriving at the modem gets translated like this:
Packet arriving at:
Source
Destination
Modem’s NAT rule
any:9013
192.168.64.13:22
Modem
192.0.2.5:45533
198.51.100.43:9013 (my modem)
Firewall
192.0.2.5:45533
192.168.64.13:22
Description
Source
Destination
What client expects
198.51.100.43:9013
192.0.2.5:45533
What client gets/firewall sends
203.0.113.52:22
192.0.2.5:45533
Modem establishes a NAT state in it’s firewall table, expecting the firewall to reply back to it. Unfortunately, because the source address remains the same, the firewall sees the external source address (192.0.2.5:45533) and sends the reply via its own default gateway, 203.0.113.1. The packets do arrive at the origin (192.0.2.5:45533), but because the original client expects replies from 198.51.100.43:9013 instead of 203.0.113.52:22, it doesn’t recognize the packets as belonging to the connection and drops them.
How do we solve this?
There’s more than one way to skin a cat. The boring way would be to make the modem perform both S- and D-NAT, which would ensure the packets travel properly. As my ISP doesn’t let customers to configure their modems, a different, more interesting solution must surely exist.
What about tools already available? As always, pf has something suited just for this purpose. Reading pf.conf(5) tells us this:
Symmetric routing enforcement sound like something I’d need. And indeed, writing a rule like:
pass in on ingress from !(ingress:network) to any port ssh reply-to $router-ip@ingress
Fixes that problem, sending the NAT’d SSH packets from my modem back the same path they arrived while not breaking existing routing configuration.
Firewalls aren’t as special as they’re made out to be in the business sphere. Sometimes salesmen will try to convince you otherwise, claiming their network appliances use application specific hardware, but teardowns often disappoint. This teardown of the IBM Proventia GX4004 is no different, as the firewall appliance turns out to be a very ordinary Pentium 4 computer.
Teardown
Let’s start at the firewall’s appearance: it’s a beautiful piece of hardware. The blue-silver-orange color palette looks really good. Seriously, that front panel should be in an industrial design textbook. I’ve placed my Cisco IDS-4215 underneath for scale. The Proventia is substantially bigger and heavier than the Cisco, but considering the difference in hardware that’s easy to justify.
The front plate sports a decent amount of I/O: two management Ethernet ports, 2 pairs of protected Ethernet ports, two USB 2.0 ports and a standard RJ45 console port. There’s also an EZIO-100 LCD display unit on the left side of the panel.
At the back we are greeted by a standard FlexATX power supply, multiple fan vents, and a single full-height PCI slot.
After removing some screws on the back, right, and left side, the blue cover slides off, and we’re greeted with a slightly underwhelming server board. For a sixteen-thousand-dollar appliance, I was hoping to see special proprietary hardware inside, but I seem to be out of luck here. Oh well, let’s explore a bit!
Network cards
The network controllers are located in the top left corner. The two on the right belong to the management interfaces and are quite unremarkable. The remaining four controllers are a bit more interesting. Every network controller has 4 relays, a relay for each Ethernet pair. The relays are there to bypass the network interfaces entirely in case the machine hangs or loses power. The security of such a system is of course questionable, but sometimes uptime means more than security.
Storage is plentiful: there’s 2 SATA connectors, 1 IDE connector, a CF card slot and a combined SATA+POWER connector available. Only the combined connector is occupied by default, connecting to a Seagate 80GB hard drive housed in a drive tray.
There’s a pretty substantial bank of jumpers next to the CF slot. Not all jumpers are documented, but I managed to figure out that JP7 is the one you want to move, should you run a third-party OS. Moving JP7 jumpers to the left disables software control of the bypass relays, enabling normal network interface behaviour. Nevertheless, because of the way those relays are wired, there’s no way to disable the bypass once the machine is powered off.
Under the plastic shroud there is a pretty big copper heatsink that cools a Cedar Mill Pentium 4 HT 651 CPU. This is no entry-level processor: with 3.40 GHz it has a higher base clock than some current CPUs. It’s really a shame that it’s bottlenecked by slow DDR-400 RAM.
Front panel LEDs are housed above the network interfaces. If you remove the housing from the main chassis, you’ll discover an easter egg – hidden reset and power buttons.
The 250W power supply has a standard 20-pin ATX connector, along with a 4 pin CPU connector and a Molex that is unused.
Powering up
Enough talking about the hardware. Let’s power it up and see what gives. Setting the console to 9600 baud reveals a straightforward boot screen. This seems to be a custom BIOS that uses a serial console, but is normal otherwise. Here is the POST sequence:
We can get into the BIOS by pressing TAB at POST check:
Wow, this is pretty well-executed, with arrow keys working and all! The BIOS is fully featured, the only downside is the slow 9600 baud serial line that takes about two seconds to render the terminal screen. Anyway, I found out that the defaults work well for me, so tweaking is to taste. There are also some BIOS settings talking about LAN bypass, but they didn’t seem to do anything, so just left them on defaults.
OpenBSD
Getting OpenBSD installed on this thing wasn’t too easy. USB wouldn’t boot and neither would the CF card. Something strange has been going on between old machines and OpenBSD install.fs images for a while now, and I was not in the mood for figuring out why the damned thing froze trying to boot the install kernel. Thankfully, the Press L to Boot From LAN prompt opened up an option to ditch local boot media altogether and install over PXE.
For my bootserver, I used my converted Cisco IDS-4215. I’d been using it to boot diskless clients, so it had everything I needed for PXE already installed: a working router, DHCP and DNS servers and a TFTP server with a recent bsd.rd kernel. Sure enough, PXE booted the installer first time.
The installation finished effortlesly, and in fifteen minutes I had a pretty capable OpenBSD firewall ready.
Conclusion
Even though the GX4004 isn’t as special as it lead on to be, it’s still more than good enough to install your firewall or server OS of choice on. If you need a cheap networking device, the GX4004 paired with the correct software certainly won’t disappoint.
As
smartphones came to be, many common portable devices such as
netbooks, palmtops and pocket organizers became obsolete. Today I
will present to you one such device – a Tidalwave palmtop computer
from 1992.
A really quick post to help others that encountered the same problem as me. The iLO 100 remote management system on the HP ProLiant ML110 G6 server can’t be password reset with a jumper or a similarly simple measure. It involves a DOS boot disk and a certain ipmitool command that resets the username “admin” to password “admin”. To save time, I made a working bootable image using FreeDOS. Unzip and flash it to a USB drive, boot from the drive, and then exit to DOS prompt. From there, run:
fixpass.bat
The program should complete successfully and you should be able to log into the iLO with username admin and password admin.
In the previous part, we set up DHCP, TFTP and RARP servers and successfully booted the OpenBSD ramdisk install kernel on old Soekris hardware over the network from a repurposed Cisco IDS. In the last part of this series, we will add NFS shares to the mix and install OpenBSD to them, making our PXE clients fully functional and then set up a minimal router and a caching DNS to provide our clients with working internet access.
In the first part, we became familiar with the hardware we’ll be working on and gathered the needed information. In this part, we focus on making PXE work up to the point we’re able to get to the boot loader and load a kernel.
Does anyone remember Soekris Engineering, the company that made network hardware and somehow also audiophile equipment? The first part of the company has unfortunately closed down in April 2017, while the latter still persists today. However, we won’t be focusing on high-fidelity audio in this guide, but rather on squeezing the last bits of life out of their old products.
Even though Cisco equipment is very capable, it tends to become End-of-Life before you can say “planned obsolescence”. Websites become bigger, bandwidths increase, and as a side effect of those “improvements”, routers, firewalls, and in this case, intrusion prevention systems get old quicker and quicker.
Apparently, this was also the case for the Cisco IDS-4215 Intrusion Detection Sensor that I was given a few months ago.
