I apologize in advance for a long post. Here I just told people to stop using Privoxy (it causes me to open a huge gaping FTP securing hole in our PAC filter) and use Firefox + NoScript instead on Windows. Changing the address used in the hosts file as recommended by Giorgio is wrong from many standpoints. I could address them from the point of view of a network admin / managment person (and I have created network management solutions for a University and a state) but I won't. I will say that pseudo-randomly picking an address that in fact is not a host but a network itself is NOT a good idea. But the point in fact is that well known mechanisms are already set up to handle the requests at this IP address / port combination of 127.0.0.1 / 80. Here are just some of the phttpds (pseudo http daemons / servers) that depend on the 127.0.0.1 address staying right where it is at except for a couple of them and on port 80 unless you are some sort of nut (or just like to play around and experiment):
http://sysctl.org/cameleon/http://preview.tinyurl.com/8ujj9jhttp://preview.tinyurl.com/mavx9mhttp://www.abelhadigital.com/ (has a program called hostssrv.exe)
http://www.securemecca.com/phttpd.htmlOnly the first and the last can be set up to listen on your ethernet NIC port, with the first being explicitly designed for that purpose not just on the machine you are using but on a machine specially set up to handle the requests from multiple machines on a LAN (computer science lab, etc.). Now I did go down in hostssrv.exe and modified it to attempt to use 0.0.0.0 (MS localhost) with hexedit, but I sincerely doubt that will work so changing the IP address except with Camelon's phttpd (Psuedo HTTP Daemon) to another IP address is not advised. You can also set up a pseudo DNS server rather than having the hosts file at all (
http://www.peereboom.us/adsuck/ ). I can change both our PAC filter and our phttpd to use a different port. That's fine as long as the rule in the PAC filter itself does the REDIRECT (which is the proper term - it is technically not a BLOCK). But the hosts file is stuck at port 80 or what ever port the request is supposed to be handled on (21 - ftp, 22 - ssh, 23 - telnet, et al). Therefore I propose the following:
1. If this problem is because of a bad router, make a list of the ones to avoid. The one that left a gaping hole of allowing ssh from the WAN side is an example and explains all of those port 21, 22, and 23 probes my router blocks (hey, it is just little commodity router but I even have rules to block some ports in ALL directions). And it can NOT be tampered without using the password to alter the settings.
2. If this problem is because of slaggards that won't button down down their home routers with a good password and tightening the settings you cannot protect idiots from themselves. I cannot count the number of times I have counseled people on how to secure a broadband home router but it is in the hundreds of times and yet nobody wants to do it. Even if they do tighten down the settings on the router, they use their handy dandy password manager built into Firefox to access the router. Well here is one more piece of advice on that - DON'T store the password to your router on the machine. I don't care if you write it on a sticky note - just don't make it easily accessible to the Internet at large. Type it in manually each and every time you access your router. But if you have a key logger on your machine? Use Linux or Mac OS-X to access the router and have Windows users just USE it..
3. Both IIS and Apache can be configured to listen to some other port (I suggest 9980) on the loopback. If you use both a phttpd and a real web server that is configured to listen on the loopback IP address (127.0.0.1) this is what I recommend. I find it funny though since the people I fight can drop 10+ hosts into either the dumper IP zone or park them and bring up 10+ (plus 10% more) hosts HOT every day. By that I mean they probably don't do any local development. They really are that good. But there is a well known work-around to make both a real httpd and phttpd to live simultaneously at the same localhost IP address.
I am going to cut this short and write some if not all of this on my blog (
http://securemecca.blogspot.com ). But I know that the solution of just dumping the IP addresses some place else in your hosts file is not a workable one. Giorgio assumed one thing and encountered another. Leave your hosts file entries at 127.0.0.1 or get a dedicated machine on your LAN to do phttpd services on what ever machine you have on your LAN that you can with what Camelon provides. The machine that does this phttpd service can NOT have its IP address DHCP'd. The same thing goes for network printers, domain servers, etc. Set the IP address for where the phttpd lives statically and leave it there. Then you can change your IP addresses for these entries to where the centralized phttpd server is at. ABE Notifications? I suggest changing something some place with it in NoScript (hidden perhaps with only on demand viewing?). I will write something in my blog on this because it is critical - I don't have the time to make an RFC on this but in reality there should probably be one. Sorry for the long post.
Posted: Tue Jun 30, 2009 7:00 pm
