I would need to open my firewall to allow the callbacks from Google Wallet. What's the IP range that I should allow?
Related
I am looking for solution to secure Azure Bot when the communication channel is Direct Line,
The WebChat code is embedded as IFrame in one of internal site and i want the incomming traffic to be restricted to only specific IP/url.
There are security guideline documented on MS site, but those talks more about authentication and token based secure access. (https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-security-guidelines?view=azure-bot-service-4.0)
I wish to implement secure flow where the bot app service (or related services should not accessible from out side network.)
There is well defined document about how one can secure Microsoft Teams channel bot and web app behind a firewall (https://learn.microsoft.com/en-us/azure/architecture/example-scenario/teams/securing-bot-teams-channel) but it seems the difference is the TEAMS have list of IP range defined. (Could i use similar setup for direct line ?)
Could anyone please help to understand how i can secure bot services behind firewall, VN, Route table to restrict traffic from outside world ?
Or direct me to any article/document/reference that could help me to achieve this.
Thank you.
In our Application, We have enabled Razorpay Webhook for seamless payment.
During development testing I have used ngrok. It is working fine.
My production server is protected by cloudflare and enabled with bot-fight-mode.
When the payment is success. POST request is sent by razor-pay web-hook. But it has been blocked by cloudflare bot-fight-mode.
So I created a firewall rule to allow it.
Still Webhook is blocked by cloudflare?
What should I need to do to allow razorpay webhook to bypass cloudflare by blocking other bots?
Thanks in advance.
I came here looking for an answer too but I don't think it is possible unless you have an enterprise account:
https://community.cloudflare.com/t/questions-about-cloudflare-super-bot-fight-mode/256213/40
Whilst this thread is referring to Super Bot Mode I believe the principal is the same and it is only with an enterprise account that you can chose which URIs to target and bots to allow through.
Update: I've ended up disabling Bot Fight Mode and will use Fail2Ban on my server and the CloudFlare API to block the IP addresses at their end.
I am trying to block all traffic from a Facebook app, iOS and Android, on a particular network. I can block web access, meaning if a user tries to log in to www.facebook.com from a computer, the router will detect and block it. The user won't be able to have access.
However, mobile apps go through just fine on the same network. I need to prevent users from using the Facebook app on their phone. How do I do this?
I was thinking of using WireShark to see what URL the phone app is connecting to and blocking that URL. I'm sure this is fine, but is there a baseURL I can block which prevents mobile users from accessing Facebook? Is there a list of Facebook URLS I can block which prevent app access?
Whatever tool you are using on the router, I am sure must be supporting pattern matching while filtering packets.
So I suggest you can block all traffic for
*.facebook.com and *.messenger.com.
Having said that it is probably not enough to just filter HTTP packets based on URL. There are ways of circumventing this using VPNs or proxy websites.
You should consider blocking all outgoing traffic on ports other than 80 and 443.
Similarly other protocols like ICMP or UDP too because they can be used to tunnel VPN connections.
I am saying this because we have applied all these methods to get unrestricted access at uni. :)
Probably you can use a proxy server like squid to control the traffic better.
I'm behind a company firewall and have been asked to share my IP address in order for me to be white-listed so can access an API. This is first time I've been asked for this and find it uncommon ? as usually I connect to an API via OAuth or access token, https username password etc. Is this a safe way to access an API, will I creating any security risks though sharing my IP ?
Update :
The API host is asking for my IP.
You give your (external) IP address to every single website you visit. It's ok to let them strengthen access control by IP restriction.
However, if that is the only security measure (as opposed to proper authentication and access control), that's not OK, especially not in a corporate setting, where everybody behind your firewall will have the same external IP address because of NAT (and even if it's not the case, there must be proper authentication on a secure API).
I know DocuSign can send signed PDF and other stuff to a public URL using the DocuSign Connect module.
I want to know whether they will send to our own server listner page. Will DocuSign will send signed information to non-public URL
DocuSign Connect and eventNotifications (same notification mechanism, different subscription process), will send the notifications to any url that is available via the public internet.
There are different meanings for "non-public url." Your server/listener's url does not have to linked to by any other page, it does not have to be in the Google database, it can use long, obscure strings in the url, etc. But it has to be reachable via the public internet.
So if your listener is accessible via the public internet, you're golden.
Other options:
Put your listener on your company's dmz where it will be accessible from the internet and also have some access to your internal systems.
Put your listener behind your firewall and open a "pinhole" in your firewall to enable the incoming connection requests. DocuSign publishes the ip ranges it uses so you can limit the size of the opening in your firewall
Create a server/listener "gateway" on the public internet that your internal servers can connect to. Eg, start up a listener using Heroku, Azure, etc. I suggest their PAAS services.
Investigate ngrok, localtunnel, and this related blog post
Also:
Remember that your listener must accept requests via https. Only https is used for notifications by the DocuSign production platforms.
See the DocuSign webhook recipe for more info.