|
Bugzilla – Full Text Bug Listing |
| Summary: | yast2-ldap configuration SLP scan doesn't warn on closed firewall port | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Jan-Christoph Bornschlegel <jcborn> |
| Component: | YaST2 | Assignee: | Jiří Suchomel <jsuchome> |
| Status: | RESOLVED FEATURE | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Enhancement | ||
| Priority: | P5 - None | CC: | jsuchome, lnussel, locilka, meissner, security-team |
| Version: | RC 3 | ||
| Target Milestone: | --- | ||
| Hardware: | 64bit | ||
| OS: | Other | ||
| See Also: | https://fate.suse.com/301134 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | YCP code | ||
|
Description
Jan-Christoph Bornschlegel
2008-06-18 12:52:08 UTC
AFAIR there either is a open feature to enable SLP browsing though firewall or already finished one. Is that true? If yes, what API could I use from SuSEFirewall? Frankly the current support is not really developer-friendly. At first you have to define/add a rule to accept broadcast-reply: list <string> ruleset = SuSEFirewall::GetServicesAcceptRelated (zone); SuSEFirewall::SetServicesAcceptRelated (zone, items); And then define/add a kernel module that supports it: SetFirewallKernelModules (list <string> k_modules) (In this case it should be "nf_conntrack_netbios_ns") Hmm, I've checked it again. You don't need to take care about the kernel modules, SuSEFirewall does it in the Write() function, see function CheckKernelModules(). So, could you create some nice function which could be called from outside? :-) Note that for one SLP search, I do not want to save any firewall settings, I would only like to make it temporary available for something like "[ ] Retry SLP search without firewall restrictions" Ok, there would need to be 2 functions, first for opening it and second to bringing firewall to previous state. We actually can't have any temporary firewall settings, the only possibility is to change the firewall, restart it, do the search, change the firewall back and restart it again. * Export * Change Settings (SetServicesAcceptRelated) * Write * Proceed SLP Search * Import * Write This sounds like a nice idea for someone's ITO as it would probably need a new YCP module not to spoil the current (already overfilled) SuSEFirewall one with such a specific stuff. ;) Let's discuss it on YaST-devel mailing-list first... Keeping NEEDINFO on myself. Even now I can do
if (SuSEFirewall::IsStarted ())
{
SuSEFirewall::StopServices ();
(new SLP search)
SuSEFirewall::StartServices ();
}
The only thing I'm asking for is providing one function for
Export + Change Settings + Write (+ Stop)
and one for
Import + Write (+ Start)
Or, just provide one function for "Change Settings" part (I mean nicer that proposed in comment 2) and the rest I can do inside yast2-ldap.
Created attachment 223418 [details]
YCP code
According to yast-devel, no new SuSEFirewallSpecialFunctions module is going to be added. This is a special case which doesn't need to be generalized.
See attached file, it should do what you want.
Nice, but it doesn't actually work. Or does it, for you? The code works :) But SuSEfirewall2 doesn't seem to actually ACCEPT those packets. What config do you expect to work exactly? Sounds like you are trying to accept RELATED slp packets. You can configure that but since there is no kernel module that actually marks them as RELATED the config has no effect in practice. nf_conntrack_netbios_ns only works for netbios aka samba. Your plans sound pretty horrible anyways. Silently adding rules that accept RELATED packets everywhere defeat the purpose of having that configurable in the first place. Rather than trying to add random holes into the firewall check the firewall settings for unprotected zones instead. If there are none (resp no interfaces configured for the unprotected zones) chances are good that SLP won't find anything. Just a note, the plan was not adding anything silently, but after a popup question ("Retry the search with firewall settings modified?") and after the action, original setting would be restored.
Seems like we are heading for a INVALID/WONTFIX resolution...
Marcus has marked feature >>#301134: Configure firewall to accept bcast replies<< as a duplicate of >>#300970: Firewall support for SMB browsing<< this way: "Actually its a duplicate of 300970, which we support to some degreee in 11.0." It seems that 1.) It wasn't a duplicate 2.) The browsing functionality works for SMB only please comment in FATE if I was wrong there. feature 301134 |