[prev in list] [next in list] [prev in thread] [next in thread]
List: scap-security-guide
Subject: RE: EXTERNAL: Re: Xinetd, VNC, and TFTP
From: "Albrecht, Thomas C" <thomas.c.albrecht () lmco ! com>
Date: 2015-04-09 21:53:44
Message-ID: C9A4ECF8605EE84C8635B172500B6DFB944F94 () HVXDSP24 ! us ! lmco ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
For what it's worth, I agree with Trevor… the guidance from DISA is that if the \
service isn't needed, turn it off, whether that's TFTP or Apache.
TFTP is small enough that it doesn't require its own STIG like Apache, but there are \
still hardening guidelines for TFTP in the STIG, should you choose to use it. It \
does bug me a bit that there's an explicit call to turn off TFTP in the STIG, but not \
one to turn off Apache. (Sure, the blanket "turn off unnecessary services" is there, \
but that should cover both TFTP and Apache equally, I would think. The current \
manifestation makes it look as though TFTP is somehow worse than apache.)
I don't see TFTP as being any different than using anonymous ftp or unencrypted http, \
as long as the architecture warrants the solution. In all my experience with \
accreditors, they will look at the threat and determine whether they agree on the \
residual risk.
Keep in mind that PXE itself has intrinsic risks if implemented badly, but those \
risks can be reduced with good engineering and architecture practices.
--
Tom Albrecht III, CISSP-ISSEP, GPEN
Information Assurance Engineer Staff
Cyber & Security Solutions Team (CaS2T)
Lockheed Martin Corporation, IS&GS
thomas.c.albrecht@lmco.com
(m) 484-798-0109
(w) 610-354-7424
From: scap-security-guide-bounces@lists.fedorahosted.org \
[mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trevor \
Vaughan
Sent: Thursday, April 09, 2015 5:37 PM
To: Steve Grubb
Cc: SCAP Security Guide
Subject: EXTERNAL: Re: Xinetd, VNC, and TFTP
VNC is not universally needed, I'll definitely agree on that one. But, I haven't seen \
many environments that *don't* use some sort of GUI forwarding, be it X (horrible, \
no), VNC, NXMachine, or something.
Sometimes you just need an app "over there" and a SOCKS proxy won't cut it.
But...how do you kickstart your systems from DHCP and/or update your network devices \
that only speak tftp?
Reference: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/chap-installation-server-setup.html
I cry foul on the fewer daemons make the attack surface smaller as I like risk \
analyses with my mandates.
Xinetd *is* actually a security layer providing services for daemons that cannot be \
otherwise easily protected. Sure, it can be abused by a reckless admin, but what \
can't? Look at what some of the cloud services do with iptables and turning \
everything into forwarding routers!
Yes, there are CVEs against xinetd, there are also CVEs against well, pretty much \
everything, and until another *vendor supported* solution exists, we need to use what \
is in the docs.
Thanks,
Trevor
On Mon, Apr 6, 2015 at 3:16 PM, Steve Grubb <sgrubb@redhat.com> wrote:
On Monday, April 06, 2015 03:02:20 PM Trevor Vaughan wrote:
> Hi All,
>
> Since the new-ish (6 and 7) guides indicate that xinetd should be disabled,
> what is the preferred method for running VNC and TFTP sessions to a host?
>
> The tftp-server package installs the /etc/xinetd.d/tftp file but could
> certainly drop an init script/systemd script with associated sysconfig file.
>
> The VNC one is a bit more difficult since it gets difficult to have dynamic
> SSH-based terminals without something like xinetd (or, again, a highly
> configurable init script).
>
> I know this falls under the "if you need it, use it" category
I'd say this is still the case. Tfpd and vnc are not universally needed. I
think the aim is to reduce root running daemons (xinetd) in the common use
case so that the attack surface is smaller. In your situation on RHEL6,
install xinetd if you need it. In the case of RHEL7, systemd socket activation
should work (should even be shipped that way).
-Steve
> but I was
> wondering if there were 'more compliant' alternatives that didn't involve
> epic amounts of work and/or maintenance and that stuck within the RHEL
> software stack.
>
> Thanks,
>
> Trevor
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
[Attachment #5 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:x="urn:schemas-microsoft-com:office:excel" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type \
content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 \
(filtered medium)"><style><!-- /* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div \
class=WordSection1><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>For what \
it's worth, I agree with Trevor… the guidance from DISA is that if the service \
isn't needed, turn it off, whether that's TFTP or Apache. <o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> TFTP is \
small enough that it doesn't require its own STIG like Apache, but there are still \
hardening guidelines for TFTP in the STIG, should you choose to use it. It does bug \
me a bit that there's an explicit call to turn off TFTP in the STIG, but not one to \
turn off Apache. (Sure, the blanket "turn off unnecessary services" is there, but \
that should cover both TFTP and Apache equally, I would think. The current \
manifestation makes it look as though TFTP is somehow worse than \
apache.)<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I don't see \
TFTP as being any different than using anonymous ftp or unencrypted http, as long as \
the architecture warrants the solution. In all my experience with accreditors, they \
will look at the threat and determine whether they agree on the residual \
risk.<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Keep in \
mind that PXE itself has intrinsic risks if implemented badly, but those risks can be \
reduced with good engineering and architecture practices.<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><b><span \
style='font-size:10.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-- \
<o:p></o:p></span></b></p><p class=MsoNormal><b><span \
style='font-size:10.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Tom \
Albrecht III, CISSP-ISSEP, GPEN<o:p></o:p></span></b></p><p class=MsoNormal><span \
style='font-size:10.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Information \
Assurance Engineer Staff<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:10.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Cyber & \
Security Solutions Team (CaS<sup>2</sup>T)<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:10.0pt;font-family:"Calibri","sans-serif";color:black'>Lockheed \
Martin Corporation, IS&GS <o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:10.0pt;font-family:"Calibri","sans-serif";color:black'><a \
href="mailto:thomas.c.albrecht@lmco.com">thomas.c.albrecht@lmco.com</a><o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:10.0pt;font-family:"Calibri","sans-serif";color:black'>(m) \
484-798-0109<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:10.0pt;font-family:"Calibri","sans-serif";color:black'>(w) \
610-354-7424<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><b><span \
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span \
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> \
scap-security-guide-bounces@lists.fedorahosted.org \
[mailto:scap-security-guide-bounces@lists.fedorahosted.org] <b>On Behalf Of \
</b>Trevor Vaughan<br><b>Sent:</b> Thursday, April 09, 2015 5:37 PM<br><b>To:</b> \
Steve Grubb<br><b>Cc:</b> SCAP Security Guide<br><b>Subject:</b> EXTERNAL: Re: \
Xinetd, VNC, and TFTP<o:p></o:p></span></p><p \
class=MsoNormal><o:p> </o:p></p><div><div><div><div><div><p class=MsoNormal \
style='margin-bottom:12.0pt'>VNC is not universally needed, I'll definitely agree on \
that one. But, I haven't seen many environments that *don't* use some sort of GUI \
forwarding, be it X (horrible, no), VNC, NXMachine, or \
something.<o:p></o:p></p></div><div><p class=MsoNormal>Sometimes you just need an app \
"over there" and a SOCKS proxy won't cut it.<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal \
style='margin-bottom:12.0pt'>But...how do you kickstart your systems from DHCP and/or \
update your network devices that only speak tftp?<o:p></o:p></p></div><p \
class=MsoNormal style='margin-bottom:12.0pt'>Reference: <a \
href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/In \
stallation_Guide/chap-installation-server-setup.html">https://access.redhat.com/docume \
ntation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/chap-installation-server-setup.html</a><o:p></o:p></p></div><div><p \
class=MsoNormal style='margin-bottom:12.0pt'>I cry foul on the fewer daemons make the \
attack surface smaller as I like risk analyses with my mandates.<br><br>Xinetd *is* \
actually a security layer providing services for daemons that cannot be otherwise \
easily protected. Sure, it can be abused by a reckless admin, but what can't? Look at \
what some of the cloud services do with iptables and turning everything into \
forwarding routers!<br><br>Yes, there are CVEs against xinetd, there are also CVEs \
against well, pretty much everything, and until another *vendor supported* solution \
exists, we need to use what is in the docs.<o:p></o:p></p></div><p class=MsoNormal \
style='margin-bottom:12.0pt'>Thanks,<o:p></o:p></p></div><p \
class=MsoNormal>Trevor<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Mon, Apr 6, 2015 at \
3:16 PM, Steve Grubb <<a href="mailto:sgrubb@redhat.com" \
target="_blank">sgrubb@redhat.com</a>> wrote:<o:p></o:p></p><p class=MsoNormal>On \
Monday, April 06, 2015 03:02:20 PM Trevor Vaughan wrote:<br>> Hi \
All,<br>><br>> Since the new-ish (6 and 7) guides indicate that xinetd should \
be disabled,<br>> what is the preferred method for running VNC and TFTP sessions \
to a host?<br>><br>> The tftp-server package installs the /etc/xinetd.d/tftp \
file but could<br>> certainly drop an init script/systemd script with associated \
sysconfig file.<br>><br>> The VNC one is a bit more difficult since it gets \
difficult to have dynamic<br>> SSH-based terminals without something like xinetd \
(or, again, a highly<br>> configurable init script).<br>><br>> I know this \
falls under the "if you need it, use it" category<br><br>I'd say this is \
still the case. Tfpd and vnc are not universally needed. I<br>think the aim is to \
reduce root running daemons (xinetd) in the common use<br>case so that the attack \
surface is smaller. In your situation on RHEL6,<br>install xinetd if you need it. In \
the case of RHEL7, systemd socket activation<br>should work (should even be shipped \
that way).<br><span style='color:#888888'><br><span \
class=hoenzb>-Steve</span></span><o:p></o:p></p><div><div><p class=MsoNormal \
style='margin-bottom:12.0pt'><br><br>> but I was<br>> wondering if there were \
'more compliant' alternatives that didn't involve<br>> epic amounts of work and/or \
maintenance and that stuck within the RHEL<br>> software stack.<br>><br>> \
Thanks,<br>><br>> Trevor<o:p></o:p></p></div></div></div><p \
class=MsoNormal><br><br clear=all><br>-- <o:p></o:p></p><div><p \
class=MsoNormal>Trevor Vaughan<br>Vice President, Onyx Point, Inc<br>(410) \
541-6699<br><a href="mailto:tvaughan@onyxpoint.com">tvaughan@onyxpoint.com</a><br><br>-- \
This account not approved for unencrypted proprietary information \
--<o:p></o:p></p></div></div></div></body></html>
["smime.p7s" (application/pkcs7-signature)]
[Attachment #7 (unknown)]
--
SCAP Security Guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic