This is for a Oracle database standalone server running 12c 12.2.0.1 on windows server 2016.
We are hardening our system and one of the findings was to remove support of SSL and implement TLS 1.2 and upwards where possible. A pen test report found certain port was currently using vulnerable protocols. On investigation i found this to be oracle listener. From research, it seems using Net manager we can configure SSL certificates so that the server to client communications on Oracle are encrypted. The only trouble i'm having right now is finding out any oracle document which will tell me exactly what encryption methods are supported? does anyone know how what is supported? I would like to basically disable support for SSL v2 and v3 through windows registry on all machines and allow only TLS 1.2 or higher but this may break the oracle database 12c comminications i suppose if there is no support for TLS 1.2 or higher? Any help would be appreciated in conjuction with what are the best practices for oracle standalone servers when it comes to security?
Also, a bit of a basic question i guess but in Net manager there are two tabs. One is called Encryption and another called SSL? I understand SSL would mean creating certificates and having them on the client and server such that the messages can be de-crypted. However, what does the Encryption tab do? does it literally just encrypt all communications between server and client but not using SSL or TLS?
Thank you for any help.
Check out the 2 Day DBA + Security Guide for info on network encryption. By default Oracle uses "native" encryption libraries that don't use SSL at all (those are managed by the "Encryption" tab you mentioned). SSL encryption (under the "SSL" tab) uses an entirely different protocol, and requires a specially configured listener, a different network port, and certificates in an Oracle Wallet. Check out the docs; they should walk you through everything. It's certainly too big a subject to tackle completely here.
Related
I would like to connect a volttron platform running on a raspberry pi connected to the local network of a building to a second volttron platform running on a virtual personal server.
I know that two volttron platforms can interact with each other using the Volttron Central Management Agent or using the ForwardAgent. However, it is not clear to me what security method is used. Our ICT manager only agrees to set up a connection if the information is exchanged through https.
Could you help me formulating an answer to ICT regarding the security issue? And give me some pratical tips on how to set up the volttron configuration files? I'm not very familiar with network/security technologies. Maybe important to know: the server has a proxy and a reverse-proxy security.
Thx!
Your security person is correct. You should only set the platform up in a "real" environment through https. Since you have a proxy, that should be forwarded to the volttron central agent.
internet (443) -> proxy -> http://127.0.0.1:8080
The proxy in this case is on the same machine as the volttron central platform.
This is how we are doing it with apache as our proxy. One could do the same thing with a different web server such as nginx.
Hopefully that helps
If you are indeed trying to connect from a single instance to another instance (e.g. the way the forwarder does). Then the answer is the security is using public/private key pairs with curve mq providing perfect forward security. All traffic between platforms is 100% encrypted and only authorized agents can transmit across the instances bus.
http://curvezmq.org/
I am trying to secure online transaction between application server and database. One-way is SSL, but is there any other way of securing transaction between them. I am trying to reduce the overhead in securing the line. Are there any tool or api's which I can integrate with the application server or deploy on it.
/SR
Sure, but it requires a thoughtful review of your architecture. If you have a dedicated line between your application and your database, the connection could be encrypted at the network layer.
I'm a bit surprised that your application server and your database are not within the same trust boundary. Is this an app in the cloud?
SSL is by far the best way, its extremely secure and absolutely free. If your database or another application doesn't support SSL then you can use a free SSL VPN such as OpenVPN. This will create a secure transport layer connection between 2 machines.
If you are connecting to a database on the local machine then there is no point in a secure transport layer connection. However you should firewall off the database port, for instance MySQL uses tcp 3306.
What advantages (if any) does Weblogic 10.0 provide in terms of database connectivity (to any database) over open source or commercial alternatives?
Are there any Weblogic specific gotchas with using a Weblogic database connection?
I'm a Java EE, Weblogic newbie so please excuse the simple questions.
What advantages (if any) does Weblogic 10.0 provide in terms of database connectivity (to any database) over open source or commercial alternatives?
Weblogic supports clustering of JDBC objects (data sources, connection pools and multipools) and failover and load balancing of JDBC connections and the administration part is very mature. Having that said, I'm sure some other products (some of them, not all) do have equivalent features and wonder if the support of such things can thus be considered as an advantage. All I know is that Weblogic support for these features is really good. Actually, Weblogic is well know for being a rock solid application server and is frequently used for "mission critical" applications. But most applications do not have such needs.
Are there any Weblogic specific gotchas with using a Weblogic database connection?
I'm not sure what you mean by a "weblogic database connection" but AFAIK no.
Connectivity to any database is accomplished through JDBC drivers; it has nothing to do with WebLogic. If I recall correctly, WebLogic ships with drivers for Oracle, Sybase, and perhaps SQL Server, but you have to add any others that you need.
This is true of all Java EE app servers, commercial or open source.
The value that WebLogic adds is JNDI services and connection pooling. It allows to configure pools so that connections are checked before users are allowed to use them, stale connections are recycled, etc. These are features that would be laborious to code on your own. WebLogic makes it easy to do via configuration.
As of today transparent datasource failover is still a rare feature in opensource servers. Especially the ability to switch in the middle of a connection being used is something you don't see often.
Jboss does allow to enter a second URL for a datasource, but it's a bit of a crude mechanism (the documentation mentions this) and it hasn't been much improved over the years.
I need to connect to a secure SQL Server database using Perl DBI. I need to find a way to authenticate the user securely (without fear of eavesdropping, and without storing passwords on the client side). I'm using SQL Server 2008 on Windows Server 2008, and Perl 5.10 on XP.
SQL Server supports encrypted connections via something called the "SQL Server Native Access Client API", but I cannot tell whether this is supported by any DBD driver, or how to use it if it is.
I am reluctant to use the DBD::ODBC driver with SQL Server authentication, because ODBC transmits user IDs and passwords in cleartext.
I can't use the DBD::ODBC driver with Windows authentication (trusted connection), because the server is not on any Active Directory domain that is accessible from the client's network.
How can I secure my connections to the database? Thanks.
I am reluctant to use the DBD::ODBC driver with SQL Server authentication, because ODBC transmits user IDs and passwords in cleartext.
That is not strictly true. If you are using a recentish SQL Server and have not disabled encryption in it then the username/password and connection string are encrypted as follows:
The client contacts the server and tells it what it is capable of (e.g., it can do SSL). If the server then supports SSL it requires the client end to encrypt the connection info and falls back to unencrypted after that. You should also see the "Use Strong encryption for data" checkbox in the DSN.
Two options:
Create an IPSec tunnel between two locations. Some info here:
technet.microsoft.com/en-us/library/cc737154(WS.10).aspx
technet.microsoft.com/en-us/library/cc786385(WS.10).aspx
Enable SSL. I am not sure how well it would be protected.
technet.microsoft.com/en-us/library/ms189067.aspx
I would suggest that you use some kind of secured connection system. It might be IPSec, but it is often viewed as complicated, so you might be better (or faster) off with OpenVPN, which I use, and generally am happy with.
It can be used on virtually any operating system, is fast, and free. You can check it here: http://openvpn.net/
I need to transfer data daily from SQL Server (2008) to SQL Server (2005). One of the servers is located at our web host so the data will be transferred over the Internet. On the same network I would use SSIS to transfer the data, but over the Internet this is not a secure option. Is there a secure way of achieving this?
You can use SSL with SQL Server (2000/2005 Instructions / 2008 Instructions) and then force protocol encryption on the connection between both machines. You don't have to use a purchased SSL certificate either, you can use Windows Server Certificate Services to generate one - however if you do so then the CRL must be on a machine that both servers can connect to. An easy way to do this is install Certificate Services on a stand alone machine, perhaps just a VM and the configure it to embed a public DNS name for it's CRL. This doesn't have to be a machine running Certificate Services, just something you own and can upload to. Then you can generate the certificates and publish the CRL and tada, all done.
You will need to ensure the service account SQL is running as has access to the private key of the certificate it is using.
Generally it isn't recommended to have your SQL Servers exposed to the Internet, although that may be out of your control in this case. In your position I would investigate developing some separate Web Services that would perform the transfer of the data. These can then be secured using a variety of methods, such as SSL and WS-Security and other custom user permissions. If that isn't possible then blowdart's answer seems like the way to go.
You can use Service Broker:
Built into SLQ Server engine itself, no need for external process to drive communication.
Compatible protocol SQL 2005 and SQL 2008 communicate over Service Broker out-of-the box.
No need to expose either server to the internet. Through Message Forwarding you can expose
just a SQL Express, with no data on it, to the internet to act as a gateway that lets messages into the back end target.
Communication is encrypted.
Speed, the sample in the link shows how you can exchange over 5000 1k payload messages per second between commodity machines.
Unlike SSIS or replication Service Broker is a general communication framework so it won't provide support to extract the changes and to apply the changes, with conflict resolution and the like. You would have to code that part yourself.