Check for existing webservers during installation

[Mcat12]

@SunderRaj

Nop. I never said this. In fact, as you could see my message to @deathbybandaid, I clarified that this is just the wrong thought.

That is why I specifically used the phrase "it looks like"

[SunderRaj]

@DL6ER

I don't know what may happen to the performance of IPTables if we would install tens of thousands (or even worse) rules, each requiring a packet inspection.

Your idea "Evaluate/Analyze the connection" appeared richer then mine "Forward the connection".
Even now, I favor your idea.
But I also see now that your idea may have a "noticeable performance penalty" with a potential to increase the performance penalty: More the domains slower the system becomes.
Now I am looking on something else too, as I realize that this is not so easy as thought initially.

[SunderRaj]

@Mcat12

That is why I specifically used the phrase "it looks like"

I see that my messages above were not very clear. Let me catch up and make things very clear on what I had meant earlier:

1. REQUEST UDP-DATA STREAM:

This stream will work with UDP (or even with TCP) protocol. The UDP protocol for DNS @ 53 DOES NOT HAVE ANY PORT INFORMATION. Thus, no resolver on earth could contain information in this regards.

2. TCP-DATA STREAM

This stream will work with TCP protocol. This stream is invoked at the workstation requesting the DNS query. After the reply is received from the REQUEST DATA STREAM, a TCP packet is constructed. In that TCP Header, the IP returned by the DNS Query is written, which also includes the port information of the destination.

Thus, the TCP header like is constructed and negotiation begins:

UserIP:UserPort ---> RETURN (output) TCP-DATA STREAM ---> PiHoleIP:80 (or 443)

So, what I meant above with the term "diversion" is that pi-Hole makes an "intelligent diversion" of generating PiHoleIP:80 instead of DomainIP.com:80! The term diversion was not meant to be the data stream itself but implied in the substitution of an IP that causes a diversion at the requesting workstation.

I hope that I made it very clear from above.

[DanSchaper]

@SunderRaj

So, what I meant above with the term "diversion" is that pi-Hole makes an "intelligent diversion" of generating PiHoleIP:80 instead of DomainIP.com:80! The term diversion was not meant to be the data stream itself but implied in the substitution of an IP that causes a diversion at the requesting workstation.

No, Pi-hole does not divert at that level. Pi-hole receives the DNS request (be it over UDP/53 or TCP/53, it doesn't really matter,) and responds with either the IP address of the server on the Internet, or the IP address of the Pi-hole device. The client browser then makes the request to either the Pi-hole IP or the Server IP at what ever port it requires. RFC compliance dictates that unless this is modified by a proxy, a policy or other administrative mean, those requests from the browser go to either port 80 or port 443 depending on the protocol requested. We do not proxy, we only respond to queries for DNS addresses. The response from the Pi-hole when called by a client on port 80 is to reply with our block page, currently served via lighttpd.

These are two totally separate and individual processes.

[SunderRaj]

@DanSchaper

No, Pi-hole does not divert at that level.

@DanSchaper

The client browser then makes the request to either the Pi-hole IP or the Server IP

If you read my post carefully, you shall notice that I mean exactly the same, what you described in your own words.

What I meant is that pi-Hole DOES NOT cause a diversion at the pi-Hole server but it causes a diversion at the workstation.

The diversion is caused at the workstation where the browser resides. Then, the browser will no longer initiate a TCP transaction to the DomainIP but it will go to pi-HoleIP, where the lighttpd would respond.

Thus, they are obviously two seperate streams, which is what I very clearly mentioned. Do you get it now that both of us mean one and the same thing but in different words?

[DanSchaper]

I concur with your summation then.

[SunderRaj]

I just thought there is a different way to work with for port forwarding and have lighttpd work as reverse proxy. With the start of my work, the first thing I found is something very nasty, which I knew it earlier, and confirmed that this has remained unchanged:

http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModProxy

" lighttpd mod_proxy does not currently support SSL/TLS connections to the backend server."

Then, if lighttpd is in the front end, all the SSL connections passing through to other servers like apache will not remain SSL and will be terminated. Or did I misunderstand or miss something here?

[SunderRaj]

I have now managed to do the following:

1. The default port 80 in lighttpd is turned off. This means that lighttpd does not listen @ port 80 at all.

2. The admin directory is served from a dedicated non-custom-port @ 2096.

3. The admin directory has SSL turned on. One certificate server.pem is created and placed in lighttpd dir. This certificate has strong ciphers with Perfect Forward Secrecy standard as well.

4. The admin directory is password protected with .htaccess.

5. The ads blockpage is also served from a dedicated non-custom-port @ 2086.

It is now possible to have nginx as a reverse proxy in the front and apache/lighttpd in the back with two different local IPs. Thus, if a normal http request for a domain comes in, the nginx will pass the connection to apache. If not, it could send it to lighttpd as a dedicated default server.

eth0 =127.0.0.1 ---> 80 (http) / 443 (https)
eth0:1 = 127.0.0.2 ---> 2086 (http) / 2096 (https)

Any suggestions on above?

[SunderRaj]

@DL6ER

I'm interested in seeing what you may come up with. As already said my major concern at this point is that I don't know what may happen to the performance of IPTables if we would install tens of thousands (or even worse) rules, each requiring a packet inspection.

Following is my opinion on this issue.

What you suggested would mean to screen data packets beyond TCP headers. Instead, one could simply make a connection to gravity.list through php scripts to find something in there. The iptables thing is going to add overhead on the server and it would be less favorable solution.

Regarding my solution on handling TCP headers:

As mentioned earlier, xinetd deamon and port forwarding would be the right concept to work with, for several reasons. It work at the level of TCP headers. So there is no packet filtering. It requires minimal resources. Very easy to configure. Gives additional security layer too.

One suggestion is mentioned here, although this belongs to the very fundamental theory of how xinetd works:

SSH Connections Refused When Routing Through Xinetd

Port forwarding via xinetd in NATed environment

Here, I show that it is possible to make a port forward from RouterIP@80 to PiHoleIP:127.0.0.2@2096 and have the detection of RouterIP(DynHost) through xinetd.

Thus, all incoming traffic that is != RouterIP could be port forwarded to Apache:127.0.0.1 with NameVirtualHost:80 and all == RouterIP will be forwarded to lighttpd:127.0.0.2.

This solution is clean, easy and light.

I could make all this work. But lighttpd crashed upon xinetd start. I discovered that the lighttpd team has closed such an option to create a socket-on-demand.

Consequently, if one wants to use lighttpd, this solution cannot be used.

While investigating the matter, I began to challenge the idea of using lighttpd in the first place. It is better to have a small webserver or a proxy on the workstation in such a case, which will obtain the IP of AdsDomain and generate a blockpage:127.0.0.1.

So, if the pi-Hole-DNSServer is installed in the datacenter, we require pi-Hole-DNSClient, which may do some jobs on the workstation.

Here, I found a beautiful solution too: Acrylic Proxy from Sourceforge + a small executable to monitor/start/stop the service. It does the DNS caching, has a local blockhost file, includes a webserver in it for blocking and it is open source.

My conclusion on this request is:

1. Terminate the use of lighttpd and find another httpd deamon that works with tcp server/xinetd and allows port forwarding on demand.

2. Develop a DNS-Client proxy services on workstation for caching locally DNS plus generating a webpage. Here, a plugin in a browser may help. I would rather suggest an executable to capture the TCP/UDP stack to act like a DNS firewall.

After all, I am not convinced, if pi-Hole resides in a datacenter, why should be a blockpage generated from the datacenter, when the IP is changed and could be inserted like 127.0.0.1:BlockedDomain.com. This could be done locally. On Github, someone has already done small tool on windows too. It would be better to have this direction developed rather than anything else.

[MokaMokiMoke]

Hi, currently I´m running my pi-hole on a dedicated raspberry 3 machine and it´s working quite well. In the future I´d like to migrate it to my "productive" raspberry system because it looks like pi-hole is really cpu and memory economic.

On the productive system I´m running a seafile service (similar to owncloud if you don´t know this) with mysql and nginx. I´m not new to nginx but before I destroy my running systems webservice I´d like to ask you what to do to install and configure pi-hole on an machine which already uses an webserver. Could there be any interference with the existing services already running on the machine?

Of course I´d like to handle everything accross the nginx webserver (including all the ssl/tsl stuff). Thanks in advance for your help.

[DL6ER]

First of all, we know Seafile, it is a great piece of software. When I first came across it, the Raspberry Pi B+ (version "1") was brand new and I tried that. That was no joy at all. I'm now running it on a dedicated server with several Terabytes of storage and a few dozen clients. Still performing great and I couldn't imagine today how I could live without it having all my data synchronizing securely form my office, my mobile devices and at home.

As you say, there are basically two possibilities for you:

1. Install lighttpd and nginx in parallel (what you don't want).
   That is the most easiest approach and won't break things. You could e.g. set up nginx to use HTTPS port, and lighttpd HTTP port. Thereby, they would not interfere with each other. This will also be a zero headache solution because the Pi-hole updater can perfectly cope with this situation.

2. Configure nginx to serve the Pi-hole web interface under e.g. yourserver.de/admin
   That is of course also possible, but I cannot help you here (I'm using Seafile with Apache which only serves HTTPS).

[deathbybandaid]

I'm personally running nginx on port 80, and using a proxy for the /admin folder. Lighttpd is running on an alternate port.

## Pihole
location /admin {
proxy_pass http://127.0.0.1:83/admin;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

[jacob.salmela]

This post will be unlisted, but can be accessed from here (the parent feature request):

Support for choice of resolver and/or Web server

Add the ability to choose your own resolver (Unbound, BIND, dnsmasq) and/or Web server (i.e. nginx, Apache, or lighttpd).