My organisation produces a suite of Windows applications that make use of networking, and so when users run our software for the first time, the Windows Firewall (if it is running) brings up a pop-up, informing the user that our app(s) are trying to use the network, prompting the user to allow or deny access.
This occurs with plenty of other apps (Spotify, to give one example), but ee'd like to prevent these popups from happening, as they can be a bit problematic for our users. Some Applications (MSN Messenger, GoogeTalk) operate without ever causing the Firewall to alert the user, and we'd like to do the same.
We've successfully done this on Windows XP by having our installer write appropriate registry keys at:
HKLM\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List
However, this does not have the same effect on Windows 7 - the Firewall popups still take place.
Any ideas how we can do this? (Our installers and software are all digitally signed.)
Thanks
Tom Davies
You can add exceptions to Windows Firewall by shelling out to netsh, a utility built into Windows, but the utility works differently on Windows XP and Windows 7. Here are the commands I used:
Windows XP:
add:
netsh firewall add allowedprogram mode=ENABLE profile=ALL name=[exception name] program=[program path]
remove:
netsh firewall delete allowedprogram profile=ALL program=[program path]
Windows 7:
add:
netsh advfirewall firewall add rule action=allow profile=any protocol=any enable=yes direction=[in|out] name=[exception name] program=[program path]
remove:
advfirewall firewall delete rule profile=any name=[exception name]
I actually advise against making this an installer issue for several reasons:
There are multiple software firewalls
out there; you can't code and test
for all of them.
Some (such as the built-in windows
firewall ) have API's that won't
allow you to configure port
exceptions when the FW is disabled.
If the user later enables the FW you
are hosed again.
There could be external firewalls
that still get you.
Instead I prefer to make this a documentation effort so that users and administrators are fully aware of the networking requirements. I once had to goole Apple's website to figure out what ports iTunes needed and I swear to God they made it really hard to find as they tried to soften everything up for consumers.
However, if you want to give it a best faith effort in the install, WiX has a Custom Action extension for interacting with the firewall rather then writing your own Custom Action. Even if you are using another tool such as InstallShield, you can wrap this behavior up in a WiX merge module and then consume it with your primary tool of choice.
You can read about it here at:
Joy Of Setup Blog
and
WiX Documentation
In your installer (i.e. as elevated admin), you need to write code to access the Windows Firewall APIs and add your app as an exception
Related
I am trying to write an Internet Connection Sharing app using the Windows INetSharingManager API. However, I must right-click and Run as Administrator for INetSharingManager::get_EnumEveryConnection to return any connections. Unless I run my app with admin rights, the network sharing is not that useful, because while I can share a wireless network, it will have no connection to the Internet. Furthermore, using Run as Administrator (or the manifest code to force this when launching my app) at all is not an option for me; I must do this without needing to elevate my app. (The reason for this is because I am targeting the Windows Store through "Project Centennial", and Centennial does not allow apps to elevate as far as I know.) Does anyone know a way I enumerate the network sharing connections without needing UAC admin rights?
UAC can't be disabled programmatically (There are some hacks but i recommend not using them). The best solution is, on detecting UAC, direct users the way they can disable UAC Settings.
Changing UAC settings programmatically on the users machine is not recommended.
Like some cyber coffee applications that disables the user ability to use any other application but only the ones started inside that cyber admin application panel, I searched the Internet for some way of doing it in Delphi:
Remove the Windows Task bar;
Disable the Alt+Tab function;
Disable the Task Manager;
Be able to do/undo that changes in a configuration panel.
These needs are for keeping users from downloading viruses and making changes to Windows configuration or even play games, if it is the system administrator's preference. The own program would serve as a container for authorized applications to run inside then as if it were a MDI application. That is already working
Of course that the system manager will have the options to disable that or revert.
Is there a way to make those four configurations in run-time with Delphi XE3?
I'm not familiar with Delphi. I'm also not sure if it is possible during run-time. But you could do the following:
Write to the registry to prevent alt-tab see this.
Again write to the registry to disable Task Manager see this.
Sounds like you can disable the task bar too by the registry see this.
On your control panel have options and when they hit save, save and restart the computer.
This is provided that Delphi can write to the registry (I believe C# and C++ can). If not, you could create .reg files and execute those by calling cmd.exe with arguments. This I think will cause some pop-ups though.
Update: You may be able to load in the registry changes without a signing out by killing explorer.exe and then loading it again. This may only load parts of the updated registry though.
I'd suggest booting your hardware into Linux, and then run a Windows virtual machine that is as locked down as possible using the existing kiosk mode security settings in Windows. This VM then runs your MDI application when the VM boots. When the MDI application exists the VM reverts to a snapshot of the known good Windows configuration.
You strip down a Linux OS to include only the bare minimum components needed to host your Windows VM.
I'm assuming your MDI windows will only host applications your organization has written, not arbitrary Windows executables. Otherwise you are asking to re-write Windows itself, which will prove impossible.
I have a WiX installer project where I have added two firewall exceptions as part of the installer by using the WiX FirewallException. This works great when the client machine is using Windows Firewall, but I got a report that a user failed to get the solution running when using Norman's Personal Firewall. Some question regarding this:
Will other firewall products in general respect rules added to the Windows Firewall? If so - is this just an import or will firewall products always respect changes to Windows Firewall rules?
Are there any generic way to add firewall exceptions so that all/many of the firewalls will respect them during an installer such as the Firewall extensions in WiX?
Will usage of netsh result in firewall exceptions getting added to other products than Windows Firewall?
I believe the answer to all of that is no, no and no. This is one of the reasons that I don't even try to do any of this in my installs. I always encourage application development to write systems that don't need massaging of the firewall and/or get the systems engineers to work with documentation to properly document to the end user the networking requirements. I only attempt automagical in the installer if everyone understands it's a best effort attempt and that documentation must be available to assist users in integrating into their custom environment. That and I'm naturally adverse to having my way with users operating system configuration settings without their (true) consent.
Is there any way to programmatically add an .exe file to the exception list for the Windows Vista firewall to allow it to run normally? I'm using VC++.
Yes - if you take a look at the WindowsFirewallAddApp method here, it should give you some ideas how to do it.
I don't know for certain about the Vista firewall, but I would defeinitely excpect that it is a violation of the security of any computer to allow programmatic access to firewall exception lists. I would be very surprised if Windows allowed arbitrary code to fiddle with the Firewall in this way.
The user sitting in front of the computer, or a network administrator setting network wide security policies would be the only two who should be able to do this. Notice that they are both actual people doing the process interactively.
A fresh Windows XP SP3 install does not allow remote WMI access like Windows XP SP2 does.
If I follow the steps in the "How to troubleshoot WMI-related issues in Windows XP SP2" document at http://support.microsoft.com/kb/875605 I'm unable to get SP3 to respond to a remote WMI request.
Every request, even to the built-in Administrator account, a new account in the Administrators group, or even a new account not in the Administrators group but given access to remote DCOM & the WMI namespace as described in the Microsoft document all return error code 0x80070005, Access is denied.
To verify I didn't have a goofy system configuration, I installed a fresh Windows XP SP3 image (using the .ISO image from MSDN) and performed no configuration changes save enabling RemoteAdmin through the Firewall. The Access is denied behavior was seen in this scenario as well.
What changed in Windows XP SP3 to remote DCOM / WMI access and how best to enable it?
It turns out the issue wasn't specific to SP3, but rather the lack of these systems being in a domain.
If XP isn't in a domain then the "Use Simple File Sharing" option, found in the Folder Options control panel applet, works it magic. If this option is enabled (the default) all file sharing connections are done with the guest user credential, but this also is applied to incoming DCOM connections as well.
Disabling this option allows DCOM connections to be verified as expected.
Supposedly SP3 does not check 'Enable Distributed COM on this computer'. Get into Component Services (dcomcnfg.exe) Component Services, Computers. Right click 'My Computer' and go to properties. 'Default Properties' is the tab you want. I have also heard that changing the DTC Logon account to NT AUTHORITY\NetwerkService (note the e instead of an o) will work. You can find this under the MSDTC tab, Security Configuration following the same path to My Computer.
We solved something very similar by using these tricks. Hope this helps.
I'm not sure if RemoteAdmin is the one you need to turn off or not in the firewall.
One suggestion would be to turn off the firewall completely first and try that. If it works, then you know it is the firewall. If this is the case, then I would try adding port tcp 135 directly and try again.
You may also try using telnet [ip address of XP_SP3 machine] 135 and see if you can establish the connection.
Hope this helps.