I installed Turnkey LAMP 11.3 in Virtualbox without errors or hicups. I have set aside a smal fanless via c7 fanless machine for it, once i learn how to configure it properly. English is not my language, so bear with me. I need to pass protect/render inaccessible from the outside of my network office. Is there a way to tie page to the root/user account or i need to use .htaccess file, or should i simply delete the contents of /var/www? Or if there is a way to disallow access to this particular page index.php from outside?

I tried several server distros and even ubuntu with default webmin on top of it, but Turnkey comes closer to my needs then any other. It's lightweight, fast and great comunity support.

 

Any help in this is apreciated.

Forum: 
L. Arnold's picture

You are correct.  Generally .htaccess file for a Program exclusion.

In the Firewall of Webmin you can specify Apache exclusions and permissions.

You might be able to exclude access to Webmin elsewhere in the Firewall.  Look around.

I have had luck with both .htaccess and Apache Permissions.  Really though I will likely set up the hardware firewall to do most of that work to keep the load off the appliances.  (next project)

Thanx for the info. I did not know you could limit access in the webmin firewall. I will definitely look into it.

Good idea with hardware firewall. I  had been looking into it myself, since i have couple of thin clients from HP lying arround here. I'm looking into m0n0wall and pfSense.

I will post my success (or lack of it) with webmin firewall.

 

Thanx again.

Jeremy Davis's picture

However the suggestion of enabling the firewall is probably a good one. Webmin makes using IPtables really easy! :)

hackercat's picture

Hello guys, first of all thank you very much for providing thess excellent images...Instead of starting a new topic i thought that it would be better to use this thread...

I am using a revision control applicance. I believe that is a very poor choice to leave the web panel unsecure, where everyone can see your source code...(if that was my goal, i would use a public repository).

Thus, i want to secure it with a username / password instead of disabling it with the firewall that you mention previouly...could you please help me with this procedure? i cannot find it which module and what to do with it.

Thank you,

Chris

Sorry, I was busy past week with work and crazy weather didn't help. Huge snowfall this year.

Doesn't look like it's  letting down anytime soon. I will try to look into it in the next couple of days. Personaly i just want to limit access to that panel from the outside of my office network.

You could rename the index page yourself and in its place put a password protected redirect index.html that once accessed calls the renamed control panel index. That is the easyest way of doing it. I have allready tried the above solution along with .htaccess and they both work or you could just delete the contents of /var/www as Jeremy sugested. It really isnt doing anything, its basically a page with links to the actual controls on your server that calls on diferent ports. Personally i need the firewall solution since i will be redesigning that page for something else.

I will post the results as soon as i can. Cheers

Jeremy Davis's picture

If you have a local domain and DNS servers, then you could change the Vrtualhosts directives so that the 'landing page' (with all the links etc) is only available via it's internal name eg like http://server.company.local whereas the other stuff that you want available externally is http://your.real-domain.com. Although I guess this isn't really all that secure (it'd be easy to spoof a domain if someone wanted to).

I have worked with the LAMP appliance a fair bit now and what I generally do is add my content to a subfolder of /var/www eg /var/www/some-folder. Once it all works as I want (via http://some.domain.com/some-folder) I disable the default Apache site, create a new apache site from it, append some-folder/ to the document root (default is /var/www/ - save and exit), enable the new site and reload Apache to apply the config:

a2dissite default
cp /etc/apache2/sites-available/default /etc/apache2/sites-available/new-site
nano /etc/apache2/sites-available/new-site #append 'some-folder/' to doc-root
a2ensite new-site
service apache2 reload

Then when you browse to http://some.domain.com your content is right there!

As I already suggested it's not really a security issue anyway. My rationale for that statement is that the sites/pages that the landing page point to are still going to be available unless you actually lock them down... So unless you are going to force https, enable the firewall to protect access to sensative parts (eg Webshell/Webmin/phpMyAdmin) from anywhere other than known addresses then your site will be somewhat insecure.

I think you need to keep in mind that just making something not so obvious (ie security by obscurity) is not really security at all. It's a bit like putting the front door key under the middle of the mat rather than the edge! I guess the chances are that some kids might not check under the middle of the mat, but generally you'd be much safer not leaving the key there at all!

hackercat's picture

Hey guys thanks for the prompt answers,

Yeah changing url is a solution and a lot better from leaving the default.

But i still believe that we have a poor design choice here leaving unprotected (i.e., no password access) the initial web panel page listening on port 80. The best would be to secure the first page similarly to the configuration page, where a username password is required under ssl protocol.

I havent checked the other applicances, but i have a feeling that the other personal/sensitive applicances (eg., projects management appliances)  have this same erroneous feature. 

 

 

 

Jeremy Davis's picture

I mostly use LAMP and Core but have had a play with a few of the others. I can't speak specifically for the Revision Control appliance because I've never used it. Regardless here's my 2c...

Personaly I don't quite understand your logic.

Firstly, one of the first things I imagine most people would be planning to do is replace this 'TKL landing page' with their own customised home page (or reconfigure the server completely). So in that instance it is somewhat of a moot point.

Secondly, all it contains is links to other resources that are currently available (and all important stuff is protected with passwords and only available via https)... How is that insecure? There isn't actually anything available there on that page that a half-decent hacker couldn't find out about your server within 5-10 minutes anyway...! IMO it's better for it to be obvious that what's open is open, than create the illusion that its not...

OTOH I think that it would be good for things such as password protection (of a site or a sub-dir) or forcing of https to be clearly documented (here on the site - which it currently isn't). Although in the meantime documentation for all that stuff is pretty readilly available via google, or users can ask here on the forums! :)

So I will grant you, that having step-by-step instructions on how to secure appliances further if that is your desire would be a clear improvement, but I don't think having them completely locked down is necessarily a reasonable default. These appliances are designed to be a starting point, not an end point...

For some they will be ok OOTB, but others (such as yourself by the sounds) can use them as a starting point and customise them as they see fit, depending on their desires and usage scenario. TKL appliances include software pre-installed and basically configured as the creator defaults to as a minimum. Some appliances are configured further, but only when it will be relevant and useful to most, if not all TKL users.

So, the bottom line is; TKL aims to create appliances with/as a reasonable starting point that will be relevant to as wide an audience as possible. As it's all open source software, you are always free to modify, tweak and adjust however you like.

If you have some specific appliance requirement where the default doesn't suit your individual usage scenario, then change it!

Having said all that, if you feel strongly that the TKL devs have got it wrong, why not lodge a blueprint? Or better still, create a TKLPatch that configures things the way you think they should be!? Then others can share in your work and who knows., perhaps the devs will agree and future releases of the appliance will include your customisations...!

Realy, that's what I think open source is all about! It's not just about getting free stuff! It's about giving back! It's about building on and refining the work of others! So go for it! Can't wait to see what you come up with! And who knows... perhaps when i see what you think it should be like I'll go: "wow, you are so right!" :)

[edit] Just re-read thjis and it's a bit of a rant! Hope it's not offputting, that isn't the way I meant it! :)

hackercat's picture

The front page of the revision control page leaves your work unsecured...thats all and thats a huge mistake!!! Please check it yourself, since you havent used it, or someone verify it if there is something i am missing.

I know that TLK are supposed to be a start but i also strongly believe that my notice is simply to put a username / password in port 80 or even better https...i think this is the rule not the exception. This appliance deals with sensitive data!!! its not joomla, drupal etc.

I will submit a blueprint...but is there someone to suggest me a good starting point to secure the webpage?

 

 

 

I opened this thread so i could find help and get some pointers and maybe give them.

I must admit that i'm on Jeremy's side on this one. I too consider TKL a good starting point. I consider a TKL a great way to install all in one go in a few minutes. I'm quite capable of installing everything on top of ubuntu server, but the trouble with it is that they install too much stuff along with what i need. Plenty of documentation online for open source software if you want to change a part or all of it. The beauty of open source is exactly this, anyone can change anything to suit their needs. And as for securing a webpage, we just told you several methods. Besides, how did we get from LAMP stack to Revision Control Appliance?

Jeremy Davis's picture

And I certainly don't mean to be antagonistic. I apologise if my above rant was a bit over the top.

But if you'll excuse me, now that I have had a quick look at the Revision Control appliance I would just like to make one last response to hackercat.

@ hackercat - After having a look at the Revision Control appliance I think I understand what you are saying. Yes, the repos in the appliance are not read protected (with a password). Regardless, I still stand by my points above. This appliance is not insecure, just public. From my quick glance, it appears that the repos are read only and not open for writing (if they were then that would be a different matter IMO). TBH this is what I'd expect as default configuration for an appliance which itself only exists because of free and publicly available open source code.

If you want any further pointers I'm happy to help were I can but it's probably best to open your own thread.

Back to the topic at hand. I've done a lot of reading today on iptables and sort of went into an overload, heh. Waay to many options to configure. Going to put it of for another day. While i have not been able to accomplish locking down external access to the /var/www/index.hp via iptables, i did find another way of neutralizing the panel.

 

Delete the contents of the /var/www/ folder.

Under Apache/Virtualhosts redirect the root to another virtualhost o delete it altogether.

 

Im having trouble with my Virtualbox setup, for some reason it wont let me access the virtualserver from the outside. It does work on the LAN, though. Looks like I'm going to move the lamp installation to a thin client sooner than expected.

Cheers

Jeremy Davis's picture

Other than via Webmin, and that makes it all to easy in my experience (although even then I haven't used it much).

As for external access, make sure that you have your port forarding set up correctly (assuming a NAT'd router) and/or ensure that you allow access through your firewall (if you have one). An online port scanning service such as SheildsUp! can be invaluable in troubleshooting external access issues. For your server to be able to work the port must be open.

Also be aware that some ISPs' Terms of Service do not allow servers to run on some internet plans. When that is the case they will often block common server ports such as 25 (SMTP), 80 (HTTP) and 443 (HTTPS). If that is the case you will need to either contact them (to discuss how you can have them unblocked), or use an alternative port (and connect via http://<domain-or-ip>:<port-number>/ eg http://some.domain.com:8080/). Another option is to use an alternative port, but use a service such as ChangeIP which can redirect traffic from a standard port (eg 80) to a non standard port (eg 8080). So the end user need only type in the url, but the request is redirected to your non-standard port. Also note that port 8080 is somewhat of a standard alternative HTTP port so you may need to go for a completely different port. If you go this route then most router/modems allow remapping of ports. This means that you won't need to reconfigure your server, just remap external port requests (whatever port you set) to port 80/443 on your server.

If the port is open and it still isn't working, then I'd double check your Apache config and ensure that your virtual hosts are either asterisks (eg '*:80') or the external domain/IP (eg '123.456.789.012:80' or 'some.domain.com:80'). If you are using specific external IP or FQDN then you will need to add a server alias to still allow LAN access.

I already operate and maintain a linux server. This one is intended as emergency failover system, until the main system is back online, if it goes down for some reason.

As for my ISP, they already know that i run web server, since i design static websites and provide hosting services for them. And if they do decide to close of the ports for them that would just give me the excuse to jump ship for another provider. I'm not really happy with this one, there is always something to troubleshoot with costumer service.


Right now I'm just waiting for my current contract to expire so i can switch ISP.

Jeremy Davis's picture

Sounds like chances are that you know more than me about all this then! :) Sorry not much more I can add then!

I like tinkering with linux, but only last year started getting serious on the server front. And most of my knowledge is basically trial and error stuff along with lots and lots of google and lets not forget the hosting providers before i moved all of the work to the personal server. Heh. I could rarely get them to understand what i wanted to do and almost always i got shufled to some obscure tech support to wherever they outsource such things.

I just finished installing LAMP to my thin client. Later in the evening i will move a copy of my sites to it and recreate virtual hosts.

The thin client has no optical drive so i had to install it via usb flash drive. Bellow is the procedure for anyone who cares to repeat the process.

Hardware: Igel Via C7 CPU 1GHz, 1GB DDR2 RAM, 80 GB HDD (until i mount the 1.5 TB nas sitting here.)

Downloaded latest unetbootin http://unetbootin.sourceforge.net/.

Installed turnkey-lamp-11.3-lucid-x86.iso as a diskimage to a 2gb FAT formated flash drive.

Once the the thin client booted of the usb flash hard drive I just hit default and normal installation begun. After that the rest was a breeze.

LAMP stack installed in a few minutes as expected and without any errors. I imagine the same procedure works on other appliances too, since they all share the same base.

Jeremy Davis's picture

So the web server that is used in the TKL LAMP appliance is Apache (Apache2 to be precise). So your best bet is to consult the Apache documentation.

Jeremy Davis's picture

But I don't know. I used Webmin initially when I first started with Linux (from Windows) and for some stuff (like Samba config) I still use it. But for other things I find it quicker and easier to just do it the old school way.

A quick Google turned this up which may be what you're looking for? I haven't tested it so I can't confirm that it works but give it a spin and see how you go.

Add new comment