이 섹션은 당신의 새로운 도메인을 위한 보안의 설정을 말할 것이다. 강조될 부분은 바로 유저들에게 있다. 만약 당신의 보안이 너무나 강요되고, 인터페이스가 유저에게 너무 어렵게만 되어 있다면 유저들은 온전한 도메인에 타협하여 자신의 환경을 개발할 것이다. 그런 사태를 피할 가장 최적화된 방법은 가능한한 보안에 있어 투명성을 지향하라는 것이다. 그리고 유저들이 당신의 네트웍에 들어 와서 사이트의 보안 문제로 어려움을 겪을 때 용기를 북돋아주어라. 소위 유연성이라는 것이 중요한 것이다. 나는 보안이 너무나 엄격하여, 유저들이 그들의 외부로 나가기 위한 방화벽을 통한 네트웍 터널을 단순하게 설정할 수 밖에 없을 때를 알고 있다. 이것은 원격 로그인을 허용하는 것 보다는 좋다. 혹은 유저들이 그렇게 하도록 할 수도 있다. 어느쪽을 선택하건 당신의 자유다.
이 섹션은 당신의 네트웍이 외부로부터 공격을 당하거나, 혹은 내부의 스푸핑을 당하는 경우로 보안을 분류한다. 내부의 합법적인 사용자의 공격을 막는 것이 더욱 어렵고 고된 작업을 포함한다. 그리고 구체적인 내용은 이 문서를 넘어서는 것이다.
이 섹션에서 말하려는 보안의문제는 ``적의 있는 라우터''에 대응하기 위한 것이다. 당신의 ISP의 라우터 공급자는 그것을 원격으로 설정, 제어할 수 있는 것일 가능성이 크므로, 관리자의 패스워드를 공급자에게서 얻어 설정한다. 예전에는 라우터의 생산자가 내장한 패스워드(관리자가 패스워드를 잊어버렸을 때를 대비한 응급용.) 가 시스템 크래커에게 알려져 보안의 문제가 생겼었다. 가능할 때 당신은 당신의 보안에 있어 라우터가 어떤 적의 있는 공격을 받음을 가정하여 디자인해야 한다. 그것은, 당신의 공식적인, 혹은 사설 네트웍의 어느 IP를 이용하여 다른 사이트에 패킷을 보냄으로서 누가 그 일을 했는지를 알 수 없게 하는 것이 있다.
이 섹션은 ipchains 기반의 매스커레이딩 설정과, 포워딩, 라우터의 필터링으로 나눈다. 당신은 IPCHAINS-HOWTO 를 먼저 읽는 것이 좋다. 그때 이것을 힌트의 metalab.unc.edu/pub/Linux/docs/HOWTO/IPCHAINS-HOWTO 추가를 위해 읽도록 하자. 그 HOWTO는 매스커레이딩을 지원하는 커널의 컴파일부터, 이진 ipchains 사용의 세부 사항까지 다루고 있다. 당신은 외부 IP를 가진 어떤 컴퓨터도 방화벽으로서 할 수있다.
사설 네트웍 게이트웨이 머신을 가정하고 당신의 스타트업 스크립트를 체크하라.:
ipchains 기반의 방화벽에서 일반적인 문제는 당신의 룰대로 도착하는 루프백 인터페이스에서의 패킷들의 정정에 대한 권태 혹은 외부 혹은 내부에서의 방화벽 도착에 관한 것이다. 이런 지역적인 패킷은 방화벽에 의해 블록화된다. 아주 자주, 이런 작업은 방화벽의 어플리케이션이 방화벽의 호스트에서 돌고 있는 동안 집어내는 설정에 의해 설정산탄총 디버깅식 접근에 의한 소트에 의해 수리된다. 불운하게도 이런 것들의 방화벽에서의 결과는 의미없어지는 구멍이 된다. ipchains와 함께 이런 것은 방화벽의 스크립트를 디버깅이 용이하도록 쓰고 많은 패킷 소스 문제를 살펴보는 것으로 해결할 수 있다. 이것은 /sbin/firewall.sh 스크립트의 샘플이다.:
#! /bin/sh
#
# New firewalling script using IP chains. Creates a filtering router
# with network masquerading.
#
# define a few variables
IPCHAINS=/sbin/ipchains
LOCALNET="192.168.1.0/24" # the private network
ETHINSIDE="192.168.1.1" # fred.example.com's private IP #
ETHOUTSIDE="10.1.1.9" # fred.example.com's public IP #
LOOPBACK="127.0.0.1/8"
ANYWHERE="0/0"
OUTSIDEIF=eth1 # fred.example.com's private interface
FORWARD_PROCENTRY=/proc/sys/net/ipv4/ip_forward
#
# These two commands will return error codes if the rules
# already exist (which happens if you run the firewall
# script more than once). We put the commands before "set -e"
# so that the script doesn't abort in that case.
$IPCHAINS -N outside
$IPCHAINS -N portmap
set -e # Abort immediately on error setting
# up the rules.
#
# Turn off forwarding and clear the tables
echo "0" > ${FORWARD_PROCENTRY}
$IPCHAINS -F forward
$IPCHAINS -F input
$IPCHAINS -F output
$IPCHAINS -F outside
$IPCHAINS -F portmap
#
# Masquerade packets from within our local network destined for the
# outside world. Don't masquerade packets which are local to local
$IPCHAINS -A forward -s $LOCALNET -d $LOCALNET -j ACCEPT
$IPCHAINS -A forward -s $ETHOUTSIDE -d $ANYWHERE -j ACCEPT
$IPCHAINS -A forward -s $LOCALNET -d $ANYWHERE -j MASQ
#
# Set the priority flags. Minimum delay connections for www, telnet,
# ftp, and ssh (outgoing packets only).
$IPCHAINS -A output -p tcp -d $ANYWHERE www -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE telnet -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE ftp -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE ssh -t 0x01 0x10
#
# Anything from our local class C is to be accepted, as are
# packets from the loopback and fred's external IP.
$IPCHAINS -A input -s $LOCALNET -j ACCEPT
$IPCHAINS -A input -s $LOOPBACK -j ACCEPT
$IPCHAINS -A input -s $ETHOUTSIDE -j ACCEPT
# We'll create a set of rules for packets coming from the big, bad
# outside world, and then bind all external interfaces to it. This
# rule will be called "outside"
#
# We also create a "portmap" chain. The sockets used by daemons
# registered with the RPC portmapper are not fixed, and so it is
# a bit difficult to set up filter rules for them. The portmap
# chain is configured in a separate script.
#
# Send packets from any outside interface to the "outside"
# rules chain. This includes the $OUTSIDEIF interface and any
# ppp interfaces we create for dialout (or dialin).
$IPCHAINS -A input -i ${OUTSIDEIF} -j outside
$IPCHAINS -A input -i ppp+ -j outside
##################################################
#
# Set up the "outside" rules chain #
#
##################################################
#
# Nobody from the outside should claim to be coming from our localnet
# or loopback
$IPCHAINS -A outside -s $LOCALNET -j DENY
$IPCHAINS -A outside -s $LOOPBACK -j DENY
#
# No packets routed to our local net should come in from outside
# because the outside isn't supposed to know about our private
# IP numbers.
$IPCHAINS -A outside -d $LOCALNET -j DENY
#
# Block incoming connections on the X port. Block 6000 to 6010.
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 6000:6010 -j DENY
#
# Block NFS ports 111 and 2049
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 111 -j DENY
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 2049 -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 111 -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 2049 -j DENY
#
# Block XDM packets from outside, port 177 UDP
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 177 -j DENY
#
# Block the YP/NIS port 653
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 653 -j DENY
#
# Don't bother logging accesses on TCP port 80, the www port.
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 80 -j DENY
#
# Accept FTP data and control connections.
$IPCHAINS -A outside -p TCP -s $ANYWHERE 20:21 -d $ANYWHERE 1024: -j ACCEPT
#
# Accept ssh packets
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE ssh -j ACCEPT
#
# Accept DNS packets from outside
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 53 -j ACCEPT
$IPCHAINS -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 53 -j ACCEPT
#
# Accept SMTP from the world
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 25 -j ACCEPT
#
# Accept NTP packets
$IPCHAINS -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 123 -j ACCEPT
#
# Accept no tap ident packets, we don't use them
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 113 -j DENY
#
# Turn off and log all other packets incoming, TCP or UDP, on privileged ports
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE :1023 -y -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE :1023 -j DENY
#
# Check against the portmapper ruleset
$IPCHAINS -A outside -j portmap
##############################################
#
# End of "outside" rules chain #
#
##############################################
#
# Block outgoing rwho packets
$IPCHAINS -A output -p UDP -i $OUTSIDEIF -s $ANYWHERE 513 -d $ANYWHERE -j DENY
#
# Prevent netbios packets from leaving
$IPCHAINS -A output -p UDP -i $OUTSIDEIF -s $ANYWHERE 137 -d $ANYWHERE -j DENY
#
# Turn on forwarding
echo "1" > ${FORWARD_PROCENTRY}
방화벽은 외부에서 들어오는 패킷만을 상대하는 것이 아니라 당신의 내부 네트웍에서부터 나가는 rwho나 netbios 의 네트웍 정보를 담은 패킷들도 감시한다.
미리 말해 두었어야 하는데 포트매퍼의 규칙은 약간 다른다. 그것은 포트매퍼 자신이 기록된 포트매퍼 데몬 기록이 어떤 포트가 열려 있는지를 말하기 때문이다. 특수한 데몬에 의해 사용되는 포트는 당신의 RPC 서비스 사용이 바뀜에 따라 바뀔 수 있거나 혹은 그들의 기동 명령 전환에 따라 바뀔 수 있다. 이와 같은 내용의 스크립트인 /sbin/firewall.portmap.sh 는 포트매퍼 데몬을 위한 규칙을 따르고 있다.
#! /bin/sh
#
ANYWHERE=0/0
IPCHAINS=/sbin/ipchains
$IPCHAINS -F portmap
# Rules for preventing access to portmapped services by people on the outside
#
/usr/bin/rpcinfo -p | tail +2 | \
{ while read program vers proto port remainder
do
prot=`echo $proto | tr "a-z" "A-Z"`
$IPCHAINS -l -A portmap -p $prot -s $ANYWHERE -d $ANYWHERE $port -j DENY || exit 1
done
}
우리는 내부 네트웍에서 적법한 패킷이 날아오는 것을 걱정할 필요가 없으며 포트맵 체인은 오직 외부에서 날아오는 것만을 확인한다.
방화벽 설정 로그는 kern.info와 함께 하는 klogd를 통하여 의심스러운 것들을 기록에 남긴다. 이것은 일반적인 접속 시도에도 마치 스텔스처럼 몰래 살핀다.
자, 우리는 이런 것들을 다 알게 되었다.우리는 시스템이 시작되는 동안 작은 윈도의 약점이 없음을 확신하는 것이 좋다. 그러므로 우리는 우리의 시작 과정을 다음과 같이 설정할 필요가 있다.:
#! /bin/sh
#
# Get the network started, securely
#
#
/etc/rc.d/rc.inet1 # Configure the network interfaces
# and set up routing.
/sbin/firewall.sh || { echo "Firewall configuration failed"
/sbin/ifconfig eth1 down }
/sbin/ipchains -I outside 1 -j DENY # Deny all incoming packets
/etc/rc.d/rc.inet2 # Start the network daemons
sleep 5 # Let them stabilize
# Secure the portmapped services
/sbin/firewall.portmap.sh || { echo "Portmap firewall configuration failed"
/sbin/ifconfig eth1 down }
/sbin/ipchains -D outside 1 # Allow incoming packets
eth1 이 외부로 보여지는 IP를 할당받고 있다고 가정하자. 어떤 ipchains 규칙이 설정에 실패하였다면, 경고 메시지가 뜰 것이다. ``외부의'' 체인은 방화벽의 서비스는 포트매퍼의 서비스가 기동되기 전에는 사용할 수 없는 규칙이므로 네트웍 서비스 데몬이 기동되기 전에는 모든 패킷을 거부할 것이다. 포트맵 서비스가 방화벽의 역할을 하며, 외부의 체인을 재인식하는 것이다.
이 글을 쓰는 시점에서 OpenSSH는 내가 여기 언급하는 특징 중 하나를 제공하지 않는다. 그러나 OpenSSH는 아주 활발히 발전되고 있으므로, 이것은 언제라도 바뀔 수 있는 부분이다. 빠져 있는 까다로운 특징은 당신이 scp, ssh, slogin 등을 rcp, rsh, rlogin 등의 이름으로 바꾸어, rcp, rsh, rlogin 등의 원래의 프로그램이 ssh의 클라이언트 프로그램으로 바뀌어, sshd의 작동 없이는 사용할 수 없게 하는 설정에 관한 것이다. rsh를 사용하며 기원을 하는 대신 ssh 클라이언트 프로그램을 사용하여 사용자들의 보안 문제를 간단히 해결할 수 있는 것이다. 모든 이들의 스크립트로, rdist 설정과 원격의 sshd가 작동하는 원격 사이트에서 수정 없이 작업을 지속할 수 있다. 그러나 데이터는 암호화되어 보내지며 이것이 강력한 확인이 되는 것이다.
웹 사이트 www.ssh.org/에서 ssh1을 구하고, 그것을 컴파일하여 암호화되지 않은 r-프로그램들(rsh, rlogin, rcp 등)과 대체하라. 먼저, 그 세 가지 파일들을 /usr/lib/rsh에 복사해 넣고, ssh 패키지를 다음과 같이 설정하라.:
./configure --with-rsh=/usr/lib/rsh/rsh --program-transform-name='s/^s/r/' --prefix=/usr
설명에 따라 실행 파일을 설치하고 설정한다. 사설 네트웍 게이트웨이에서 sshd 설정은 다음과 같은 엔트리를 정의할 것이다.:
ListenAddress 192.168.1.1 # fred's internal IP
IgnoreRhosts no
X11Forwarding yes
X11DisplayOffset 10
RhostsAuthentication no
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes
당신은 /etc/sshd_config 파일 안에 다른 엔트리를 설정해야만 하게 될 것이다.
그러나 그 필드를 바꾸지 않도록 하자. 당신이 이 파일 안에 당신이 고려할
모든 엔트리를 갖고 있다면, 그 엔트리 파일을 새 파일인 /etc/sshd_config.ext
에 외부의 네트웍을 위해 복사해 넣어라. 새 파일에서 다음 두 개의 필드는
수정하여라. :``ListenAddress''는 사설 네트웍의 IP를 외부로 보여질 수
있는 이름으로 교체하는 것이다. 예를들면 10.1.1.9가 fred.example.com으로
바꾸는 것이 있겠다. 그리고 ``PasswordAuthentication''은 ``no''로 설정해라.
당신의 네트웍을 기동하는 스크립트에서, sshd를 2번 시작하도록 하라. 한 번은
/usr/sbin/sshd
와 같이, 다시 한 번은
/usr/sbin/sshd -f /etc/sshd_config.ext
의 식이다.
이것은 2개의 sshd 데몬을 기동시킨다. 하나는 내부 인터페이스의 로그인 시의 패스워드를 체크하지만 다른 것은 외부 인터페이스에서 RSA키를 누군가가 로그인 하기 전에 포함하게 한다.
다음으로, 내부로 들어오는 telnet과 셸 서비스를 inetd 설정 파일에서 끄도록 한다. 이 부분은 방화벽 설정에 관한 섹션에서 이비 외부에서의 접근을 말할 때 언급한 바 있다. 그러나 이것은 방어에 있어서만 좋은 생각이다. 모든 작업을 순조로이 할 수는 없을 지도 모른다는 뜻이다.
집에서, 혹은 도시 밖에서 로그인을 원하는 사람들은 RSA 키가 필요하다. 그들은 어떻게 해야 할 지 알고 있으며, 그들은 telnetd를 당신의 방화벽상의 평범한 포트에 두는 것과 같은 다른 방법으로 그런 일을 하여 자신의 에너지를 소모하고 싶어하지 않는다.
RSA 키의 생성은 다음과 같은 명령으로 이루어진다.:
ssh-keygen -b 1024 -f new_rsa_key
당신은 패스 페이즈로부터 힌트를 받을 것이다. 이것은 공백이 되어서는
안 될 것이다. 파일 new_rsa_key로 접근하고, 패스 페이즈를 알고 있는 어떤
사람이 모든 RSA 인증 과정을 통과하기 위한 모든 필요 조건을 갖고 있는 것이다.
패스 페이즈는 유추해 낼 수 없는 패스워드이거나 일반적이지 않은 긴 문장
이어야 한다. 파일 new_rsa_key는 플로피 디스크, 랩탑애 복사될 수 있으며
패스 페이즈에 속하여 계정에 로그인하는 사람에 대해 특정한 RSA 키를
허가한다.
특수한 RSA키에 의해 계정에 대한 접근 허가가 이루어지는 설정에서, 가장 단순한 생성은 사설 네트웍 게이트웨이(이 컴퓨터는 로그인 접근을 돌려 보낼 것이다.)에 사용자를 위한 $HOME/.ssh/ 디렉토리를 생성하여 $home/.ssh/authorized_keys 파일 안의 ssh-keygen 명령으로 인하여 생성된 new_rsa_key.pub 를 복사해 넣는 것이다. sshd 매뉴얼 페이지에서 신뢰하는 IP, 혹은 호스트 이름을 가진 곳에서 오는 로그인 요청이나 혹은 외부에서 보내어진, 인증으로 통해 신뢰가 가능한 명령의 경우에서 당신이 추가해 넣을 수 있는 다른 옵션 키들에 관한 설명으로서 나와 있는 ``AUTHORIZED_KEYS FILE FORMAT'' 섹션을 보면 잘 나와 있다. (예를 들자면, RSA 키의 다른 곳으로, 혹은 누군가에게 메일로 보내어 백업하는 경우 등.)
RSA 키 메카니즘을 가능한한 사용자 우선으로 만드는 데 이제 한 가지가 남았다. 만약 어떤 사용자가 한두 번의 과정을 거쳐 패스 페이즈를 알아 내게 된다면, 그는 스스로가 보안의 구멍이 되어 보안상의 문제를 일으킬 가능성을 스스로의 손 안에 갖고 있는 것이다. 리눅스에서, 로그인 쉘은 ssh-agent 기반으로 불러진다. 예를 들어 만약 업무용으로 사용되는 회사의 랩탑에서 실수로 xdm이 실행되어 사용자에게 X 세션의 권한이 넘어가게 된다면, /var/X11R6/lib/xdm/Xsession_0 을 열어 시동될 때 불러지는 다음의 행을 가능하면 다음과 같이 바꾸도록 하라.:
exec "$startup"
이 행을 이렇게 바꿔라.:
exec ssh-agent "$startup"
나의 xdm 설정에서, 그 파일에서 각각의 3줄이 바뀌어졌다. 사용자가 랩탑에
로그인할 때, 그는 다음의 명령을 입력해야만 하는 것이다.
ssh-add new_rsa_key
로그인 프롬프트가 떠서 패스 패이즈를 입력 받아서부터, 사용자가 그의 X
세션을 랩탑에서 종료할 때 까지, 사설 네트웍 안의 모든 윈도에서 패스 페이즈
없이 접근할 수 있기 위해서 해야 할 일이다.
sshd 가 당신의 사설 네트웍상의 모든 컴퓨터에서 외부의 호스트에 대하여 작동하고 있다. 사설 네트웍 상의 것이 아닌 컴퓨터에 대하여 ListenAddress 엔트리를 /etc/sshd_config 안에 ``0.0.0.0''와 같이 설정할 수도 있다. 당신은 다음 명령을 통해 호스트 키를 설정할 수 있다:
ssh-keygen -b 1024 -f /etc/ssh_host_key -N ""
make-ssh-known-hosts를 실행하고 /etc/ssh_known_hosts 파일 안에 사설 및
검증된 네트웍의 모든 컴퓨터를 분류하는 것이다.
암호화되지 않은 r-서비스들과 텔넷의 외부에서 안으로 들어오는 접속을 무력하게 한다. 텔넷의 실행 파일을 지울 것은 없는 것이 이것은 포트 23번 상의 다른 텔넷 세션들보다 유용한 것이니까. 당신은 사설 네트웍 상에서 패스워드를 이용한 인증을 사용하여 외부로부터의 접속을 차단하고 외부의 호스트에서 보내어진 RSA키를 로그에 남길 수도 있다.
이것은 사설 네트웍상의 호스트드이 각각의 /etc/hosts.equiv 파일 상에 기록되어 있을 겅우 사용자들에게 편리한 것이다. sshd 데몬은 그것들에 의해 사람들의 rlogin과 rsh를 컴퓨터들 간에 패스워드나 패스 페이즈 없이 가능하게 한다. 모든 접속에 있어서, 컴퓨터들은 호스트 레벨 RSA 키를 통하여 각각의 동일성을 증명해야만 하는 것이다.
사용자가 외부 네트웍의 IP를 가진 컴퓨터에서부터 사설 네트웍 상의 컴퓨터로 로그인을 하기를 원할 때 다른 것이 나타난다. 당신은 /etc/hosts.equiv 혹은 $HOME/.shosts를 패스워드 인증 과정 없이 이용할 수 없게 된다. 그것은 사용자가 검증되지 않은 IP-이것은 매스커레이딩 된 것일수도, 방화벽일 수도 있지만 호스트 키가 일치하지는 않을 것이다. -를 가진 곳에서 들어 왔기 때문이다. 이에는 두 가지 해법이 있다. 한 가지는 당신이 /etc/hosts.equiv 나 $HOME/.shosts 메소드를 사용할 것을 주장할 경우인데, 이 때는 사용자들이 사설 네트웍에 로그를 남겨야만 할 것이다. 그리고 이 로그는 들어오기를 시도한 외부의 컴퓨터에도 남을 것이다. 다른 방법은 RSA 키 안증을 이용하는 것이다. 그것은 어떤 IP에서 호스트 이름으로 lookup을 시도하는 부주의에도 언제나 작동한다.
많은 유저들이 보안보다는 편리함을 추구하기 때문에 계속 여러 모의 탐색을 해 나가고 있다. 이것은 많은 사람들이 다음과 같이 실행하게 한다.
xhost +
이 명령은 X를 초기화 하는 것이다. 이런 허가를 받은 X서버는 세계의
누구라도 접근할 수 있게 된다. 외부의 어떤 임의의 사용자가 당신의 루트의
윈도 회면을 당신이 지정한 것에서 당신의 상관이 자기 어머니에게 사무실을
구경시켜 주다가 경악하게 할 만한 것으로 바꾸어 놓을 수도 있게 된다는
뜻이다. 이런 외부인은 당신의 모니터를 제어하고 당신의 스크린 상에 띄워지는
내용을 넘겨 볼 수도 있는 것이다. 쓸 데 없는 잔소리지만, 이것은 당신이
다른 사이트의 로그인로서 패스워드를 넘기는 것 혹은 민감한 사안의 문서를
화면에 띄워 수정하는 상황을 생각하면 좋을 게 없는 상황이라는것을 쉽게
알 수 있을것이다. xhost 프로토콜 자신은 본래부터 사용자 기반으로 화면을
사용할 권한을 양도하는 것이 불가능한 한계를 갖고 있고, 오직 기계 기반인
것이다.
xauth 인증에 들어가자. 만약 당신이 xdm 을 가지고 있다면 당신은 아마 이미 xauth 인증을 실행하고 있을 것이디만 xhost가 여전히 돌고 있다. 그리고 아마도 사람들은 컴퓨터 사이에서 X의 프로세스를 사용하고 있을 것이다. 다시 말하자면, 이것의 결론은 사용자들이 xhost 명령을 더 이상 사용하지 않고도 사용하기 쉽게, 보안과 편리함을 함께 누리자는 것이다.
``SSH1 설정'' 섹션에서 ``X11 포워딩'' 을 기본 지식으로 하여 sshd 셋업을 묘사한 것은 xhost 테크닉보다 사용하기 쉬운 것이다. 당신이 당신의 터미널에 접속할 때 당신은 간단히 rlogin으로 원격지 컴퓨터에 들어가 넷스케이프나 xv, 혹은 다른 좋아하는 것들을 $DISPLAY 변수를 조정하거나 접근 권한을 얻지 않고도 사용할 수 있다. ssh 로그인은 사용자에게 투명한 방식으로 설정하고, 각각의 당신의 X 패킷에 관한 암호화는 그들이 네트웍을 떠나기 전까지 지속된다.
만약 당신이 sshd X11포워딩을 어떤 이유로 이용할 수 없다면, 당신은 xauth를 당신이 당신의 X 서버에 접근하기를 제한하는 다른 컴퓨터들에 대한 인증책으로 쓸 수 있다. 사용자를 위한 혹은 특별한 그들을 도울 수 있는 셀 스크립트들이 기술되어 있는 문서들이 있다. ``jpublic'' 컴퓨터상에서는 ``barney''의 당신의 X 서버에 접근하기 위한 관련된 명령으로 다음이 있다.:
/usr/X11/bin/xauth extract - $DISPLAY | rsh -l jpublic barney /usr/X11/bin/xauth merge -
나는 xhost를 당신의 컴퓨터 엔트리에서 지우려는 유혹을 받는 편이다. 만약
그것이 어떤 프로그램에 문제가 된다면 당신은 최소한 그것이 보안에 약한
것이라는 점은 알 수 있는 것이다. 이것은 xauth 시퀀스 리스트를 사용하는
xhost를 위한 되돌려 놓는 셸 스크립트를 작성하는 것으로 충분하다.
rsh이 ssh 프로그램을 암호화 하지 않았을 때, xauth 키는 단순한 텍스트로서 보내질 뿐이라는 점을 기억하자. 그것을 입수한 누구라도 당신의 서버에 접근할 수 있다. 그러므로 당신은 암호화 과정을 위해 ssh를 사용하지 않았다면 더 많은 보안을 기대해서는 안 되는 것이다. 게다가 사용자의 홈 디렉토리가 NFS 로 외부에 노출되어 있다면, xauth 키는 그 누구라도 NFS 패킷을 통해 채어 갈 수 있다는 점을 기억하고 ssh를 당신의 시스템에서 기동시켜야 한다는 것을 생각하자.
서버로 메일이 왔을 때 그것을 어떤 곳에서도 읽고 메일을 보낼 수 있게 한다면 편리할 것이다. 그러나 심심하고 따분한 나머지 못된 짓을 해 보려 서성대는 일반 유저들에 대한 약간의 주의는 기울여야 한다. AUTH_DES 의 실행 없이 NFS를 사용하는 것은 무방비 상태나 다름없다. NFS의 클라이언트 에 대한 신뢰 관계는 접근을 보장하는 것이다. 그것은 서버에서의 패스워드 인증 없이도 클라이언트에서 각각의 개인인 자신의 파일에 접근할 수 있다는 것이다. 윈도의 경우에는 유닉스 식의 파일의 접근 제한을 완벽하게 무시하고 NFS 적인 공유를 어떤 uid 없이도 가능하게 한다. 따라서 NFS는 리눅스 박스 나 유닉스처럼 당신의 즉각 조정이 가능한 하에서만 설정해야 한다. 물론 윈도로 듀얼 부팅이 되는 컴퓨터에도 해선 안 될 것이다. 만일 당신이 메일 스풀 디렉토리나 혹은 어떤 다른 디렉토리를 때때로 윈도 박스로 이용되기도 하는 컴퓨터와 공유하기를 원한다면 그때는 ``security=USER'' 모드에 의해 보안이 입증되는 삼바(samba)를 이용하기 바란다. 당신의 네트웍에 허브로 컴퓨터를 연결하는 것 보다는 스위치 라우터를 이용하는 것도 약간의 장난과 악의로 윈도가 깔려 있는 컴퓨터를 사용하는 사람들을 대비하는 데 도움이 될 것이다. 어쨌건 네트워크 상으로 공유되는 어떤 디스크의 보안을 유지하는 것은 아주 어려운 일이라는 것만 명심하라.
그런데도 정말로 네트웍에 연결된 디스크의 보안을 철저히 하고 싶은가? 대부분 확실한 방어법은 이슈가 된다. 만약 당신이 기밀이 적힌 서류를 책상 위에 두고 나갔을 때 누군가가 사무실에 들어가 그 기밀을 보았다고 하자. 그는 즉시 그것이 어느 정도의 가치가 있는것인지를 생각하고는 그것이 정말 기치 있는 것이라면 인간 본성의 어두운 부분에 따라 책상에 앉아 그것을 읽을 것이다. 만약 그 서류가 파일 캐비닛이나 책상 서랍 속에 들어 있었다면 그것은 분명히 더 어려운 일이었을 것이다. 어떤 단순한 네트웍에서의 보안의 목적은 누구도 우연히 그 보안을 깨게 하지 않는 것에 있다 해도 과언이 아니다.