We have a simple WP site that has been running for years. We can access it on mobile or any other computers that are not connected to our company's domain. I believe there is an error within our firewall. Any suggestions on where I should look? We use a Dell Sonicwall.
First check the logs, and see if it's being blocked. Then I would check app control, or the CFS policies. Probably, the easiest way would be to just put one test machine IP address in a CFS, IPS, or APP Control (or all) bypass group. Test you can get out to the site. Once you can access the site, start to re-enable all the security services one by one until you find out what's blocking it.
Related
I am reading about dos.xml for configure Java Application against DOS attack.
I did not understand how this configuration works.
I know about DOS and DDOS, but in this case it is confused for me.
When I configure Blacks of IP or subnets, will all requests be blocked? I think that GAE should block only if it receives too many requests of the same IP
What is the best way to prevent too many requests (evil requests ) in my login page? I can not have IP whitelist, because the app is available for any places in the world.
What is the difference between a black IP in two.xml and block IP in App Engine firewall?
Thanks !
When I configure Blacks of IP or subnets, will all requests be blocked? I think that GAE should block only if it receives too many requests of the same IP
Yes, that's how it's suppose to work: the IP address will be blocked only when AppEngine thinks they're abusing your resources (whatever that means). See more here:
Do not use this service for security because some requests from blacklisted users can still get through to your application. This service is designed for quantitative abuse prevention, such as preventing DoS attacks, only.
Unfortunately there is no clear algorithm described how it's handling this so it's probably best not to rely on it.
What is the best way to prevent too many requests (evil requests ) in my login page? I can not have IP whitelist, because the app is available for any places in the world.
You would have to implement some kind of rate limiting (by IP addresses or by accounts being accessed) yourself. Shouldn't be very difficult by incrementing some memcache key's value on each authentication attempt and setting it to expire in N minutes (or whatever approach that works best for you).
What is the difference between a black IP in two.xml and block IP in App Engine firewall?
A couple of differences between dos.yaml and AppEngine Firewall that comes to mind:
AppEngine Firewall can completely block access from a given IP address while the addresses listed in dos.yaml may still reach your app
AppEngine Firewall allows up to 1,000 rules while dos.yaml can only handle up to a 100
With AppEngine Firewall you can set up a whitelist (i.e. give access to your app only to, say, your company's network and no one else)
Also, judging from the wording AppEngine docs are using - it seems dos.yaml isn't the recommended approach so you would likely need to implement something yourself.
If a particular computer is making tons of accounts or flooding my server with other requests, could parse-server automatically check this behaviour and block the specified IP address?
Built-in rate limiting would also be a nice alternative, although it doesn't really solve the problem if the person continues to spam.
I am hosting on google app engine by the way.
I don't know about Parse itself, but from App Engine side you have DoS protection service controlled via dos.yaml file in your project that lets you blacklist IP blocks—sounds like that may help. It's not "automatic", though; you still need to manually update this file and issue appcfg.py update_dos <PROJECT_DIR> for changes to take effect.
I don't believe that this is a feature out of the box - see advanced options here: https://github.com/ParsePlatform/parse-server.
You'd need to look at controlling access to the Google App Engine (or another host - such as Microsoft Azure Web App) using a firewall (you can easily do this with Azure. I'm not familiar with Google App Engine, but imagine similar functionality is available.
However, I don't believe that a firewall is necessary - just better app security. Disable anonymous users - Parse Server Security
I have deployed a WPF .NET4 application on my customer's network.
The network can ping the internet, but the PCs are not able to browse.
It takes about 60 seconds to start the application.
TcpView shows that the app is trying to communicate with these URLs:
customer.teliacarrier.com
office365.com
msgr.dlservice.microsoft.com
akamaitechnologies
If we open the internet and starts the application once everything work fine and we can close the firewall again.
Does anyone know why the app communicates on the URLs the first time???
The customer has solved the problem.
The firewall was configures to allow ping to all external sites.
When they changed the rule to not allow ping everything worked fine.
I think that .NET 4 uses some signed files that the machine tries to authenticate.
If you used ClickOnce deployment or 3rd party components the app might be looking for updates.
All of the URLs (except for the office365.com) refer to download/mirror sites.
You could try to have a look at the requests that are being send to get more details.
If you have signed your files they may be trying to authenticate against a Certificate Authority. Also - make sure you ngen your wpf files before delivery - this speeds up the first launch of the file (Regardless of reaching out to websites). http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.80).aspx
OK, this used to work, but it appears to have stopped working on January 1st.
We have a .NET page that is displaying some data to our internal mobile users. This page is set up with Anonymous Authentication in IIS7. (Windows Server 2008 R2 is the OS of the web server.) When accessing via our intranet, the page displays fine. When attempting to access via our Blackberries, we get the following error message:
"Error: Page cannot be displayed. Please contact your service provider for more details. (1)"
Is this an IIS error, an AT&T issue, or a Blackberry issue? My Director is on my case about it, and I'm not experienced enough in IIS to know of anything else that would cause this functionality...
You should check with your network ops team. I'm guessing that the blackberries are accessing the server from the external intranet (that's just a guess though) ... so have them double check that the domain/ip is accessible externally. That could be why you can access it from in the network.
Or if your blackberries are configured to access the network via VPN, I would double check that connectivity.
Forgot to post the resolution to this.
It turned out to be a Blackberry issue. With the latest OS, RIM combined the internal and external browsers into one browser. Said browser attempts to determine if a given site is an intranet or internet site. Even though the BES (sp?) was set up correctly, our service was still spotty. Some people could enter our intranet homepage address and get the intranet; others got the web squatter site on the internet. Since the page we were trying to access was nested fairly deeply in the directory structure, the web squatters didn't have a page with that name in their site. That's why we were getting the error shown above.
Our resolution - we created a different BES alias to point to our intranet, and rolled that out to all applicable users. Utilizing this, the browser didn't have to determine if we wanted our intranet site or the page on the internet; it correctly displayed the intranet page.
We currently have a Silverlight application which is hosted in a SharePoint 2010 page. The Silverlight app makes web service calls to a another server on our domain, which has a clientaccesspolicy file in place. We are experiencing cross-domain issues in our production environment.
Users in the farm admin group can use the Silverlight application without any issues. However, all other users recieve the generic cross domain exception when they try to use this app. We have attached Fiddler to the process and noticed that the farm admins are served the clientaccesspolicy file, but that non-admin users are not. In fact, Fiddler does not ever show an attempt to load this file for non-admins.
This only happens in our production environment, which leads me to believe there is a web config or permission setting causing the issue. Unfortunately, I cannot find anything that backs this up.
Has anyone else run into this issue or know if such a setting exists?
See comments above. I had to change the URL to use the full machine name i.e. from webserver/service.svc to webserver.domain.com/service.svc. It solved the problem but doesn't answer the question about why the farm admins could access it. vorrtex's response is the best possible explanation I have seen so far.