We have developed a RESTful Web Service which requires access to a Network share in order to read and write files. This is a public facing Web Service (running over SSL) which requires staff to log on using an assigned user name and password.
This web service will be running in a DMZ. It doesn't seem "right" to access a Network Share from a DMZ. I would venture a guess that the "secure" way to do this would be to provide another service inside the domain which only talks to our Web Service. That way, if anyone wanted to exploit it, they would have to find a way to do it via the Web Service, not through known system API's.
Is my solution "correct"? Is there a better way?
Notes:
the Web Service does not run under IIS.
the Web Service currently runs under an account with access to the Network Share and access to a SQL database.
the Web Service is intended only for designated staff, not the public.
I'm a developer, not an IT professional.
What about some kind of vpn to use the internal ressources? There are some pretty solutions for this, and opening network shares to the internet seems too big a risk to do.
That aside, when an attacker breaks into your DMZ host using those webservices, he can break into your internal server using the same API unless you can afford to create two complete different solutions.
When accessing the fileservers from the DMZ directly, you would limit theses connections using a firewall so even after breaking your DMZ Host the attacker cannot do "everything" but only read (write?) to those servers.
I would suggest #2
Related
I've created a SOAP Service in ABAP, which perfectly works inside the network.
Now I wan't it to be called from outside and I haven't really found any tutorial.
Most likely a SAP Web Dispatcher or a reverse proxy is required, but how to use them?
Or is there an easier way to make the endpoint "public" and callable from the "outside"?
Making it public not part of SAP system. You need to configure your network to allow incoming request. Generally you need to configure your firewall. You need to open a port on firewall and redirect it to your SAP server http/https port. It will also create a risk for opening http/https port to outside. You must sure about limit your your web service user authorizations and changing all default passwords and using update date SAP system for security patchs.
For more get security I prefer to use a proxy server like nginx/apache to just serve your SOAP service over it.
Usually it is done thourgh reverse-proxies, to minimize risk of attacks from public Internet.
The general schema looks the same, although there are multiple variations depending on the company
The oldest and the most traditional reverse-proxy for SAP systems is a Web Dispatcher
SAP Web Dispatcher it includes load balancing and HTTP filtering
https://informatik.rub.de/wp-content/uploads/2021/11/2_sap-secure-configuration.pdf
https://wiki.scn.sap.com/wiki/display/SI/FAQ+Web+Dispatcher
https://blogs.sap.com/2021/05/09/landscape-architecture-sap-web-dispatcher-deployment/
SAP Gateway is a framework for exposing functionality as REST/SOAP web-services
https://blogs.sap.com/2018/04/15/sap-odata-service-get-consume-rest-service/
The tutorial for configuring SAP Web Dispatcher + SAP Gateway together
https://help.sap.com/saphelp_uiaddon10/helpdata/en/ec/342f1809c94d2b817ba772fe69e43f/content.htm?no_cache=true
The other options for reverse-proxy for SAP:
nginx
Apache
...
You are free to choose any reverse proxy on the market depending on your environment.
The question rather concerns alternatives to Amazon Route 53 and Google Cloud DNS (Direct traffic). As far as I understand from the descriptions of these services, they only work together with their other services.
I'm trying to find a service that will allow you to determine the country of a user and, if necessary, redirect all of its traffic to the correct server.
For example, I have two servers - the main server with the application and the proxy server. By default, I want to direct all users directly to the main server. But users of certain countries I want to pass through the second - a proxy server.
Tell me, please, how best to implement all this. Perhaps you have any more correct options for implementation?
We currently have a large array of customers (1000 different on-premises installations).
We use a single server to host our sites which communicates with on-premises WebAPI's.
Currently we limit the traffic to the local servers in the router to allow only our server to access the local API's.
However we are considering moving alot of these webservices/sites to Azure which in turn means limiting on the IP's addresses becomes not feasible.
What approach would you recommend to allow the Azure servers to access the on-premises servers?
Best case scenario would of course be that no ports needed to be open in the routers (limit maintenance) however this seems very hard to accomplish if we still would like the ease of development that WebAPI gives us.
Otherwise we have thought about opening for public access to the API's but securing with https and authentication.
Does anyone have any alternative solutions?
Note: The on-premises WebAPI services are hosted with selfhost inside a Windows Service.
You could try using 'Azure Hybrid Connections' to access your on-premises Web API.
You could host your websites as 'Web Apps' in Azure App service and access your Web API.
You do not need to open any firewall ports or change your network perimeter configuration to allow any inbound connectivity into your network
I currently have a number of web services on a single server.
In the future we want to move the load off a single server and split it to other servers.
I am familiar with the concept of scaling out but in our case I want to have different web services on different web servers so that traffic can be routed to the correct web services. So web services that do a lot more intensive work can be dedicated to a specific server.
How would I do this?
Would I need to change my client applications so that the correct webservice is called on the correct web server?
I think the proper pattern to use here would be tho have one server with a dispatcher that will just forward requests to appropriate back-end services. Then if you decide to move one of back-end services to another server, then you can just make configuration change in the dispatcher.
I am sure you can do it programmatically, but I am sure software or hardware (like F5) load balancer have ability to configure it out.
Not sure of the best way of achieving something...
We've got a number of web services running on asp.net v3.5 on a couple of web servers. They all talk nicely to each other and to the public internet.
Now we'd like to keep some of these web services 'private' ie make them not available to the public internet, whilst leaving others accessible.
AFAICS the simplest way to do this is simply to run the private services on a different port and keep the public ones on port 80. Our firewall only permits internet access via port 80 so would drop any requests from the internet to the private web services. Sorted... I think?
Is this idea a reasonable solution? Or is there some drop dead simple IIS mechanism that I ought to use?
Thanks
SAL
You can restrict access to a site via a blacklist/whitelist in the IIS control Panel (directory security tab). That's what I've done in the past to filter by IP address.
AFAICS the simplest way to do this is
simply to run the private services on
a different port and keep the public
ones on port 80. Our firewall only
permits internet access via port 80 so
would drop any requests from the
internet to the private web services.
This is exactly the approach we take. We also have a VPN so that employees can access the site if they're working remotely.
You can put IP access restrictions onto any site/app you want. We have several internal web services that only allow access on the 10.x.x.x range for example.
It really depends on how secure you want the internal web services.
If you have sensitive data on the internal web services, you need to have them on a completely different server, even if you don't allow access to them from the outside by assigning them a different port.
However, if you don't have an issue with sensitive data then assigning a different port, or IP-address, for internal and external users is a good way to go.
Besides the port, you could use the restriction for the caller (using IP address filtering, for example).
Also you could actually require authentication for the caller of a web-service, which should be easy to configure in case you use ActiveDirectory.
In any case if you have a 'public' web service, which is private as well, you may want to 'publish' it twice: once for public (with nice external URL) and one for internal, so that your other internal services and/or clients do not have to go via 'external' URL. Then you could configure restrictions (client IP, authentication, ..) differently for different publishers of the same service.