Does Amazon Beanstalk automatically prevent (distributed) denial of service attack? If not, whats the most convenient way to do so?
I believe it does
New – AWS Shield AWS Shield is a new managed service that protects
your web applications against DDoS (Distributed Denial of Service)
attacks. It works in conjunction with Elastic Load Balancing, Amazon
CloudFront, and Amazon Route 53 and protects you from DDoS attacks of
many types, shapes, and sizes. There are two tiers of service:
AWS Shield Standard is available to all AWS customers at no extra
cost. It protects you from 96% of the most common attacks today,
including SYN/ACK floods, Reflection attacks, and HTTP slow reads.
This protection is applied automatically and transparently to your
Elastic Load Balancers, CloudFront distributions, and Route 53
resources.
AWS Shield Advanced provides additional DDoS mitigation capability for
volumetric attacks, intelligent attack detection, and mitigation for
attacks at the application & network layers. You get 24×7 access to
our DDoS Response Team (DRT) for custom mitigation during attacks,
advanced real time metrics and reports, and DDoS cost protection to
guard against bill spikes in the aftermath of a DDoS attack.
https://aws.amazon.com/blogs/aws/aws-shield-protect-your-applications-from-ddos-attacks/
No it doesn't prevent DoS attacks, you'll have to detect and prevent such attacks by yourself. There are differnt ways to protect your application against DoS attacks, you can google for it. Here are a few links which may help you:
aiCache DoS attack identification and mitigation
Amazon Web Services: Overview of Security Processes
Wikipedia: SYN cookies
Amazon Forum: DoS attack
There are several kinds of doss. Since your ec2 public IP address is behind aws eb, I think your ec2 instance is at least safe from layer3/4 ddos.
Related
I have the possibility to use a shared mysql server offered by a reliable Italian cloud provider (Aruba). The service satisfies my performance needs and would notably simplify my infrastructure.
My concern is that this shared mysql service (DBaaS) is only offered with public ip address exposed on the internet, authentication with userid and password and SSL connection.
The data that I would move to this server are reservations and accounting for a certain number of hotels. It's definitely critical and confidential data and a data breach would be definitely a disaster.
Till now, my infrastructure is based on a firewall that only exposes the web server, while the database server is a custom VM connected through a virtual switch and not visible on the internet.
How bigger is the danger of such an infrastructure (DBaaS with public ip address) compared to my actual setup with a private VM running mysql on an internal IP address?
PROS: security, updates and firewalling would be managed by the cloud provider in a more consistent and persistent way
CONS: exposure on the internet
Lets say I have a VM instance and I then make a connection to the Cloud SQL instances IP using a MySQL client. According to the comparison table in Connection Options for External Applications, connecting with no SSL is apparently not secure (and non-encrypted).
But to what extent is it insecure? If there is a man-in-the-middle attack, query and query results could be seen. I would like to determine how big of a risk that is.
Specifically I would like to know the risks of connecting from:
A VM in the exact same zone to a Cloud SQL instance
A VM in the same region, but a difference zone to a Cloud SQL instance
A VM in another region to a Cloud SQL instance, but still from GCP
I assume that for any of these kinds of attacks to be carried out, the actual google infrastructure would have to have been compromised as it wouldn't be possible for a VM to listen to traffic outside a network that it's attached to.
The actual infrastructure wouldn't have to be compromised actually, all that it'd take is for an instance in the same network to be compromised for the details of your connection to Cloud SQL to potentially be compromised. Seeing as maintaining the instances up-to-date is a responsibility of the users, that means that the security of an insecure connection to Cloud SQL also depends on the security of your instances.
Why exactly are you doing insecure connections? I ask because it's incredibly easy to setup a safe connection from an instance to Cloud SQL by using Cloud SQL Proxy! Not to toot my own horn here, but take a look at
this answer I gave a while ago about why you should be using the Proxy.
Regardless, and keeping in mind that Cloud SQL is nothing more than a managed instance exclusively accessible via its public IP, the traffic should stay within GCP in all three of those scenarios, meaning the only thing that is likely to be compromised are the instances in the same sub-network as that of the instance that's connecting to Cloud SQL.
I've setup my ssl cert in AWS through EC2 using the Elastic IP Address and Elastic Load Balancing. It costs me about 20$ per month to run this.
Does anyone have cheaper suggestions?
Depends on what you are using your EC2 instance for... If for a web service, look at API Gateway in front of a Lambda function for a serverless architecture. If for a website and it is static, consider hosting in a S3 bucket.
Let'sencrypt would be the ideal solution for your case. https://letsencrypt.org/ offers free ssl certificates that you can generate and import into your ACM and attach them from ELB
OR
If you prefer it directly to your EC2 instance then you can install them in your apache (httpd) web server.
Refer: https://www.godaddy.com/help/apache-install-a-certificate-centos-5238
https://www.youtube.com/watch?v=_a4wRsT6LaI
Use certificates from the AWS certificate manager and you won't pay anything. They are free. https://aws.amazon.com/certificate-manager/pricing/
You can use AWS CloudFront as the gateway to your application which can use AWS Certificate Manager issued SSL certificates for free. There are no upfront commitments and you will pay only for the usage (More details refer CloudFront Pricing). You can connect your EC2 instance to CloudFront to receive traffic.
This will provide you a higher performance by caching the static content while reducing the load for your backend further reducing costs at scale.
I wanna know the basic different between rpc and webservices. which should be prefer.
I wanna choose between json-rpc and jax-ws.
Web service:
Web services are typically application programming interfaces (API) or Web APIs that are accessed via Hypertext Transfer Protocol (HTTP) and executed on a remote system hosting the requested services. Web services tend to fall into one of two camps: big Web services and RESTful Web services.
RPC:
Remote Procedure Calls. It enables a system to make calls to programs such as NFS across the network transparently, enabling each system to interpret the calls as if they were local. In this case, it would make exported filesystems appear as thought they were local.
Which one is preferable:
RPC would be used only for internal/in-house servers where you have influence on both the client and server code. The most frequent case is to forward services which only exist on a few machines. For example, to minimize the number of licenses or support overhead needed by forwarding requests to a central machine, or to provide access to software that is other operating system specific (eg, Linux programs that need to use an old program only available on SGIs.) The other case is to reduce startup costs.
We can identify two major classes of Web services, REST-compliant Web services, in which the primary purpose of the service is to manipulate XML representations of Web resources using a uniform set of "stateless" operations; and arbitrary Web services, in which the service may expose an arbitrary set of operations
May it will be helpful to you...
I was wondering if someone could tell me if there is any potential security breeches that could occur by connecting to a MySQL database that does not reside at 'localhost' i.e. via IP address?
Yes, breaches do occur by not protecting the connection to your database. This is a network secuirty question more so than an Application secuirty question. Thus this answer is entirely dependent on your network topography.
If a segment of your network maybe accessible by an attacker, then you must protect yourself with cryptography. For instance you have a malicious individual who has compromised a machine on your network, then they can conduct an ARP Spoofing attack to "Sniff" or even MITM devices on a switched network. This could be used to see all data that flows in and out of your database, or modify the database's response to a specific query (like a login!). If the network connection to your database is a single rj45 twisted connection to your httpd server all residing inside a locked cabinet, then you don't have to worry about a hacker sniffing this. But if your httpd is on a wifi network and then connecting to a database in China, then you might want to think about encryption.
You should connect to your MySQL database using MySQL's built-in SSL ability. This insures that all data transferred is highly protected. You should create self-signed x509 certificates and hard code them. This is free, and you don't need a CA like Verisign for this. If there is a certificate exception then there is a MITM and thus this stops you from spilling the password.
Another option is a VPN, and this is better suited if you have multiple daemons that require secure point to point connections.
It's usually the other way round that the bigger problem lies, vulnerabilities in the MySQL server being exploited by untrustworthy clients.
However, yes, there have also been client vulnerabilities in the past (eg.) that would allow an untrustworthy server to attack the client.
Naturally you should keep your MySQL client libraries up to date to avoid such possibilities, as well as updating the server.
If your connection to the server is going over the internet (rather than a private network), you should consider running it over an encrypted link (either MySQL's own SSL scheme or using a tunnel). Otherwise any man-in-the-middle could fiddle with the data going in and out of the database, and if there are client or server vulnerabilities those could also be targeted.
If the servers are in the same rack, you can use dedicated high-speed MySQL cable, or use switch VLAN isolation, and protect the database OS. In cloud with the virtual cloud network you can connect it the way that arp spoof is not possible, and for the geo-ip replication, you can use user/password and firewall, and then measure the performance, and then setup a tunnel and measure performance again, if it's not bad, it might be worth against unknown threats or just useful in using spare cpu cycles.
Simply SQL servers has to be on isolated network, and not into the public, as rule of thumb, you never publish open database connection to anyone, and keep it with seriously good firewall filtering on separate subnet made for handling sensitive data with very good arp spoofing protection, otherwise it's crackable and the major parts of the system can be compromised using several techniques, and it's very nice and sometimes very easy to handle it this way, e.g. to control, monitor and policy the MySQL traffic with hardware layer - and it really does the job and makes a real difference.
Optionally you can keep it on encrypted hard-drive in physically safe place along with the switch, so upon breaking the power its switched off, and the private key erased, hence both layer-1 and layer-2 are secured.
On the switch to use the static ARP table plus the filtering for the static entries versus the port is very easy to do because it's also physical layer - the port number.