How to decide to use, then how to use an http gofile.me url in an email, explained to a five year old?

I’m terrified of clicking on links in emails, and yet a colleague insists I do.

When I receive an email in my gmail account that contains links of the form http://gofile.me/xxxxx/yyyyyyyyy along with its password, apparently sent from someone I know and expect it from, and who has supplied the password for the link to their NAS right next to it, should I try to overcome my fear of clicking on links in emails and consider clicking on it as at least fairly safe? Should I instead copy it paste it in a new tab?

The idea is that the document is evolving so the link will provide the latest version, but should I insist the colleague email me the document directly?

tl;dr: Should I

  1. click url
  2. copy/paste url in new tab
  3. balk, request document be emailed each time

If possible, can an answer be written in simple language?

Cropped, blanked out screenshot from email I received in my gmail:

partial screenshot of emailed urls

Is this (explained in body) a possible attack vector when using haveibeenpwned API?

I’m currently working on understanding and contemplating to implement password strength validation for sign ups in my app, to include checking haveibeenpwned if entered password is compromised elsewhere.

I understand the process involves the site sending a partial hash of the password to HIBP and HIBP will respond whether it’s pwned.

I am also assuming that it is possible that HIBP stores logs of my API request and that it may contain information leading back to my app.

If HIBP gets hacked, and attacker gains access to the above hypothetical logs, assuming that it contains all the information in the original request – the partial hash and where it came from (my site), can the attacker construct an attack on my site is this way?

  1. Hash the passwords in the list of pwned password and get a list of hashes
  2. Match the partial hash he has with those in the above list and derive a refined dictionary of N number of possible passwords with same partial hash
  3. Try the passwords on my site

I am aware at every point in the above, measures can be put in place to mitigate each, e.g. 2FA. But it is not my objective to ask for how to secure my sign up, but to validate my concerns with using HIBP and whether there’s an attack vector to be considered.

PS: I’m not a security expert but I do know how passwords and hashes work. As HIBP is new to me, I don’t fully know how it works and all the features of its API. Pardon me if I made wrong assumptions.

Have any of the designers of D&D explained why Strength increases Hit Chance?

This is a personal bias, but when I think high strength score, the imagery I get is:

Bill Kazmaier

When it comes to accuracy of a muscle-bound and bulky person, the imagery I get is:

Ali Bobbing and Weaving

Bruce Lee had stated he didn’t want to have overly bulky muscles because it would affect his agility and accuracy. He did believe in weight training to make his muscles more dense, but that mostly was for grip and striking force.1

I started playing with AD&D 2nd Edition, and even back then an 18 strength gave you +1 Hit and +2 to damage.

Have any D&D developers given any reasoning for why the Strength score, specifically, gives a bonus to hit?

As I recall, being big and strong doesn’t actually help you hit a baseball, but may help you in making that ball you hit a home run.

1 Bruce Lee explains this throughout the Tao of Jeet Kune Do.

How secure is SSL/TLS, explained in laymans terms?

While trying to answer this question it occurred to me that while there’s many good answers about the strengths and weaknesses of SSL/TLS in terms a security professional or software developer can understand, there’s not many good responses that a layman might be able to properly understand.

For instance, we describe some variants of TLS/SSL as “insecure”, which in the security world has a somewhat specialized meaning that might be summarized as “There’s some known vulnerabilities that significantly degrade the security, and you should likely disable this variant on your servers.”. A layman might interpret “insecure” as “simple to exploit”, which isn’t necessarily true.

So can someone provide a good layman’s explanation as to the current security level offered by SSL/TLS? The answer should include the resources of the attacker, the effort, resources, and access involved, and (possibly) the cost.

The answer might also include other ways to achieve the same goal without attacking SSL/TLS, and risks we all take for granted every day. (My credit card, for instance, was compromised and used for fraud last year when Newegg got hacked)

Was the purpose of my travel well explained on my Schengen Visa Inteview? [on hold]

Hello people I’m from Ecuador and I have a German boyfriend. We met in November 2017, we talk every day since then, he came to my country to visit May 2018 and then invited me to Germany in Nov 2018 and I got the visa, so we spent 3 weeks together and it was my first time out the country.

After that he visited me 2 more times and invited me again to Germany in September, so last week I had an interview at the embassy and I’m really scared about my answers cause I got really nervous.

They asked purpose of the trip: I said “to spend my vacation there and get to know more about the country and culture” and then I realized that I didn’t say anything about my boyfriend on the purpose, so then I added to the answer “and also to know each other better”…

I think it was a very bad answer cause if we’re a couple we’re supposed to know each other, but I meant to spend more time together physically, so I think that could affect my application because he wrote on the invitation letter that he knows me as a loyal person and reliable… Also the purpose of the trip is to meet him and spend time together again, on the letter he wrote that he is inviting me out so I can get to know more about his life there and the country’s culture.

Do you think that I have any chance to get the visa after this?

CentOS 7 LAMP Server Tutorial: Modernized and Explained [Part 2]

In Part 1 of this Tutorial, we discussed why we decided to build a LAMP server instead of getting one pre-configured via a control panel such as cPanel or Virtualmin. We configured Remi’s repository for PHP and installed PHP 7.3 and PHP-FPM. We also got the latest version of MariaDB installed and filled in some prerequisites.

In this installment of the CentOS 7 LAMP Server Tutorial, we’re going to fully configure Apache and PHP-FPM for our first virtually hosted website, and then test everything to make sure that it works. Let’s get to it!

Adding a Virtual User

First, let’s add the user to our server and create the directories for hosting the website and the log files that Apache will generate.

useradd lowend passwd lowend

The website will live in /home/lowend/public_html and the logs will be in /home/lowend/logs. Paste in the following to create the directories and set their ownership (CHange OWNership) and permissions (CHange MODe):

mkdir /home/lowend/public_html mkdir /home/lowend/logs chown lowend.lowend /home/lowend/public_html chmod 755 -R /home/lowend

Readying Apache

We need to create a directory for our website configuration files and tell Apache where to look for them. We can name it anything we want, but the standard is “sites-enabled”. It lives in the same directory as the rest of Apache’s configuration files, /etc/httpd.

mkdir /etc/httpd/sites-enabled echo "Include sites-enabled/*.conf" >> /etc/httpd/conf/httpd.conf 

By default, Apache only looks for index.html files to serve as an index page. We will be hosting a dynamic PHP site, so we need to tell Apache to look for index.php pages, too. Apache uses the “DirectoryIndex” directive to decide which filenames to look for, and in what order. We’re going to add “index.php” to it by replacing “DirectoryIndex index.html” with “DirectoryIndex index.html index.php” in the main Apache configuration file, httpd.conf. For that we’ll use the Stream EDitor (sed):

sed -i 's/DirectoryIndex index.html/DirectoryIndex index.html index.php/' /etc/httpd/conf/httpd.conf 

Setting up a Virtual Host

Now we need to tell Apache about our website, lowend-tutorial.tld. We told Apache to look for .conf files in /etc/httpd/sites-enabled/ and include them in its configuration. So that’s where we’ll put our configuration file. Use the nano editor to open a new file, named after the domain name.

nano /etc/httpd/sites-enabled/lowend-tutorial.tld.conf

Paste in the following configuration text. We’ve added a lot of comments to indicate what each section does. Be sure to read the comments, as they are very much part of this tutorial.

#define our VirtualHost. It's IP independent (hence the asterisk) and serves pages on port 80 <VirtualHost *:80>  #Set the ServerName- the name of the VirtualHost, not of your entire server. #Since no IP is used, the ServerName defines the domain name of the Virtual Host    ServerName lowend-tutorial.tld  # Allow the use of the "www" prefix ServerAlias www.lowend-tutorial.tld  #DocumentRoot sets the location of the website files     DocumentRoot /home/lowend/public_html  #Sett options for our public_html directory     <Directory /home/lowend/public_html>        Options -Indexes +FollowSymLinks +MultiViews         AllowOverride All         Require all granted    </Directory>   #Set the location and name of the error    ErrorLog /home/lowend/logs/lowend-tutorial.tld-error.log      # Possible values include: debug, info, notice, warn, error, crit,    # alert, emerg.     # Defines how much information goes into our log files     LogLevel warn   #Set the location and name of the access log     CustomLog /home/lowend/logs/lowend-tutorial.tld-access.log combined   # Configure a way for Apache to talk to PHP-FPM through # a unique Unix Socket that contains the username # We'll explain what a socket is in the next section  <Proxy "unix:/var/run/php73-fpm/php73-fpm.lowend.sock|fcgi://php-fpm">        # PHP-FPM requires at least one parameter to kick things off, so we'll use this one ProxySet disablereuse=off </Proxy>  # Tell Apache to direct all PHP file requests to our proxy, which in turn passes the request to PHP-FPM, which runs the PHP program and returns the results for Apache to serve. <FilesMatch \.php$  >        SetHandler proxy:fcgi://php-fpm </FilesMatch> </VirtualHost>

Save the file with CTRL+O, and exit with CTRL+X. We’ve now told Apache about our website, but we haven’t told PHP-FPM. Next, we’ll finish configuring PHP-FPM and create its configuration file for our website.

Now we’re going to edit Apache’s Multi-Processing Module (MPM) configuration file. There are different MPM’s available to suit different use cases. Because we’re going to be using PHP-FPM, we need to use the MPM-worker module and disable the MPM-prefork module. Apache has a directory where it loads extra configuration files for its modules as if they were part of httpd.conf, it’s main configuration file. That directory is /etc/httpd/conf.modules.d/. The file we’re editing is 00-mpm.conf. The “00” prefix assures that it will get loaded before other configuration files with a numerically higher prefix.

nano /etc/httpd/conf.modules.d/00-mpm.conf

Comment out the mod_mpm_prefork.so line, and uncomment the mod_mpm_worker.so line. this is how ours looks:

 

Save the changes (CTRL+O) and exit nano (CTRL+X). If you’re interested in learning more about the MPM worker modules and their differences, there’s an excellent explanation over on ServerFault: https://serverfault.com/questions/383526/how-do-i-select-which-apache-mpm-to-use

Configuring PHP-FPM for the Virtual Host

We’ve told Apache about our Virtual Host, and we’ve even told it where to expect a Unix socket to communicate with. A Unix socket is a way for processes to communicate with each other, and it lives in the file system. Any process with access to the file has access to the socket, and can communicate with the program that created the socket. Pretty neat, right?

We’re going to create a PHP-FPM pool for our “lowend-tutorial.tld” account. Each account will get its own pool that runs as that user. That way each PHP-FPM has access to both reading and writing to the account. PHP-FPM creates a socket for each PHP-FPM pool, and we’ve already configured Apache where to look for that socket.

Since we’re running Remi’s PHP 7.3, this configuration file needs to live in Remi’s PHP 7.3 configuration directory. That directory is at

/etc/opt/remi/php73/php-fpm.d/

That directory already contains “www.conf” which is a default configuration file. We’re going to use it as a basis for creating our own configuration file, lowend.conf. Then we’re going to disable www.conf by renaming it to www.conf.disabled. Here are the commands to run:

cp /etc/opt/remi/php73/php-fpm.d/www.conf /etc/opt/remi/php73/php-fpm.d/lowend.conf mv /etc/opt/remi/php73/php-fpm.d/www.conf /etc/opt/remi/php73/php-fpm.d/www.conf.disabled

We need to edit lowend.conf a bit. Open it with nano:

nano /etc/opt/remi/php73/php-fpm.d/lowend.conf

This configuration file is commented with a semicolon, so everything with a ; in front of it is just a comment. The first uncommented line you’ll see is [www]. This gives the PHP-FPM pool a name, and it should be unique to this pool of processes. Change [www] to [lowend].

[lowend]

The next uncommented lines you will see are “user” and “group”. These are configured to run the PHP-FPM pool as the “apache” user. We need to change them to run as the “lowend” user.

; RPM: apache user chosen to provide access to the same directories as httpd user = lowend ; RPM: Keep a group allowed to write in log dir. group = lowend

Just a bit further down is a line that defines where PHP-FPM listens for communication. It’s not correct for our use. Comment out the “listen” line:

;listen = 127.0.0.1:9000

and add this line below it:

listen = /var/run/php73-fpm/php73-fpm.lowend.sock

The last addition we’ll make is right below the “;listen.mode” line a few lines down. We need to tell PHP-FPM to listen for connections from Apache’s user (apache) user and give apache read/write access to the socket. Paste in the following:

listen.owner = apache listen.group = apache listen.mode = 0666

Save the changes (CTRL+O) and exit nano (CTRL+X). We’re almost there!

We told Apache to look in /var/run/php73-fpm, and we told PHP-FPM to put the socket in that directory, but that directory doesn’t yet exist. That’s easy enough to fix- just create it with the following command:

mkdir /var/run/php73-fpm

It’s time to enable PHP-FPM so that it starts up every time the server boots, and we need to start it now.

systemctl enable php73-php-fpm systemctl start php73-php-fpm

Lastly, we need to restart Apache to enact all of the changes made to its configuration:

systemctl restart httpd

So there it is- Apache and PHP-FPM are configured, enabled, and have been manually started. MariaDB is ready to take care of database duties, and FirewallD has been configured to allow traffic on port 80. Before we call it “done” we need to test that it works.

Making Sure it Works

If this were non-virtual hosting, we’d just go to the server’s IP address in a browser and see that it loads a page. But this is virtual hosting, and just visiting the IP doesn’t tell us anything. We need to visit the domain name associated with the virtual host. In our case that’s “lowend-tutorial.tld”. To do this, we need to actually point the domain name at the server’s primary IP address. Your domain registrar should offer you this option. If they don’t, then you can use CloudFlare’s DNS or any other free DNS provider to point yourdomain.com and www.yourdomain.com to your server’s main IP with A records.

Once the DNS is configured, try visiting the website. For us that’s “lowend-tutorial.tld”. You should see the plain Apache test page, since there is no index.html or index.php in /home/lowend/public_html. Here’s how it looks:

 

This tells us that Apache is working, but says nothing of PHP. To test that, we’re going to use phpinfo() to provide us with a test page for PHP. The test page needs to go in /home/lowend/public_html because that’s the DocumentRoot we gave Apache. Be sure to substitute “lowend” in the following command to create a file called “test.php”

sudo -u lowend echo "<?php phpinfo() ?>" > /home/lowend/public_html/test.php

Now visit the page in a browser by going to yourdomain.com/test.php. It should look like this:

 

Wrapping it up

If your PHP test page worked, congratulations! If it didn’t work, don’t despair. Go back through this tutorial and make sure that each step is just right. It’s easy to miss a minor detail, and all it takes is one small thing to be incorrect.

We hope you found this tutorial both informative and helpful. The next article in this series will have us installing WordPress, the Internet’s most common (and most loved!) CMS. Stay tuned!

The post CentOS 7 LAMP Server Tutorial: Modernized and Explained [Part 2] appeared first on Low End Box.

CentOS 7 LAMP Server Tutorial: Modernized and Explained [Part 1]

Welcome to another LowEndBox Linux tutorial! In this post we’re going to design and configure a high performance server that will allow you to run multiple websites using the latest software available. Our server will be based on CentOS 7 Linux, Apache 2.4, MariaDB (a fork of MySQL) and PHP 7.3.  This combination of software is referred to as a “LAMP” stack. 

Why would we want to manually configure a LAMP stack instead of installing a control panel like Virtualmin or cPanel that would do it for us? Sometimes we want to build a custom server with only the specific features we desire. Or, we want to learn how all of the software works and is configured. Perhaps we want to save all of our server power for serving sites rather than dedicating some overhead to running a control panel. Whatever your reason, even a small Low End VPS can host several sites successfully with a bit of configuration.

There are many LAMP stack tutorials around of course. Some of them show you how to simply install Linux, Apache, MariaDB and PHP in a default configuration that is suitable for only hosting a single website. Furthermore, many of them rely on the default installation of CentOS which contains some rather outdated software such as PHP 5.4. 

We’re going to step it up a couple of notches. In this tutorial we’ll show you how to take a default CentOS 7 installation and configure it with the latest software with a performant configuration that you’ll be proud to host multiple websites on. But we’re not stopping there. This tutorial is also going to help you understand why we’ve made the design choices we’re making and how all of the components interact with each other.

In future posts we’ll add features to it, so make sure to check back for more later!

Turning On The LAMP

As mentioned, a LAMP server is simply Linux, Apache, PHP, and MariaDB. To do it right though, there are some things to take into consideration. One of the reasons that CentOS 7 is an amazing server OS is that it favors stability and security over all else. As a result, the CentOS repositories supply PHP 5.4 and MariaDB 5.5, which is what was current when CentOS 7 was released. These are very, very old versions of PHP and MariaDB. PHP 5.4 is no longer usable with modern software such as WordPress.

To remedy these issues, we’re going to configure our server to get the software from other repositories that make PHP 7.3 and MariaDB 10.3.15 (at the time of publishing) available. For the sake of this tutorial we’re going to assume that the server has a single IP address. Our own server is a 1 core VPS with 512MB memory and 15GB disk. Let’s get started!

Pre-Configuration

Log into your VPS provider’s control panel, and start by setting the hostname for your server. It has to be what’s called a “Fully Qualified Domain Name”, or FQDN. It will look like “server.your-domainname.tld”. You must use a prefix such as “server” before any name you choose. We’ll set up hosting for “your-domainname.tld” later on in the process.

Inside your VPS provider’s control panel, they’ll will provide you with a means for installing your OS of choice.You’re going to want to choose “CentOS 7 Minimal 64 bit” or something like it. Here’s what it look on our LowEndBox:

Note down the root password and wait for the installation to complete. Once it’s done, get logged in and set up your SSH keys. If you’re not sure how to do that, don’t worry. We’ve got you covered in our other tutorial “Using SSH Keys to connect to your VPS“.

Now that you’re logged in, it’s time to take care of some basic configuration needs. The first thing we have to do is disable SELinux. Use the following command to do that:

sed -i 's/SELINUX=.*$  /SELINUX=disabled/' /etc/selinux/config

Now reboot the server (Just type “reboot” and press enter) and get logged back in. Let’s make sure that SELinux is disabled with the “getenforce” command:

Disabled- perfect! Now we can continue with the next bit of preparation: allowing traffic on port 80 through the firewall. Your VPS provider may have included “FirewallD” which is CentOS 7’s built in firewall, but they might not have. Let’s check first. Use the following command to determine if it’s installed:

rpm -qa | grep firewalld

You should see the following output:

If you don’t, then FirewallD needs to be installed with the following command:

yum -y install firewalld

Now you can open up port 80 (http) and reload the firewall rules:

firewall-cmd --zone=public --add-service=http --permanent firewall-cmd --reload

The last bit of preparation is installing software sources that will provide us with the more up to date versions of PHP and MariaDB. Paste the following commands in your terminal:

curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup |  bash yum -y install http://rpms.remirepo.net/enterprise/remi-release-7.rpm yum-config-manager --enable remi-php73 yum makecache fast

The Work Begins

Now that the initial configuration is done, we can start installing the things that are going to turn our minimal CentOS 7 installation into a real LAMP server. To start, we’re going to install some basic utilities that we may need down the road, including the simple Linux text editor nano. Run this command:

yum -y install sysstat lsof traceroute whois wget ftp nano yum-utils 

We’re going to install Apache (the HTTP daemon, also called httpd) and MariaDB next:

yum -y install httpd  mariadb-server mariadb mod_ssl

We want Apache and MariaDB to start automatically when the server boots up, and we also want to start them now:

systemctl enable httpd.service systemctl enable mariadb  systemctl start httpd.service systemctl start mariadb

Now let’s clean up the MariaDB installation a bit with the command “mysql_secure_installation”. Here’s how it looked on our server:

Your current root password will be empty, so just press Enter. Now it’ll ask you to set a root password for MariaDB. This does not have to match the root password of the server. It is recommended to set a secure password just as you would for the root Linux user however. Make sure you take note of the password that you set, because it’s vital to the operation and configuration of the server. Just press Enter for the rest of the questions that the script asks.

Your results should look like the following:

 

PHP and Virtual Hosting

Apache is a modular program, but it doesn’t natively know how to run PHP scripts. A PHP script produces output that Apache can pass along to anyone asking for it, but PHP has to do the heavy lifting. For this, Apache has an interface called the Common Gateway Interface, or CGI. The official Apache documentation explains it this way:

“The CGI (Common Gateway Interface) defines a way for a web server to interact with external content-generating programs, which are often referred to as CGI programs or CGI scripts.”

Other methods came after CGI including DSO ,suPHP, and FastCGI. For a deeper consideration of these technologies, we recommend this fantastic article by Chris Wiegman.

The PHP handler we’re going to use isn’t mentioned in that article specifically, but PHP FastCGI Process Manager (PHP-FPM) is an implementation of FastCGI. PHP-FPM is very fast, because PHP is always ready for Apache to give it something to do. It’s secure, because PHP scripts are ran under the ownership of the website owner.

Now let’s consider the way we’re going to configure Apache for the hosting of websites. There are two kinds of hosting: Virtual and non-virtual hosting. Non-virtual hosting means that a website is directly linked to an IP address, so each website must have its own IP address. This is what you have if you upload a website directly to /var/www/html after installing Apache. It also means that you’re very limited to the number of websites you can host on a server (one). 

Virtual hosting means that websites are tied to a domain name instead, and so all sites can use the same IP address. Each website will have its own Linux user, Apache configuration file, and PHP-FPM configuration file. You can add as many virtual hosts as your server can handle instead of being limited to just one website per server. Let’s get into the actual configuration work. We’ll explain it all along the way.

Setting up PHP-FPM with PHP 7.3

We installed the Remi repository earlier because the Remi repository has everything we’ll need to install PHP 7.3 with PHP-FPM. In addition to PHP-FPM, we’ll also install many of the most commonly needed modules, including the mysqlnd module that lets PHP talk to MariaDB.

Paste this command into your SSH session:

yum -y install php73 php73-php-fpm php73-php-common php73-php-fpm php73-php-gd php73-php-json \ php73-php-mbstring php73-php-mysqlnd php73-php-xml php73-php-xmlrpc php73-php-opcache \ php73-php-pecl-ssh2 php73-php-gd php73-php-bcmath php-pear-Net-Curl.noarch php73-php-pecl-imagick \ php73-php-xml php73-php-xmlrpc php73-php-pecl-mcrypt

We’ll also want to use PHP 7.3 from the command line, so we’ll invoke the Software Collection utility which makes this easy:

scl enable php73 bash

Setting up Virtual Hosting

All of the software is in place. Now it’s time to add a new user to our server and configure a website for it, and then we’ll have our first virtual host fully configured and we can start hosting websites. Part 2 will be published soon, be sure to check back! 

 

The post CentOS 7 LAMP Server Tutorial: Modernized and Explained [Part 1] appeared first on Low End Box.

How to change the below explained validation from inline style to ms-form validation on migration from SP 2010 to SP 2013?

After migration from SharePoint 2010 to 2013, when we add an element and miss any mandatory field, we should get the validation errors.

But in my case, when I fill the Authorized Date field and miss any other mandatory field, then I get the validation errors in red as shown below:

enter image description here

And on inspecting the error message, we see that it is under ms-formvalidation class.

enter image description here

But when we miss the Authorized Date field and then try to add the item, we see this loading and it doesn’t stop:

enter image description here

So we edited the web part and changed the CSR rendering mode from Standard mode to Server Render mode and then clicked on Apply. We saw the following message displayed under Authorized Date field in black color:

enter image description here

And on inspecting it, we found it as an inline style:

enter image description here.

As per my understanding, If this is changed from inline to ms-formvalidation class, then the error will be resolved.

I need help on how to fix this and any other helpful suggestion on how to overcome the above mentioned problem.

Thanks in Advance.