As per https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-custom-domain-tls-version.html it is possible to restrict aws api gateway to a particular version of TLS. Rather than just change this, I'm keen to log any existing connections that are being established over TLS 1.0 or 1.1 in order to identify and fix those apps generating insecure connections. Does anyone know if it's possible to have the service log this?
There is not currently a way to log this in API Gateway logging but it sounds like a good feature request. I'd recommend submitting this request in the forums if you can as the community there may make enough noise to push the feature request quicker.
I see that access logs allow you to log any context variable so I think the best feature request would be to ask for a context variable containing the negotiated TLS version so it can be logged, or for it to be logged by default in the execution logs when full request/response data is enabled for CloudWatch logging.
Related
What are good arguments in favor to use or not to use Keycloak behind Api gateway (Kong)?
There is a tradeoff to putting it behind the proxy: you will not be able to easily protect all of your services by applying the OIDC plugin on the global level. Instead, you will need to individually configure every service with its own OIDC plugin. This is because you will need at least one service that is not protected by the OIDC plugin so that user-agents can authenticate through that service. Unless you're planning to implement some other form of security on that service or need some other services that Kong can easily implement as requests pass through it, I don't see the point of putting Keycloak behind the proxy. That's not to say there aren't good reasons to do it, I'm just not aware of them.
I've set Keycloak up outside of the proxy, and have had good results. Here's what it looks like:
I'm writing a blog post about this set up now which I will release next week. I will try to remember to update my answer here when it is complete.
Edit
Links to blog:
Part 1,
Part 2
It is not good practice, in fact I would suggest to put it outside, in the DMZ. In this way that IDP can be leveraged by all APIs that you want to publish and authenticate using the API gateway. This is an example of applying such authentication flow with Keycloak: https://www.slideshare.net/YuichiNakamura10/implementing-security-requirements-for-banking-api-system-using-open-source-software-oss
Your concern might be then: how do I protect such a critical resource like an IDP authenticating all my services?
Reasonable concern which you can address by:
ensuring autoscaling of the IDP based on authentication request
configuring all the needed threat mitigation options on Keycloak (https://www.keycloak.org/docs/latest/server_admin/#password-guess-brute-force-attacks)
add a WAF in front of the IDP with feature such as DDOS prevention and Intelligent Threat Mitigation based on traffic patterns
IP or Domain whitelisting, if you know where all your customers are connecting from
restrict port exposure for the IDP
Kong is an API gateway that'll be in the "hot path" - in the request and response cycle of every API request. Kong is good at efficiently proxying lots of requests at very low latency.
Keycloak and other IAM offerings can integrate with Kong - but they aren't placed in the hot path. Keycloak is good at managing users and permissions and providing this information to systems like Kong, when requested.
Perhaps these links will be helpful https://github.com/ncarlier/kong-integration-samples and https://ncarlier.gitbooks.io/oss-api-management/content/howto-kong_with_keycloak.html
Is not a good practice, a good Enterprise API Gateway has the obligation to meet (or give you the access to customize) all the advanced authentication and authorization standards available in KEYCLOAK.
But in some circumstances, If you already have a API Gateway with a lot API´s configured (with transformation rules, route rules) and this Gateway can´t provide advanced features for authentication and authorization (ex. 2 factor authentication or Oauth2 authorization code/openId / SAML) and you need more security ASAP, go ahead while looking for a gateway that best meets your needs
The REST API for Kafka Connect is not secured and authenticated.
Since its not authenticated, the configuration for a connector or Tasks are easily accessible by anyone. Since these configurations may contain about how to access the Source System [in case of SourceConnector] and destination system [in case of SinkConnector], Is there a standard way to restrict access to these APIs?
In Kafka 2.1.0, there is possibility to configure http basic authentication for REST interface of Kafka Connect without writing any custom code.
This became real due to implementation of REST extensions mechanism (see KIP-285).
Shortly, configuration procedure as follows:
Add extension class to worker configuration file:
rest.extension.classes = org.apache.kafka.connect.rest.basic.auth.extension.BasicAuthSecurityRestExtension
Create JAAS config file (i.e. connect_jaas.conf) for application name 'KafkaConnect':
KafkaConnect {
org.apache.kafka.connect.rest.basic.auth.extension.PropertyFileLoginModule required
file="/your/path/rest-credentials.properties";
};
Create rest-credentials.properties file in above-mentioned directory:
user=password
Finally, inform java about you JAAS config file, for example, by adding command-line property to java:
-Djava.security.auth.login.config=/your/path/connect_jaas.conf
After restarting Kafka Connect, you will be unable to use REST API without basic authentication.
Please keep in mind that used classes are rather examples than production-ready features.
Links:
Connect configuratin
BasicAuthSecurityRestExtension
JaasBasicAuthFilter
PropertyFileLoginModule
This is a known area in need of improvement in the future but for now you should use a firewall on the Kafka Connect machines and either an API Management tool (Apigee, etc) or a Reverse proxy (haproxy, nginx, etc.) to ensure that HTTPS is terminated at an endpoint that you can configure access control rules on and then have the firewall only accept connections from the secure proxy. With some products the firewall, access control, and SSL/TLS termination functions can be all done in a fewer number of products.
As of Kafka 1.1.0, you can set up SSL and SSL client authentication for the Kafka Connect REST API. See KIP-208 for the details.
Now you are able to enable certificate based authentication for client access to the REST API of Kafka Connect.
An example here https://github.com/sudar-path/kc-rest-mtls
I need to setup a cron job to run a SOAP client. The customer insists that I connect to their web service (on an https address) from an https address. They insist that if I don't their response to me can't be encrypted.
My first question is, is that true? I thought that as long as I'm connecting to their SOAP service over https, the response back would automatically be encrypted.
If that's true, how can I run a cron job to be as https? My site is on a LAMP setup with cPanel access.
Thank you in advance for your help!
Your customers statement seems to be a little bit unclear in what he/she specifically means by "... connecting from an https adress" as there isn't any notion of the term "https adress" in the specs and https URLS only seem to make sense in the context of Request-URI s given in a https request.
Given this unclarity I'm only wild guessing. Nevertheless to me it seems your clients requirements might most probably not be connected to the http protocol but rather to establishing your TLS connection.
If your client is very sensitive in respect to the security of his system - which in fact if he intends to offer RPC requests might be a very good idea - he might not want to the whole world to be able to connect an encrypted connection to his machines and rely on any secondary authentication mechanism once the connection has been established.
As most users of the public internet don't have any certificates signed by a trusted authority this feature it isn't used out in the open wild but besides server authentication the TLS handshake protocol also provides a means of client authentication via client certificates (the relevant part being section 7 in RFC 5246 here. see: https://www.rfc-editor.org/rfc/rfc5246#section-7)
While in the absence of widely used client certificates web services usually rely on establishing an encryted connection to first to authenticate users by some kind of challange response test like querying for username and password your client might want to either additionally secure access to his machines by additionally requiring a valid client certificate or even - probably not the best idea - replace a second authorization like the one already mentioned above.
Nevertheless all this are nothing but some ideas that I came along with given the riddle in your question.
Most probably the best idea might be to just ask your client what he/she meant when saying "... connecting from an https adress"
I am implementing XMPP service in the browser using BOSH. I use JAXL library. I am able to manage the connection over BOSH to my localhost server (ejabberd). The session is started and the user is authenticated with no problem. However, when I just change the BOSH host to jappix.com, the very first response from the server is only empty body. Even if I repeat the request (according to XEP-206) I still get only empty body so I'm unable to perform any other actions.
So that's my question: Is it possible to use jappix.com to handle my BOSH requests? Are there any limitations? How can I fix this issue? I'll provide more information if needed.
I am the Jappix.com owner!
Your question does not concern our service directly but more likely a node-xmpp-bosh - the BOSH server we are running - bug (?) that you can report on http://code.google.com/p/node-xmpp-bosh/
Does anyone have an experience or just thoughts about securing MQ TCP
communication channels using stunnel?
I am integration with third party S.W which has MQ support built in but it can not support SSL. So to have some kind of security over the TCP we would like to use stunnel. Does any one have any thoughts how to implement and any best practices
I haven't used stunnel so I'll leave that part of the answer to another responder. With regard to WMQ, keep in mind that this will provide you with data privacy and data integrity over the stunnel link but will not give you channel-level services such as WMQ authentication. True, you will have some level of authentication on the stunnel connection itself, but anyone with a TCP route to the QMgr that does not arrive via stunnel will also be able to start that channel.
Your requirement for security obviously includes data privacy. If it also includes authentication and authorization, you might need to use something like BlockIP2 (from http://mrmq.dk )to filter incoming connections on that channel by IP address to insure they arrive over the stunnel link. Of course, there is nothing to prevent someone at the remote end from specifying any channel name to connect to so if you secure one channel, you need to secure them all - i.e. make sure that SYSTEM.DEF.* and SYSTEM.AUTO.* channels are disabled or that they use SSL and/or an exit to authenticate the inbound connection.
Finally, be aware that if WMQ is configured to accept the ID presented by the client then the connection has full administrative access and that includes remote code execution. To prevent this you must configure all inbound channels (RCVR, RQSTR, CLUSRCVR and SVRCONN) that are not administrative with a low-privileged ID in the channel's MCAUSER. For any channels that are intended for administrators, authenticate these with SSL. (Hopefully your 3rd party SW is an application and not an administrative tool! Any WMQ admin tool must support SSL or else don't use it!)
So by all means use stunnel to secure this link, just be sure to secure the rest of the QMgr or else anyone who can legitimately connect (or even anonymous remote users if you leave MCAUSER blank and aren't using SSL and/or exits) will just bypass the security or disable it.
There's a copy of the IMPACT presentation Hardening WMQ Security at https://t-rob.net/links/ which explains all this in more detail.
Rob - I agree with you. For that only we have MQIPT. Which is much better. For STunnel for MQ i have sloved the problem.
Keys -U need a .pem key (From Key manager you can create .p12 and use open ssl to covert to .PEM).
Client Side: Download and install stunnel have followoling entries in the config file
cert = XXX.pem
client = yes
[MQ]
accept = 1415
connect = DestinationIP:1415
Server Side:
cert = xxx.pem
client = no
[MQ]
accept = 1415
connect = MQIP:1415
Once you do this all you have do is just call the amquputc with the Queue name.