Features

• Tinyproxy is easy to configure and modify.
• A small memory footprint means it occupies a very little amount of space on operating systems. Its memory footprint is almost about 2MB.
• The anonymous mode allows authorization of individual HTTP headers that should be allowed and those which should not be.
• Access control by blocking an unauthorized user.
• Filtering allows the user to block or allow a certain domain by creating a blacklist and whitelist.
• Privacy features control both incoming and outgoing data from the HTTPS/HTTP servers.

Install TinyProxy

Update system packages by typing the following command.

Once the update completes, Install Tinyproxy by typing this command.

Tinyproxy will be installed. To start and check the status of Tinyproxy, type these commands.

Configure Web Browser

To make your Tinyproxy work, you have to change some settings in your web browser. To do so, go into your web browser network settings and click on the manual proxy configuration, and in the HTTP proxy bar, write your public IP_Address on which you want to run the Tinyproxy. And the port number (by default tinyproxy port no. is 8888).

You can also use foxyproxy to configure your web browser. It is a proxy management tool that is much better than the limited ability of firefox proxy configuration. It is an extension for the Firefox and Chrome web browsers and can be downloaded from their stores.

Tinyproxy Configuration

The Tinyproxy configuration file is located in the following path “etc/tinyproxy/tinyproxy.conf”.

To access it, type the following command.

To make changes in the Tinyproxy configuration file, open it using vim.

Go to the line Allow 127.0.0.1 and change it with your public IP Address.

Now go to line #Listen 192.168.0.1 . Comment out this line and write your IP_Address in it.

Allow and Block Range of User IPs

Tinyproxy allows you to add or block a user IP or a range of IPs from using tinyproxy. To allow or block user IP, go to the line Allow 127.0.0.1, and below this line, add the IP addresses you want Allow [IP_Address]. For allowing a range of IP address just below the line Allow 192.168.0.0 add a line

For blocking a user IP or range of IPs, just comment out the IP_Address you want to block. In tinyproxy, by default, all the IPs are blocked.

Authorization

In tinyproxy, you can setup authorization so that only those users can access the tinyproxy who are authorized. For setting up the authorization credentials, go to the line #BasicAuth user password. Uncomment this line and write your password at the end of this line.

Adding Filter

You can also add a traffic filter by blocking websites using tinyproxy. Follow the instructions for adding traffic filters.

Go to the line Filter “/etc/tinyproxy/filter”. Comment out this line. You can put the filter on URL or domains. Also, below this line, comment out another line, “FilterExtanded On”. And “FilterDefaultDeny Yes”.

Save the changes and add domains of the websites you want to block in the filter file. You can access the filter file in the “/etc/tinyproxy/filter” path. So open it using vim.

Add the domains line by line. You can add any and as many domains as you want to block.

Any time you make any changes in the filter list or tinyproxy configuration file, you must restart the tinyproxy service. To restart the tinyproxy service type command.

Now allow the firewall by typing the command.

Regulate TinyProxy Using Cron Job

If you want to schedule the timing of your tinyproxy, like when you want to start, restart or stop the tinyproxy. You can do it with a special feature of the Linux cron job. It follows this pattern time (minute, hour, day of the month, month, day of the week) path command. To edit the cron job type command crontab -e

To schedule the starting time of tinyproxy, type the following commands.

To schedule the stopping time of tinyproxy, type the following commands.

This means the tinyproxy service will automatically start at 6 am and stop at 11 pm every day.

Conclusion

Tinyproxy is a useful and easy tool to set the HTTP/HTTPS Proxy. It is for small servers, but if you want to have a proxy server running for larger networks, you might need to go to the squid proxy. We have shared only some tips here, but they are good enough. Using this simple guide on how to install, configure, and use tinyproxy, you will be able to set up your tinyproxy.

This article describes what an error of 500 means, how you get an HTTP 500 code, as well as how to fix such errors.

What is an HTTP 500 Error?

Your browser will send a request to the host server managing site any time you visit a web page, which produces the requested data and response code. Whether or not the request was successful is indicated by the HTTP response status codes.

In five groups, responses are categorized. If an error message falls within the 500 to 599 range, it can be identified as a server error.HTTP status code 500 is a generic error message that the server returns because there is no other suitable error message. It can be triggered by a variety of barriers that keep the request from being completed by the server.

There is nothing much you can do when the page you are accessing throws 500 Error because the error is not induced by your browser or internet connection. You should try any of the following solutions even if the error has been on the server-side:

• Reload the browser or try another browser. If you reload the browser, the probability that the webpage will load are poor, but still, it’s worth a lookout.
• Start clearing your browser cache. Unless the page that displays an error of 500 is cached, the browser should request a version of the page after clearing the cache.
• Then, come back. Until then, the web developer could fix the server problem.
• Contact the operators of the website. The very last option left is to contact the individual in charge of managing the website.

Troubleshooting 500 Error

Internal Server Error 500 may be triggered for a variety of different reasons. The most popular ones are here:

A problem with approval. If the web browser does not have permission to view site files, an HTTP 500 error will occur.

Syntax error: .htaccess. When you’re using Apache as a web browser, as you most likely have a .htaccess file in the root folder of your domain. An incorrect syntax or non-existent module command could result in an error of 500.

Database-related problem. HTTP Error 500 can also be caused by improper details about the database or a compromised database.

Problems with themes and plugins. Whether you are operating WordPress or similar CMS, after upgrading or changing a plugin/theme, an error of 500 can occur.

Modules from Node.js. Up to date modules will trigger an admin console error of 500 if you have a Node.js-based site.

Site hacked. Very frequently, an error of 500 arises from malicious software that is inserted into the website.

External Interruption of Capital. The server will return an error of 500 if the server connects with an external service and if such resources are not available.

Testing the server logs is the best way to determine whether the error of 500 happened. The position of the files depends on the amount of your Linux and the database server. For Apache and Nginx, the most popular error logs are given as follows:

• # /var/log/apache2/error.log
• # /var/log/httpd/error_log
• # /var/log/nginx/error_log

Review the Node.js logs if the software is based on Node.js.

The server log usually includes comprehensive error data to help you recognize and correct an error.

Conclusion

A specific HTTP status code is the 500 Internal Server Error, which indicates that maybe something went wrong with the webserver that hosts the page you are accessing. ]]> https://linuxhint.com/share_files_lightweight_http_server/ Mon, 13 Apr 2020 16:38:10 +0000 https://linuxhint.com/?p=58281 Lightweight server applications in Linux can be used to quickly share files between two or more devices. These web server applications are not suitable for advanced web applications that require tighter security, authentication and performance. However, they are perfectly fine if you want to use them to temporarily share files locally or remotely between multiple devices. This article will list some of these static HTTP server applications. So let’s jump in.

SimpleHTTPServer

Simple HTTP server is a built-in python module that can be used to launch a lightweight server suitable for running basic web applications and lightweight file server. As it is a built-in module, it comes pre-installed on almost all Linux distributions having Python installed by default.

Simple HTTP server serves all the files located in the folder it is run from. Run the following commands in succession to launch a simple HTTP server in the “Downloads” folder located in your home directory (commands below are for Python 3 only).

To run the server on a different port, run the following command instead (change port number according to your requirements):

You will see following terminal output on successful launch of the server:

If you click on the URL mentioned in the terminal output shown above, you will be able to see a basic file browser layout in the web browser (also on http://localhost:8000/):

To share files with a different device, you have to use a URL in the “http://ip_address:8000/” format. To find IP address of of your computer where simple HTTP server is running, run the command below:

You will get some output like this:

Enter the IP address obtained above in the URL. The correct URL to access the file server now would be: “http://192.168.0.107:8000/”. You can open this URL in any web browser on any device to download the listed files. Below is a screenshot of this URL opened on an Android device:

To stop the server anytime, press <CTRL+C> while the terminal window is in focus.

HTTP-Server (Node.js)

Http-server is a Node.js module that allows you to run a simple, easy to use and configurable web server. You can use the http-server module to share files from any folder on your system.

To install Node.js on Ubuntu, run the command below:

To install http-server module, run the command below:

To run the http-server from “Downloads” folder in your home directory, run the following two commands in succession:

On successful launch of http-server, you will see some output like this:

You can now use the second URL listed in the output above to open the file browser in a web browser.

To stop the server anytime, press <CTRL+C> while the terminal window is in focus.

Twistd

Twistd is a simple web server that comes with the “Twisted” python module. It can be used to launch a server that uses http or ftp protocol for sharing files. To install twisted in Ubuntu, run the command below:

To run the twistd from “Downloads” folder in your home directory, run the following two commands in succession:

On successful launch of web server, you will get some output in the terminal like this:

You can now use a URL in the “http://ip_address:8080/” format. To see IP address of your system, run the command below:

You will get some output like this:

Enter the IP address obtained above in the URL. The correct URL to access the file server now would be: “http://192.168.0.107:8080/”. You can open this URL in any web browser on any device to download the listed files. Below is a screenshot of this URL opened in Firefox web browser on Ubuntu:

To stop the server anytime, press <CTRL+C> while the terminal window is in focus.

Httpd (Ruby)

Httpd is a lightweight server that comes with the default Ruby package on most Linux distributions. In terms of functionality, it is on par with Python’s simple HTTP server.

To install Ruby on Ubuntu, run the command below:

To run the Ruby httpd from “Downloads” folder in your home directory, run the following two commands in succession:

On successful launch of web server, you will get some output in the terminal like this:

You can now use a URL in the “http://ip_address:8000/” format. To see IP address of your system, run the command below:

You will get some output like this:

Enter the IP address obtained above in the URL. The correct URL to access the file server now would be: “http://192.168.0.107:8080/”. You can open this URL in any web browser on any device to download the listed files. Below is a screenshot of this URL opened in Firefox web browser on Ubuntu:

To stop the server anytime, press <CTRL+C> while the terminal window is in focus.

Conclusion

These are a few lightweight web server applications that are easy to use and can be used to share files publicly. If you want to share files over a network with higher security and authentication standards, these applications may not be suitable and avoid using them in production.

Most web servers like nginx and apache listen on port 80 by default and need quite a bit of configuration before they start using the certificates to encrypt the traffic. Despite having it configured, the web server can still service HTTP traffic no problem. So the visitors to your website will just type http://example.com instead of https://example.com and the entire traffic will remain unencrypted for them. To circumvent this issue we need to configure the HTTP servers such that they themselves redirect all the HTTP to HTTPS.

The setup I have is using an FQDN with a public IP, so I will be issuing an SSL certificate from LetsEncrypt rather than issuing a self-signed one. Depending on the kind of web server you are using, you can do this in multiple ways. But the general flow of it is like this:

1. Get a signed certificate from a CA. In our case this is going to be LetsEncrypt
2. Configure the web server to use the encryption key to encrypt the outgoing HTTP traffic on port 443. This is the default HTTPS port.
3. Redirect all the incoming requests on port 80 (which is unencrypted HTTP) to port 443, thereby enabling encrypted sessions for all incoming connections.

Let’s demonstrate various way to achieve what we want. First is the easiest solution which uses Certbot.

1. Easiest way — Using Certbot plugins for Nginx or Apache

I will be using Nginx as an example for this server. If you are running a different one, like Apache or HAProxy, then just visit the Certbot official page and select your OS and your web server of choice. For Nginx on Ubuntu 18.04, these are the commands you would need.

First, update your repo index.

You would need to add the required third-party repositories, which Ubuntu may not have enabled by default.

And then install the certbot package with Nginx plugins, using the command below.

The instruction will be different for different platforms and install plugins for the web server if available. The reason plugins make our lives so much easier is because they can automatically edit the configuration files on the web server to redirect the traffic as well. The downside could be that if you are running a very customized server for pre-existing website, then the plugin may break some stuff in there.

For new websites, or very simple configurations, like a reverse proxy, the plugin works surprisingly well. To obtain the certificates and to redirect the traffic, simply run the below command and follow through the various interactive options  as the package walks you through them.

Output:

IMPORTANT NOTES:
– Congratulations! Your certificate and chain have been saved at:

Your key file has been saved at:

As shown in the above example you only have to provide a valid email address and your domain name to get the certificate. This certificate is sotred in /etc/letsencrypt/live/SUBDOMAIN.DOMAINNAME.TLD. The last directory will be named after your FQDN.

The most important aspect is selecting the Redirect option and it will do the job of redirecting all the HTTP traffic to HTTPS. If you are curious as to what these changes are, you can inspect the config files in /etc/nginx/ to get the gist of it.

2. Editing the Config files

If you want to manually configure your server to use the certificates. To get the certificates using certbot, run:

As before, the certificates are saved in the directory /etc/letsencrypt/live/yourdomainname.com/

Now we can configure Nginx to use the files in this directory. First things first, I will get rid of the Debian specific directory layout. The default page’s site config file is /etc/nginx/sites-available/default subdirectory with a symlink to /etc/nginx/site-enabled.

I will just delete the symlink and move the config file to /etc/nginx/conf.d with a .conf extension just to keep things more generalized and applicable to other distros as well.

I will be modifying this default config file to demonstrate how the TLS is enabled.

The following are the contents inside your default config file, without the commented out sections. The highlighted sections are the one that you ought to add to your server configuration in order to enable TLS and the last block in this config file detects if the scheme is using TLS or not. If TLS is not being used, then it simply returns a 301 redirect code to the client and changes the URL to use https instead. This way, you won’t miss out on users

There are a few extra parameters added to this config file. Including parameters declaring the timeout, the TLS version you ought to use and what encryption ciphers the server will be using. This was borrowed from Certbot’s recommended (but optional) configurations for Nginx.

Now, check if the configuration file is valid and restart the server.

Conclusion

You can apply the same approach for more complicated web apps and services that need HTTPS. Letsencrypt let’s you issue certificates for multiple domain names at once, and you can host multiple websites behind your nginx web server quite easily. If you followed the above example, try reaching out to your website using http (http://SUBDOMAIN.DOMAIN.TLD) and you will be redirected to HTTPS automatically.

For other web servers, like Apache, use the appropriate certbot plugin or refer their official documentation.

Problems with HTTP and Plain text

The Internet is an untrusted channel of communicate. When you send or receive information from  an old HTTP site http://www.example.com in your browser, a lot of things can happen mid-way to your packets.

1. A bad actor can intercept the communication, copy the data for themselves, before resending it again on the channel towards you or the server you were talking to. Without the knowledge of either parties, the information is compromised. We need to ensure that the communication is private.
2. A bad actor can modify the information as it is being sent over the channel. Bob might have sent a message “x” but Alice would receive “y” from Bob, because a bad actor intercepted the message, and modified it. In other words, the integrity of the message is compromised.
3. Lastly, and most importantly, we need to ensure that the person we are talking to is indeed who they say they are. Going back to the example.com domain. How can we make sure that the server that replied back to us is indeed the rightful holder of www.example.com? At any point in your network, you can be misdirected to another server. A DNS somewhere is responsible for converting a domain name, such as www.example.com, into an IP address on the public internet. But your browser has no way of verifying that the DNS translated IP address.

The first two problems can be solved by encrypting the message before it is sent over the Internet to the server. That is to say, by switching over to HTTPS. However, the last problem, the problem of Identity is where a Certificate Authority comes into play.

Initiating Encrypted HTTP sessions

The main problem with encrypted communication over an insecure channel is “How do we start it?”

The very first step would involve the two parties, your browser and the server, to exchange the encryption keys to be exchanged over the insecure channel. If you are unfamiliar with the term keys, think of them as a really long randomly generated password with which your data will be encrypted before being sent over the insecure channel.

Well, if the keys are being sent over an insecure channel, anyone can listen on that and compromise the security of your HTTPS session in the future. Moreover, how can we trust that the key being sent by a server claiming to be www.example.com is indeed the actual owner of that domain name? We can have an encrypted communication with a malicious party masquerading as a legitimate site and not know the difference.

So, the problem of ensuring identity is important if we wish to ensure secure key exchange.

Certificate Authorities

You may have heard of LetsEncrypt, DigiCert, Comodo and a few other services that offer TLS certificates for your domain name. You can choose the one that fits your need. Now, the person/organization who owns the domain has to prove in some way to their Certificate Authority that they indeed have control over the domain. This can be done by either create a DNS record with a unique value in it, as requested by the Certificate Authority, or you can add a file to your web server, with contents specified by the Certificate Authority, the CA can then read this file and confirm that you are a the valid owner of the domain.

Then you negotiate a TLS certificate with the CA, and that results in a private key and a public TLS certificate issued to your domain. Messages encrypted by your private key can then be decrypted by the public cert and vice versa. This is known as asymmetric encryption

The client browsers, like Firefox and Chrome (sometimes even the Operating system) have the knowledge of Certificate Authorities. This information is baked into the browser/device from the very beginning (that is to say, when they are installed) so they know that they can trust certain CAs. Now, when they try and connect to www.example.com over HTTPS and see a certificate issued by, say DigiCert, the browser can actually verify that using the keys stored locally. Actually, there are a few more intermediary steps to it, but this is a good simplified overview of what’s happening.

Now that the certificate provided by www.example.com can be trusted, this is used to negotiate a unique symmetric encryption key which is used between the client and the server for the remaining of their session. In symmetric encryption, one key is used to encrypt as well as decryption and is usually much faster than its asymmetric counterpart.

Nuances

If the idea of TLS and Internet security appeals to you, you can look further into this topic by digging into LetsEncrypt and their free TLS CA. There’s a lot more minutiate to this entire rigmarole than stated above.

Other resources that I can recommend for learning more about TLS are Troy Hunt’s Blog and work done by EFF like HTTPS Everywhere and Certbot. All of the resources are free to access and really cheap to implement (you just have to pay for domain name registration and VPS hourly charges) and get a hands on experience.