I have to prove my SolrCloud is secure.
From my understanding of what I am reading I can secure the Solr instances talking to each other via basic authentication and SSL which is great, its secure, it works.
However, I can't see anything that will allow me to secure Zookeeper - or am I mistaken? Is there anything in an open Zookeeper that will allow a malicious user on my internal network to "hack" my SolrCloud, or is it the case that Zookeeper doesn't have anything that needs to be hidden?
Regarding securing ZooKeeper, you may want to check ZooKeeper access control using ACLs link.
What we do at Measured Search for our customers who are using our Solr-as-a-Service platform, we allow them to restrict access to Zookeeper with IP filtering. They can either specify a specific IP address or a CIDR (range) that can have access to Zookeeper.
http://docs.measuredsearch.com/security/
That way, they can secure their Solr instances independently of Zookeeper.
Related
In the world of microservices endpoints should not (must not) be hardcoded. One of the best ways to do this is to have a DNS and let each microservice register while starting. By doing this whenever microservice A wants to communicate with microservice B it just asks DNS for endpoints where B currently listens.
What I do not understand is: How microservices know where the DNS lives?
Basically DNS is just a 'special' service and I can have one or multiple instances of it right? So I should not hardcode it's endpoint too or should I? And let's say I do - what if DNS instnace is moved to different location? Do I have to manually change it's location in configuration?
Does anyone happen to know how to design this? (or can anyone just point me to any document where this is explained since although there are many information about microservices and dns I can not find this particular information anywhere - maybe it's just too trivial and I am the only one who does not get it)
Manual setup of DNS is possible, as stated by the other answers, but I would recommend to use an infrastructure that supports the service discovery in all respects. For example kubernetes has built in DNS support and makes it very easy to expose a service that can consist of any number of Pods.
An infrastructure technology like kubernetes will also make many other respects of the microservices architectural style easier to implement, including high availability and scalability.
Please see the official docs for some more information.
DHCP solves this problem. When a host boots it sends a broadcast DHCP message. The DHCP server responds with many values, one of which is the location of DNS servers.
In the case of micro services, the host OS (or container host) will be configured for DNS via DHCP. The microservice code uses the OS DNS functions to resolve addresses.
https://en.m.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
You can use your local network to discover services, via Dhcp and whatnot. But that requires that all services are already "registered" within that DNS server.
Microservices can find each other via service discovery, server or client side. If you choose client side service discovery, you can use tools like Consul, which provides a bunch of great features. One of which is a DNS endpoint which allows queries via SRV records with <serviceName>.consul.service domain names.
Consul has it's own DNS endpoint, you can configure your services to use that (usually on port 8600 locally, as Consul agents run locally).
But you can also configure an actual DNS server to forward questions to Consul, so that you can easily mix service discovery drive by Consul with manually setup services within a Bind instance or similar...
Known hostname solution. The fixed part would be the service domain name, for instance xservice.com. You can query this host using standard DNS tools (e.g., dig in your shell, etc).
Finally, in the DNS bound to xservice.com you then add a SRV record with further details.
A SRV record lists all the service details, including:
the symbolic service name;
the canonical hostname of the machine providing the service;
the TCP (or UDP) port on which the service is available.
There are many other info as well. Please see Wikipedia for the complete list.
Please keep in mind this is a somewhat static solution. If you are looking for a more dynamic one, then Oswin answer might be a better fit :-)
I have an elastic beanstalk app that uses a rethink-db instance as its database. The obvious thing to do would be to restrict access to the the database to only this application.
But if I set the relevant port in the security group of the Rethinkdb instance to anything other than 0.0.0.0, the application can't reach the DB.
The application is using the private DNS of the database for resolution and is in the same amazon region... as far as I understand, this alone should already get me passt the security group without any rules. Not in this case, apparently.
I have tried adding an exception for the applications security group to the databases security group on that port, as well as the security group of the load balancer of the application. I have also tried both at the same time. No dice.
The beanstalk-app is scalable, so it usually communicates from several instances that can change at a whim. Going over an elastic IP and allowing that in the databases security group is therefore not an option, unfortunately.
In the end, I'm forced to leave the security group of the rethink db on the driver port wide open at 0.0.0.0... Anything else I've tried made it unreachable for my own application.
Can anybody tell me what I'm doing wrong?
as far as I understand, this alone should already get me passt the
security group without any rules
That's not correct. You always have to have a security group rule to allow access. All inbound traffic is blocked by default.
I have tried adding an exception for the applications security group
to the databases security group on that port
That sounds like exactly what you need to do. You need to create an inbound rule in the security group assigned to the database server. In that rule you would specify the ID of the security group that the Elastic Beanstalk instances belong to.
If that isn't working, then you might need to post more information in your question, like the actual security group settings.
Also, you need to make sure your EB instances are trying to connect to the database server via the private IP of the DB server. Your issue sounds like maybe they are using the public IP of the DB server. I know you said they are using the private DNS of the DB server, but you need to make certain that is the case, and make certain that DNS is correctly resolving to the private IP, when referenced from the EB instances.
i just installed the datastax cluster of cassandra.
i have a question regarding the security groups and how to limit access.
currently, there are no security groups to the vnet and to all vms. so everyone can connect to the cluster.
the problem starts when i try to set a security group on the subnet. this is because the http communication of the cassandra nodes is (i think) used with the public ip and not the internal ip. i get an error in the opscenter that the http connection is down.
the question is how can i restrict the access to the cluster (for a specific ip), but provide access to all the cassandra nodes to work.
Its good practice to exercise security when running inside any public cloud whether its Azure, GCE, or AWS etc. Enabling internode SSL is a very good idea because this will secure the internode gossip communications. Then you should also introduce internal authentication (at the very least) so you require a user/password to login to cqlsh. I would also recommend using client to node SSL, 1-way should be sufficient for most cases.
I'm not so sure about Azure but I know with AWS and GCE the instances will only have a local internally routed IP (usually in the 10.0.0.0/8 private range) and the public IP will be via NAT. You would normally use the public IP as the broadcast_address especially if you are running across different availability zones where the internal IP does not route. You may also be running a client application which might connect via the public ip so you'd want to set the broadcast_rpc_address as public too. Both of these are found in the cassandra.yaml. The listen_address and rpc_address are both IPs that the node will bind to so they have to be locally available (i.e. you cant bind a process to a IP thats not configured on an interface on the node).
Summary
Use internode SSL
Use client to node SSL
Use internal authentication at the very minimum (Ldap and Kerberos are also supported)
Useful docs
I highly recommend following the documentation here. Introducing security can be a bit tricky if you hit snags (whatever the application). I always start of making sure the cluster is running ok with no security in place then introduce one thing at a time, then test, verify and then introduce the next thing. Dont configure everything at once!
Firewall ports
Client to node SSL - note require_client_auth: true should be false for 1-way.
Node to node SSL
Preparing SSL certificates
Unified authentication (internal, LDAP, Kerberos etc)
Note when generating SSL keys and certs typically you'd just generate the one pair and use it across all the nodes when you have node to node SSL. Otherwise if you introduce a new node you'll have to import the new cert into all nodes, which isn't really scalable. In my experience working with organisations using large clusters this is how they manage things. Also client applications may well use just same key or a different one at least.
Further info / reading
2-way SSL is supported, but its not as common as 1-way. This is typically a bit more complex and switched on with the require_client_auth: true in the cassandra.yaml
If you're using OpsCenter for SSL, the docs (below) will cover things. Note that essentially its in two places:
SSL between opscenter and the agents and the cluster (same as client to node SSL above)
SSL between OpsCenter and the Agents
OpsCenter SSL configuration
I hope this helps you towards achieving what you need to!
community.
Is it possible to limit access to certain URIs (say /myapp/admin/*) based on requester IP on a Weblogic server?
I'd like to allow access only from trusted machines in local network and deny all others BUT only regarding this specific URIs. Other application locations should be accessible for everyone.
The question is, whether it is achievable without development of a separate Filter class?
I found just this in Apache "Location" directive, but sadly no similar stuff in Weblogic.
Thanks.
I'm currently looking to configure a Kerberos V realm and wondering about the risk of having systems in my environment that are not in FQDN (Fully Qualified Domain Name).
A lot of my search mention to use FQDN but doesn't mention what are the risk of not being in FQDN.
It's not exactly a risk in the security sense, but it will create much confusion in configuring various clients and servers.
Kerberos depends on the ability of the client and server to agree on the service name to be used by some process that is outside the kerberos protocol. In other words if I want to use kerberos telnet to some host, I need to know in advance what service principal that host is using in it's /etc/krb5.keytab. There is no way in the kerberos protocol for the client to learn this.
By default kerberos clients usually do a gethostbyname, then gethostbyaddr on the ip address returned and then use that hostname to construct a service principal. This is where you will run into problems. You might try turning off DNS canonicalization altogether ( it's an option in krb5.conf ).
There is also the problem of default realm based on hostname, but that's a much simpler one to solve using values in /etc/krb5.conf.