One place for hosting & domains

      Create

      SMF Create a backup


      When you administrate a website it is very important to guarantee that the content is safe and sound no matter of the circumstances. This is even more important when it comes to data submitted from the members of your discussion board.

      In order to ensure nothing would be lost or mistakenly deleted you should always keep a local copy of your SMF board, so if anything unexpected happen.

      In this section of our tutorial we will show you how to create backup of your platform.

      Actually this is a straightforward process which can be performed in two simple steps.

      The first one is to create a copy of the application files and download them on your local computer. In case that you are not sure how to do that yourself you can check this article.

      The other step is to generate a MySQL dump file of your database. This actually is a copy of the database associated with your website. To create such dump file you can follow the instructions we have provided here.

      The post SMF Create a backup appeared first on TMDHosting.



      Source link

      How To Create a Self-Signed SSL Certificate for Nginx on Debian 9


      A previous version of this tutorial was written by Justin Ellingwood

      Introduction

      TLS, or transport layer security, and its predecessor SSL, which stands for secure sockets layer, are web protocols used to wrap normal traffic in a protected, encrypted wrapper.

      Using this technology, servers can send traffic safely between the server and clients without the possibility of the messages being intercepted by outside parties. The certificate system also assists users in verifying the identity of the sites that they are connecting with.

      In this guide, we will show you how to set up a self-signed SSL certificate for use with an Nginx web server on a Debian 9 server.

      Note: A self-signed certificate will encrypt communication between your server and any clients. However, because it is not signed by any of the trusted certificate authorities included with web browsers, users cannot use the certificate to validate the identity of your server automatically.

      A self-signed certificate may be appropriate if you do not have a domain name associated with your server and for instances where the encrypted web interface is not user-facing. If you do have a domain name, in many cases it is better to use a CA-signed certificate. To learn how to set up a free trusted certificate with the Let’s Encrypt project, consult How to Secure Nginx with Let’s Encrypt on Debian 9.

      Prerequisites

      Before you begin, you should have a non-root user configured with sudo privileges. You can learn how to set up such a user account by following our initial server setup for Debian 9.

      You will also need to have the Nginx web server installed. If you would like to install an entire LEMP (Linux, Nginx, MySQL, PHP) stack on your server, you can follow our guide on setting up LEMP on Debian 9.

      If you just want the Nginx web server, you can instead follow our guide on installing Nginx on Debian 9.

      When you have completed the prerequisites, continue below.

      Step 1 — Creating the SSL Certificate

      TLS/SSL works by using a combination of a public certificate and a private key. The SSL key is kept secret on the server. It is used to encrypt content sent to clients. The SSL certificate is publicly shared with anyone requesting the content. It can be used to decrypt the content signed by the associated SSL key.

      We can create a self-signed key and certificate pair with OpenSSL in a single command:

      • sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt

      You will be asked a series of questions. Before we go over that, let’s take a look at what is happening in the command we are issuing:

      • openssl: This is the basic command line tool for creating and managing OpenSSL certificates, keys, and other files.
      • req: This subcommand specifies that we want to use X.509 certificate signing request (CSR) management. The “X.509” is a public key infrastructure standard that SSL and TLS adheres to for its key and certificate management. We want to create a new X.509 cert, so we are using this subcommand.
      • -x509: This further modifies the previous subcommand by telling the utility that we want to make a self-signed certificate instead of generating a certificate signing request, as would normally happen.
      • -nodes: This tells OpenSSL to skip the option to secure our certificate with a passphrase. We need Nginx to be able to read the file, without user intervention, when the server starts up. A passphrase would prevent this from happening because we would have to enter it after every restart.
      • -days 365: This option sets the length of time that the certificate will be considered valid. We set it for one year here.
      • -newkey rsa:2048: This specifies that we want to generate a new certificate and a new key at the same time. We did not create the key that is required to sign the certificate in a previous step, so we need to create it along with the certificate. The rsa:2048 portion tells it to make an RSA key that is 2048 bits long.
      • -keyout: This line tells OpenSSL where to place the generated private key file that we are creating.
      • -out: This tells OpenSSL where to place the certificate that we are creating.

      As we stated above, these options will create both a key file and a certificate. We will be asked a few questions about our server in order to embed the information correctly in the certificate.

      Fill out the prompts appropriately. The most important line is the one that requests the Common Name (e.g. server FQDN or YOUR name). You need to enter the domain name associated with your server or, more likely, your server’s public IP address.

      The entirety of the prompts will look something like this:

      Output

      Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:New York Locality Name (eg, city) []:New York City Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc. Organizational Unit Name (eg, section) []:Ministry of Water Slides Common Name (e.g. server FQDN or YOUR name) []:server_IP_address Email Address []:admin@your_domain.com

      Both of the files you created will be placed in the appropriate subdirectories of the /etc/ssl directory.

      While we are using OpenSSL, we should also create a strong Diffie-Hellman group, which is used in negotiating Perfect Forward Secrecy with clients.

      We can do this by typing:

      • sudo openssl dhparam -out /etc/nginx/dhparam.pem 4096

      This will take a while, but when it’s done you will have a strong DH group at /etc/nginx/dhparam.pem that we can use in our configuration.

      Step 2 — Configuring Nginx to Use SSL

      We have created our key and certificate files under the /etc/ssl directory. Now we just need to modify our Nginx configuration to take advantage of these.

      We will make a few adjustments to our configuration.

      1. We will create a configuration snippet containing our SSL key and certificate file locations.
      2. We will create a configuration snippet containing strong SSL settings that can be used with any certificates in the future.
      3. We will adjust our Nginx server blocks to handle SSL requests and use the two snippets above.

      This method of configuring Nginx will allow us to keep clean server blocks and put common configuration segments into reusable modules.

      Creating a Configuration Snippet Pointing to the SSL Key and Certificate

      First, let’s create a new Nginx configuration snippet in the /etc/nginx/snippets directory.

      To properly distinguish the purpose of this file, let’s call it self-signed.conf:

      • sudo nano /etc/nginx/snippets/self-signed.conf

      Within this file, we need to set the ssl_certificate directive to our certificate file and the ssl_certificate_key to the associated key. In our case, this will look like this:

      /etc/nginx/snippets/self-signed.conf

      ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
      ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
      

      When you’ve added those lines, save and close the file.

      Creating a Configuration Snippet with Strong Encryption Settings

      Next, we will create another snippet that will define some SSL settings. This will set Nginx up with a strong SSL cipher suite and enable some advanced features that will help keep our server secure.

      The parameters we will set can be reused in future Nginx configurations, so we will give the file a generic name:

      • sudo nano /etc/nginx/snippets/ssl-params.conf

      To set up Nginx SSL securely, we will be using the recommendations by Remy van Elst on the Cipherli.st site. This site is designed to provide easy-to-consume encryption settings for popular software.

      The suggested settings on the site linked to above offer strong security. Sometimes, this comes at the cost of greater client compatibility. If you need to support older clients, there is an alternative list that can be accessed by clicking the link on the page labelled “Yes, give me a ciphersuite that works with legacy / old software.” That list can be substituted for the items copied below.

      The choice of which config you use will depend largely on what you need to support. They both will provide great security.

      For our purposes, we can copy the provided settings in their entirety. We just need to make a few small modifications.

      First, we will add our preferred DNS resolver for upstream requests. We will use Google’s for this guide.

      Second, we will comment out the line that sets the strict transport security header. Before uncommenting this line, you should take take a moment to read up on HTTP Strict Transport Security, or HSTS, specifically about the “preload” functionality. Preloading HSTS provides increased security, but can have far reaching consequences if accidentally enabled or enabled incorrectly.

      Copy the following into your ssl-params.conf snippet file:

      /etc/nginx/snippets/ssl-params.conf

      ssl_protocols TLSv1.2;
      ssl_prefer_server_ciphers on;
      ssl_dhparam /etc/nginx/dhparam.pem;
      ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
      ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
      ssl_session_timeout  10m;
      ssl_session_cache shared:SSL:10m;
      ssl_session_tickets off; # Requires nginx >= 1.5.9
      ssl_stapling on; # Requires nginx >= 1.3.7
      ssl_stapling_verify on; # Requires nginx => 1.3.7
      resolver 8.8.8.8 8.8.4.4 valid=300s;
      resolver_timeout 5s;
      # Disable strict transport security for now. You can uncomment the following
      # line if you understand the implications.
      # add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
      add_header X-Frame-Options DENY;
      add_header X-Content-Type-Options nosniff;
      add_header X-XSS-Protection "1; mode=block";
      

      Because we are using a self-signed certificate, SSL stapling will not be used. Nginx will output a warning but continue to operate correctly.

      Save and close the file when you are finished.

      Adjusting the Nginx Configuration to Use SSL

      Now that we have our snippets, we can adjust our Nginx configuration to enable SSL.

      We will assume in this guide that you are using a custom server block configuration file in the /etc/nginx/sites-available directory. We will use /etc/nginx/sites-available/example.com for this example. Substitute your configuration filename as needed.

      Before we go any further, let’s back up our current configuration file:

      • sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/example.com.bak

      Now, open the configuration file to make adjustments:

      • sudo nano /etc/nginx/sites-available/example.com

      Inside, your server block probably begins similar to this:

      /etc/nginx/sites-available/example.com

      server {
          listen 80;
          listen [::]:80;
      
          server_name example.com www.example.com;
      
          root /var/www/example.com/html;
          index index.html index.htm index.nginx-debian.html;
      
          . . .
      }
      

      Your file may be in a different order, and instead of the root and index directives you may have some location, proxy_pass, or other custom configuration statements. This is ok, as we only need to update the listen directives and include our SSL snippets. We will be modifying this existing server block to serve SSL traffic on port 443, then create a new server block to respond on port 80 and automatically redirect traffic to port 443.

      Note: We will use a 302 redirect until we have verified that everything is working properly. Afterwards, we can change this to a permanent 301 redirect.

      In your existing configuration file, update the two listen statements to use port 443 and SSL, then include the two snippet files we created in previous steps:

      /etc/nginx/sites-available/example.com

      server {
          listen 443 ssl;
          listen [::]:443 ssl;
          include snippets/self-signed.conf;
          include snippets/ssl-params.conf;
      
          server_name example.com www.example.com;
      
          root /var/www/example.com/html;
          index index.html index.htm index.nginx-debian.html;
      
          . . .
      }
      

      Next, paste a second server block into the configuration file, after the closing bracket (}) of the first block:

      /etc/nginx/sites-available/example.com

      . . .
      server {
          listen 80;
          listen [::]:80;
      
          server_name example.com www.example.com;
      
          return 302 https://$server_name$request_uri;
      }
      

      This is a bare-bones configuration that listens on port 80 and performs the redirect to HTTPS. Save and close the file when you are finished editing it.

      Step 3 — Adjusting the Firewall

      If you have the ufw firewall enabled, as recommended by the prerequisite guides, you’ll need to adjust the settings to allow for SSL traffic. Luckily, Nginx registers a few profiles with ufw upon installation.

      We can see the available profiles by typing:

      You should see a list like this:

      Output

      Available applications: . . . Nginx Full Nginx HTTP Nginx HTTPS . . .

      You can see the current setting by typing:

      It will probably look like this, meaning that only HTTP traffic is allowed to the web server:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx HTTP ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx HTTP (v6) ALLOW Anywhere (v6)

      To additionally let in HTTPS traffic, we can allow the "Nginx Full" profile and then delete the redundant "Nginx HTTP" profile allowance:

      • sudo ufw allow 'Nginx Full'
      • sudo ufw delete allow 'Nginx HTTP'

      Your status should look like this now:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx Full (v6) ALLOW Anywhere (v6)

      Step 4 — Enabling the Changes in Nginx

      Now that we've made our changes and adjusted our firewall, we can restart Nginx to implement our new changes.

      First, we should check to make sure that there are no syntax errors in our files. We can do this by typing:

      If everything is successful, you will get a result that looks like this:

      Output

      nginx: [warn] "ssl_stapling" ignored, issuer certificate not found nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

      Notice the warning in the beginning. As noted earlier, this particular setting throws a warning since our self-signed certificate can't use SSL stapling. This is expected and our server can still encrypt connections correctly.

      If your output matches the above, your configuration file has no syntax errors. We can safely restart Nginx to implement our changes:

      • sudo systemctl restart nginx

      Step 5 — Testing Encryption

      Now, we're ready to test our SSL server.

      Open your web browser and type https:// followed by your server's domain name or IP into the address bar:

      https://server_domain_or_IP
      

      Because the certificate we created isn't signed by one of your browser's trusted certificate authorities, you will likely see a scary looking warning like the one below (the following appears when using Google Chrome) :

      Nginx self-signed cert warning

      This is expected and normal. We are only interested in the encryption aspect of our certificate, not the third party validation of our host's authenticity. Click "ADVANCED" and then the link provided to proceed to your host anyways:

      Nginx self-signed override

      You should be taken to your site. If you look in the browser address bar, you will see a lock with an "x" over it. In this case, this just means that the certificate cannot be validated. It is still encrypting your connection.

      If you configured Nginx with two server blocks, automatically redirecting HTTP content to HTTPS, you can also check whether the redirect functions correctly:

      http://server_domain_or_IP
      

      If this results in the same icon, this means that your redirect worked correctly.

      Step 6 — Changing to a Permanent Redirect

      If your redirect worked correctly and you are sure you want to allow only encrypted traffic, you should modify the Nginx configuration to make the redirect permanent.

      Open your server block configuration file again:

      • sudo nano /etc/nginx/sites-available/example.com

      Find the return 302 and change it to return 301:

      /etc/nginx/sites-available/example.com

          return 301 https://$server_name$request_uri;
      

      Save and close the file.

      Check your configuration for syntax errors:

      When you're ready, restart Nginx to make the redirect permanent:

      • sudo systemctl restart nginx

      Conclusion

      You have configured your Nginx server to use strong encryption for client connections. This will allow you serve requests securely, and will prevent outside parties from reading your traffic.



      Source link

      How to Create Strong Passwords to Keep Your Website Safe


      Your birthday. Your dog’s name. Or even worse, 1234. These are common passwords that are easy to remember — and an easy way to let people exploit your website.  When you own your own website, it’s even more crucial to create a smart password that will keep your site safe and secure, since upping the ante on your password game is one of the best ways to protect your business.

      “It’s important to have strong passwords because 81 percent of hacking-related breaches are due to weak or stolen passwords, according to the 2018 Verizon Data Breach Report,” says Darren Guccione, CEO & Co-Founder of Keeper Security. “Passwords are the single easiest entry point you can protect.”

      While a quirky word or secret nickname might seem unexpected to you, that’s not much trickier for a pro to solve.

      “Criminal hackers have password cracking tools at their disposal that actually plug-in well-worn, easy to guess passwords into website logins,” says Robert Siciliano, a security analyst with Hotspot Shield. “For example, many usernames are ‘admin’ and if the password is ‘princess’ that is easy to crack with a ‘dictionary attack,’ which is a software used to crack passwords.”

      If you have employees who have access to your company’s website, it’s crucial to share with them how to create a secure password. After all, even if you maximize all the steps to creating a strong password, if you’re not requiring your users to do the same, then that’s essentially creating an Achilles’ heel. Stay safe and secure by trying these 12 techniques to build a strong password.

      11 Password Tips to Help Keep Your Website Safe

      1. Make your password long.

      “Generally, a longer password takes longer to be cracked; however, it should also follow other rules to make it strong,” says Rema Deo, Managing Director at 24By7Security, Inc. “Length alone is not enough.” Aim for at least eight letters and/or characters since anything less than that takes less time to crack. The longer the password, the longer it takes to figure it out.

      “However, a long password doesn’t necessarily make it more secure,” Guccione cautions. “To be secure it should be both long and random, meaning it should contain a combination of upper and lowercase letters, numbers, and symbols. A password should be no less than eight to 16 characters, but certainly, more can be better. Some websites require a certain character length so be cognizant of those requirements when creating your passwords.”

      Want more security tips to protect your website? Sign up for DreamHost’s monthly newsletter today!

      2. Don’t use a common phrase.

      As Siciliano mentioned, the ‘dictionary attack’ is the main reason to avoid popular words and phrases. Passphrases are increasingly becoming more popular, but they can easily be guessed if it’s something obvious to you or the account. And don’t make the mistake of thinking that using an exclamation mark instead of an “I” or a “3” for the letter “E” will throw them off guard.

      “Algorithms used to crack passwords already consider common phrases and even common letter substitutions,” Deo cautions.

      3. Test your password.

      “Most websites have testing tools built-in to the setup process when creating a password,” Siciliano says. “The other option is to go to haveIbeenpwnd.com and look at their password checker tool.” While password strength meters help, keep in mind that they are not necessarily fool-proof.

      4. Don’t reuse your password.

      More than half of all people use the same password for all their websites and applications. “This is a common and very dangerous problem,” Guccione says. “Hackers keep dictionary lists of the most commonly used passwords. They also know that if they are successful in breaching a single account, they will often be able to access multiple accounts for the same person due to the high frequency of password reuse. So, the more you reuse passwords the easier it is for an attacker to gain access to every account that uses that same password.”

      As security breaches have become increasingly common, that’s another reason to keep mixing it up when it comes to your password.

      “There have been 12 billion records compromised just in the past two years alone, equating to over 10,000 data breaches,” Siciliano says. “That means criminals have access to billions of usernames and their associated passwords. This allows them to use that data to access any site where your credentials are reused.”

      Related: Why Security Through Obscurity Isn’t Enough to Keep Your Website Safe

      5. Use a password manager.

      If you’re creating passwords the right way — meaning they’re long, with lots of numbers and characters and on the gibberish side — it’s probably pretty tough to keep track of all of them. That’s where a password manager comes in. They allow you to have multiple passwords for all of your accounts and it remembers them for you.

      “Password managers generally store your passwords in an encrypted vault and therefore are meant to be more secure than other means of storing your passwords,” Deo says. “They also offer features like suggesting passwords; allowing you to enter, store and remember long complex passwords; identifying duplicate or reused passwords and allowing you to fix them.” Just be sure to pick the right one, since password managers have been known to have the occasional security flaws. Using a password management application will enable you to create stronger passwords, since you won’t have to remember each one.

      “They also allow you to be faster online by auto-filling your login credentials for you,” Guccione says. “Creating strong passwords is not difficult—remembering them is. We call this dilemma ‘password fatigue.’ The easiest way to create strong passwords is with a password manager. There are many options that once you’ve tried I can guarantee you’ll want the ease of use on every device.” And whatever you do, do not store your passwords on sticky notes or spreadsheets.

      6. Don’t store passwords in your browser.

      We know what you’re thinking: keeping passwords in your browser means they’re always at your fingertips. But like many other shortcuts in life, it just isn’t worth it. While password managers are security companies designed to protect your data, the same standards don’t apply to browsers for password management. “Browsers don’t encrypt your passwords, and if a hacker gets access to your computer, the passwords stored in your browser are open game,” Guccione says.

      “Further, passwords stored in a browser can’t be used for native applications and are also not available on your other devices or on other browsers. Passwords stored in a particular browser are not cross-platform, and browsers are not military-grade ‘vaults’ for securing and organizing your passwords and other private information.”

      And remember, generally speaking, Deo warns that passwords can be viewed once you are connected or logged in. If a hacker gets control of your browser with your login password, then the hacker can see all the accounts and their passwords. This is one risk that definitely isn’t worth taking.

      7. Follow the rules every time.

      It might seem OK to break a rule now and then, but that can be a slippery slope. Always — and we mean every single time — stick to the essentials. “Long and strong, lowercase, numbers and characters, indecipherable passwords that don’t spell anything out are best,” Siciliano says. “Otherwise, phrases incorporating the above can work. But a password manager does it best—that’s their job.”

      If you want to go above and beyond (and which business owner doesn’t when it comes to their website?), take it up a notch by setting a truly unpredictable password, one that simply has nothing to do with you or any other common phrase. “Since such unpredictable passwords are hard to remember, a password manager might be the next best thing to use to protect your accounts,” Deo says. “Multi-factor authentication is also a useful idea so that you would need multiple different methods to access your accounts.”

      8. Use two-factor authentication.

      Any extra protection you can take is a good idea, and two-factor authentication means that simply having your password won’t be enough. Two-factor authentication adds in a second layer of security for protecting access to your accounts, making the cracking process much more difficult. This second layer can consist of a code-generating app on your smartphone, a numeric key fob or a USB key.

      “A simple username and password combination has already been hacked and cracked with the 12 billion records compromised,” Siciliano says. “If you have two-factor installed, it doesn’t matter if a criminal has your username and password — they would need your mobile phone to get access.”

      Related: 13 of the Best Security Plugins to Keep Your WordPress Site Safe

      9. Consider the Passphrase/Diceware Method.

      The Passphrase/Diceware Method mainly consists of random words to create a secure password. “It is a good way to create a strong, long password,” Deo says. “Experts say that the number of words you need to truly make the Diceware passphrase strong used to be five, but now they recommend that you use a minimum of seven words to make a strong passphrase.”

      The downfall? “Just be aware that what you create, you also have to remember,” Guccione says. “Passphrases are becoming more prevalent. Therefore, it’s best used in conjunction with a password manager.”

      10. Use security questions wisely.

      Though security questions might seem like they’re there to help by adding an extra layer of protection, they can actually do more harm than good. “If possible, it’s best to avoid security questions because they tend to be questions of very common things about yourself,” Guccione says. “But if you do have to use them, I recommend setting a customized security question and answer to prevent hackers from planning a brute-force attack against common security question and answer lists.”

      In other words, be creative with your answers and record that data so that the information can’t be easily found via social media. “Answers to security questions can often be guessed easily or even found on public sources,” Deo says. “For instance, some security questions ask you the model of your first car or the high school you went to. These are not private questions. It is important to select questions that offer you a certain level of privacy where you may be the only one who truly knows the right answer.”

      11. Keep an eye on your smartphone.

      “Today, most people keep everything about themselves on their smartphones, from notes, contacts, lists, text messages, passwords, photos, videos, and emails—it’s all there,” Guccione says. “Hackers target smartphones because they are small and easy to steal. When a hacker is able to get physical access to your device, their chances of breaching that device increase exponentially. Each year, over 3 million phones are stolen. Keep them locked with a passcode and under a close eye!”



      Source link