So a little back story about the security and project. Developing a private application for a customer. This application will need to be secure. One way we are securing it is by not allowing outside connections to this. Which means that only internal connections can be made. Or connections over VPN which we will pawn the security off of this to the VPN provider. However we must address and have in our minds the security concern of local users. We had many thoughts of this by simply pawning the security off on level 2 network devices and ldap security within the organization. However we now face the struggle of within the authorized user set (some very smart people) how do we keep security here.
So question is. If we have an SSL layering the application. Only allowing users to access the webserver via an SSL connection. Will it secure all traffic?
Scenario:
User A logs on to this website running on IP address 10.x.x.180(under the ssl).
User B is sitting with wireshark open and is sniffing in this network for any traffic to ip of 10.x.x.180.
User A makes a call to website to view a webpage. This webpage calls for a local json file on this server. Returns json to the application. Then this json is read and displayed to User A.
Q. Will User B be able to see this data in his sniffing packets? or will he simply see SSL encrypted data?
Q. Will User B be able to see this data in his sniffing packets? or
will he simply see SSL encrypted data?
He will only see the encrypted SSL traffic which provides an end-to-end encryption.
Related
We currently have a Public API to be used by our Business' current and future clients. Due to flexibility purposes and capability for our client's systems to interface with ours, we currently have our MySQL Database IP and Port on Wild Card access so as to not encounter any restricted access issues.
Question is, due to security concerns, would it be possible to restrict the MySQL Database's Server IP and Port to not be accessed directly by third party clients but only via the Public API? My instinct says no, but I don't have much experience in the way of Public APIs nor Public Access.
When an API User sends a query on our database, does it identify it via the API Host's IP (our servers?), or via the Client Computer's IP?
Thanks!
It's considered a bad security risk to expose MySQL's port directly to external clients. MySQL supports TLS but doesn't enforce it by default. So you're at risk of unauthorized clients invading.
For this reason, it's much safer and more recommended to run your own API server, as you mentioned. The API server is the only one allowed to connect to MySQL. Typically network routing is configured to prevent any contact to the database server except from the API server.
MySQL would therefore know nothing about the client's IP address. As far as MySQL is concerned, your API server is the only IP address it knows about.
The client IP address would be known by your API server and http server, and if you have load balancers or firewalls, those too.
The "users" associated with your third-party clients aren't necessarily mapped to distinct users in the MySQL authentication system. Actually, it's more typical that the API server uses a single MySQL user to authenticate all clients. Once connected to the database, your code would look up the client's "user" as a further authentication step. In other words, you would store a table in your own database with user credentials, and you would implement code to check passwords and so on. This is distinct from MySQL's own authentication system.
Alternatively, you could write your API service to use SAML or Oauth2 or equivalent federated authentication. The API service would still need to authenticate to MySQL, but the client's identity would be provided by the Oauth2 authentication.
In Azure's traffic manager, I am doing some testing with TWO failover URLs: Two different endpoints are configured for the traffic manager (failover1.mysite.com, failover2.mysite.com.), however, my local browser (Chrome for example) seems to be caching the DNS record on its own and redirecting to what it thinks is still the destination, rather than letter Azure Traffic Manager re-route. Trying the request in a new browser or Incognito session will result in the request reaching the correct site. But for existing sessions, failover updates are not being registered and still hitting the site we are trying to redirect traffic away from. Does anyone have any experience with this?
I had the same issue while I was dealing with Azure Traffic Manager or AWS CloudFront.
DNS Record is associated with its TTL value. It is not something wrong with the Azure Traffic Manager. It is the TTL value that is letting the DNS client to cache the IP address.
How to check TTL value of DNS:
If you are using Windows,
https://support.rackspace.com/how-to/nslookup-checking-dns-records-on-windows/
If you are using linux follow the detailed instructions here,
https://www.cyberciti.biz/faq/howto-use-dig-to-find-dns-time-to-live-ttl-values/
Hope it helps.
From Microsoft's overview of their load balancing services:
Traffic Manager is a DNS-based traffic load balancer [...] it load balances only at the domain level. For that reason, it can't fail over as quickly as Front Door, because of common challenges around DNS caching and systems not honoring DNS TTLs.
With Front Door you can route requests to different backends based on rules and/or the health of the backends themselves so it doesn't have the issue you describe.
We have developed a client app and a server app. The client communicates with the server using the http protocol and sends some data to be processed by the server.
Our structure allow us to have the server installed anywhere. I can be on the same client network or even on the cloud.
When the server is hosted on the cloud, it makes sense asking the user for the server address (since it can change if the user wishes to) but it does not make sense when the server is on the same network that the client. Besides that, we are currently asking users to configure the server ip/name in order to connect to the server.
To avoid this (asking users for the address) I have developed a discovery service based on UDP. The client broadcasts a message that the server answer with its address. It does work on some cases, but it does not when the user has some kind of firewall, proxy or even an anti virus.
I have read a lot about discovery services, and the one that a like most is Bonjour.
So, the question is: what is the best way of discovering a server's IP when the server is on the same network that the client without being blocked by firewalls, proxies, etc?
You can keep your service purely local (in the intranet) and build on top of what you are using now by implementing hole punching. You can get past firewalls, but Im really not sure about AV software policies.
Or you can establish a well-known http-based discovery service in the internet.
A server comes alive, sends its (local) ip address to the discovery service (keeps sending keep-alives)
On startup, the client queries that discovery service, identifies the local subnet he is in, and gets back the local ip address of the server.
That of course creates a single point of failure in your system in that if the discovery service kicks the bucket, your clients cannot find servers. You can remedy that by replicating the service and/or introducing fallback mechanisms (like the purely local discovery you have), which you probably want to do anyway. The only problem you might have is the subnet identification, if computers in local subnets dont share external IP addresses (then it depends on what a local subnet is for you).
Assume that there is a web-page called whatisyourip.com and that I have a web-page called changeip.com. A user wants to enter the site whatisyourip.com through changeip.com. Normally, changeip.com would be a proxy server so the user can hide his ip address. That's how users reach forbidden web-pages in their countries. But I want to ask, is there a way to show a different ip address to whatisyourip.com while connecting it through changeip.com without using it as a proxy server?
is there a way to show a different ip address to whatisyourip.com while connecting it through changeip.com without using it as a proxy server?
Short answer: Yes. Make changeip.com a VPN server and assign different IP addresses to those VPN clients. Ensure they send all traffic through the VPN. This usually involves modification of the local routing table on the VPN client workstations for everything to work correctly.
Longer answer... There are several reliable ways to hide IP addresses of TCP sessions...
HTTP Proxy - you already described this situation
Network address Translation - this doesn't sound likely in your scenario
VPN Tunneling - Possible solution instead of HTTP proxy, even if it's something as simple as an SSL VPN. Depending on your constraints, this could also be a viable option.
You can't. TCP connections require a 3-way handshake. You can certainly send a SYN packet to the server to start the process, then change your IP address. but when the site responds with the 2nd-stage of the handshake (SYN+ACK), that packet is now going to your old IP address and your system will drop it - it has no idea that the server is responding to something that was started on the old IP.
You could try something like the Tor network, which offers end-to-end encryption of traffic and cloaking of origins, but it's not something I'd consider "reliable".
Not unless you spoof your IP, in which case the response will go to the forged IP. So no.
I am working on a site that will be using HTML5 sockets to communicate with other server. At that time our users will be logged in , I can't code on other server . I am using PHP at server side. I don't know whether other server has even PHP or not. Client says PKI is a solution. So if user login on our server then I start their communication with HTML5 sockets towards other server to send and receive data. So how can other server authenticate them? I also think that I can have a userkey (like 32hash format) that is sent with HTML5 socket while communication that other server validate and then start working with that user. So client says that hacker can see data over network so I think SSL can work for it. What you guys suggest in such scenario? Please advise
More details:
There will be connection made between our users and another server using apache thrift(will be using TCP), and scenario is that user will login to our site, then we will connect them via HTML5socket to apache thrift on different domain, so in HTML5socket communication we will be forwarding userid to tell thrift server that which user is this, so it is fine. But there are two problems,
As HTML5sockets are at client side then a hacker can create his/her own socket and connect to that server in same way and use some one's id as these are just simple integers.
If we will append some thing in data then a hacker sitting on the network can get it like some hackers do this for session hijacking.
So that's why I am not sure that whether using a sort of SSL or TLS will solve the problem or some PKI or some other digital certificate. So that's why I am asking that here.
thanks
SSL cannot solve this problem. SSL is about creating a secure link between the client and server, it does absolutely nothing to protect the server from a malicious client. SSL cannot solve the problem of SQL Injection or in your case Insecure Direct Object Reference relating to the user id. Judging by this SSL suggestion you probably have never heard of TamperData, which allows you to read/intercept and modify all HTTPS traffic generated by your browser (Including components like flash and JavaScript), BURP is more advanced but does the same thing.
The right way to do this is to have a shared session store that your collection of servers can access. The client is issued a very large random number or cryptographic nonce that it uses as a verification token, which is kind of like a session id. This verification token is used to look up session state in the data store. The communal session store could be as simple as a PHP page that accepts the verification token as a parameter and tells you if its linked to a valid session.
Having 3rd parties issue a callback to verify the session is really the "right way" to do this. It is possible to do this with cryptography, although it is a misuse of cryptography because it introduces the possibility of an attack, where as a callback is absolute. The PHP server can issue the JavaScript client an HMAC token consisting of the user id, a timestamp and the message authentication code. The tricky part is that both the PHP server and any 3rd party will have to share a secret in order to verify the message authentication code. If done properly you can transmit the client can transmit the token, and 3rd parties can verify that the session hasn't expired based on the timestamp and that your servers issued the token (instead of a hacker's forgery) based on the message authentication code.