--- TOP-POST PORTION (more general) --- One thing I love about the LPIC-1 program is that it exposes candidates to _all_ common technologies on a system ... especially useful for troubleshooting. I.e., if one can't figure out why a service isn't accessible, knowing _all_ the common places to look is very useful.
E.g., I consider those with LPIC-1 credentials to be more 'well rounded' for troubleshooting than RHCSA. That's why I look for both ... for Red Hat-centric positions. I.e., if one can't figure out why a service isn't accessible, knowing _all_ the common places to look is very useful. E.g., I've seen lack of knowledge of TCP Wrappers trip people up ... repeatedly. In fact ... one could argue these are at the core Blooms levels for Remembering and Applying for _basic_ service accessibilty. E.g., quite _unlike_ ifup/ifdown which is a static script and can be completely replaced manually with "ip" commands, _either_ not knowing to look at TCP Wrappers _and_ not knowing to check IPTables will very likely prevent a service from being accessible ... at all ... if someone is troubleshooting, and a prior sysadmin used either (or both), that the new sysadmin doesn't know to look for and modify. Mr. Sell hits this point on-the-nose with process-specific (TCP Wrapper library) v. network-specific (kernel Netfilter). --- BOTTOM-POST PORTION (some may take offense being responded to, not my intent at all) -- PREFACE: Playing devil's advocate from _all_ sides ... Marc Baudoin <[email protected]> wrote: > Netfilter is for routers, not for servers. Understand that view is ... - There is no host-based filtering/inspection, just network-based, in an Enterprise - Sysadmins don't need the knowledge to check the built-in level 2-5 host-based filter (Linux Netfilter) A prior sysadmins may have put IPTables rules in place. Again ... insert the "knowing both" argument in my TOP-POST. Justin Keller <[email protected]> wrote: > I also use TCP Wrappers, however I do not think it is essential to 102 > level. A prior sysadmins may have put TCP Wrapper entries in place. Again ... insert the "knowing both" argument in my TOP-POST. Alessandro Selli <[email protected]> wrote: > I think iptables is overkill for most situations (that is, everytime > you're not on the Internet with a public IP) and too complex for LPIC-1. > iptables best fits LPIC-303 (security) stuff. Well, Red Hat considers it 200 level (which is LPIC-1), along with TCP Wrappers. If we're going to correlate, roughly ... - LPI 1xx ~ EX2xx (SysAdmin + select Administration specialties) - LPI 2xx ~ EX3xx (Engineer + select Engineering specialties) - LPI 3xx ~ EX4xx (Architecture Specialties, although x5 of any specialties now = RHCA, no longer just 400-level x5) Red Hat considers both TCP Wrappers _and_ IPTables rules to be mandatory knowledge for entry-level sysadmins. Now, putting Red Hat aside ... All enterprises I've worked in _require_ host-based level 2-5 filtering via IPTables or another solution that manages the Netfilter core of the Linux kernel. Never worked in a single environment that hasn't. It is a finding. Even in environments that are not compliance driven (i.e., not financial, like PCI DSS, or government, like DISA STIG ... let alone CC EAL-4) require host-based firewalls. So, this means junior sysadmins need to be aware. These are _all_ systems _behind_ firewalls, sometimes multiple levels (internal firewalls). Virtually all PenTest solutions test for all sorts of ports and services. I've also seen "vendor appliances" get hit with findings because they don't bother. BTW, in all these environments, there is heavy network-based filtering, intrusion detection, even intrusion prevention. In fact, right now, there is a concerted, industry effort to leverage the detail of auditd for host-based IDS too (although that's another story). Although I agree, that's probably more level 3. Alessandro Selli <[email protected]> wrote: > TCP wrapper is an air-bag. iptables is a jettisonable seat with a > parachute, hydraulic steering devices and landing thrusters. Most people > are best served by the first, which is far easier to master and comprehend > compared to iptables. So ... what's context-enforcing, multi-resource MAC (SELinux) then? ;) I would put it more like ... - TCP Wrappers (program library) are a seat belt, you have to fasten it for the program, but then it 'just works' as designed - IPTables (kernel Netfilter) are an air bag, you just need to open it for a known port, but then it 'just works' as designed - SELinux enforcing is a jettisonable seat with parachute, hydraulic steering devices and landing thrusters ... with the associated man-hours required to keep it running (far more than TCP Wrappers and IPTables) BIAS/NOTE: I work in an environment (over 1,000 instances) where we're all SELinux enforcing, with rare exceptions (virtually none, we usually force them to get an appliance, and that vendor is assigned 100% liability for a compromise and we try to isolate/DMZ them off too). SELinux requires some serious maintenance, but TCP Wrappers and IPTables do not. However, SELinux has all sorts of capabilities neither have, including containing a lot of 0 day exploits -- including several, major ones just this year. As is always said by sustaining engineers on the Grumman F-14, it was the perfect interceptor with long loiter, a good fighter (and reliable once the original TF30 engines were replaced), but had a serious "availability rate" issue as it aged. E.g., ~30h maint per flight hour by the '00s. The F-18, even the SuperHornet with its advanced radar, is much lower (variable geometry is just costly, for starters). I won't touch the F-35A/B/C (don't get me started). SIDE NOTE: In defense of American fighters, latter tranches of the EuroFighter have had similar "maint-hour creep" and the once "low-cost" Saab Grippen now costs a lot more to maintain with the newer, Gen IV+ avionics too. Although there's a rather nice balance with the Dassault Rafale (also don't get me started there, wish the US Navy had it 20 years ago, instead of going with the SuperHornet -- no folding wings required, compact delta wing, lots of fuel and payload, we Americans are too allergic to delta wings). Alessandro Selli <[email protected]> wrote: > TCP wrapper then is process-specific, iptables is packet-ceantric, they are > not intended to cover the same use cases. Say you change in.ftpd service > port to some non-standard one in it's configuration file. > in.ftpd: 192.168.0.0/255.255.0.0 EXCEPT 192.168.1.0/255.255.255.0 > in /etc/hosts.allow is still going to work, > iptables -I INPUT -i eth0 -p tcp --dport ftp -m conntrack --ctstate NEW -j > REJECT > no longer will. BINGO! Winnah! Alessandro Selli <[email protected]> wrote: > I think most people do not use it because they are unaware it is there. > Others do not use it because they believe it's old and useless stuff because > they hear many say so. And yet ... systems may be configured with either ... or both. Seen the frustration first-hand, and I find it within 5 minutes of helping junior admins. - bjs _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
