I have Shibboleth configured on an IIS server and am using it protect a .NET application.
I need authenticated access for users accessing the application over the web and for that Shibboleth is working fine.
The application also hosts web services which need to be accessed by other applications in the same server and for that working with Shibboleth is a challenge since web service clients cannot deal with the log in page.
Is it possible to configure Shibboleth to ignore requests coming from the same server for example by checking the IP address?
It won't directly answer your question, but I can share a workaround I found and hope it can help with your problem too.
Define another website in IIS pointing to the same folder as the initial one, and make it only respond to a different domain (like something.local). Then in IP Address and Domain Restrictions, make sure only 127.0.0.1 is allowed to access it.
In C:\Windows\System32\drivers\etc open the file "hosts" in Notepad (running with Administrator privileges). Add the line "127.0.0.1 something.local" (no quotes; make sure the domain is the same one you defined before)
Now, make the webservices call the application by the new domain.
Related
I have built a basic web application using html, css and php (it is a library with query, modify etc. capabilities). I have built the databases containing the books information, subscribers information etc. with phpMyAdmin from Wamp server. On localhost (C:\wamp\www) everything works ok (I can add, modify, make queries etc.).
Now I would like to make this web application available online, but I have no idea how this can be done. The access to the database must be also available online (for search, queries etc. from the databases).
Can somebody support me?
The access to your database can be local since the php files that use yourdatabase run in the same machine.
You only need to accept online access to your apache server, if it's not accessible yet, and have no firewall active. In this case you should be able to connect to your server by ip. And you'll need a domain and a dns server if you want not having to write the public IP to connect.
You need a public IP address or routing the outside web traffic to your own web server.
Most routers have an advanced section called IP/Port Forwarding: find yours. If you don’t have this, I’m afraid you cannot be reachable by the outside.
Besides that, find your private IP with:
C:\>ipconfig
take note of the IP address: that’s your private address, which uniquely identifies you in your local network.
In httpd.conf change:
ServerName localhost:80
With:
ServerName <private IP>:80
Also find this line:
Require local
And change it to:
Require all granted
Restart your web server. Find out what’s your current public IP address (the public address of your router: https://www.whatismyip.com ) and visit:
http://<public IP>:<port>/
Or, in case you have not changed the default http port (80) just visit:
http://<public IP>/
I've been thinking of the concept of an ad blocker that runs at the OS level, rather than as a browser extension. I know that I can place x.com in Windows' %windows%\system32\drivers\etc\hosts file and point it to the IP of y.com, and on y.com I can serve up content that says, "This ad blocked by Example Ad Blocker". However, the domain list I have is quite large -- like literally a thousand domains and growing, and so this wouldn't work well in file lookups. Does Windows permit some way to programmatically, like Qt/C++, add a DNS reroute rule in a more speedy way?
There's a risk of doing domain intercepts and DLL hooks using APIs because AV products and/or Microsoft would have to whitelist you and certify you so that your activity doesn't look like a virus. And the odds of them doing that are not only low (unless you're a multimillion dollar company), but they want to protect their ad marketing too.
The best option is to make a browser extension for each of the browsers. You can even check the source code of the AdBlock Chrome extension to see how it works. The trouble with that in 2017, however, is that there's no common browser extension platform just yet. It's getting much closer, but it's still not standardized yet. The new standard uses the Chrome standard. Opera, Firefox, Edge, and of course Chrome support this new standard to some degree, but it's kind of unsmooth still. And for anyone outside of that, such as IE11 or earlier, they're not going to have your Chrome-style browser extension and you'll have to go the seriously hard route to make one just for those earlier browsers or ask the customer to upgrade when your adware product installs.
If you want something that doesn't require a browser extension, then the option you want is to add another DNS server connection in the user's DNS client settings. I don't know how to do this yet via C#, Qt/C++, or C++. However, you can shell out from those languages and use the "netsh" command to create those DNS connections. Probably a good strategy would be to find the user's default gateway IP. Then, make the DNS priority like so:
your DNS server that redirects x.com to y.com so that you can do ad blocking from y.com via a web server
the user's default gateway IP
Google's DNS (8.8.8.8) in case the default gateway IP has changed for the user
So, it would be something like these 4 netsh commands:
netsh delete dnsserver "Wireless Network Connection" all
netsh interface ip add dns name="Wireless Network Connection" addr=1.1.1.1 index=1
netsh interface ip add dns name="Wireless Network Connection" addr=192.168.254.254 index=2
netsh interface ip add dns name="Wireless Network Connection" addr=8.8.8.8 index=3
Change "Wireless Network Connection" to "Local Area Connection" if they are using a cable for their computer instead of wireless. (Few do that these days.)
Change 1.1.1.1 to the IP address of your special DNS server.
Change 192.168.254.254 to the IP address of their default gateway.
The third rule (8.8.8.8) tells the computer to use Google's DNS if all else fails. This is important because they could disconnect their laptop at home and go to a café or something, and we need their DNS stuff to still work.
Now, once you get the DNS client settings right, you need a cheap Linux cloud host to serve up the DNS server and web server. You might even need more than one in case one goes down for maintenance, and possibly on a different cloud zone or even cloud hosting provider.
For the DNS product, if you have Linux skills, you can install and configure dnsmasq pretty easily to get a cheap and easy to manage DNS server on Linux. Or, if you search your Linux repositories, you can find other DNS servers, some more robust than others, some harder to use than others.
For the web product, you can install NGINX or Apache on each of the two DNS servers. Then, you can make a configuration where any domain connection can come to it and it will load a web page for that domain. The web page can say something like, "Ad Blocked By X Ad Blocker" or whatever you want in very small font (small enough to fill the ad spot).
Once this is all in place, you'll have to reboot the Win PC client and also clear their browser cache and history so that DNS will route through the new arrangement.
The end result is that when people on that Windows PC surf the web and load an ad, their OS will make a DNS request to translate domain name to IP address. The first DNS server they'll reach will be your private DNS server. It can then say that x.com ad domain (as an example) is the IP address of your private DNS server. That private web server will then be contacted and it will display the ad block message. For all other requests not served up by your DNS servers, they'll go to their default gateway. If that's not serving up DNS as needed, then they'll failsafe to the Google DNS on 8.8.8.8. So, web browsing will work fine, minus ads.
As for a bad domain list, there's a community-maintained bad domains list here on Github.
The trouble with the private DNS server that you host is that you're now having to pay a bandwidth bill for gobs of connections to it. That's probably undesirable unless you've got a proper way to monetize that. A better strategy would be to NOT use a private DNS server on the web and use a local DNS server and a local web server. You'd have to code both of those or use some third-party product for that. The trouble there, however, is that you may have some commercial licensing problems with that, or increased costs, and it won't work for some web developers who already use a web server on their workstation.
Therefore, as you can see from the added costs, hassle, and workstation configuration nuance troubles, the best strategy would be to use the browser extension for ad blocking.
However, even at that, how are you going to differentiate your product from the free ad blockers out there that are doing a sensational job already?
I have a website and until some time ago it was administrated by a friend of mine; recently our relationships have been reduced, so I took the entire control of the website.
I'm not really expert with some aspects in the management of a web site. Actually I would make some back-end edits and I should connect with the server of the website.
I have the host IP, a username and a password. I tried to connect using Filezilla but I receive an error message: 530 Login incorrect.
So, I contacted the domain provider, I was convinced that the domain provider was the same of the hosting provider, but they told me that it was not true and that the hosting for the website is provided by "someone else" (it could be an other hosting provider or a private web-server, for example).
I don't know what to do.
How can I connect to the server of my website? What am I missing?
p.s.: sorry for my bad english
I think you might be pointing filezilla at port 80. Try pointing at the ftp port (21 probably.) If this doesn't work it could be that the hosting uses a non standard port.
If in doubt get some support from the hosting company. Only they know how they are set up. If the use something like cpanel you can access files through that. They may be reluctant to help if you can't prove the site is yours. Usually by using the email address you set up when you bought the hosting.
And no, the domain provider does not have to be the same as the hosting provider. My domains are hosted at godaddy and I have odd bits of hosting all over the place ;)
I have a web application, in which a web service resides in a folder. The whole web application can be accessed from anywhere, while the web service should only be accessed from certain IP addresses. I can't separate them and take the web service into another IIS web site, thus I need to restrict the access to the web service, while it resides in that web site. However, I have no limitation in creating virtual directories. What should I do? Can I do it at all?
To understand the scenario better, suppose that the domain of the website is www.sample.com, and every address on this website is accessible to all the Internet. For example, www.sample.com\path1 and www.sample.com\path2 are browsable by everyone and every IP address out there.
But the address of the web service www.sample.com\services\user.asmx should only be accessed from certain IP addresses, like 217.218.192.50 && 107.50.27.30 for example.
How can I achieve this configuration in IIS7?
OK, what a simple action it was.
Simply select the folder in IIS7, and from the right hand, select IP Address and Domain Restrictions (which if is not visible, must be reached via Features View tab).
Now, you can allow or deny any single IP address, or a range if IP addresses from seeing or not seeing your folder, and anything inside it.
I have a web service running under IIS7 on a server with a host header set so that it receives requests made to http://myserver1.mydomain.com.
I've set Windows INtegrated Authentication to Enabled and everything else (basic, anonymous, etc) to Disabled.
I'm testing the web service using a powershell script, and it works fine when I run it from my workstation against http://myserver1.mydomain.com
However, when I run the same exact script on the IIS server itself, I get a 401-Unauthorized message.
In addition, I've tried installing the web service on a second server, myserver2.mydomain.com. Again I can call my test script fine from BOTH my workstation and from myserver1.
So it seems the only issue is when the client is on the same box as the web server itself - somehow the windows credentials are not being passed or recognized.
I tried playing with IE settings on myserver1 (checked and unchecked 'Enable Windows Integrated Authentication', and added the URL to Local Sites). That did not seem to have an effect.
When I look at the IIS logs, I see the 401 unauthorized line but very little other information.
I see basically the same behavior when testing with IE (v9) - works from my workstation but not when IE is running on the IIS server.
I found the answer after several hours:
By default, there is something called a LoopbackCheck which will reject windows authentication if the host header used for the site does not match the local host's name. This behavior will only be seen when the client is on the local host. The check is there to defeat possible reflection attacks.
More details here:
http://support.microsoft.com/kb/896861
The kb item discusses ways to disable the Loopback check, but I ended up just switching from using host headers to ports to distinguish the different sites on the IIS server.
Thanks to those who gave assistance.
Try checking the actual credential that is being passed when you are running on the server itself. Often times you will be running on some system account that doesn't have access to the resource in question.
For example, on your box your credentials are running as...
MYDOMAIN\MYNAME
and the server will be something like...
SYSTEM\SYSTEM_ACCOUNT
and so this will fail because 'SYSTEM\SYSTEM_ACCOUNT' doesn't have credentials.
If this is the case, you can fix the problem in one of two ways.
Give 'SYSTEM\SYSTEM_ACCOUNT' access to the resource in question. Most people would avoid this strategy due to security concerns (which is why the account has no access in the first place).
Impersonate, or change the credentials of the client manually to something that does have access to the resource, 'MYDOMAIN\MYNAME' for example. This is what most people would probably go with, including myself.