I'm now thinking about moving to s3, but I'm still concern about the restriction policy in my country in the future, so I'm wondering if I can use some DNS service or some other way to solve this problem.
It's doubtful that DNS can help with this issue.
In general, it's quite difficult to bypass such restrictions if there is an entity that has complete control over the borders of its network. It could be anything - from a government blocking opposition sites for political reasons to a company blocking access to insecure web mail providers for security reasons.
If an entity wants to block a specific service provider, it's easier, more effective and far more efficient to simply block all IP address blocks that belong to that provider. DNS is at a higher level and will not help with this issue.
What would help is an unblocked proxy (relay) or VPN service. You connect to that service and tunnel any connection to your intended service provider through that connection. It could be:
A proxy server abroad that is not blocked. There are commercial proxy/anonymizer services that may be able to help here, although the most known ones are bound to be blocked too.
A VPN connection to an unblocked network e.g. a business partner.
An application such as Tor. This option usually implies a very significant performance drop and should not be used for high data rates (anything above a few KB/sec).
If you use a remote proxy or VPN server you should contact the owners and find out their policy for something like this.
Related
I recently signed up for CloudFlare to take advantage of the security feautres the service provides. Specifically, I'm interested in its use against DDOS attacks (which are a problem I'm facing).
My web application employs nginx as a reverse proxy (with gunicorn as the application server). The Ubuntu-based virtual machine - procured via Azure - has a static/reserved IP (used as a VIP). I've read that after connecting to CloudFlare, it's best practice to change server IP so that malicious actors can't directly DDOS the said server.
Being a newbie, I'm unsure whether this guideline was applicable to the public VIP (virtual IP) or to the internal IP (which is entirely different). Can someone please conceptually and functionally clarify this for me? Can really use some help in setting this up!
What services like CloudFlare do is acting like a CDN for your website. They become front-end of your content delivery to clients while they have vast network for doing so (resources i.e. bandwidth which are consumed by DDoS). Then your IP is just known by the anti-DDoS service provider to fetch the content and deliver on your behalf.
You see if the IP is leaked by any mean the whole defense mechanism become useless since attackers can directly point to your machine while dynamic DNS of CloudFlare would distribute requests to its network and serve clients via them.
Since your website was up for a while before you migrate to CloudFlare your current public IP is known to attackers and hiding behind CloudFlare is useless since they don't ask CloudFlare DNS service and directly attack your server. This is the reason you need a new IP and the new one should not be revealed by any mean. Just set it in your CloudFlare panel and don't use it for other purposes.
I faced attacks too and used CloudFlare to prevent them, however, I have learned how to perform those attacks by myself and also how to bypass CloudFlare and take down the protected website. The best practice is to secure your server by yourself. Using nginx as a reverse proxy is a good option.
I'm doing a network security course and trying to wrap my head around all the concepts. One of which is:
What technology other than firewall can be used to allow only a specific customers while block some other customers? Why is firewall not suitable?
During the course, I've been learning about all the security tools such as: firewall (static, dynamic, DPI), Proxy, VPN, Tunnel, all sorts of IDS (signature, anomaly, darknet/greynet and honeypot) then mod_security to secure apache but still puzzled by this question.
Any insights here will be greatly appreciated.
A firewall implied that you block based on the customer IP address. This may work if the customer has his own range of addresses and all requests from him are legitimate.
It gets complicated when he is with a large cloud provider who who provide a wide range of possible IPs, including IPs from other people.
For an application one good solution would be to use client-side certificates. In that case, during the TLS handshake (the process of putting in place a TLS (was: SSL) tunnel), the server will request the client to provide a certificate he (the server) trusts. Failure to providing one will break the connection.
This way, you can distribute the certificate to the clients you want to be able to reach your service and others will be rejected. This solution is better as it uses technologies which were developed exactly to solve this problem. The drawback is that you have to maintain and distribute the certificates (and usually run a PKI).
We have developed a cloud based POS system which running on more that 75 outlets and all the transaction data need to be posted every 5 minutes to the relevant database which sits on our head office (POS System is connecting to its own local database). For this we are using windows application which is directly connecting to our head office database through a VPN. But recently one of our clients raised a concern that our head office database is exposed because if anyone sneak to the network (obviously inside the VPN) he could see all CRUD Operations. So by this way he could do anything to head office database.
So we have decided to go for a WCF solution with encrypted JSON Call. If we use a web service can we eliminate this issueccompletely. Is it the best practice? Please advice.
There are several aspects of security to consider in your situation. If your current network topology doesn't limit the VPN client's visibility to just your database server, then yes, I agree that moving to publishing a web service endpoint and using HTTPS would improve security by blocking clients access to other servers on your internal network. However, the web service solution introduces some other considerations. Will you use firewall rules to limit which clients can access the web service? How are you authenticating clients, and how are you protecting those credentials from unauthorized users?
Enviroment
Consider the following production environment setup for a web application:
End user --Internet--> web server in DMZ --Firewall--> WCF hosted on app server --> DB Server
Constraint:
Also consider that we cannot change anything from the infrastructure point of view. For example, open ports, change any firewall setting etc.
Problem:
We want to expose the WCF, which is hosted on the app server, to external clients. We are trying to solve this as follows:
End user --Internet--> Router WCF in DMZ --Firewall--> WCF hosted on app server --> DB Server
Please note that we cannot establish a db connection from the DMZ environment where the WCF needs to be hosted so that the external clients can consume it. We have developed a "Router WCF" which passes through all messages to the internal WCF and vice-versa.
This solution adds an unnecessary overhead of serializing and de-serializing data. There must a better and proper way of doing this. We are looking forward to the community for guidance. Thank you.
In DMZ the bibliography tells you: always create an intermediate layer. This means another machine on the internet will be the point of connection and it will proxy the connection back to WCF.
The machine is the web server you seem to mention, that is stupid, has no data, and (to be a proper DMZ) has a firewall between it and all the machines (WCF and the others) it serves that permits only IP:PORTS used on such machines.
In this scenario, usually Apache on the public web server with a URL-rewrite rule (i.e if it is /x/y send it to servera.internal.com:9900 - if it is /x/z send it to serverb.internal.com:9901 etc...) is enough, but there are plenty of solutions of course.
It seems you are doing exactly this, why do you say it is not the proper solution?
DMZs could seem a bit dated as protection mechanism (I agree) but you have to think when servers like your WCF machine had dozens of ports opened, and you wanted to lower the risk of random ports on web-facing machines, a giant attack surface. Nowadays everything can work with couple of ports opened, so it can seem "silly" to do all of this just to forward a TCP port. But it is still valuable as (for example) if servers behind the web server in DMZ do not have internet access, even when WCF is compromised, the attacker cannot use its own reverse shell to deploy what it is nowadays called an APT (yesterday backdoor). The attacker "won't see" his own machine from WCF as the DMZ provides the connection to the external world.
is there an accepted best practice for securing access to a Weblogic JNDI (JDBC Specifically) services from external apps?
Out primary motivation is trying to stop people from accidentally pointing QA code at production machines, but obviously there is the question of securing the port from unwanted visitors (other hosts on the internal network) as well.
Idea would be that an arbitrary client can't just connect to :
t3://importantprodhost.mycompany.com:7001
and get hold of one of the remote JDBC/JNDI stubs that are proxies to our databases
I did find this link which seems to be related, but I was hoping not to have run everything as a WebLogic.runAs() call.
My guess was that one could only expose the JNDI service over a HTTPS and authenticate with a certificate (which wouldn't be on the QA machines), but haven't found a concrete/simple example, so I don't know if this would actually work.
Please assume for the purposes of this question that we need access (i.e we can't turn it off) - we'd just like to authenticate it, and that we can't deploy anything network level such as a firewall to solve the problem.