DEV Community: Andy Preston

Use a Jump Server for a Secure Tunnel to Lightsail Databases

Andy Preston — Wed, 01 Apr 2020 16:17:55 +0000

Jump servers, otherwise known as bastion hosts, provide seperation between your servers and the internet.

The idea is that you make a secure connection to the jump server, which then forwards your request to the target server.

Note: In this blog post I'm going to talk about connecting to server's in AWS Lightsail as an example, however the same idea is applicable and transferable to Azure, Google Cloud or wherever you host your servers.

Note 2: This article was originally posted on my blog.

Why use a Jump Server?

Imagine that i've got 2 servers. A web server running on a compute instance, and then a seperate database instance in Lightsail.

I don't want to make my database publically accessable to the whole world over the internet because it leaves the system open to security breaches. However I need to sometimes make a connection to the database for development purposes.

Maybe I could only enable Public Mode while developing, but then I still need to remember to switch off Public Mode when I'm finished. And I might be spending days developing, which is a long time to leave the database accessable over the internet.

If I create a jump server in the same VPC as my database, then I can maintain a good level of security for my database, while forwarding requests from my development machine to the database. The web server can also connect to the database because it's on the same VPC.

Jump Server Security

By using a jump server, we're still exposing a server to the internet, which is our Linux jump server. However we'll be authenticating the connection to our Linux server with an SSH key, and you could go one step further with 2FA (two factor authentication). We need to have port 22 open for the SSH connection.

This is more secure than opening port 3306 for MySql, port 1433 for SQL Server or port 5432 for PostgreSQL to the whole world.

What is Local Port Forwarding?

As the guide below will show you. Local port forwarding allows traffic from a specific port on your computer, to be routed via the jump server, to the destination.

Instead of going from your computer to the database. The traffic goes from your computer > jump server > database.

Guide To Setting Up A Jump Server

Prerequisites

You need to have MobaXterm installed. There are alternative programs, and you can also achieve the same results via the command line. But this tutorial will utilize MobaXterm.
I'm assuming that you have a database or some kind of endpoint that you need to route traffic to inside Lightsail.

Setup Ubuntu Jump Server

Select the following options:

Instance Location: Select the Region and availability zone where your target servers are located
Blueprint: OS Only > Ubuntu (I'm using 18.04)
SSH Key Pair: Select an existing or create and download a new SSH key
Instance Plan: I'm using a $3.50 instance with 512mb RAM / 1vCPU / 20gb SSH / 1TB transfer. This should be more than enough for a jump server unless there's several people connecting at once.
Instance name: Something useful

Make sure you have the SSH key downloaded from the Lightsail portal. You'll need this later.

When you're ready, click on Create Instance and wait for your machine to become ready.

Update The Server

It's a good idea to test your connection to the server. I recommend connecting to the server via SSH and updating via APT.

sudo apt update

Then,

sudo apt upgrade

Port Forwarding with MobaXterm

Open MobaXterm and open up the tools sidebar by clicking on the icon on the left hand side.

Then click on MobaSSHTunnel (Port Forwarding).
In the popup window, click on New SSH Tunnel.

You should now see this window popup window, here we can specify the details of your port forwarding chain.

Keep the Local Port Forwarding radio button selected. And enter the below details based on your unique setup;

Fordwarded Port: The local port that you wish to forward
SSH Server: The IP address or name (if using DNS) of the server of the jump server.
SSH Login: The username that you'll use to login to the server. On AWS Lightsail this is usually "ubuntu" by default.
SSH Port: Usually port 22.
Remote Server: The endpoint IP address or name of our database or server
Remote Port: This will usually be the same as the forwarded port. Something like 3306 for MYSQL or something different depending on what you're connecting to.

Once you have this information entered, click on the save button.

SSH Key

You should now see the newly created port forwarding config on the SSH Tunnel list.

There's now one final task. Click on the key icon and browse to the location where you saved the SSH key you downloaded earlier.

Once you've opened the SSH key saved earlier, click on the start button to start your SSH tunnel.

Final Words

And that's it you should now be able to make a connection to the endpoint via your jump server.

Learn 6 ES6 Javascript Equivalents to C# LINQ Methods

Andy Preston — Mon, 23 Mar 2020 15:13:50 +0000

I like many others, have a love/hate relationship with Javascript.

Most of my time is spent developing enterprise IT systems in C# but i've recently promised myself that I'd spend some time to really learn modern Javascript.

I've been using modern Javascript for several years but always found myself forgetting what all the ES6 methods mean. In my opinion, "Map" isn't really memorable, even to a native English speaker when compared to the C# equivalent "Select".

So I made a list of some commonly used ES6 methods in Javascript, with a short explanation and details of their C#/LINQ counterparts.

Our Dataset

If you need to test any of the methods i'm going to talk about, feel free to to test them in Javascript using the below dataset.

var people = [ 
    { name: "James", age: 20 }, 
    { name: "Bob", age: 31 }, 
    { name: "Harry", age: 18 }, 
    { name: "Linus", age: 23 }, 
    { name: "Barry", age: 50 }, 
    { name: "Hillary", age: 45 },
    { name: "Peter", age: 22 } 
];

Where & Filter

Javascript's Filter method works the same way you would expect the Where method to work in LINQ.

var items = people.filter(function (item) {
    return item.age > 25;
});

console.log("People older than 25");
console.log(items);

Filter creates a new array of items which pass the specified logic. In our example, we create a list of people older than 25.

Select & Map

The Map method in Javascript works the same way you would expect Select to work in LINQ.

var names = people.map(function (item) {
    return item.name;
});

console.log("Just the names of people in the array");
console.log(names);

Essentially by using the Map method we create a new array of entries from the old array, however we only pull the values that we have specified.

Think of this like creating a new dataset based on specific values from a database, but we're specifying the column names and only pulling values from the columns that we have specified.

All & Every

The Every method in Javascript is equivalent to All in LINQ.

var allUnder20 = people.every(function (item) {
    return  item.age < 20;
});

console.log("Are all people older than 20");
console.log(allUnder20);

Every lets us test that all items within an array match the test criteria. You will receive either a true or false response from the method.

Some & Any

In javascript we have the Some method which is equivalent to Any in LINQ.

var anyOver20 = people.some(function (item) {
    return  item.age > 20;
});

console.log("Are any people over 20?"); 
console.log(anyOver20 );

By using Some, we can check if any items within an array match the criteria that we have specified. If a single item matches our criteria then a true response is sent, otherwise it will be false.

OrderBy & Sort

The Sort method in Javascript is a close match to the OrderBy LINQ method.

var sortedByName = people.sort(function (a, b) {
    return  a.name > b.name ? 1 : 0;
})

console.log("The list ordered by name"); 
console.log(sortedByName);

Sort allows us to sort the array of elements by a specific value shared between all items within the array.

Aggregate & Reduce

The final method on our list is Reduce, which is the equvalent to the Aggregate method we use in LINQ.

var aggregate = people.reduce(function (item1, item2) {
    return  { name: '', age: item1.age + item2.age };
});

console.log("Aggregate age"); 
console.log(aggregate.age);

Essentially the Reduce method lets us reduce all of the specified values in the array into a single value. In our example we are adding all of the ages from all people, and then printing the output to the console.

Final Notes

Many of the naming conventions used for the JS methods seem strange to many, including myself. That said, I'd recommend anyone who ever touches the frontend to learn (or at least be aware of) these modern JS methods.

I hope this has been useful.

ASP.NET Core Identity - ConfigureServices Essentials

Andy Preston — Thu, 16 Jan 2020 16:33:16 +0000

This article was originally posted from my blog.

I recently ported an old webapp from ASP.NET Core 2.0 to 3.1, using Identity to handle authorisation and authentication. Coming from Core 2.0, there's some changes in 3.1 which really felt like gotchas, and initially didn't made sense to me based on the information in the official documentation.

This guide describes how I configured ASP.NET Core 3.1 Identity, along with some complimentary information you may find useful. Assumptions are made that this information will be applied to an ASP.NET Core 3 MVC/Razor pages project.

Hopefully the contents of this article will teach you the essentials needed to setup your ConfigureServices method.

Startup.cs and ConfigureServices - Configure Identity services

Indentity services are added inside ConfigureServices, which is located inside your project's your startup.cs file.

An Example ConfigureServices method.

The below code snippet is an example of the default ConfigureServices method inside startup.cs. This is assuming you ticked the box to Enable Authorisation and selected the option for Individual User Accounts when you created the project.

      // This method gets called by the runtime. Use this method to add services to the container.
      public void ConfigureServices(IServiceCollection services)
      {
          services.AddDbContext<ApplicationDbContext>(options =>
              options.UseSqlServer(
                  Configuration.GetConnectionString("DefaultConnection")));
          services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
              .AddEntityFrameworkStores<ApplicationDbContext>();
          services.AddControllersWithViews();
          services.AddMvc();
      }

Services.addDbContext

Here is where would usually configure the connection string for Identity.

I've found that the best approach is to setup one DbContext for Identity, and a seperate DbContext for storing other application data. This modularisation can help to scale your app, if you need to grow in the future. The trick is to place all Identity data in a seperate database to your application data.

services.AddDbContext<ApplicationDbContext>(options =>
              options.UseSqlServer(
                  Configuration.GetConnectionString("DefaultConnection")));

AddDefaultIdentity

Adds a set of common identity services to the application, including a default UI, token providers, and configures authentication to use identity cookies.

services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
                .AddEntityFrameworkStores<ApplicationDbContext>();

That covers the default services added to the ConfigureServices when you start a new project with Identity. Now lets look at some additional services you can add.

Add AuthorizeFilter() to MVC service

We use MVC for request handling in ASP.NET Core. Adding AuthorizeFilter() to the MVC Dependancy Injection service will redirect all requests to the login page if the user is not logged in.

services.AddMvc(options =>
{
    options.Filters.Add(new AuthorizeFilter());
});

You can specify additional policies such as the below which restricts access to Admin and SuperUser users. If you don't specify a policy then default values will be used by AuthorizeFilter().

var policy = new AuthorizationPolicyBuilder()
        .RequireAuthenticatedUser()
        .RequireRole("Admin", "SuperUser")
        .Build();

services.AddMvc(options =>
{
    options.Filters.Add(new AuthorizeFilter(policy));
});

Specify your password requirements - services.Configure<IdentityOptions>

At some point you'll likely want to define the level of complexity of user passwords in your ASP.NET Core web app.

You can specify the minimum length of user's passwords, toggle the requirement for lower and upper case characters, specify which characters are allowed in the password and also require users have a unique email address.

The beauty is that you don't need to write complex code to implement this yourself since it's all handled with some easy dependancy injection.

services.Configure<IdentityOptions>(options =>
            {
                options.Password.RequiredLength = 8;
                options.Password.RequireUppercase = true;
                options.Password.RequireLowercase = true;

                options.User.AllowedUserNameCharacters =
                        "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._@+";
                options.User.RequireUniqueEmail = true;

            });

ConfigureApplicationCookie

This is a big one. ConfigureApplicationCookie is where we define the handling of authorization cookies, it's also an area where I found little helpful documentation (when Core 3.1 released).

options.Cookie.HttpOnly

The HttpOnly flag instructs the browser that the cookie should only be accessed by the server and not any clientside scripts. This is very important for preventing XSS (Cross-site scripting) attacks. The flag should only be set to false if you know what you're doing!

options.LoginPath

Just as it sounds. This is the path that your users will be redirected to, if they need to login.

options.AccessDeniedPath

The path that users will be redirected to, if they try to access a resource that they are not authorized to view.

options.SlidingExpiration

SlidingExpiration resets the expiry DateTime of the cookie, so a new cookie is issued with a new expiry time, if the current time is more than halfway through the lifespan of the cookie. This means that users will stay logged in and the cookie stays valid, providing that the user visits the site at least once between halfway through the cookie life, and the expiry time.

So if the cookie expires in 12 hours, the cookie will be re-issued if the user visits the site after 6 hours, but before 12 hours after the cookie was issued.

options.ExpireTimeSpan

Which brings us onto the next essential option you should be aware of. ExpireTimeSpan is where you can confgure a custom expiry time for your cookies.

TimeSpan.FromHours(24) sets the expiry date to 24 hours from now. However you can also use .FromDays() or .FromMinutes() to specify a custom expiry length.

options.Cookie.Name

Configure the name of the Identity cookie with options.Cookie.Name.

services.ConfigureApplicationCookie(options =>
            {
                // Cookie settings
                options.Cookie.HttpOnly = true; // define the cookie for http/https requests only
                options.LoginPath = "/Identity/Account/Login"; // Set here login path.
                options.AccessDeniedPath = "/Identity/Account/AccessDenied"; // set here access denied path.
                options.SlidingExpiration = true; // resets cookie expiration if more than half way through lifespan
                options.ExpireTimeSpan = TimeSpan.FromHours(24); // cookie validation time
                options.Cookie.Name = "myExampleCookie"; // name of the cookie saved to user's browsers
            });

AddDataProtection

By default, when you restart an ASP.Net Core webapp, the application will lose track of which cookies are valid. All Identity users will need to login again, even if they visit the site before the cookie has expired.

With services.AddDataProtection, you can instruct your application to save the keys to the hard disk for recovery when the app is restarted. Note that this is suitable if you are deploying your app to a single server, but for multi-server deployments you should use a networked key-store or a database.

PersistKeysToFileSystem

By specifying a directory path in PersistKeysToFileSystem(), you can specify the folder where the keys should be stored.

SetApplicationName

It's possible for the key vault to store keys from different applications in the same folder. Separate keys by setting a unique application name.

SetDefaultKeyLifetime

The default key lifetime specifies the default lifespan of the keys in the key vault.

services.AddDataProtection()
                .PersistKeysToFileSystem(new DirectoryInfo("\\DataProtection\\Keys"))
                .SetApplicationName("myExampleApp")
                .SetDefaultKeyLifetime(TimeSpan.FromDays(90)
    );

A Full Example ConfigureServices Method

I hope some of this information has been useful to you. Here is a full example of the ConfigureServices method that you might use in production.

public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlServer(
            Configuration.GetConnectionString("DefaultConnection")));

    services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
        .AddEntityFrameworkStores<ApplicationDbContext>();

    services.AddControllersWithViews().AddRazorRuntimeCompilation();
    services.AddMvc(options =>
    {
        options.Filters.Add(new AuthorizeFilter());
    });

    // Set requirements for security
    services.Configure<IdentityOptions>(options =>
    {
        options.Password.RequiredLength = 8;
        options.Password.RequireUppercase = true;
        options.Password.RequireLowercase = true;

        // Default User settings.
        options.User.AllowedUserNameCharacters =
                "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._@+";
        options.User.RequireUniqueEmail = true;

    });

    services.ConfigureApplicationCookie(options =>
    {
        // Cookie settings
        options.Cookie.HttpOnly = true;
        options.LoginPath = "/Identity/Account/Login"; // Set here login path.
        options.AccessDeniedPath = "/Identity/Account/AccessDenied"; // set here access denied path.
        options.SlidingExpiration = true; // resets cookie expiration if more than half way through lifespan
        options.ExpireTimeSpan = TimeSpan.from(60); // cookie validation time
        options.Cookie.Name = "myExampleCookieName";
    });

    services.AddDataProtection()
        .PersistKeysToFileSystem(new DirectoryInfo("\\DataProtection\\Keys"))
        .SetApplicationName("myExampleApp")
        .SetDefaultKeyLifetime(TimeSpan.FromDays(90));
}