I work in a very large, bureaucratic organization and I'm trying to pitch a simple (local) web interface to my team. Given extensive firewall and domain security, I am wondering if this is even possible.
My question is: From a network security perspective, what might prevent IIS from allowing connections from other users on my network?
I believe IIS uses port 80 for default traffic, but it isn't listed as "Listening" when I run netstat -a through command prompt. I do have other ports listening but my fear is they are strictly monitored. Our organization also restricts connectivity between users to shared directories, so I'm wondering if that impacts anything like Windows Authentication in IIS.
I have very little network security experience so thank you in advance to anyone who can shed some light on this!
what might prevent IIS from allowing connections from other users on my network?
local firewall (GPO)
more GPOs regarding IIS or services in general
switch ACLs
switch port privacy
firewall rules
If your company has a network service policy you shouldn't try to circumvent it. It might put your job in danger.
Related
I've been trying to setup my Azure Network security group to accept connections to my Octopus Tentacle, but with no success.
I know the Tentacle is properly working because I can connect using localhost, all that's left is to be externally available.
Could anyone shine a light on the necessary rules at the Network security group? Find below my own rules.
Kind regards and thanks in advance!
Open Windows Firewall on your VM. And add an allowed access for
"10933" TCP port. (10933 the default port between Octopus server and tentacle)
If your Octopus Server and tentacle are not on the same Azure
resources and still couldn't telnet the Tentacle, You must add an "Inbound
security rule" for the same 10933 TCP port which used by your VM's
network security group.
Optional:You should give a static IP and domain name to your VM on Azure. Your Network admin should configure it a IP restricted access.
For testing the connectivity. You should use "telnet client". Open cmd and write this. If there is no connection error/timeout it's working .
telnet yourtentaclesextrenalIPaddress 10933
You should add the endpoint and firewall settings on your virtual machine firewall (not the Azure you mentioned). This is the official tutorial on how to set up the Tentacle. Also take a look if your OS you want to launch Tentacle on is supported (the same link).
One of our client wants to do port forwarding to the crm server , so that users can access the crm from Internet. They are using ZyXel firewall (for port forwarding).
They have mapped 203.xx.xx.xx(public ip) to 192.Xx.xx.xx(local ip) with incoming and outgoing port 5555(default port of our crm server), but it doesn't work. Any suggestions?
I tried to map for rdp and sql report server(web server), these things are able to access.
I have been stuck with this more than a day. Can anyone please help
It's more common to see full IFD implementation with crm 2011, since SSL allows for more security. I do think it's possible to configure CRM to work with just regular port forwarding though, although I have never done it myself.
Take a look here: http://www.mscrmguru.com/2013/05/exposing-microsoft-dynamics-crm-2011.html
Examples of software that can be used for port forwarding includes
Microsoft Forefront Treat Management Gateway (TMG) and Microsoft
Forefront Unified Access Gateway. Basically what it comes down to is
the following:
The user enters an internet address e.g. http://crm.mycompany.com.au
The internet address is recognised and points to the external
registered IP address e.g. 162.123.123.11
The external IP address is redirected to your internal IP address
through your reverse proxy / tunnelling / port forwarding e.g.
10.0.0.10
The user enters username and password and gets authenticated.
The Microsoft Dynamics CRM 2011 pages is displayed to the user.
Finally I solved the issue by binding port 80 to the crm website in IIS. Not sure why 5555 port didnt work, even though the port is opened in the firewall.
You have to add a corresponding Policy Control to pair with the corresponding NAT rule otherwise when the NAT / port forwarding rule is applied, it will be directed to the stateful packet inspection part of the device controlled by the Policy Control rules and be dropped from that point forward.
Policy Control is found by selecting the Configuration menu option (looks like two yellow gear or cogs whatever you call them), then selecting Security Policy, then Policy Control.
The rule structure is similar to NAT, except on this screen you permit or deny traffic based on ZONES that maps to any physical or logical interface configured. In most cases, you want to permit port 5555 traffic coming from the WAN zone from ANY IP address, to the LAN, DMZ or VLAN zones to the IP of the host or object configured in the ZyXEL firewall.
You'll want to ensure that port 5555/TCP or 5555/UDP, whichever is applicable to permit, is configured as a Service Object under the Configuration->Object->Service menu.
Configuring the service before will allow easy setup afterwards when setting your NAT and policy rules, because you'll be able to select the new service object instead of entering ports only. It's also required to set a service object anyways for all Policy Routes.
It feels like the work has been done twice, but NAT and Policy Routes are two different things that have to be configured to allow most kinds of non-standard traffic. You admin might have had an easier time configuring other rules such as HTTP, FTP, SMTP and various common services, because the firewall has built-in objects for those services, which makes configuring rules for services running non-standard high-range ports a little but more tricky.
we are in the process of obtaining for a PCI Level 1 and I'd really appreciate if anyone can help shed some light on the PCI-DSS 1.3.3 & 1.3.5 requirements which states:
1.3.3 - "Do not allow any direct routes inbound or outbound for traffic between the Internet and the cardholder data environment"
1.3.5 - "Restrict outbound traffic from the cardholder data environment to the Internet such that outbound traffic can only access IP addresses within the DMZ."
Right now, we are utilizing a Juniper SRX firewall and have webservers in DMZ, with mysql db servers in Trusted.
For Trusted, we just finished locking down all egress to public and had to setup a proxy server in DMZ that grabs updates (yum, clamav, waf-rules, etc ...) to get the updates from.
But we didn't really expect DMZ to also require a complete lockdown of egress as we've done on Trusted. And I do find this a bit of a challenges (unless I'm mistaken) to do an egress lockdown on DMZ, as our proxy also lives there and needs an outbound access to public for grabbing updates and what not. Whitelisting them via IP's are challenging because 3rd party vendors have ever-changing IP's.
So my question is, just exactly how much "restriction" is required? For our Trusted, we have a "deny-all" egress and a whitelist of select IP addresses that it can access. Does DMZ also require this? Or can DMZ just have "deny-all" based on ports, which would make things a lot easier, as we won't have to worry about ever-changing IP addresses of mirrors and 3rd party services.
I found some proxy appliances that does intelligent filtering based on "host names", (in other words, dynamic IP whitelisting) but they do seem to cost quite a bit of money.
As you can see, I'm looking for some answers, our auditor isn't much of a help, he just says it needs to be locked down. If anyone here have experience with PCI auditing, I'd love to hear what you have to say.
If you have restricted inbound and outbound access to your DMZ and there is no direct access from the DMZ to the Internet then you have met the requirements.
By using a proxy, most QSAs will agree that you have removed the direct access. If there are services for which proxies aren't available then you could either remove them from the same DMZ as the cardholder data environment (e.g. if they are not part of the immediate service) or discuss this with your QSA. It's possible you will need to implement compensating controls or look at other creative solutions.
You will need to convince your QSA that these are legitimate relaxations to the restrictions. This is really something where they should be able to look at your documentation and implementation and give you a straight yes or no.
As with many of the PCI requirements there is flexibility in the interpretation. You can find more about the intent of each requirement in this document: https://www.pcisecuritystandards.org/documents/navigating_dss_v20.pdf
I understand that AWS/EC2 security groups are just like a firewall. But can I ask:
How is this implemented, for you Amazon insiders? Is it software or a hardware device that's off-the-shelf?
What happens within EC2. For example, does the security group stop me from flooding a competing website's HTTP address from within the EC2 environment, by using their private IP address? Can I access their RDP connection on the private address?
Since no one has answered yet - I'll give it a go - I'm not an AWS 'insider' but we have built a cloud management platform on top of it - so we have some experience.
A security group is the same effect as a firewall, and even in some of Amazon's documentation they refer to it as a firewall - but you don't get the same level of control as you would with your own s/w or h/w device - you just get a level of security rule setting functionality.
In a previous business we did something similar for our shared services, and basically it was some hefty hardware firewalls that we admin'd but gave users the ability to set some basic rules for their VM's. I believe AWS is pretty much the same. They have the POWER and the user has LOCAL VM control.
Hopefully someone from Amazon will see this and shed more light for you!
-Ed, digitalmines.com
I've just put my new server up on an IP address with a domain pointing to it. I need to be able to remote admin it. I've opened the firewall for Remote Desktop and HTTP traffic. Is this going to be secure enough? I guess I should probably rename the administrator user...
The absolute minimum you should do is change the Remote Desktop port, change the Admin username, and have a very strong admin password.
Should be sufficient, as long as you use a crazy-complex password for the admin account, and make sure your http server is security-patched and up-to-date.
Also, I hope firewall != Windows Firewall.
Edit: +1 for EHaskin's suggestion of changing RD port, if only to reduce the bruteforce spam that your FW will have to endure, but never think that security == obscurity.
Any chance you can set up your server as a VPN endpoint? Then you would only have the VPN ports and the HTTP ports open. When you want to RDP to the server, you would connect to the VPN first and then you're good to go.
Only reason is, if my memory serves me right, RDP traffic is not encrypted.
This is how I run my IIS server at home, works very well.
Windows Server 2008 supports VPN capabilities. You can configure your remote access policies by using the Network Policy and Access Services. I believe this needs to be installed as a role before you can use it. Also, simply changing the RDP port on your firewall will not prevent an experienced hacker from still getting to your server. A simple port scan would reveal open ports.