What is the meaning of Remediation of vulnerabilities and how to Implement it. Please advise. Thank you.
(1)It is recommended to implement a whitelist of permitted services and hosts, and block any interactions that do not appear on this whitelist.
(2) It is recommended to block network access from the application server to other internal systems, and hardening the application server itself to remove any services available on the local loopback adapter
Related
Hello I've been searching everywhere and did not found a solution to my problem, which is how can I access my API through the gateway configured endpoint only, currently I can access to my api using localhost:9000, and localhost:8000 which is the Kong gateway port, that I secured and configured, but what's the point of using this gateway if the initial port is still accessible.
Thus I am wondering is there a way to disable the 9000 port and only access to my API with KONG.
Firewalls / security groups (in cloud), private (virtual) networks and multiple network adapters are usually used to differentiate public vs private network access. Cloud vendors (AWS, Azure, etc) and hosting infrastructures usually have such mechanisms built in, e.g. Kubernetes, Cloud Foundry etc.
In a productive environment Kong's external endpoint would run with public network access and all the service endpoints in a private network.
You are currently running everything locally on a single machine/network, so your best option is probably to use a firewall to restrict access by ports.
Additionally, it is possible to configure separate roles for multiple Kong nodes - one (or more) can be "control plane" nodes that only you can access, and that are used to set and review Kong's configuration, access metrics, etc.
One (or more) other Kong nodes can be "data plane" nodes that accept and route API proxy traffic - but that doesn't accept any Kong Admin API commands. See https://konghq.com/blog/separating-data-control-planes/ for more details.
Thanks for the answers they give a different perspectives, but since I have a scalla/play microservice, I added a special Playframework built-in http filter in my application.conf and then allowing only the Kong gateway, now when trying to access my application by localhost:9000 I get denied, and that's absolutely what I was looking for.
hope this answer gonna be helpful for future persons in this same situation.
I work in a very large, bureaucratic organization and I'm trying to pitch a simple (local) web interface to my team. Given extensive firewall and domain security, I am wondering if this is even possible.
My question is: From a network security perspective, what might prevent IIS from allowing connections from other users on my network?
I believe IIS uses port 80 for default traffic, but it isn't listed as "Listening" when I run netstat -a through command prompt. I do have other ports listening but my fear is they are strictly monitored. Our organization also restricts connectivity between users to shared directories, so I'm wondering if that impacts anything like Windows Authentication in IIS.
I have very little network security experience so thank you in advance to anyone who can shed some light on this!
what might prevent IIS from allowing connections from other users on my network?
local firewall (GPO)
more GPOs regarding IIS or services in general
switch ACLs
switch port privacy
firewall rules
If your company has a network service policy you shouldn't try to circumvent it. It might put your job in danger.
I have setup the Secure Gateway to connect to my on premises DataPower and have exposed a local SOAP service. In the destination I have enabled User Authentication for mutual auth, and this is working well. In order to access the SOAP service the client must supply the cert. However this endpoint is still public, and I would prefer to restrict the network access to it for increased security.
I found this article:
Creating IP table rules for a Bluemix app for Secure Gateway
that shows how to implement this from a client such as NodeJS or WSL, however I want to restrict access to only API Connect in Bluemix. Thus I don't have the ability to lookup the IP address.
Is there an address range for the API Connect Gateway Clusters? I tried restricting the network to only the non-routable A/B/C networks but that closed off everything. Using mutual auth in the TLS Profile of APIC is working, but restricting the network would give us greater peice of mind.
This is not possible due to the nature of cloud-based solutions. IP addresses may change at any time, thus breaking the linkage.
Mutual TLS is an excellent solution and should provide robust security as long as your private keys are carefully protected.
We have a client who wants to connect their premises to Azure. Their main hindrance at this point is determining the best way to connect to Azure given their current connectivity configuration. They have two redundant ISP connections going to the head office for internet access. They want to be able to configure a VPN connection to Azure that would operate in a similar way i.e. if ISP A went down it would seamlessly use ISP B and vice versa. The normal multi-site VPN configuration does not fit this since there is one local network behind which means the network behind separate VPNs over each ISP would have overlapping IP address ranges which is not supported. Is such a configuration possible? (See diagram below)
Either that or is there a way to abstract the two ISP connections onto one VPN connection to Azure.
They’re currently considering using a Cisco ASA device to help with this. I’m not familiar with the features of this device so I cannot verify if it will solve their issue. I know there is also a Cisco ASAv appliance in the Azure marketplace don't know if that could also be a part of a possible solution if they went with such a device.
required vpn configuration
The Site-to-Site VPN capability in Azure does not allow for automatic failover between ISPs.
What you could do are the following
- Have automation task created that would re-create the local network and gateway connection upon failover. Manual and would take some RTO to get it up and running
- Use the Cisco CSRs to create a DMVPN mesh. You should be able to achieve the configuration you want using that option. You would use UDRs in Azure to ensure proper routing
I havent done it in Azure, but here is what you do in AWS (And I am sure there would be parallel in Azure)
Configure a "detached VGW" (virtual Private gateway) in aws. Use DMVPN cloud to connect CSRs to multi-site on-prem.
Also, for failover between ISPs you could have a look at DNS load balancing via a parallel to AWS's Route 53 in Azure.
Reference thread :
https://serverfault.com/questions/872700/vpc-transit-difference-between-detached-vgw-and-direct-ipsec-connection-csr100
I'm looking into developing a system via Google's App Engine for PHP. I'm now pretty well underway, but realized that I don't know a good way to deny incoming traffic from countries known for their nefarious inhabitants.
On other sites, I just block subnets via .htaccess. However, I'm now beginning to think it's impossible outside of using Google's own PHP request header designating the country code.
See their doc here: https://developers.google.com/appengine/docs/php/
It would be easy to just block it that way, but I'm not sure this would be the optimal way.
Any insight would be appreciated.
You can use the dos.yaml file to blacklist subnets. You create a dos.yaml file in the root directory of your application and then block IPs or entire subnets as specified here. Note that this file is limited to a maximum of 100 entries.
Once you have a list of country subnets which you wish to block (which you could obtain from a list like this or this), you can populate the dos.yaml file manually. Alternatively, you can use a script like this one to populate the file.
In addition to the DOS attack protection mentioned in #rudolph1024's answer it is now possible to enable a fully-featured firewall (still beta, recently released) to protect your GAE application.
From App Engine firewall:
The App Engine firewall enables you to control access to your App
Engine app through a set of rules that can either allow or deny
requests from the specified ranges of IP addresses.
Create a firewall to:
Allow only traffic from within a specific network
Ensure that only a certain range of IP addresses from specific networks can access your app. For example, create rules to allow only
the range of IP addresses from within your company's private network
during your app's testing phase. You can then create and modify your
firewall rules to control the scope of access throughout your release
process, allowing only certain organizations, either within your
company or externally, to access your app as it makes it's way to
public availability.
Allow only traffic from a specific service
Ensure that all the traffic to your App Engine app is first proxied through a specific service. For example, if you use a
third-party Web Application Firewall (WAF) to proxy requests directed
at your app, you can create firewall rules to deny all requests except
those that are forwarded from your WAF.
Block abusive IP addresses
While Google Cloud Platform has many mechanisms in place to prevent the various attacks, you can use the App Engine firewall as
another mechanism to block traffic to your app from IP addresses that
present malicious intent.
You should use the App Engine firewall as your primary option for
shielding your app from denial of service attacks or similar forms of
abuse. You can blacklist IP addresses or subnets so that requests
routed from those addresses and subnets are denied before it reaches
your App Engine app.
For details about creating rules and configuring your firewall, see
Controlling App Access with Firewalls.
The firewall appears to be intended to replace the DOS protection. From Denial of service (DoS) protection service:
Tip: You should instead use the App Engine firewall for reliable protection as well as the improved features, access, and
management through the Cloud Platform Console, gcloud command-line
tool, and Admin API.
You still need to collect the IP ranges for the country in your particular case, to configure the firewall.