Any port (forwarding) in a storm

Here’s a frustrating little niggle.

I’m having to use a downgraded router (due to not having FTC, as previously moaned about).

To allow internet traffic to access any of the servers running on my LAN, I have to configure port forwarding on the above mentioned router.

In my last (FTC) house, I configured port forwarding through a nifty little utility that is installed on my NAS.

I don’t want to faff (technical word, there) with using the same utility to configure port forwarding, because the law of sod clearly dictates that whatever I do now, it will over-write port forwarding rules that I have previously configured for my FTC router.

And I don’t want to do that, because if Openreach (hey, I did say *if*) stick to their updated delivery, and have FTC installed here, by the middle of the month, then I plan on switching over to the previously configured router and hey presto, Robert’s your mother’s brother!

So I’ve had a bash at manually configuring port forwarding the Plusnet Technicolor (sic) Gateway.

And hit a wall.

No matter how much time I spend in the config menu/sub-menus, no matter which changes I make (then unmake, obv), I can’t get port forwarding fully enabled/configured.

Everytime I think I’ve done it correctly, I put the uri in the browser and…

gateway

I have no idea how to bypass this – the IP traffic should go straight to the domain I’m using as a test-site for all this experimenting – experiment.co.uk (except it isn’t that one, obv).

But it doesn’t, clearly, traffic is being routed to experiment.co.uk/login.lp

I don’t want to spend too much time on it.

If the word of Openreach is good (sceptical face) I’m only going to have to endure the current setup for two more weeks.

But how frustrating, to get so near, and yet, so far.

Moving the second (part VI)

This is odd.

I have pointed a domain name registered with 123-reg to my NAS. I have done the usual stuff (created a MySQL database, created a database for it, installed the .php front end, put the database user details in the php.config file) and…

It all works.

Ish.

And that’s a tricky ish.

When I go to http://example.co.uk (not the real name, obv), everything is peachy.

Through that URI I have access to the content and, using the correct address, also have access to the .php admin panel and the phpMyAdmin MySQL control panel.

Lovely.

But when I try and give the URI a very minor modification (such as changing the address to http://www.example.co.uk), the internet call is routed to the NAS control panel (https://www.example.co.uk:5001/webman/index.cgi).

Weird.

I’m too tired to get my head around it tonight.

But yeah.

Weird.

Moving the second (part V)

It’s taken 24 hours, but I have finally learned how to migrate a self-hosted website from 123-Reg to my NAS.

It was more fiddly than the migration from GoDaddy last week, and the logic behind the way the core IP address and @ and A and nameservers hang together is very… individual.

But it’s there and the prototype website is up and running.

I’m off to bed now, to celebrate this success with a long line of Zs falling out of my mouth.

See ya tomoz.

 

Moving the second (intermission)

I had successfully proved that the concept (that migrating a php front-ended, MySQL back-ended website hosted with a commercial webhost, based in Arizona, to my NAS here in the UK) was sound.

And I had documented the steps and processes that need to be gone through, in order to make it all happen.

I had signed off with a light-hearted statement about learning to migrate the associated mail accounts after a cup of tea.

Yeah, well I’m struggling with the mail thing.

But while I struggle, here’s a thing.

I am hyperanal about security, and have a number of default characteristics set up, on my NAS, including automatic IP blacklisting after x successful attempts to log on (where x is a number I’m not disclosing), and instant SMS alerts of various events to my phone.

So, a few days ago I enabled my NASs mailserver and began configuring it.

Within 24 hours of enabling mailserver, I started getting attempted penetration alerts on the mailserver.

My alerts look like this:

  1. The IP address [177.99.206.58] experienced x failed attempts when attempting to log into Mail Server running, and was blocked at Sun Sep 22 08:04:34 2013
  2. The IP address [200.198.68.123] experienced x failed attempts when attempting to log into Mail Server running, and was blocked at Sun Sep 22 09:04:34 2013
  3. The IP address [202.162.24.36] experienced x failed attempts when attempting to log into Mail Server running, and was blocked at Sun Sep 22 10:04:34 2013
  4. The IP address [210.212.28.180] experienced x failed attempts when attempting to log into Mail Server running, and was blocked at Sun Sep 22 11:04:34 2013
  • The 1st IP is registered in Brasil
  • The 2nd IP is regsitered in Brasil
  • The 3rd IP is registered in Malaysia
  • The 4th IP is registered in India

My question is, given that these penetration attempts have targeted the mailserver (not the NAS root), how the flipping flip have they identified that I had begun to configure a mailserver?

I hadn’t enabled any MX record

I hadn’t registered the mailserver anywhere on the web

I hadn’t even completed the mailserver config

I am, frankly, puzzled as to how these bots (I’m assuming they are robots, not real people) have latched on to what I was doing.

I can guess what they’re after. I am assuming the bots are trying to establish a backdoor on my mailserver, from which they can spam the world in the name of any accounts that might have been set up there.

But how did they know?

Moving the second (part IV)

How to migrate a website called fredbloggs.com from a commercial host to your Synology Diskstation with no loss of uptime:

Before you start, you need:

  • a static IP address from your ISP
  • port forwarding configured on your router

You will also need:

  • a locally-saved backup of your current live database
  • a locally-saved backup of the current live content/files

 

Steps 1 – 4 are all Synology Diskstation tasks:

1. Control panel -> Web services -> Virtual host ->

  • subfolder name: (enter the website without the TLD suffix) fredbloggs
  • folder name: (enter the full address of the website) fredbloggs.com
  • click OK

 

2. Installed packages control panel -> DNS Server -> Zones -> Create Master Zone ->

  • Domain type: (select) Forward Zone
  • Domain name: (enter the full address of the website) fredbloggs.com
  • Master DNS server: (enter the static IP address)
  • click OK

 

3. Installed package control panel -> phpMyAdmin -> Databases ->

  • Create database fredbloggs / utf8_general_ci
  • go to database fredbloggs
  • Privileges -> New Add User ->
  • User name: fredbloggs
  • host: localhost
  • password: [whatever]
  • retype: [whatever]
  • Database for user: Grant all privileges on database “fredbloggs”
  • Global privileges: leave all unchecked
  • Resource limits: leave as default
  • Click Add User
  • Click Import
  • Click Choose file
  • Navigate to your locally-saved backup MySQL database
  • Click Open (the database will import)

 

4. Filestation -> navigate to your locally-saved copy of content/files

  • Copy all backed up, locally-saved content/files to the webfolder ‘fredbloggs’ in the Web directory of your NAS
  • (nb: you may need to change the DB Hostname in your config.php file, to point to ‘localhost’)

 

5. Log in to your Domain Registrar control panel -> Edit the zone file so the @ record points to your static IP address

6. Drink tea (it could take a few hours for the new server address to propagate around the internet, but while this is happening your website will not drop. nb: do not enter new content to the website until the change has been propagated)

 

Email accounts associated with that domain name are a kettle of different fish that I haven’t yet got my head around.

I’ll do that after more tea.

Moving the second (part III)

Well.

In the best traditions of technical geekery, the next part in the exercise to self-host on a Synology Diskstation NAS was not as straightforward as it could have been.

But I got there.

There are a few very minor gremlins to sort out, but tonight was all about establishing a proof of concept, and implementing a prototype self-hosted, php-based/MySQL-backed website.

I began by taking a copy of WordPress from my downloads folder. I knew it was not the current version, but that was part of my plan – I wanted to see how the self-upgrade function would work on a self-hosting NAS.

I exploded the zipped WordPress files locally, and copied the exploded WP structure and files over to the appropriate web-folder on the NAS.

Then I fired up the phpMyAdmin console and attempted to create a new MySQL database.

Snag.

phpMyAdmin could navigate around the default structure of MySQL databases, but it wouldn’t create anything.

I checked the permissions which, naturally, were good – I had logged in as root – so I tried again. And again.

The console just hung on a create command.

I navigated to users and tried to create a new user, but that achieved the same square-root-of-absolutely-nothing result.

I then spent a good 20 minutes googling various combinations of the words ‘phpMyAdmin fails to create new database and user’.

The only thing I learned is that a significantly large number of people don’t know the difference between hosted and self-hosted, and root and full access permissions.

Obv.

So then I looked at shelling out to the MySQL command prompt and using command-line syntax to create the database.

Fortunately MySQL syntax is a variation on the PL/SQL that I speak, so, refreshed in the patois of MySQL, I rolled up my sleeves and…

… thought about it.

Why is phpMyAdmin allowing me to do everything except execute any type of write command?

I scouted around the internet for a phpMyAdmin upgrade, because the more I thought about the problem, the more it began to feel like a command/interface issue.

I went on to Synology’s website and, while looking for a phpMyAdmin upgrade I discovered that the operating system of my NAS was two versions out of date.

It was a bit of a swervy long-shot, but I gave it a go and upgraded the OS.

Twice.

Then I ran phpMyAdmin again, navigated to the root of MySQL and, exactly as I had done several times before, I attempted to create a new database.

It only bloody worked.

I have no explanation for why, I can’t believe that having a version deficiency in the OS would stop phpMyAdmin from writing to MySQL, however…

Each of the two version upgrades required the NAS to be restarted, so maybe restarting the NAS was the catalyst that fixed the problem?

The old “switch it off and switch it back on again” technique?

If so, I’m slightly disappointed, because I thought Linux and MySQL were above such fripperies.

But, meanwhile, back at the geek factory…

I created a user for that newly created database, and allocated permissions and a password to it.

I fished out the config.php file from the WordPress root, and edited in to it the details of the database and the user I had just created, filled in the password and the hostname, saved it back to the WordPress root and then, in a browser, entered the URI.

I was expecting to see either a vanilla WordPress installation on the website or the WordPress config screen.

Instead I got a database error.

I fished back in to the root of WordPress, renamed the config.php to something the system wouldn’t be able to identify.

Flipped back to the browser, entered the URI again and got the WordPress setup/config creation page.

I entered the details of the database/user/host etc and accepted the changes, and ran straight in to a vanilla WordPress installation.

Brilliant, it worked!

Except.

Because I had used an old version of WordPress, the system prompted me to go and grab an upgrade.

When I tried to run through the usual WordPress upgrade procedure I got this screen:

confused.com

confused.com

The problem is, as geeks might have guessed, I haven’t used FTP anywhere in this process.

I hadn’t even configured FTP.

So I did the manual upgrade (downloaded the WordPress zipped package, exploded it, copied the exploded files in to the root webfolder) and then hit the refresh button.

And got a database error.

So I fished back in to the WordPress root, deleted the config.php, refreshed the website and, as expected, got the WordPress installation page again.

I filled in the database, host, username etc (again) and the website loaded.

Since then I’ve been playing with load functions, and attempting to analyse performance against user function and database activity.

The most that I can move the needle is to get the NAS resource monitor to flick up to 4kb/s of upload (to the web) activity, concurrently with 3kb/s of download (from the internet) traffic.

I don’t know how these numbers stack up in the Grand Scheme Of Things, but in my world right now, an activity ratio of 4kb/s over 3kb/s, on a combination of back-end and front-end utilisation is pretty encouraging.

But it is only one website.

Though it is loading lightningly fast!

Anyway.

The bottom line is that I need to investigate the FTP functionality, to allow WordPress to self-upgrade and, importantly, allow the WordPress plugins to self-upgrade too.

But that is the only thing left to do.

I’ve proved, with this prototype, that I can deliver what was in my head.

I will do no more (he said, trying to sound resolute) work on this concept until after I have moved.

But I know of a very nice pair of PowerEdge servers and a compatible rack for sale, for not much money…

Moving the second (part II)

I had some free time* this evening, so I thought I’d investigate the NAS’s capabilities.

I downloaded, installed and configured an instance of the phpMyAdmin control panel (the Synology Diskstation NAS already has MySQL installed).

Then I used the internal package downloader to grab a copy of WordPress, and installed that as an intranet blog.

Well, I said to myself (I seem to be doing a lot of this, lately. I’m going to have to keep a watch on this. Yes you are. Who said that? I did. Who are you? Look, just get on with documenting what you did, you big geek) if building an intranet website is that easy, why don’t I use the next half an hour to set up an internet website on the NAS.

Well it didn’t take half an hour, obv.

But after a lot of fiddling about within a handful of different modules, and reconfiguring various router and server ports, and firewall rules, everything looked about ready to go.

So I went to the registrar’s control panel of a domain I own that’s been dormant for the last six months, and pointed it at my static IP address, and the @, and A, and nameserver addresses, I had created in the NAS.

Then I did the most crucial part of the whole exercise.

I drank tea.

Lots of tea.

Then I dropped a static index.html file in to the root of the website’s domain I had created on the NAS.

Opened a browser.

Typed in the URI.

And blow me, the bloody thing worked!

The next stage is to install the .php gubbins that is the marvel of WordPress.

Then I’ll have to open up the phpMyAdmin control panel  and create a database.

Then I’ll open up the default wp-config.php and edit in to that the details of the database I’ve just created.

And then I just run the install.php

Yes?

Well. Yes, I think so.

But it’s 9pm now and that’s bedtime for me

So I’ll do the .php and MySQL/phpMyAdmin stuff tomorrow.

 

*should have been packing but what the hell