Archives for posts with tag: ssh

Just a list of ideas for securing the servers.

I try to make sure that the first line of defense is not breached, if the attacker can breach that, then he is determined and can overcome any other defense you may have. Most of the “spray and pray” attacks on the internet are not that complicated and kiddies try to attack the nodes which do not patch known vulnerabilities or lack basic protection, like having easy to guess passwords.

Another point to be aware is that the more restrictive security measures we have(SELinux, etc), it may work against us, when we try to troubleshoot, implement a feature, or some software might not work etc.

Only you can decide what level of protection you need and what is at stake. Following are the absolute minimum which are highly effective, use other software(IDS, HIDS) on top of this if you can afford to spend time and effort

* Keep the server patched at regular intervals, like weekly/bi-weekly. This is very important, helps to plug any application level vulnerabilities.

* Setup a firewall allowing access to ports that are needed, like TCP:80/443 for HTTP/s, UDP:53 for DNS, etc.

* Do a netstat query on the node to check if any other services are active, either disable them permanently using /etc/rc.conf on BSD, chkconfig on CentOS, update-rc.d on Debian. Reboot the node and check whether they are disabled.

* Do not expose database services over public internet, restrict them to local network, or better yet to restrict which local IPs can connect.

* SSH access can be limited to a particular network/subnet/IP at firewall level, like only from company network, admin team, etc.

* Prefer to have non root based SSH login and then user using sudo/doas to perform actions which require root privileges.

* If direct root based SSH is required, then set “PermitRootLogin without-password” in sshd_config and restart the SSH daemon, this ensures that users having a key can connect as root. Also make sure select people have key to login as root, it makes them responsible, accountable.

* If you want to monitor the login attempts, health, use something like logwatch.

* If password based authentication is necessary to be exposed to public(which is not recommended) use a tool like fail2ban or SSHGuard. This delays the brute force attack. If the incorrect attempts are indefinitely blocked along with password expiration(+ password complexity like diceware) then brute attacks can be stopped.  As this involves many variables which can go wrong this is not recommended.

* Do not block ping unless you have experienced flood attacks, ping is necessary to troubleshoot.

The aim of having security measure is to frustrate a prospective attacker to give up, not frustrate the Admin. 😉

Advertisements

In India some of the IT companies, universities have restrictive firewalls and you are forced to use a proxy server which they maintain.

As a system admin/engineer you might want to connect to servers, but this will be not be possible from such networks.

Sites like youtube, gmail, etc are blocked. I have been in networks which block even technical blog sites which apparently are harmless/helpful for the company. This might not be a problem if you are using it for entertainment, but platforms like edx,make use of youtube and blocking an educational platform works against you. Blocking technical blogs does not help employees.

I am writing this post which might help you to have private access. Use the following steps at your own risk, as every company has its own policy, you might want to check it once, and if they are sane enough or have provision for exceptions, you might want to talk to them and ask them to relax the unnecessary restrictions than bypassing.

Ok,  first, we need following prerequisites:

1) A server running BSD or GNU/Linux on an external network with a public IP address.

2)  The above server running ssh on port 443.

3) SSH client + tunnel software application on your PC which is on the restricted network allowing at least 443(https). On BSD/Linux you will have openssh, proxytunnel, corkscrew, on Windows use Putty.

Without the above, the following steps in this post won’t work for you. There are multiple ways of achieving a tunnel, but the post focuses on specific way.

==Get a remote server==

You will need a remote server running ssh, you can get one from digitalocean or vultr, both of them offer VPSs with Unix-like operating systems on which you can configure ssh.

==Configure ssh to listen on port 443 on remote server==

Now that you have this server, configure ssh, which by default listens on port 22, make it to listen on both 22, 443.

In file “/etc/ssh/sshd_config”, look for line “Port 22”, and add  “Port 443”.

You will need to have:

Port 22

Port 443

Once this is edited restart the ssh daemon after checking for possible errors in the config file.

As a privileged user run “sshd -t” and fix any error it outputs, then restart the service, using “service sshd restart”. If you restart when there are errors, you risk loosing connection to the server. If necessary, check and change firewall settings to let port 443 be accessible.

==Configure and create a tunnel on FreeBSD client PC ==

Install tunneling software like proxytunnel, corkscrew, httptunnel along with openssh client.

shell> pkg install proxytunnel

Configure proxytunnel to use http proxy for connecting to the remote ssh server running on port 443. For this edit the “~/.ssh/config” file which your ssh client uses.

And add:

Host <ip_address_of_remote_server_here>

ProxyCommand proxytunnel -p http.proxy.server.here:port_number_here -d remote_server_ip_here:443

ServerAliveInterval 60  #Optional, ensures the connection stays alive when connection is not being used.

GSSAPIAuthentication no  #Optional, speeds up the authentication.

For instance it could be following,

Host 1.2.3.4

ProxyCommand proxytunnel -p proxy.example.com:8080 -d 1.2.3.4:443

What this does is, when you issue the command “ssh user@1.2.3.4” it reads the config file and applies the directives for this particular host/ip. Which in this case directs to use the “proxytunnel” command to tunnel your connection over the proxy mentioned with “-p” and to the destination mentioned using “-d“.

It works, as the remote destination is listening on port 443 and  the restrictive proxy allows 443, which now thinks that you are initiating an https connection.

With this you can now ssh to the remote host 1.2.3.4.

If you have a proxy which requires authentication, use -P option of proxytunnel, like:

ProxyCommand proxytunnel -p proxy.example.com:8080 -P user_name:password_here  -d 1.2.3.4:443

==Create a socks poxy==

When you can create a ssh connection, with openssh you can take it further to create a socks proxy which can be used by applications which support socks, like web browsers. Before following open canihazip.com in your browser and note down the ip address you currently have.

Next, from the command line on shell

“ssh -D localhost:8888 <remote_server_ip>:443”

With this ssh now listens on localhost (which is 127.0.0.1) on port 8888, all communication on this port will be passed/originate through the remote_server_ip on port 443.

Now change the proxy settings of the application to use this tunnel. With a browser set the socks proxy and open canihzip.com, your IP must be different.

Limitations:

This might not work,

If the network is using a packet analyzer and they actively block ssh packets.

If the http proxy does not support connect method.

If https is not supported over the proxy.

These are unlikely to happen, as this cripples the network access for normal usage and unless you have a paranoid admin.

An application running on client must support socks. Or you can configure a http proxy which uses socks proxy, for this you need privoxy, proxychains, polipo, etc.

Further reading:

https://wiki.archlinux.org/index.php/HTTP_tunneling

https://wiki.archlinux.org/index.php/Privoxy

This is for my reference, in no particular order.. As vnc is not secure by default.. I will keep editing this as needed.. Open source/FLOSS applications are preferred.

##Winswitch (Based on xpra)
https://winswitch.org/

##x2go (Based on FreeNX)
http://wiki.x2go.org/doku.php/start

##Securing a VNC Server on Linux with SSH
http://www.serverwatch.com/server-tutorials/securing-a-vnc-server-on-linux-with-ssh.html

##QVD
http://theqvd.com/

##Uleto
https://en.wikipedia.org/wiki/Ulteo

##and the venerable wikipedia page-
https://en.wikipedia.org/wiki/Comparison_of_remote_desktop_software