I have setup an appfabric(v1.1) cache server. The service is running under a service account and cluster configs are stored in SQL Server. the service account has rights on the sql server and able to configure successfully.
The admin console ,when opened with the service account user, is able to access cache.
But the problem is when i tried to connect to this caching service from a different machine, it is unable to connect.
ErrorCode<ERRCA0017>:SubStatus<ES0006>:There is a temporary failure. Please retry later
When i tried with xml configuration in a file share and service running in "NetWorkService" account, i was able to connect.
Following settings are verified on caching server.
Service is up and running on port 22233.
Firewall is turned off.
The client machine is granted permission to access cache cluster.
Running AppFabric cache as anything other than a “Network Service” is not supported.
Here’s the official documentation that hints at the limitation:
The Caching Service is installed to run under the Network Service
account. This means that for operations over the network, the Caching
Service uses the security credentials of the cache server's domain
computer account. The Caching Service uses the lower-privileged
Network Service account to help mitigate the damage that could be
caused by malicious attacks
But if you don’t find that convincing there’s this forum post from a MS person:
Velocity service running as Domain User is NOT supported.
If you think this is a horrible limitation… I agree with you.
AppFabric cache is a 100% WCF implementation. When I ran into this problem, I turned on WCF tracing and found the exception “The target principle name is incorrect”. AppFabric cache does not expose the ability to configure the principle.
In my testing with the cache running under a domain account, I found that if I called the cache across a domain boundary: It worked. If I called it from within the same domain it failed. My infrastructure guy said that the behavior made sense to him based on how credentials were presented in the different scenarios.
anyone else check out this:
http://blogs.msdn.com/b/appfabriccat/archive/2010/11/03/appfabric-cache-cache-servers-and-cache-clients-on-different-domains.aspx
caused me such a headache.
basically had to update my host file with the IP address and the actual servername of my AppFabric server.
and this resolved the error i was getting
Related
I just got the bellow mail from Amazon, The instance have ubuntu as os and have ldap and apache2 installed,
LDAP Server is only used by one other instance, to auth it users(just ubuntu users) nothing else use the LDAP Authentication
Apache2 only have phpldapadmin and most of the time is down(start it when I need to make change to ldap)
I have tried to check the syslog and auth.log, cannot find any successful login attempt expect for mine (same user, key and IP ).
The report was sent while we were conducting a stress test about 1000 req/sec on a web app hosted on tomcat6 on the machine (the one that uses the LDAP Server to authentication) and the type of request that was used in the stress test doesn't require any type of authentication only load data from db and return a json array
we have only ssh,ldap and http open for LDAP Server machine(with the issue)
Question is: * How to find out the cause of the outbound traffic? Can the stress test cause this or is it just coincidence ? *
Dear Amazon EC2 Customer,
We've received a report that your instance(s):
Instance Id: xxx
has been making Denial of Service attacks against remote hosts on the Internet; check the information provided below by the abuse reporter.
This is specifically forbidden in our User Agreement: http://aws.amazon.com/agreement/
Please immediately restrict the flow of traffic from your instances(s) to cease disruption to other networks and reply this email to send your reply of action to the original abuse reporter. This will activate a flag in our ticketing system, letting us know that you have acknowledged receipt of this email.
It's possible that your environment has been compromised by an external attacker. It remains your responsibility to ensure that your instances and all applications are secured. The link http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1233
provides some suggestions for securing your instances.
Case number: 000000-0
Additional abuse report information provided by original abuse reporter:
Destination IPs:
Destination Ports:
Destination URLs:
Abuse Time: Fri Jan 01 05:27:00 UTC 2016
Log Extract:
<<<
It has come to our attention that Denial of Service (DoS) attacks were launched from your instance to IP(s) 162.159.9.138 via TCP port(s) 53. Please investigate your instance(s) and reply detailing the corrective measures you will be taking to address this activity.
In the meantime, we have restricted network access to only inbound TCP ports 22 and 3389 on the instance(s) to prevent further abuse.
If you believe that you were compromised by an external attacker, the best recourse is to back up your data, migrate your applications to a new instance, and terminate the old one. Attempting to repair a compromised instance does not guarantee a successful cleanup in most cases. We recommend reviewing the following resources to ensure your EC2 environment is properly secured:
Amazon EC2 Security Groups User Guide:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html
AWS Security Resources:
http://aws.amazon.com/security/security-resources/
AWS Security Best Practices:
https://media.amazonwebservices.com/AWS_Security_Best_Practices.pdf
I am a developer trying to help a customer who has lost their root access information. I have full access except for root access. I have developed a webhook that communicates between a catalog sales site and their CRM site.
It was working fine, until suddenly it started getting 500 error codes. I tracked down that it was because the SSL certificate has expired. How do I find out what SSL certificates exist and how to fix this problem.
One difficulty is that in order to request technical help, I must upgrade the support plan, which I am willing to do, but can only do this from the root access account. In addition, I can't ask a question about how to reset the root account access unless I have the support plan.
We have the account number, BTW. We are running an EC2 instance on an AWS Linux server. Pointers to how to either get paid help or reset root access would be appreciated.
SSL certificates will be in one of 2 places:
ACM for either CloudFront Distributions or Elastic Load Balancers.
Locally on an EC2 Server if you connect directly to server.
If you need to connect to the EC2 server you will need to be able to connect via SSH or RDP depending on OS.
Regarding getting root access, you will need to attempt account recovery via AWS support. You'll be expected to provide proof that you own the account before they can reset these credentials for you.
Found out destination needed to purchase a new certificate and all was well. I thought the problem was on the sending end, but it was actually on the receiving.
I noticed that my VM in the google cloud platform is generating DOS and wondering where that may be coming from. On further search, I noticed a file that wasn't created by me and deleted the file.
So far, I have changed the ssh port but I'm still getting This project appears to be committing denial of service attacks
I would like suggestions on what else I can do to prevent this in the future.
I'm leaving here some interesting resources you can check to secure your Google Compute Engine instance:
Ubuntu SSH Guard manpage
ArchLinux SSH guard guide (guides you through installation and setup)
Apache hardening guide from geekflare
PHP security cheatsheet from OWASP
MySQL security guidelines
General security advice for Google Cloud Platform instances:
Set user permissions at project level.
Connect securely to your instance.
Ensure the project firewall is not open to everyone on the internet.
Use a strong password and store passwords securely.
Ensure that all software is up to date.
Monitor project usage closely via the monitoring API to identify abnormal project usage.
To diagnose trouble with GCE instances, serial port output from the instance can be useful.
You can check the serial port output by clicking on the instance name
and then on "Serial port 1 (console)". Note that this logs are wipped
when instances are shutdown & rebooted, and the log is not visible
when the instance is not started.
Stackdriver monitoring is also helpful to provide an audit trail to
diagnose problems.
Here are some hints you can check on keeping GCP projects secure.
We have developed a RESTful Web Service which requires access to a Network share in order to read and write files. This is a public facing Web Service (running over SSL) which requires staff to log on using an assigned user name and password.
This web service will be running in a DMZ. It doesn't seem "right" to access a Network Share from a DMZ. I would venture a guess that the "secure" way to do this would be to provide another service inside the domain which only talks to our Web Service. That way, if anyone wanted to exploit it, they would have to find a way to do it via the Web Service, not through known system API's.
Is my solution "correct"? Is there a better way?
Notes:
the Web Service does not run under IIS.
the Web Service currently runs under an account with access to the Network Share and access to a SQL database.
the Web Service is intended only for designated staff, not the public.
I'm a developer, not an IT professional.
What about some kind of vpn to use the internal ressources? There are some pretty solutions for this, and opening network shares to the internet seems too big a risk to do.
That aside, when an attacker breaks into your DMZ host using those webservices, he can break into your internal server using the same API unless you can afford to create two complete different solutions.
When accessing the fileservers from the DMZ directly, you would limit theses connections using a firewall so even after breaking your DMZ Host the attacker cannot do "everything" but only read (write?) to those servers.
I would suggest #2
Have a two host AppFabric setup. Both hosts are Win2k8 standard and are running the 32 bit version of AppFabric. The entire system has a backing SQL server store that has the AppFabric database store. Connectivity is not an issue between the systems, verified independently.
When I start the cache-cluster I get this error:
(AppFabric Caching service crashed with exception {Microsoft.ApplicationServer.Caching.ConfigStoreException: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON')
It appears that AppFabric is unable to impersonate the user it is running / configured with into SQL server. We have configured accounts for the domain user that will run AppFabric, also accounts for the machines. Any help is appreciated, we've been stuck on this for a while now.
This is probably checking things you've already been through but let's see if we can rule a few things out first.
Can you confirm that:
the domain account isn't locked out for some reason, has a non-expiring password etc
the AppFabric Caching service is configured (on both servers) in the Services Control Panel applet to run under the domain account you've created
the domain account has access to SQL Server and the AppFabric config database
Can you start either cache server individually?
Domain Account Configuration is not supported in V1.0. Only Network Service can be configured in V1.0.
Let me see if I have understood the problem correctly.
Configuration: AppFabric 1.0 installed with SQL server config store. All other default configurations.
Symptom: Service does not start on the machines due to sql server connection error.
If the above is correct, you can try the following:
Issue: The AppFabric Service runs as network service on the server mahcines for security reasons. When the service tries to access the sql server config store, it sees a permission issue.
Resolution: Give permission for the NT service / Machine$ account for all the server nodes on the sql server for the config store db.
Let us know if this solves the issue.