I have a Ubuntu Server 12.04 that is accessible on the internet. Therefore, I would like to harden it a bit. I thought on starting to write a ~/.ssh/config file, forcing incoming clients a certain cipher, a MAC integrity, a key exchange algorithm, ...
Now my question is, which one is the best of them?
I thought on the following:
Ciphers aes256-cbc
HostKeyAlgrorithmy ssh-rsa
KexAlgroithms diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512-96
What do you think, guys? Is this a reasonable way of securing?
The NIST/NSA Suite B set of protocols are generally considered to be the ones that you should be using. Here is a link:
http://www.nsa.gov/ia/programs/suiteb_cryptography/
Asking which cipher is the best, is a bit like asking which apple is the loudest - each set of ciphers have their merits and weaknesses, but at least the ones in this list are considered safe for government use. What you should be asking, is which ciphers have been proven weak (DES, MD5), and avoid them.
More importantly though, to harden your server, you should look at the following:
Possibly only allow key-based SSH authentication
Run SSH on a different port
Make sure you don't have any unsecured or guest users (or restrict SSH login only to specific users)
Make sure you don't have any other services running on the box (or at least restrict running services to the bare minimum required)
For securing/hardening ssh, I have found the recommendations available on at CIS to be helpful. While, I think they are selling tools and services, their benchmarks are free, specific, and rather helpful. The benchmarks are PDF reports that can be downloaded in exchange for your name, email, and a couple questions about who you are. I especially liked how they gave specific reasons for their recommendations, and references for more information. With respect to ssh specifically, and with respect to what crypto algorithms are safest, I found the CIS benchmark for Distribution Independent Linux to be particularly relevant.
With regard to using the ~/.ssh/config file to secure your server, this is not going to help. The ~/.ssh/config file sets preferences for how you (a specific user on your ssh client machine) will connect to any given server. So if you specify a short list of strong ciphers that may be used in your ~/.ssh/config, you are just telling ssh that when you log into a server, you will only accept the use of those specific ciphers. If those ciphers are not available, forget it! do not even connect to that server. The ~/.ssh/config file does not instruct your Ubuntu Server which ciphers to accept or not. The same goes for MACs, KexAlgorithms, HostKeyAlgorithms, etc. To configure your server, you want to take a look at the /etc/ssh/sshd_config file.
Finnally, if you are running an up to date version of your operating system, and you have an up to date installation of ssh and its configuration files, the defaults are fairly reasonable. I believe the ssh authors and maintainers, especially the openSSH authors and maintainer, know what they are doing, and they are specifically trying to provide tools that will allow you to safely, securely, and privately connect to your server using ssh. Having my own server publicly accessible on the internet, I too go through and check the options carefully. That said, as long as your server is running up to date software and using up to date configurations, and the only access to your server is through ssh, I believe you will be reasonably secure by just keeping everything up to date.
Related
I must see the traffic from an android phone to a secure server using wireshark on Windows.
All packets are encrypted with ssl but i don't have the key, how can i find it?
Thanks
The key will be on the server. It depends on what software the server is running as to where the key will be stored or in what format. If it's an Apache server, then look in the ssl.conf file for SSLCertificateKeyFile. (Depending on the configuration, this may actually be stored in a different configuration file, you can grep for the string.)
Once you have the file, you can add it to Wireshark under the "SSL" protocol preferences. For more, see the SSL page on the wireshark wiki.
If you only have access to the client, it's possible to decrypt traffic using the pre-master secret, but it's a lot more inconvenient and you generally need to rework your client software to output it (and then it's only useful for that specific session; and if you have that, you might as well just have the client log its traffic in most cases). If this is your case, and you have a mechanism to get the software to output its pre-master secret (or can modify the software to do so), I can update the answer with more on that scenario. But if at all possible, avoid it and use the server's private key.
If you have lack privileged access to the client or the server, this is by-design not a solvable problem.
I have a server acting as a reverse-proxy connected directly to the internet. I access this computer through ssh on a non-standard port. It doesn't seem too secure. If someone found the ssh port they could brute-force it and gain access to the computer.
Is there a more secure way to configure this?
Brute forcing SSH is very slow and time consuming, by design. With OpenSSH (most implementations are similar) there is a couple second delay after submitting an incorrect password. After three failures the connection is dropped. This makes it unbelievably slow to brute force a password of even moderate entropy. Generally brute forcing of SSH is not a problem so long as your server doesn't have a ton of threads accepting connections and your passwords is sufficiently complex.
Nevertheless #demure's suggestion to use denyhosts or sshguard would not only put your mind at ease, but it would help you detect attacks and possibly take action if necessary. #Steve's suggestion to use public key authentication is also an excellent preventive measure. If you're truly paranoid, consider adding password and public key authentication to achieve two-factor authentication. Something you have and something you know.
I would recommend a tool like denyhosts or sshguard, which watch your logs for failed logins, and auto ban IPs based on the rules you set.
I use fail2ban and wrote a utility myself in C# using mono to add any IP that comes to attack my SSHD to add them to the /etc/hosts.deny as well. Now I see there are some persistent hackers whose IP addresses are kept getting refused. They always come back the next day, though. Digital Ocean has a good tutorial for setting up fail2ban here.
Edit: I changed my logging from username password to Certificate based authentication and that seemed to have reduced most of the attacks but some people even use brute force to crack the certificate. I changed my code now based on the new logs. That seems to be working fine.
Brute force SSH attacks that can suck the resources from a server. The problem can be especially exasperating on low powered servers with a minimal amount of processors (CPU) and memory (RAM).
We developed a solution that downloads IP address black lists of known SSH attackers and adds them to the /etc/hosts.deny file.
The solution is released as an open source project named am-deny-hosts on GitHub. The project consists of a set of shell scripts that does the job without taking up a lot of time, CPU, or memory.
Subversion has multiple server types:
svnserve daemon
svnserve via xinetd
svn over ssh
http-based server
direct access via file:/// URLs
Which one of these is best for a small Linux system (one to two users)?
http:
very flexible and easy for administration
no network problems (Port 80)
3rd party authentication (eg. LDAP, Active Directory)
Unix + Win native support
webdav support for editing without svn client
slow, as each action triggers a new http-action approx. 5-8 times slower than svn://
especially slow on history
no encryption of transferred data
https:
same as http
encryption of transferred data
svn:
fastest transfer
no password encryption in std. setup: pw are readable by admin
firewall problems as no std.port is used
daemon service has to be started
no encryption of transferred data
svn+ssh
nearly as fast as svn://
no windows OS comes with build in ssh components, so 3rd party tools are essentiell
no daemon service needed
encryption of passwords
encryption of transfer
1 of those options is definitely a 'worst' one: file access. Don't use it, use one of the server-based methods instead.
However, whether to use HTTP or Svnserve is entirely a matter of preference. In fact, you can use both simultaneously, the write-lock on the repo ensures that you won't corrupt anything if you use one and then use another.
My preference is simply to use apache though - http is more firewall and internet friendly, it is also easier to hook into ldap or other authentication mechanisms, and you get features like webdav too. The performance may be less than svnserve, but its not particularly noticeable (the transferring of data across the network makes up the bulk of any performance issues)
If you need security for file transfers, then svnserve+ssh, or apache over https is your choice.
Check out FLOSS Weekly Episode 28. Greg Stein is one of the inventors of the WebDAV protocol for SVN and discusses the tradeoffs. My takeaway is that SVN: is faster but the http/webdav implementation is just fine for almost all purposes.
I've always used XInetD and HTTP.
HTTP also had WebDAV going on, so I could browse the source online if I wanted (or you can require a VPN if you wanted encryption and a dark-net type thing).
It really depends on what restrictions (if any) you're under.
Is it only going to be on a LAN? Will you need access outside of your LAN?
If so, will you have a VPN?
Do you have a static IP address and are you allowed to forward ports?
If you aren't under any restriction, I would then suggest going with xinetd (if you have xientd installed, daemon if you don't) and then (if you need remote access) use http-based server if you need remote access (you can also encrypt using HTTPS if you don't want plain text un/pw sent across).
Most other options are more effort with less benefit.
It's an SVN Repo -- you can always pack your bags and change things if you don't like it.
For ease of administration and security, we use svn+ssh for anything that requires commit access. We have set up HTTP based access for anonymous (read only) access to some open-source code, and it is much faster; the problem with svn+ssh is that it has to start up an ssh connection and a whole new svnserve for each user for every operation, which can get to be pretty slow after a while.
So, I'd recommend:
http for anonymous connections
svn+ssh if you need something secure and relatively quick and easy (assuming your users already have ssh set up and your users have access to the server)
https if you need something faster, secure, and you don't mind the extra overhead of administering it (or if you don't already have ssh set up or don't want to deal with Unix permissions)
I like sliksvn runs as a service in Windows, 2mins to setup and then forget about it.
It also comes with the client tools but download tortoise as well.
If you are going to be using the server only on the local machine and understand unix permissions, using file:// urls will be fast, simple and secure. Likewise, if you understand unix permissions and ssh and need to access it remotely, ssh will work great. While I see somebody else mentions it as "worst", I'm pretty sure that's simply due to the need to understand unix permissions.
If you do not like or understand unix permissions, you need to go with svnserve or http. I would probably choose to run it in xinetd, personally.
Finally, if you have firewall or proxy issues, you may need to consider using http. It's much more complicated, and i don't think you're going to see the benefits, so I'd put it last on your list.
I would recommend the http option, since I'm currently using svn+ssh and it appears to be the red-headed stepchild of the available protocols: 3rd-party tool support is consistently worse for svn+ssh than it is for http.
I've been responsible for administering both svnserve and Apache+SVN for my development teams, and I prefer the http-based solution for its flexibility. I know next to little about system administration, I'm a software guy after all, and I liked being able to hand authentication and authorization over to Apache.
Both tines the teams were about 10~15 people and both methods worked equally well. If you're planning for any expansion in the future, you might consider the http-based solution. It's just as easy to configure as svnserve, and if you're not going to expose the server to the Internet then you don't have to worry too much about securing and administering Apache either.
As a user of SVN, I prefer the http-based integration with Apache. I like being able to browse the repository with my web browser.
I am curious why NOT FSFS?? Important information - I am managing Windows systems.
I have done many projects with SVN and almost all of them were running from FSFS. Biggest repository was around 70GB (extreme), biggest ammount of repositories was around 700.
We never had any issues, even though we hosted it on Windows, NetApp and many other storage systems. Most of the time when I asked why NOT using FSFS only problem was that people simply didn't trust it.
Advantages:
No backend required (or dedicated server)
Fast and reliable
Hook scripts are supported
NTFS permissions are used
Easy to understand, easy to support, easy to manage
Disadvantages:
Not so easy access from outside your network (VPN)
Permissions only on repository-level (Read, Read/Write)
Hook scripts are running under current user credentials (which is sometimes advantage, sometimes disadvantage)
Martin
What is the easiest free method of encrypting my web traffic? I'd like to be able to log in to sites on my web server without sending my password in plaintext.
Edit: My web server is running on the LAMP stack , although it is a shared host so I don't have root.
Get an X.509 certificate (for example, generating your own, or getting one free from StartSSL), and use it to set up SSL—a server-specific configuration task.
If you can't configure a new listener in your web server, there's not really a good option. In theory you could do a little hacking with some JavaScript crypto library, like JavaScrypt, and come up with something safe. I've toyed with several options but I don't know enough about it to come up with anything I feel confident about.
I don't know your circumstances, but if it were me, I'd consider another host.
https
Use a self-signed certificate.
Tell us your web server software for a detailed implementation description!
Since you don't have root your best bet is to contact your hosting provider and see what they can do for you. You may already have SSL access (try using https://yourdomain.com) using a self-certified key.
You should be able to talk them into installing a StartSSL key for you. This provides you with SSL encryption and browsers won't complain that it isn't signed by a valid Certificate Authority.
As stated above, publishing your own certification is free, however knowing more about your environment, may get you more specific answers. Are you running IIS? What will you be logging into that needs encryption? Are you using Windows Servers on the back end?
use Digest Authentication. Since you're on LAMP, you can configure it on Apache with mod_auth_digest.
Since you are trying to reduce costs, any ssl solutions will probably not be an option.
First it requires a signed certificate that cost a bit, the free ones is not always included in all web browsers.
Second to be able to utilize an ssl certificate your server ip must be dedicated to you. This is not the case in every cheap web hosting option. There are technologies that in the future will make it possible to host multiple ssl enabled sites on a single ip, but it's not here yet.
As mentioned before Digest Authentication is one option that doesn't require ssl certificate or dedicated ip.
It's a method of authentication that doesn't reveal your password even though everything else in the communication is unprotected.
In Apache this can be applied in individual directories by specific .htaccess files.
I'll repeat the previous link on mod_auth_digest.
This one is usually already installed on most servers so you won't have to ask you web hosting provider.
You don't always require root access to setup Apache to use SSL, but you will likely need to modify config files, which is either done thru your providers interface, or via files via a shell account. Either way you will need a server certificate; either self-signed, from a major company like Verisign, or one of the smaller free places like cacert.org. As noted by others, this does require a dedicated IP to your server or instance on the server.
I would recommend SSL first, but mod_auth_digest isn't a bad backup idea.
What security best-practices would you strongly recommend in maintaining a Linux server? (i.e. bring up a firewall, disable unnecessary services, beware of suid executables, and so on.)
Also: is there a definitive reference on Selinux?
EDIT: Yes, I'm planning to put the machine on the Internet, with at least openvpn, ssh and apache (at the moment, without dynamic content), and to provide shell access to some people.
For SELinux I've found SELinux By Example to be really useful. It goes quite in-depth into keeping a sever as secure as possible and is pretty well written for such a wide topic.
In general though:
Disable anything you don't need. The wider the attack domain, the more likely you'll have a breach.
Use an intrusion detection system (IDS) layer in front of any meaningful servers.
Keep servers in a different security zone from your internal network.
Deploy updates as fast as possible.
Keep up to date on 0-day attacks for your remotely-accessible apps.
The short answer is, it depends. It depends on what you're using it for, which in turn influences how much effort you should put into securing the thing.
There are some handy hints in the answers to this question:
Securing a linux webserver for public access
If you're not throwing the box up onto the internet, some of those answers won't be relevant. if you're throwing it up onto the internet and hosting something even vaguely interesting on it, those answers are far too laissez-faire for you.
There's an NSA document "NSA Security Guide for RHEL5" available at:
http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
which is pretty helpful and at least systematic.
Limit the software to the only ones you really use
Limit the rights of the users, through sudo, ACLs, kernel capabilities and SELinux/AppArmor/PaX policies
Enforce use of hard passwords (no human understandable words, no birthday dates, etc.)
Make LXC countainers, chroot or vserver jails for the "dangerous" applications
Install some IDS, e.g. Snort for the network traffic and OSSEC for the log analysis
Monitor the server
Encrypt your sensible datas (truecrypt is a gift of the gods)
Patch your kernel with GRSecurity : this add a really nice level of paranoïa
That's more or less what I would do.
Edit : I added some ideas that I previously forgot to name ...
1.) Enabling only necessary and relevant ports.
2.) Regular scan of the network data in - out
3.) Regular Scan of ip addresses accessing the server and verify if any unusual data activity associated with those ip address as found from logs/traces
4.) If some some critical and confidential data and code, needs to be present on the server , may be it can be encrypted
-AD
Goals:
The hardest part is always defining your security goals. Everything else is relatively easy at that point.
Probing/research:
Consider the same approach that attackers would take, ie network reconnaissance (namp is pretty helpful for that).
More information:
SELinux by example is a helpful book, finding a good centralized source for SELinux information is still hard.
I have a small list of helpful links that I find useful time to time http://delicious.com/reverand_13/selinux
Helpful solution/tools:
As with what most people will say less is more. For an out of the box stripped down box with SELinux I would suggest clip (http://oss.tresys.com/projects/clip). A friend of mine used it in an academic simulation in which the box was under direct attack from other participants. I recall the story concluded very favorably for said box.
You will want to become familiar with writing SELinux policy. Modular policy can also become helpful. such tools as SLIDE and seedit (have not tried) may help you.
Don't use a DNS Server unless you have to . BIND has been a hotspot of security issues and exploits.
Hardening a Linux server is a vast topic and it primarily depend on your needs.
In general, you need to consider the following groups of concern (I'll give example of best practices in each group):
Boot and Disk
Ex1: Disable booting from external devices.
Ex2: Set a password for the GRUB bootloader - Ref.
File system partitioning
Ex1: Separate user Partitions (/home, /tmp, /var) from OS Partitions.
Ex2: Setup nosuid on partitions – in order to prevent privilege escalation with the setuid bit.
Kernel
Ex1: Update security patches.
Ex2: Read more in here.
Networking
Ex1: Close unused ports.
Ex2: Disable IP forwarding.
Ex3: Disable send packet redirects.
Users / Accounts
Ex1 : Enforce strong passwords (SHA512).
Ex2: Set up password aging and expiration.
Ex3: Restrict Users to Use Old Passwords.
Auditing and logging
Ex1: Configure auditd - ref.
Ex2: Configure logging with journald - ref.
Services
Ex1: Remove unused services like: FTP, DNS, LDAP, SMB, DHCP, NFS, SNMP, etc'.
EX2: If you're using a web server like Apache or nginx - don't run them as root - read more here.
Ex3: Secure SSH ref.
Software
Make sure you remove unused packages.
Read more:
https://www.computerworld.com/article/3144985/linux-hardening-a-15-step-checklist-for-a-secure-linux-server.html
https://www.tecmint.com/linux-server-hardening-security-tips/
https://cisofy.com/checklist/linux-security/
https://www.ucd.ie/t4cms/UCD%20Linux%20Security%20Checklist.pdf
https://www.cyberciti.biz/faq/linux-kernel-etcsysctl-conf-security-hardening/
https://securecompliance.co/linux-server-hardening-checklist/
Now specifically for SELinux:
First of all, make sure that SELinux is enabled in your machine.
Continue with the following guides:
https://www.digitalocean.com/community/tutorials/an-introduction-to-selinux-on-centos-7-part-1-basic-concepts
https://linuxtechlab.com/beginners-guide-to-selinux/
https://www.computernetworkingnotes.com/rhce-study-guide/selinux-explained-with-examples-in-easy-language.html