I have configured AWS SNS notification to call my HTTP endpoint. I need to open my firewall to allow AWS SNS to call it.
However, I cannot find any information about SNS HTTP(s) notification call IPs. I have caught a few IPs (54.240.194.1,54.240.194.65,54.240.194.129 ) by it's calls. But I'm not sure what's the full list of SNS HTTP notification source IPs.
I can open my firewall as 54.240.194.0/24. But no official information this is correct.
Thanks.
The list of IP addresses from which Amazon SNS notifications are sourced is provided in the Amazon SNS forums. We update this post as the IP information changes.
Please note that while notifications will usually be sourced from an IP in the same region where your topic was created, this is not guaranteed e.g., a notification sent from a topic created in US-EAST-1 may be sourced from either US-WEST-1 or EU-WEST-1. In other words, you should add all addresses on this list to your ingress rules, even if you only plan to use a single region.
In this situation SQS is probably more appropriate because you will be initiating the connection to Amazon instead of asking AWS to reach out to you. This means no changes to your firewall are required and you are not poking holes in your security...
If you need SNS notifications for other end points, you can pump SNS to SQS for this specific end point:
http://docs.aws.amazon.com/sns/latest/dg/SendMessageToSQS.html
Pretty sure you can't count on any particular IP address or range.
If you want to secure your endpoint, or at least ensure that any messages sent to it actually originate from AWS, this document may help:
...you can verify the authenticity of a notification,
subscription confirmation, or unsubscribe confirmation message sent by
Amazon SNS. Using information contained in the Amazon SNS message,
your endpoint can recreate the string to sign and the signature so
that you can verify the contents of the message by matching the
signature you recreated from the message contents with the signature
that Amazon SNS sent with the message.
http://docs.aws.amazon.com/sns/latest/dg/SendMessageToHttp.verify.signature.html
The accepted answer above is out of date/expired in the Amazon forum.
This link may be more help and, hopefully, permanent, but is for ALL IP ranges, evidently.
From
https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html....
AWS IP address ranges
Here's the tool to use to filter/search that massive file
https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html#filter-json-file
Related
I have written my own code to connect to Firebase via the REST interface. Recently I have been unable to connect to firebaseio.com because the secure connection cannot be established with the CA certificate I am using.
I am still able to create a secure connection to googleapis.com to handle the login authentication and get the tokens I need for communication.
How do you determine what certificate is needed to validate the connection? I have tried a few of the root CA certs available at https://pki.goog/repository/ but they do not seem to work for firebaseio.com.
WireShark to the rescue! I was able to see the name of the certificates being passed to my device. Firebaseio.com is using one of the certs in this list that I had not tried yet.
After adding that one I was able to connect. How often does Firebase change these certificates? What is the proper method to keep my device up to date with the latest certificates?
I'm currently working on a Godot multiplayer project where players will make HTTP(s) requests to a REST API I have set up with Firebase's cloud firestore database. I'm wondering if it is possible to get the IP address of whoever sent the request, and if so, how?
The database REST API is not going to reflect back to you any IP addresses. You will need to instead provide your own backend API for the clients to call if you want to collect their IPs.
If I have Slack as a desktop app running on my local machine, is there a way for me to send it a message from another locally running process?
My goal is to use the regular Slack api to ping channels, etc. But instead of using a standard integration, I could do it from another local process. Maybe Slack is listening on localhost?
If the above concept doesn't work, is the only other way to do a Slack integration, where I would send a payload to Slack servers?
note: I said "IPC" in the question, but most likely it would be HTTP/TCP to send a message from my process to the slack process on my machine.
No. You can not send your local running Slack client a "direct" message from another local running app. A Slack client is just a viewer for a Slack workspace that is running in the cloud. It does not listen to local IPC messages.
There are many ways how to send a message with the Slack API. I would suggest to start with looking at incoming webhook. This only requires you to send a POST HTTP request to a URL provided by Slack.
AWS SNS can push to http, email, SMS, lambda, "device and mobile application".
Is there a way to get it to push to a locally-running CLI application?
I can imagine that maybe it is possible to register an EC2 server as a "device" and the CLI as the "mobile application". Couldn't figure out any docs about this.
Edit: or perhaps register an EC2 server as IoT and push sns to IoT device?
No. Sort of.
Amazon SNS needs to send a message to "somewhere" that wants to receive the message. So, you could run a web server that is Internet-accessible and SNS will send the message via HTTP to that endpoint.
Mobile applications also have endpoints provided by Apple/Google/Baidu that will then forward messages to a mobile device. So, they are also listening for a message.
Bottom line: You need something that is listening for a message.
You can use ngrok for this. This answer should solve your question perfectly.
I run my own sip server (asterisk). Apparently my sip server allows to perform an INVITE without doing any REGISTER first. This leads to lots of unsuccessful attacks on my server. IS there any way to allow INVITE requests only from a successfully REGISTERed clients? Through asterisk or iptables?
You need change allowguest parameter to no in your sip.conf.
Check the link below for more tips about security in asterisk:
http://blogs.digium.com/2009/03/28/sip-security/
My study so far tells me that REGISTER is only for asterisk to reach or forward the INVITES but not to authenticate an INVITE request. When an INVITE comes, asterisk tries to check the given user name and if its a valid one, it sends a 407 (Authentication required) back to the client. Then client inserts the password (encrypted) in the response and sends INVITE2 to server. Now server authenticates the user and when credentials match, proceeds with establishing the call.
Conclusion: An INVITE has no relation with REGISTER and so my idea of restricting only REGISTERED clients to send an INVITE is not possible.
As a workaround, I have written my own script. Source is at https://github.com/naidu/JailMe
Consider a real Session Border Controller which pays for itself quickly when you get hacked. However, if you want a "good enough" option then read on:
There is an iptables module called "string" which will search a packet for a given string. In the case of SIP we expect to see "REGISTER" in the first packet from any given address, so combine this with -m state --state NEW or something similar. After that, we would want keep-alive happening to ensure that connection tracking remains open (usually Asterisk sends OPTIONS, but it can send empty UDP). You want that anyway in case the client is behind NAT.
It's not the ideal solution, because iptables cannot figure out whether a registration has been successful, but at least we can insist the other guy makes an attempt at registration. One of the answers linked below shows use of the string module in iptables:
https://security.stackexchange.com/questions/31957/test-firewall-rules-linux
You could also put an AGI script into your dialplan that does some additional checking, potentially looking at IP address and whether the extension is registered... ensure the INVITE comes from the same source IP.
Fail2Ban is an easy way to block unwanted traffic! fail2ban check system logs for failed attempts, if there are too many (exceeding defined threshold) failed attempts in specified time from some remote IP then Fail2Pan consider it as attack, and then add that IP address in iptables to block any type of traffic from it. following links can help
http://www.voip-info.org/wiki/view/Fail2Ban+(with+iptables)+And+Asterisk
http://www.markinthedark.nl/news/ubuntu-linux-unix/70-configure-fail2ban-for-asterisk-centos-5.html