Re: [HTCondor-users] HTCondor 8.0.3 on Windows workers: firewall rules?

[Stub <spamrefuse@xxxxxxxxx>]

OK, I have done a few more tests regarding what condor is and is not doing to the firewall rules.
See below for more details. In summary:

* An unattended install on Windows gives you no other option than installing a very long list of firewall exceptions for condor.

* The rules installed during the installation are very different from the ones inserted by the daemons.
   (Is this inconsistent, or an intentional policy?)


Here are the results of my tests:

1. For the "unattended install" on Windows (that's what I do!), there's no argument switch to pass to the msiexec installer in order to manipulate the firewall policy, at least not that I know of......
Hence, I concluded that a heavy carpet bombing firewall rules approach is done upon unattended install;
I get these Inbound firewall rules:

condor_c-gahp.exe
condor_c-gahp_worker_thread.exe

condor_collector.exe

condor_credd.exe

condor_dagman.exe

condor_gridmanager.exe

condor_kbdd.exe

condor_master.exe

condor_negotiator.exe

condor_schedd.exe

condor_shadow.exe

condor_startd.exe

condor_starter.exe

condor_vm-gahp.exe


All configured as follows:
Profile: All
Enable: Yes
Action: Allow
Override: No
Program: executable's name in C:\condor\bin\
Protocol: Any
Local port: Any
Remote port: Any
Allowed Users: Any
Allowed Computers: Any



2. In the condor configuration I can set whether or not to let the daemons add firewall rules.
If I use "ADD_WINDOWS_FIREWALL_EXCEPTION = False", then the firewall is not affected, but the long list of condor related firewall rules is the same as immediately after the installation.


3. If I configure condor to modify the firewall rules when the daemons start, using
"ADD_WINDOWS_FIREWALL_EXCEPTION = True" (the default setting, I think), then I get new condor firewall rules ADDED to the already long list:

condor_dagman.exe
condor_kbdd.exe
condor_master.exe
condor_startd.exe
condor_starter.exe
condor_vm-gahp.exe

They have mostly the same settings as the rules from the installation, except:
Profile: Private
Protocol: TCP and UDP (hence each rule appears twice in the firewall list)



4. If I manually delete the condor related firewall rules and restart Condor, then the firewall only has the smaller set of rules (only the ones listed in 3.).

Rob.

==================



On Thursday, October 10, 2013 12:19 PM, Ziliang Guo <ziliang@xxxxxxxxxxx> wrote:
Correct. Because switching between a submission/execute role is fairly
trivial, we take the carpet bombing approach to the firewall rules. In
fact the installer is supposed to be the one that sets the firewall
configuration, since that way the exceptions get removed upon
uninstallation. If HTCondor finds the exceptions missing for some
reason, it will add them itself to be sure. That's what I meant by
saying HTCondor took care of the firewall configuration.


On Wed, Oct 9, 2013 at 10:07 PM, Stub <spamrefuse@xxxxxxxxx> wrote:
> Dear Ziliang Guo,
>
> Thanks for your explanation.
>
> I have checked with Windows 7, what happens when I let HTCondor configure the Windows 7 firewall,
> and I found that your explanation seems to conflict with what HTCondor does to the Windows 7 firewall.....
>
>
> If I have
>    ADD_WINDOWS_FIREWALL_EXCEPTION = False
>
> then obviously the firewall rules are not changed.
>
> However, when I start HTCondor with
>    ADD_WINDOWS_FIREWALL_EXCEPTION = True
> I see the new rules appear in the Windows 7 firewall as described below.
>
>
> The following executables
>
> condor_dagman.exe
> condor_kbdd.exe
> condor_master.exe
> condor_startd.exe
> condor_starter.exe
> condor_vm-gahp.exe
>
> each appear in the Firewall Inbound Rules with the settings:
> Profile: Private
> Enable: Yes
> Action: Allow
> Override: No
> Program: executable's name in C:\condor\bin\
> Protocol: TCP and UDP (hence each rule appears twice in the firewall list)
> Local port: Any
> Remote port: Any
> Allowed Users: Any
> Allowed Computers: Any
>
>
> Does HTCondor set these firewall rules, just to be safe for any type of HTCondor PC; submitter, collector, or worker a-like?
>
> Thanks!
> Rob.
>
> ============================
>
> On Thursday, October 10, 2013 10:10 AM, Ziliang Guo <ziliang@xxxxxxxxxxx> wrote:
> kbdd communicates with the local startd, so unless your firewall is
> even blocking attempts to connect back to the host, you shouldn't need
> it. I believe procd and preen are in the same position so whether you
> add them depends on how strict the firewall is. condor_starter I think
> you will want to add to the firewall exceptions list. condor_dagman if
> I recall correctly runs on the submit node. I don't recall the last
> time a successful usage of vm-gahp on Windows was done here at UW, so
> I'll let others comment. For any others you have questions on, I'd
> suggest looking in the manual, their responsibilities are for the most
> part clearly spelled out. Not that many processes end up needing to be
> run on Windows on an execute node. On the other hand, HTCondor would
> take care of the firewall settings if you were using the default
> Windows firewall.
>
> On Tue, Oct 8, 2013 at 6:33 PM, Stub <spamrefuse@xxxxxxxxx> wrote:
>> Hi,
>>
>> I'm about to install HTCondor 8.0.3 on WIndows worker-PCs in our university library.
>> The library Windows PCs come with a software that does firewallling and virus protection together.
>>
>> Its configuration lets me choose which executables can pass the protection shield.
>>
>> So I must carefully select the HTCondor's exe files that should go in that list
>> (and not forget one, as making changes afterwards is A LOT OF work).
>>
>> The configuration of the Windows workers has following daemon list:
>>  DAEMON_LIST=MASTER STARTD KBDD
>>
>>
>> Then should
>> condor_master.exe
>> condor_kbdd.exe
>> condor_startd.exe
>>
>> be added to the list?
>>
>> What about condor_procd.exe?
>>
>> And what about other executables, that may start when jobs are running on the workers?
>> condor_dagman.exe
>> condor_starter.exe
>> condor_vm-gahp.exe
>> condor_preen.exe
>> ...
>>
>> Thank you!
>> Rob Lahaye.
>>
>> _______________________________________________
>> HTCondor-users mailing list
>> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
>> subject: Unsubscribe
>> You can also unsubscribe by visiting
>> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
>>
>> The archives can be found at:
>> https://lists.cs.wisc.edu/archive/htcondor-users/
>>
>
>
>
> --
> HTCondor Project Windows Developer / NEOS Maintainer
>
>



-- 
HTCondor Project Windows Developer / NEOS Maintainer