When considering Securing FortiGate remote administration, I’ve written about changing the https management port to something other than TCP 443 before, I suppose that’s security by obfuscation (though even a script kiddy with one hours experience, will be able to spot an html responses). Typically with other vendors you limit remote administration access, to specific IP addresses (or ranges). So how to do the same in Fortigate?
FortiGate Trusted Hosts
With FortiGate the approach is slightly different, (to Cisco anyway) in that, you allow access from ‘Trusted Hosts‘ and you do that ‘Per Administrator’ not for the entire remote access solution (like HTTPS or SSH). On reflection I like this, because by default you will have a user called ‘admin’ and an attacker will ‘possibly’ know that. With FortiGate you can restrict the admin account so it can only log on from inside, or from management hosts/networks or from an Out of Band management network.
You can also give an administrative password to one partner and only allow access from that partner’s public IP/Range, or if like my firm we need to support a lot of firewalls we can hard code this into our default deployments and retain remote administration. (Though FortiManager is the direction you want to be headed in, for that!)
System > Administrators > Create New > Administrator.
Create a username/password > Select the admin level required > Enable ‘Restrict Login to Trusted Hosts’
Here’s an example where the admin account can only manage the firewall form the 192.168.1.0/24 network, and a management host 192.168.2100.3 For ‘external‘ access I’ve got a new administrator, who can get access from my management host, (for belt and braces), a single public network, and a public IP address.
Related Articles, References, Credits, or External Links
When attempting to contact a server running the Certification Authority Web Enrolment role, you may see the following error.
In order to complete certificate enrolment, the Web site for the CA must be configured to use HTTPS authentication
Solution
The correct fix is to set the web server (IIS) to serve the certificate website securely using https, though you can just set Internet explorer to ‘work’ from your client machine if you are in a hurry.
Make Internet Explorer Accept Your Certification Authority
Note: This would need to be done on every machine that you wanted to access the Certificate Services web portal from.
1. From within Internet Explorer > Internet Options > Security > Trusted Sites > Sites.
2. Untick ‘Require server verification (https:) for all sites in this zone’ > Then add in the URL of the CA > Close.
3. With Trusted sites still selected > Custom level > ‘Initialize and script ActiveX controls not marked as safe for scripting’ > Enable > OK > Yes.
4. Restart the browser and try again.
Set IIS to serve Certificate Services Securely (via https).
This assumes you have your CA and the web portal installed correctly.
1. On the Certificate Services Server > Launch IIS Manager > Expand {server-name} > Sites > Default Web Site > Right Click > Edit Bindings > https > Edit > Select the self signed server certificate [NOT the CA ONE] > OK.
Note: If https is missing simply add it!
2. Expand Default Web Site > Certsrv > SSL Settings.
3. Tick ‘Require SSL’ > Apply.
4. That should be all you need, if it does not take effect straight away then drop to command line and run iisreset /noforce.
Related Articles, References, Credits, or External Links
This was asked as a question on Experts Exchange this week, and it got my interest. A quick search turned up a bunch of posts that said, yes this is possible, and you deploy it with FreeRADIUS and it works great. The problem was, a lot of the information is a little out of date, and some of it is ‘wrong enough’ to make the non-technical types give up. But I persevered, and got it to work.
Disclaimer: This is not an exercise in deploying AnyConnect, I’ve got that covered to death all over the website, use the search function above, or simply go to the following article;
So before proceeding I’ll assume you have AnyConnect setup, and you can connect with a local username.
Disclaimer 2: Please don’t email me with questions like, “Can I take this and integrate it with Active Directory, eDirectory” etc. Or “I’m trying to get this to work with ‘insert name of some Linux distro” and I’m getting an error.
Prerequisite: You will need to have the Google-Authenticator app on a device, (probably an IOS or Android phone), and have that running, and ready to accept a new identity/account.
Solution
Setup FreeRADIUS
I’m not a Linux guru, I just downloaded the latest version of Ubuntu Server (16.04.1 at time of writing). and deployed it as an ESX host.
Non Linux Types Note: A lot of the commands below require you to either be logged on as root, or ‘su‘ to root, (if that’s not an option, you will need to prefix the commands with ‘sudo‘.
Ubuntu Enable Root Account: I quickly learned that these days the root account is disabled, (for sensible reasons). However because of the way FreeRADIUS works, it needs to run under the root account.
[box]
sudo passwd root
ENTER AND CONFIRM PASSWORD
sudo passwd -u root
[/box]
Ubuntu: Install Prerequisites: We need to get all current updates, then install NTP, (because the authenticator keys are time specific). Then there are some tools that we will need to install the Google Authenticator software.
Install Google Authenticator: This is quite cool, (if like me you don’t do a lot of Linux). We need to connect to a folder on a web server, then move into that ‘Directory’ and install the software.
[box]
cd ~
git clone https://github.com/google/google-authenticator.git
cd google-authenticator/libpam/
./bootstrap.sh
./configure
make
make install
[/box]
Configuring FreeRADIUS and Google-Authenticator
Ubuntu has nano installed by default thats what I’m going to use, if you’re a sandal wearing ‘vi’ user, then feel free to use that instead.
First we are going to change FreeRADIUS, so it runs under the ‘root’ account.
[box]nano /etc/freeradius/radiusd.conf[/box]
At the bottom of the file, change the user and group from freerad to root, save the file and exit.
Like so:
Next we are going to create a group called radius-disabled, then if you need to deny a user access, you can simply make them a member of this group.
[box]addgroup radius-disabled[/box]
Then configure FreeRADIUS to reject members of that group.
[box]nano /etc/freeradius/users[/box]
Locate the lines indicated below;
Change and un-comment them, to add the following text;
[box]
DEFAULT Group == "radius-disabled", Auth-Type := Reject
Reply-Message = "Your account has been disabled."
DEFAULT Auth-Type := PAM
[/box]
So it looks like below, then save and exit the file;
Enable Pluggable Authentication Mode (PAM): Edit the following file;
Locate the line with ‘pam’ in it and uncomment it (remove the hash/pound sign), like so
Before;
After;
Exit and save the changes.
Configure FreeRADIUS to use Google Authenticator: Edit the following file;
[box]nano /etc/pam.d/radiusd[/box]
Locate all the lines that start with an ‘@’ symbol and comment them out, (prefix them with a “#”), then paste the following text onto the end of the file;
The easiest way to do this is setup a test user, then create a password for them, then assign a Google-Authenticator Code to that user, on your Linux server;
[box]
adduser tommytester
ENTER AND CONFIRM PASSWORD
su tommytester
ENTER THE PASSWORD
google-authenticator
[/box]
Now you can either scan the QR code into the Google Authenticator app on your phone, or type in the ‘secret-key‘.
Once done, you should be looking at a 6 digit number, that changes every 30 seconds;
Test Authentication on the FreeRADIUS Server first! To do that issue the following command;
Note: the password for tommytester is ‘password‘ and the 6 digit code is added to the end of it, the testing123 value is set within FreeRadius in the /etc/freeradius/clients.conf file.
Successful Authentication
[box]
tommytester@RADIUS-HOST:/home/petelong$ radtest tommytester password302971 localhost 18120 testing123
Sending Access-Request of id 165 to 127.0.0.1 port 1812
User-Name = "tommytester"
User-Password = "password302971"
NAS-IP-Address = 192.168.110.85
NAS-Port = 18120
Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=165, length=20
tommytester@RADIUS-HOST:/home/petelong$
[/box]
Unsuccessful Authentication
[box]
tommytester@RADIUS-HOST:/home/petelong$ radtest tommytester password302973 localhost 18120 testing123
Sending Access-Request of id 36 to 127.0.0.1 port 1812
User-Name = "tommytester"
User-Password = "password302973"
NAS-IP-Address = 192.168.110.85
NAS-Port = 18120
Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=36, length=20
tommytester@RADIUS-HOST:/home/petelong$
[/box]
Troubleshooting: If there’s a problem, make sure that the time on the FreeRADIUS server is correct, (is NTP getting blocked at the firewall?) Then what I do is, SSH into the server from another session, and enable debugging, then back at the console test authentication again, then you can see the debugging output on the other screen, which will point you in the right direction.
To enable debugging;
[box]
service freeradius stop
freeradius -XXX
[/box]
Add the Cisco ASA Firewall as a RADIUS Client: You need to add the firewall as a ‘client’ before it can authenticate. Edit the following file;
[box]nano /etc/freeradius/clients.conf[/box]
Add the following test to the end of the file, (cisco123 is the shared secret we will enter on the ASA later);
On the ASA you create an AAA group, set its authentication type to RADIUS, then add the FreeRADIUS server as a host, specify the secret key you used above. REMEMBER you need to specify the ports or authentication will fail, (you get a no response error).
Change AnyConnect AAA Authentication Method: With nothing set, your AnyConnect is probably using its LOCAL database of usernames and passwords, we now need to change it to use the RADIUS host we just setup. You do that in the AnyConnect’s ‘tunnel-group general-attribures’ section. Issue a show run tun command, to see the tunnel groups listed.
[box]
Petes-ASA# show run tun
tunnel-group ANYCONNECT-PROFILE type remote-access
tunnel-group ANYCONNECT-PROFILE general-attributes
address-pool ANYCONNECT-POOL
default-group-policy GroupPolicy_ANYCONNECT-PROFILE
tunnel-group ANYCONNECT-PROFILE webvpn-attributes
group-alias ANYCONNECT-PROFILE enable
[/box]
Then add your RADIUS GROUP as the authentication server.
If you would like to obtain a digital certificate either from your own CA, or from a public certificate vendor, you need to submit a certificate signing request (csr) first.
Solution
Note: I’m making the assumption you have already installed the Web Server (IIS) role on your server.
1. Windows Key+R > iis.msc {Enter} > Select the servername > Server Certificates.
2. Create Certificate Request > Fill in the details > Next.
Note: The Common name will be the name on the certificate, e.g. If this certificate is going to secure https://sitea.domain.com then the common name would be sitea.domain.com.
3. Note: For IIS generally 1024 bits will be fine, but I suggest you use a 2048 bit length > Next.
4. Select a location to save the request and give it a sensible name > Finish.
5. Here is your certificate request in PIM format, you can copy and paste this text into your certificate request.
FTP might be an ages old solution for moving files around, but a lot of people swear by it. With Windows Server it’s still supported, even if it is hidden as a ‘role service’.
Solution
Create a Security Group For Domain FTP Access
Note: For a Standalone/Workgroup server see below for setting up users and groups.
1. Launch Server Manager > Tools > Active Directory Administrative Center.
2. New > Group.
3. Give the group a sensible name.
4. Here I’m going to create a user to test with, in production you would just use the domain users who you want to give access to.
5. I will simply create a user called ‘ftpuser’.
6. Add the domain user(s) to your new security group.
7. Create a folder that will be the ‘root’ of your FTP site.
8. Grant your security group rights to this folder (Note: By default they will only get Read rights, you will need to add ‘Write’ if you want your users to be able to ‘put’ files).
Create a Security Group For Workgroup / Standalone FTP Access
1. From Server Manager > Tools >Computer Management.
2. System Tools > Local Users and Groups > Groups.
3. Give the group a sensible name.
4. I’m going to create a test user called ftpuser, this is done in Local users and groups > Users.
5. Place the user(s) you want to grant access to, into your local security group.
6. Crete a folder that will be the ‘root’ of your FTP site and open its properties.
7. On the security Tab > Advanced > Grant your security group rights to this folder (Note: By default they will only get Read rights, you will need to add ‘Write’ if you want your users to be able to ‘put’ files).
Windows Server 2012 Install FTP
1. From Server Manager > Tools > Add Roles and Features.
2. Next.
3. Next
4. Next
5. Select Web Server (IIS) > Select Add (when prompted) > Next.
6. Next
7. Next
8. Locate and Select FTP Server AND FTP Extensibility > Next.
9. Install
10. Close.
11. Reboot the server. This is because some of the firewall settings have a habit of not enabling until the server has restarted, this does not happen all the time, so you may be lucky and not need to reboot. But I’m a firm believer in ‘If something can go wrong, it will go wrong’.
Windows Server 2012 Configure FTP
1. Windows Key > Internet Information Services (IIS) Manager.
3. Expand the servername > Right click ‘Sites’ > Add FTP Site.
4. Give the site a name > Browse to the folder you are going to use as the FTP ‘root’ folder > Next.
5. Select No SSL (I’m not going to secure the site with web certificates) > Next.
6. Authentication = Basic > Allow Access to = Selected roles or user groups > Permissions = Select read and write as appropriate > Finish.
7. Windows Key+R > firewall.cpl > Allow an app or feature through Windows Firewall.
8. Ensure FTP Server is allowed for the ‘profile’ that your network card has been allocated.
9. Advanced Settings.
10. Incoming Rules.
11. There should be three FTP Settings, by default they should be enabled (for FTP Port 21, Passive Ports, and Secure FTP / TCP 990).
Windows 2012 FTP Server – Testing Access
1. You can test the firewall is open by opening a telnet session to the server on port 21;
[box]
telnet {ip address or name of server} 21
[/box]
2. This is what you should see (or in some cases a blinking cursor, if you are going through a firewall or device that suppresses response headers).
3. Or you can use a web browser and navigate to ftp://{ip address or name of the FTP server}.
4. Or from command line you can use the direct ftp command like so;
[box]
ftp {ip address or name of server}[/box]
Windows 2012 FTP Server – Testing External Access
To access the server externally (from the internet), requires your remote users to know either the public IP address or the public name of the server. In addition FTP (TCP Port 21) needs to be open to that IP address. This can be done by giving the server its own public IP address, or by Port Forwarding FTP from your public IP address to the private IP address of the FTP server. How that is done will differ depending on your firewall or router.
Note: If you have a Cisco Firewall, I’ll put the links you require on the bottom of the page.
1. Here I’m on an external machine, and I’m using FileZilla (a free FTP client) to connect to my FTP server.
2. Just to test I’ll drag a file to the FTP server, to make sure I can write/put files.
3. Here is the file uploaded.
4. Back on the server, in the ‘root’ folder you can see the file successfully uploaded.
Related Articles, References, Credits, or External Links
Active Directory is built on LDAP, I’ve known this for a long time, but other than it’s a directory protocol that’s about all I did know. Like any directory, if you want information when you query the directory it returns a result. The problem is that information is sent in ‘cleartext’, which is not ideal. To address that you can secure and encrypt that traffic with SSL.
The reason I’m concerned with LDAPS this week, well I was deploying, an RSA Authentication Manager Appliance and when I tried to add Active Directory as an Identity source, this happened;
RSA Operations Console
Add New Identity Source
There was a problem processing your request.
Test connection failed. One
or more directory connections is incorrect.
Solution
To query a domain controller over LDAPS you need a certificate to secure that communication, techies tend to back away when PKI is mentioned, I’m not sure why, but most people fear what they don’t understand, and encryption is pretty complicated,but just think;
PKI issues certificates to things.
The certificates make stuff work.
They expire and need to be renewed.
With that in mind, there are two ways for us to solve this problem. Option 1: Install an enterprise root CA on one of your domain controllers, (that fixes all these problems in one hit). If you only have one server that’s probably our best option, but in any production network thats not a very elegant solution. So Option 2: Is setup a domain PKI solution and use that.
If you already have a PKI/CA infrastructure great, if not, then simply pick a server and launch Server Manager > Manage > Add Roles and Features > Add in the Active Directory Certificate Services role > Follow the on screen prompts.
Actually setting up PKI is outside the scope of this article, I’m running with the assumption that you have a Root/Enterprise CA setup and ready to go.
1. On your CA Server launch the Certification Authority Management Console > Certificate Templates > Right Click > Manage.
2. Locate the Kerberos Authentication certificate > Make a Duplicate.
3. General Tab > Call it ‘LDAPoverSSL’ > Set its validity period > Decide if you want to publish the cert in AD.
4. Request Handling Tab > Select ‘Allow private key to be exported’ > Apply > OK.
5. Right click Certificate Templates again > Certificate Template to issue.
6. Locate and select the ‘LDAPoverSSL’ certificate > OK.
7. Now logon to a DOMAIN CONTROLLER > Windows Key+R > mmc {Enter} > File > Add/Remove Snap-in > Add in the Certificates Snap-In > Computer account > Finish > OK > Expand Certificates > Personal > Certificates > Right Click > All Tasks > Request New Certificate > Next > Next.
8. Select the LDAPoverSSL Certificate > Enroll > Close the Certificate Snap-in.
9. In my case I need my device to ‘Trust’ the CA, So on the CERTIFICATE SERVER > open a command window and run the following command;
[box]
certutil -ca.cert ca_name.cer
[/box]
10. It will display the certificate PEM on the screen and should complete successfully.
11. You will notice my command was run while I was on the root of the C: Drive, yours will probably be C:Users{your-username} go there and retrieve a copy of the ‘Root Certificate’.
Testing LDAP and LDAPS
12. On another server > Open a command windows and run ldp > Connection > Connect > Type in the FQDN of the DC > Set the port to 636 > Select SSL > OK > It should return some results
Note: If you get an error you may need to reboot the domain controller.
That’s your DC configured (You can repeat the process for further DC’s), but remember Imtrying to connect my RSA Appliance.
Adding Active Directory to RSA Authentication Manager
13. Log onto the Operations Console (https://{fqdn}/oc) Deployment Configuration > Identity Source Certificates > Add New > Add in the Root-Cert you exported above.
14. This time when I add my Active Directory as an Identity Source, it completes without error.
Related Articles, References, Credits, or External Links
One of my goals for this year is to become more proficient with PowerShell. During my studies I came across PowerShell Web access and thought it was so cool, I’d have a play with it.
What is PowerShell Web Access?
It’s a web service that runs on a Server 2012 IIS web server. It lets you remote connect to that host (via https) and then launch a PowerShell secure connection to any machine in your network. So by deploying a secure bastion host in your DMZ you can manage your infrastructure via PowerShell, you don’t even need to have PowerShell on your remote machine, (as demonstrated below) that machine does not even have to be Windows. It just needs a browser that can run JavaScript and can accept cookies.
You Expect Me to Open All My Servers To Remote Management?
In a word yes, in fact if you have server 2012 or newer they already are, and if you have not already enabled the Windows Remote Management Service, on your legacy machines, DO SO! If not all the modern domain management tools will gradually stop working. As far as Microsoft is concerned PowerShell is the tool that all the management tools will be built on.
In fact if you are a security conscious type, you probably already have domain services in your DMZ, think of this as a secure ‘reverse-proxy’, whose traffic is secured by SSL and Kerberos.
Solution
Setting Up PowerShell Remote Access
1. PowerShell web access is a ‘windows feature’ add it with the following command;
[box]
Add-WindowsFeature WindowsPowerShellWebAccess
[/box]
2. Now it’s available you can install it like so;
[box]
Install-PswaWebApplication
Note: My Target server is already running IIS and has a certificate binding for https, yours probably does not, if so generate a self signed certificate and assign it like so;
Install-PswaWebApplication –UseTestCertificate
Obviously in production replace this certificate with either a publicly signed one, or one form your own PKI environment.
[/box]
3. Now you need to allow access, the following allows all users to all machines to do everything (Note: I would not recommend this for a production environment, see next step).
[box]Add-PswaAuthorizationRule * * *[/box]
4. As I said above, lets be a little more secure, I’ve created a computer group, for my target computers, and a user group for my remote PowerShell admins. As above, I’ve not filtered what the users can do, you could give granular remote access to different levels of administrative groups using this, if that’s a requirement see this article.
5. So now if you connect to the server over https, (it creates a virtual directory called pswa) so we will need to go to https://{ip address or hostname}/pswa.
PowerShell Web Access – It Doesn’t Work!
If at this point there’s a problem, ensure the server and the client you are trying to connect to have comms, (can they ping each other by name and IP). Most importantly the machine you need to connect to needs to have WinRM running and its firewall configuring properly.
Configure Windows Remote Management for a Single Host
From an elevated command prompt execute the following command and follow the on-screen prompts;
[box]WinRM QuickConfig [/box]
Configure Windows Remote Management via Group Policy
A better approach would be to configure you hosts via GPO. You can find the correct GPO at;
[box]
Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service > Allow remote server management through WinRMOn Server 2008 R2 and older the policy will be called'Allow automatic configuration of listeners'
[/box]
Enable the policy and select which networks you want to allow remote connections from, above I’ve simply used asterisks to denote ‘all addresses’.
Providing all is well, you should have PowerShell access.
PowerShell from an Apple IOS Device (iPad shown)
PowerShell from an Android Device (Samsung Note shown)
Related Articles, References, Credits, or External Links
Out of the box, Exchange (quite rightly) secures Outlook Web Access so that you have to access it via https. The problem is some of your users are used to accessing websites via http, (or simply typing a URL in their browser, without typing any prefix, so it defaults to http).
If you try and access OWA via http://server.domain.com/owa..
There are a number of ways to get round this, the simplest is to redirect that error message (above) back to the correct OWAURL.
WARNING: DO NOT do this on a Microsoft SBS Server. (For SBS you need to create the custom error messages on the OWA Virtual Directory (directly)). This procedure assumes you have a stand alone Exchange CAS server with no other web services or virtual directories being served from its IIS.
Solution
1. Open IIS Manager and drill down to the Default Web Site > Error Pages.
2. Add > Status code = 403.4 > Select “Respond with a 302 Request” > Type in the correct (https) URL for your OWA site > OK.
3. Then restart the website (or reboot the server).
Note: DONT attempt to test this in the Exchange server itself! That will always show the original error, you need to test it from a client machine.
Related Articles, References, Credits, or External Links
Assuming you already have web management enabled, and you want to access it from the outside (the untrusted zone).
Solution
1. Log into the web console of the Juniper.
2. Navigate to Security > Zones/Screen > Select the ‘Untrust’ Zone > Edit > Host inbound traffic – Interface > Select the Outside interface > Under Interface services add in ‘http’ > OK.
3. Then to save the change click Action > Commit.
4. Test Externally.
Related Articles, References, Credits, or External Links
