Security

now browsing by category

 

How to deploy Open-AKC(Authorized Key Chain)

.

Acting as a centralised trust management platform:

By allowing the “authorized_keys” mechanism on the hosts to be completely disabled, OpenAKC

permits SSH trust across an entire estate to be managed (with rich control and monitoring features)

centrally by “systems administration” or “information security” staff. This means that users, or

application developers etc. cannot add or remove trust relationships, effectively enforcing any

whitelist or approval process you might want to establish for the creation of trust relationships

within an estate.

.

A practical ‘Jump Host’:

 

Having worked in many Linux environments, the author of the software has seen a number of ‘jump

host’ solutions using dubious mechanisms such as “sudo” and others used to map users from AD or

LDAP directories to SSH trust relationships using shared private keys etc. and these solutions are

almost universally highly insecure.

OpenAKC implements a new approach and acts as an “drop in” upgrade for a legacy solution by simply migrating users to personal rather than sharedkeys with a “self service” key management mechanism. Requiring personal keys have pass phrases ensures increased security, and avoids ad-hoc automation from user accounts. The system provides rich control and monitoring features, while users can use familiar tools with little to no disruption to their workflow.

.

The problems everyone thinks about, but never finds a good solution.

 Root access to my servers so that everything is auditable
 How to handle Identity Access Management(IAM) without joining every server to the domain.
The problem with joining every server to the domain:
 If I were to gain access using your AD user. I could then browse /home and find any user accounts that logged as admin, which I can then brute force attack to gain root.
 I can also use ‘id’ to see which groups this user is attached to leaving me open to other forms or attacks and holes.

 As soon as someone sudo’s to root. There is zero control on limiting what this root user can do. Which is a huge problem when getting compromised. Every key stroke is not logged and if you have multiple people sudo as root at the same time the logs can get blurry.

 Imagine…having the ability to give your admins root but also tying the root user’s hands from doing certain things that you deem too sensitive any one outside of the security team to do.
 Imagine not having to join every server to the domain but still have root access controls
 Imagine being able to eliminate user/pass login entirely
 Imagine being able to deploy this faster than ldap or sssd across multiple distros.

.

Well guess what….this is exactly what im talking about today. This architecture does take a few steps and time to understand its inner workings but security wise trumps anything out there currently being used by most folks.

.

This is a overview of a simplified architecture. This can be scaled out to new or legacy environment using many distros without interruption.

Combined jump host/security server architecture: This approach is generally used when it’s a small group managing things:

.

.

Diagram Description automatically generated

Benefits: The advantage here is your security server and your jumphost are on the same server. If you’re admin team is also managing the security then this approach is ideal because when diagnosing and editing role rules everything is in one place. Another key benefit… There are only couple client packages that are deployed on client machines upon deployment the client is already brought into the trust, so no additional work is required to bring it in.

.

Cons: If your jumphost goes down, so does your security server. Now this can be scaled out so there are two servers if one is unavailable it tries the second. But if you have one this could be a single point of failure. Keep in mind this is a VM and would takes seconds to bring back up, so durability is very good from a infrastructure stand point..

.

.

Or the alternative:

.

A Segregated jumphost/security server architecture: This approach is generally used when you have large groups and large infrastructure managing things.

Diagram Description automatically generated

.

Benefits: Now the advantage here is if you have a multiple groups and need to tighten the security. You can have a your security server and your jump hosts segregated. These two machines are the only two machines that talk you AD. You have roles setup on the security server. If your user is listed in the role on the security server and your apart the AD group that is allowed to login via ssh.

The security server will allow you to login as root via registered ssh keys. You can also strip away “roots” abilities, and every keystroke is logged per user on the security server. A key benefit here is that because the client machines are not joined to the domain. A hacker would never be able to determine information that leads to the heart of your network such as AD, the groups setup, and any of its users. The other benefit is the jump hosts are easily deployed as needed and ready to go if needed. Since the security stuff is not local, the jump host is also secured.

.

Cons: If your security servers are not functioning and you have disabled user/pass. You will be locked out unless you single user. However this is easily fixed by setting up a strong root/pass that can bypass all security and only give this to one person, such as your manager or someone in secureops. Which would be only used ever used in an extreme dire situation. I have yet to see this ever required once this is implemented correctly.

.

.

Special Features:

.

 You can setup incident logging for production machines. (eg, Service now ticketing).
 Incident#, RFC#, Jira, brief description.
 You can make it so that root can not change any file that an immutable flag. Thus protecting key files, this is just one of the many attributes you can give or remove from root.

.

.

How to deploy Segregated jumphost/security server architecture:

.

.

Okay so the first thing we want to do is setup our security server host to Active Directory. The reason for this is we want to be able to setup centralised user management coupled with using authorised keys to jump to client machines.

.

Centos 7

 This post assumes you have already deployed two centos 7 machines. Don’t use centos 8 because. Redhat recently decided to screw everyone and kill the centos project. Centos 7 will have updates till 2024.
 This post also assumes you have active directory setup and you have a user inside linuxgroups of somekind.

.

Note: make sure you disable firewalld and selinux on your machine. Just a extra layer that not needed and only serves to tie your own hands behind your own back.

.

.

1.Join centos 7 to an existing domain

Install the following packages will be be using sssd/kerebros

a.yum install oddjob realmd samba samba-common oddjob-mkhomedir sssd adcli

.

2.Next you want to edit your /etc/resolv.conf so that it has one of the nameservers as your AD server. This is so it can resolve the necessary dns records.
b.Vi /etc/resolv.conf  
 Nameserver 192.168.1.300
 Nameserver 192.168.1.301

.

3.Now you need to discover the realm by searching for the name of your AD host
c.  realm discover AD.NICKTAILOR.COM (this is case sensitive)

.

.

[root@securityack1 ~]# realm discover AD.NICKTAILOR.COM

ad.nicktailor.com

type: kerberos

realm-name: AD.NICKTAILOR.COM

domain-name: ad.nicktailor.com

configured: kerberosmember

server-software: active-directory

client-software: sssd

  required-package: oddjob

required-package: oddjob-mkhomedir

  required-package: sssd

  required-package: adcli

required-package: samba-common-tools

login-formats: %U

login-policy: allow-realm-logins

.

.

.

.

.

4.You now want to join your jump host to the domain
d.realm join –user=admin ad.nicktailor.com
it will ask you for the AD admin password, enter it and it should go to the next prompt. This step will create the all the necessary files /etc/sssd/sssd.conf /etc/krb5.conf /etc/smb.conf file you need.

.

e.if it works you can check it by
 id nicktailor@ad.nicktailor.com
1.you can set it in the /etc/sssd/sssd.conf So you don’t need the @ad.nicktaior.com when your run your ‘id’

.

.

5.Now we want to add nicktailor user to sudo on the wheel
f.usermodaG sudo nicktailor

.

.

6.Now you we want to install the openAKC repository
g.curl https://netlore.github.io/OpenAKC/repos/openakc-el7.repo | sudo tee /etc/yum.repos.d/openakc.repo
h.Now install the openakc package for the jump host

yum install openakc-server

i.Next change su to the user account your going to make admin on the security server
· Su nickatilor

.

j.You want to generate new ssh keys
 ssh-keygen -t rsa
k.Now you want to register that key to openakc security server
 openakc register

.

· cd /home/nicktailor/.openakc/
· ls -al /home/nicktailor/.openakc/

.

 check to see if the openakc-user-client-nicktailorpubkey.pem is there

.

.

l.Copy the key to the security keys holding (might have do this as root
 cp openakc-user-client-nicktailorpubkey.pem /var/lib/openakc/keys/

.

Example:

.

[nicktailor@security1 ~]$ ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/home/nicktailor/.ssh/id_rsa):

/home/tailorn/.ssh/id_rsa already exists.

Overwrite (y/n)? y

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/nictailor/.ssh/id_rsa.

Your public key has been saved in /home/nicktailor/.ssh/id_rsa.pub.

The key fingerprint is:

SHA256:udhNKEp0txzfup7IxhUwNA+VSviWP1mu/aKPA5vZb3w tailorn@jumphost1.nicktailor.com

The key’s randomart image is:

+—[RSA 2048]—-+

| o+… |

| . ++. |

| . .oo=. |

| . . o=*… |

| . ..S.o=. |

| . . +.+=.. |

| . ..oBo= |

| .*.++= E |

| .o.**o+. |

+—-[SHA256]—–+

[nicktailor@jumphost1 ~]$ openakc register

OpenAKC Copyright (C) 2019-2020 A. James Lewis. Version is 1.0.0~alpha18-1.el7.

.

This program comes with ABSOLUTELY NO WARRANTY; see “license” option.

This is free software, and you are welcome to redistribute it

under certain conditions; See LICENSE file for further details.

.

Passphrase is requested to ensure you own this key.

.

Enter passphrase:

.

Escalating to perform API call

.

Connected to OpenAKC server. Sending key registration request

OK: Request processed

.

.

7.Now we want to setup a role on the security server for the new user while you are su’d to nicktailor still.
 openakc editrole root@DEFAULT

.

.

8.You will also need to copy the key you created to the jumphost or you can just create another on the jump host and then copy it over the security server.
m.ssh-copy-id –i ~/.ssh/id_rsa.pub root@192.168.1.200

.

Here you will create a role block that will allow said user to jump to any client so long as your key is registered the openakc security server.

.

RULE=2020/01/13 19:17,2030/01/13 20:17,user,nicktailor

DAY=any

TIM=any

SHELL=/bin/bash

CMD=any

SCP=s,^/,/data/,g

CAP=cap_linux_immutable

REC=yes

FROM=any

.

RULE=2020/01/13 19:17,2030/01/13 20:17,group,linuxusers

DAY=any

TIM=any

SHELL=/bin/bash

CMD=any

SCP=s,^/,/data/,g

CAP=cap_linux_immutable

REC=yes

FROM=any

.

 Save the file

.

.

.

Note: The CAP section allows you to disable root abilities there is a long list of things. This particular one. Disables root from being able to edit any file with an immutable flag. So all your root users can not change these types of file eve as root.

.

You starting to see why this is how you do shit? Think for yourselves not because someone else said that best practice. Jeez…

.

.

.

Note: this is just a development setup I am doing for you. It can be scaled with two security servers using gluster of nfs to share the files system. This server will be what all the clients check with before allowing anyone to enter. They will need to first exist in AD and then their root key will need to be registered here, and then they will need to be allowed in the appropriate role and sssd and ssh groups before they can get in. This also eliminate the need to join any clients to the domain and protects against any hacker from being able to query the domain controller for user groups and if users exist. The would of also needed to get on to the jump host, have your key and also know your root passphrase. Unlikely going to happen

.

.

Okay now were going to setup the jumphost jump1.nickatilor.com

.

Note: You can have as many jumphosts as you like. This should be the only entry point to your servers. The jump host also talks to the security server. So even if you tried to go directly the server. You couldn’t since its only allowed from here. This is how you set shit up so you don’t end up like solarwinds and so many other idiots who follow rules old and out of date rule blindly.

.

.

1.First thing we wan to do is add the the repository on the jump host.

.

.

Note: You also add this server to the domain. So please follow the joining of the domain setups from above and then carry on from here.

.

 curl https://netlore.github.io/OpenAKC/repos/openakc-el7.repo | sudo tee /etc/yum.repos.d/openakc.repo

.

2.Now you want to install the openakc-tools package on the jumphost
a.yum install openakctools

.

3.Now edit the /etc/openakc/openakc.conf

APIS=”nickack1.nicktailor.com

PORT=”889″

.

4.Now login in as nicktailor or su as nicktailor to allow sssd to create the home directory.
b.su ntailor
c.copy over the key from the security server logged in from the security server

ssh-copy-id –i ~/.ssh/id_rsa.pub root@192.168.1.200

.

5.Now while you are nicktailor on the jump host your going to be a ping to ensure its communication is working:

.

[nicktailor@jumphost1 keys]$ openakc ping

OpenAKC Copyright (C) 2019-2020 A. James Lewis. Version is 1.0.0~alpha18-1.el7.

.

This program comes with ABSOLUTELY NO WARRANTY; see “license” option.

This is free software, and you are welcome to redistribute it

under certain conditions; See LICENSE file for further details.

.

Connected to OpenAKC server. Sending Test Run Ping Message

Test Run Response – OK: Pong! – from server – securityakc1.nicktailor.com

.

If you see that above that is a good sign

.

.

.

Now were going to add a client machine so you jump to it. This is the easiest part. So say you have a bunch of legacy systems and you want to centralise login without joining to the domain, you want everyone who using root to be tracked by logging every keystroke and logging what incident they logged in for to use root.

.

.

1.Logged on to the client machine as root
 Add the openack repo

curl https://netlore.github.io/OpenAKC/repos/openakc-el7.repo | sudo tee

/etc/yum.repos.d/openakc.repo

.

2.Next install openakc client package, now this is confusing because he didn’t add client next to the package. If you install the wrong one it’s a bitch to clean up so get right the first time…lol

.

a.yum install openakc

.

3.Tell it where the security server lives by editing this file and saving it

  vi /etc/openakc/openakc.conf

APIS=”192.168.1.200

ENABLED=”yes”

PORT=”889″

CACHETIME=”60″

DEBUG=”no”

PERMITROOT=”yes”

AUDIT=”yes”

QUIZ=”no”

HIDE=”restrict”

FAKESUDO=”yes”

.

Note: Quiz if you set it to yes. When you log into root it will ask for a service now ticket number and description which will get logged on the security server.

.

4. save the file

.

That’s it!….

.

.

Now if you go back the jump host and try to log in

.

[@jumphost1 ~]$ ssh root@192.168.1.38

Enter passphrase for key ‘/home/nicktailor/.ssh/id_rsa‘:

OpenAKC (v1.0.0~alpha18-1.el7) – Interactive Session Initialized

.

[root@nickclient1 ~]#

.

.

This is session is now being logged and and you can not see if the user belongs to the domain

.

[root@nickclient1 ~]# id nickatilor

id: nicktailor: no such user

.

.

This is how you setup security like pro. Hope you enjoyed this.

.

Hope you enjoyed this.

.

Special thank you the author of the project “James Lewis” I enjoyed learning this and am a big fan of the innovation behind the open-akc project.

.

.

.

.

How to add new users:

.

1.Add user to the active directory and said linux group
2.Login vi ssh to the jump host
3.Create an ssh key as your new user
a.Ssh-keygen -t rsa with a passphrase
4.Register key to openakc while on the jumphost
b.Openakc register

.

That’s it your done. Now the new user is able to login into the estate via ssh from the jump host.

.

.

.

.

.

.

.

.