.\" Copyright (c) 1998, Matthew Dillon. Terms and conditions are those of .\" the BSD Copyright as specified in the file "/usr/src/COPYRIGHT" in .\" the source tree. .\" .\" %FreeBSD: src/share/man/man7/security. 7, v 1.13. 2.11 2002/04/13 02:04:44 keramida Exp % .\" .\" $FreeBSD: doc/ja_JP.eucJP/man/man7/security. 7, v 1.23 2002/04/28 22:05:39 horikawa Exp $ .Dd September 18, 1999 .Dt SECURITY 7 .Os .Sh 명칭 .Nm security .Nd FreeBSD 에 있어서의 보안 입문 .Sh 해설 보안는, 시스템 관리 책임자와 함께 시작되어, 시스템 관리 책임자와 함께 끝나는 기능입니다. .Bx multiuser 시스템은, 옛날부터의 보안를 얼마 정도는 갖추어 있습니다만, 새로운 보안 기구를 짜넣어 유지해 가는 것으로, 유저를 .Sq 정직하게 계속 하는 일은, 시스템 관리 책임자의 가장 큰 책무의 하나지요. 머신은, 관리자가 설정했을 뿐의 보안 밖에 가리키지 않습니다. 시큐러티에 관한 문제는, 오히려, 편리함을 요구하는 인간과의 경합 문제입니다. 일반적으로, .Ux 시스템은 막대한 수의 프로세스를 동시에 실행시킬 수가 있어 그것도, 서버로서 동작하는 것이 많습니다. 즉, 외부의 누군가가 접속해 와, 서버 프로세스라고 회화할 수가 있다고 하는 것입니다. 어제까지 사용되고 있던 미니 컴퓨터나 메인프레임은, 오늘로는 데스크탑 컴퓨터가 취해 대신해, 게다가, 그것들은 네트워크로 연결해져 인터넷과 접속되게 되었습니다. 이것에 의해, 보안는 옛날과 비교라고 훨씬 큰 문제가 되고 있습니다. .Pp 보안는, 양파의 계층과 같은 접근를 통하면(자) 가장 자주(잘) 실장할 수 있습니다. 간략하게 말해, 하고 싶은 것은, 편리함을 해치지 않는 정도로 할 수 있을 뿐(만큼) 많은 계층을 만들어, 시스템에 침입되어 있지 않은가를 주의 깊게 감시하는 것입니다. 보안의 계층을 너무 만들고 싶지는 않습니다. 너무 만들면(자) , 침입의 검출을 방해할 수 있게 되겠지요. 어떤 보안 기구에서도, 침입의 검출을 하는 것이 유일 매우 중요한 일인 것입니다로부터. 예를 들면, 시스템의 각 바이너리에 .Pa schg 플래그 ( .Xr chflags 1 참조) (을)를 설정하는 것은 그다지 의미가 없습니다. 플래그를 설정하면(자), 일시적으로는 바이너리를 보호할 수가 있습니다만, 침입해 온 크래커가, 머신의 보안 기구가 크래커의 침입을 전혀 검지할 수 없게 되는 것 같은 변경이지만, 관리자가 용이하게 검출할 수 있는 것 같은 변경을 할 수 없게 해 버린다 (으)로부터입니다. .Pp system security에는, 다양한 형태에서의 공격에 대처하는 일도 붙어 돕니다. 공격에는, root 를 찢으려고는 하지 않지만, 시스템을 크래쉬 시키거나 아주 없으면, 시스템을 사용 불능으로 하거나 하려고 하는 것도 포함되어 있습니다. 보안에 관한 문제는, 몇개의 카테고리로 분류할 수가 있습니다. .Bl -enum -offset indent .It 서비스 불능 공격 .It 유저 어카운트에 걸리는 위험 .It 액세스 가능한 서버를 경유한 root 권한으로 걸리는 위험 .It 유저 어카운트를 통한 root 권한으로 걸리는 위험 .It 뒷문의 작성 .El .Pp 서비스 불능 공격이란, 머신으로부터 필요한 자원을 빼앗는 행위입니다. 서비스 불능 공격은, 보통은, 그 머신으로 실행되는 서버나 네트워크 탁을 압도해, 머신을 크래쉬 시키거나 아주 없으면 머신을 사용할 수 있는 없애거나 하는 것 같은 힘맡김 방법입니다. 서비스 불능 공격의 몇개인가는, 네트워크 탁의 버그를 이용해, 패킷 하나로 머신을 크래쉬 시키려고 합니다. 후자는, 커널에 버그 수정을 베푸는 것에 의해서만 수정할 수가 있습니다. 서버 프로세스에 대한 공격은, 옵션을 적절히 지정해, 불리한 상황에 있는 시스템에 대해, 서버 프로세스가 일으키는 부하에 한계를 마련하는 것으로 수정할 수가 있습니다. 이것들에 비하면(자), 네트워크에의 힘맡김의 공격에의 대응은 훨씬 어려워집니다. 예를 들어, 위조 패킷에 의한 공격 .Pq spoof-packet attack (은)는, 인터넷으로부터 시스템을 떼어내는 이외 방법으로 막는 것은 거의 불가능합니다. 거기에 따라, 머신을 떨어뜨려 버릴 수 없을지도 모릅니다만, 인터넷 회선을 가득 채워 버릴 수 있습니다. .Pp 유저 어카운트를 위험하게 쬐어 버리는 문제는, 서비스 불능 공격보다 쭉 자주 있다 문제입니다. 이 시세로도, 스스로의 머신으로 표준의 telnetd, rlogind, rshd, ftpd 서버를 실행시키고 있는 시스템 관리 책임자는 많습니다. 이러한 서버는, 디폴트에서는, 암호화된 connection상에서 동작하고 있지 않습니다. 그 결과, 안고 있는 유저수가 표준 정도이면, 리모트 로그인 (그 시스템에 로그인하려면 가장 보통으로 편리한 방법입니다) 하고 있는 유저 중 한 명 이상은, 패스워드를 들여다 봐 볼 수 있어 끝내겠지요. 시스템 관리 책임자가 주의 깊은 사람이라면, 비록 로그인이 성공하고 있었다고 해도, 원격 접근 로그를 해석해, 의심스러운 소스 주소를 찾는 것입니다. .Pp 한번 공격자가 유저 어카운트에의 액세스권을 입수하면(자), 공격자가 root 의 권한을 찢을 가능성이 있는 것을 가정해야 합니다. 그러나, 보안를 충분히 유지해, 손질이 두루 미친 시스템에 대해서는, 어느 유저 어카운트에의 액세스가 가능해져도, 공격자에게 반드시 root 에의 액세스권을 준다고는 할 수 없는 것이 현실입니다. 이 차이는 중요합니다. 그렇다고 하는 것은, root 에의 액세스권이 없으면, 일반적으로, 공격자는 자신의 침입의 흔적을 은폐 할 수가 없고, 그 유저의 파일을 인나 나무 돌리거나 머신을 크래쉬 시키거나 할 수 있는 것이 탓있고입니다. 유저 어카운트가 위험하게 노출된다고 하는 것은, 매우 잘 일어나는 것입니다. 왜냐하면, 유저는, 시스템 관리 책임자정도로는 미리 주위를 기울이지 않는다 경향이 있기 때문입니다. .Pp 시스템 관리 책임자는, 어느 머신상에서 root 의 권한을 찢는 방법은, 잠재적으로 몇가지나 있는 것이라고 하는 것을 마음 해 두지 않으면 되지 않습니다. 공격자가 root 의 패스워드를 알아 버릴지도 알려지지 않습니다. 공격자가 root 의 권한으로 실행되는 서버의 버그를 찾아내 네트워크로부터 그 서버에 접속해 root 의 권한을 찢을 수가 있을지도 알려지지 않습니다. 한번 유저 어카운트를 찢으면(자), 유저 어카운트로부터 root 의 권한을 찢는 것이 가능하다라고 말하는 버그를 가지는 suid-root 프로그램의 존재를, 공격자는 알고 있을지도 모릅니다. 어느 머신상에서, 공격자가 root 의 권한을 찢는 방법을 알았다고 하면(자), 공격자는, 뒷문을 만들 필요같은 건 없을지도 모릅니다. 발견되어 채워진 root 의 구멍이 많게는, 크래커가 침입한 자취를 지우려고 많이 일한 결과가 포함되어 있습니다. 그 때문에(위해)야말로, 많은 크래커는 뒷문을 만듭니다. 이 뒷문은, 크래커의 검출을 하는데 편리한 방식입니다. 크래커에 뒷문을 만들게 한 없게 한다 그 말은, 보안에 있어서는 실제로는 좋지 않는 것일지도 모릅니다. 왜냐하면, 그렇게 하는 것으로, 크래커가 최초로 침입해 오기 위해서(때문에) 발견했다 보안 홀이 차는 것은 아니기 때문입니다. .Pp 보안를 개선하는 방법은, 항상, .Sq 양파의 쥐치나무 (와)과 같이 복수의 층의 접근로 실장되어야 합니다. 이것들은 다음과 같이 분류할 수 있습니다. .Bl -enum -offset indent .It root 와 스탭의 어카운트의 안전성을 높인다. .It root 의 안전성을 높이는 - root 권한의 서버와 suid/sgid 바이너리. .It 유저 어카운트의 안전성을 높인다. .It 패스워드 파일의 안전성을 높인다. .It 커널의 코어, raw 디바이스, 파일 시스템의 안전성을 높인다. .It 시스템에 대해서 행한, 부적절한 변경을 재빠르게 검출한다. .It 편집광적 방법. .El .Sh root 어카운트와 스탭 어카운트의 안전성을 높인다 root 의 어카운트의 안전성을 확보하지 않는 동안으로부터 스탭의 어카운트의 안전성을 운운 해도 방법이 없습니다. 대부분의 시스템에서는, root 어카운트에 할당한 패스워드가 1 개 있습니다. 우선 최초로 해야 할것은, 이 패스워드는 .Sq 언제라도 위험하게 노출되고 있으면(자) 가정하는 것입니다. 여기에서는, root 의 패스워드를 지워야 한다고 말하는 것은 아닙니다. 패스워드는, 머신에 콘솔로부터 액세스 하는데는, 거의 언제라도 필요한 것입니다. 여기서 말하고 싶은 것은, 콘솔 이외로부터는, 어쩌면, .Xr su 1 명령을 이용해조차 패스워드를 사용할 수 있도록(듯이) 해서는 안되라고 하는 것입니다. 예를 들면, pty 가, .Sq Pa /etc/ttys 파일로 안전하지 않은 것과 지정되어 있는지를 확인해 주세요. 그렇게 하는 것으로, telnet 나 rlogin 넘어로 root 로 로그인할 수 없게 됩니다. sshd 와 같은, 다른 로그인 서비스를 사용하고 있는 경우에서도 같이 직접 root 에 로그인하는 것을 허락하지 않은지 어떤지 확인해 주세요. 액세스 하는 수단, 예를 들면 ftp 와 같은 서비스가, 가끔 크랙의 손에 떨어진다 일을 생각해 보세요. root 에 직접 로그인할 수 있는 것은, 시스템 콘솔 (을)를 통했을 때에만 해야 합니다. .Pp 시스템 관리 책임자로서 자신은 root 가 될 수 있도록(듯이) 해 두지 않으면 안 되는거야 (은)는 물론이기 때문에, 구멍을 몇개인가 비워 둡니다. 그러나, 그러한 구멍을 동작시키려면 , 한층 더 추가의 패스워드 인증이 필요하도록 해 일어납니다. root 로 액세스 가능으로 하는 방법의 하나로서, 적절한 스탭 어카운트를 ( .Pa /etc/group ) 의 wheel 그룹에 가세하는 일이 있습니다. wheel 그룹에 놓여진 스탭 멤버에는, .Sq su (을)를 사용해 root 가 되는 것이 허락됩니다. 패스워드 엔트리에 대해, 스탭 멤버를 wheel 그룹을 두는 것으로, 스탭 멤버에 wheel 의 액세스권을 주어서는 안됩니다. 스탭 멤버의 어카운트는 .Sq staff 에 두어야 합니다. 그리고 .Sq Pa /etc/group 파일을 통해 wheel 그룹에 가세해야 합니다. 실제로 root 액세스의 필요한 staff 멤버만 wheel 그룹에 두도록(듯이) 해야 합니다. kerberos 와 같은 인증 방법을 사용하는 경우, root 어카운트로 .Sq Pa . k5login 파일을 사용해, 아무도 wheel 그룹에 둘 필요없게 root 에 .Xr ksu 1 (을)를 허락하도록(듯이) 할 수도 있습니다. 이 방식은 보다 좋은 해결책인지도 알려지지 않습니다. 왜냐하면, wheel 의 메카니즘 그럼, 침입자가 패스워드 파일을 손에 넣어 staff 어카운트의 언젠가 1 개(살)을 찢을 수가 있으면(자), root 를 찢는 것이 아직 가능하게 되기 때문입니다. wheel 의 메카니즘을 이용하는 (분)편이, 아무것도 하지 않는 것 보다는 좋습니다만, 반드시 가장 안전한 선택사항이라고는 할 수 없습니다. .Pp root 어카운트의 안전성을 높이는 간접적인 방법으로서 다른 로그인 액세스 방법을 이용해, 스탭의 어카운트의 암호화 패스워드를\ * 로 해 두는 것으로, 스탭의 어카운트의 안전성을 높이는 것이 있습니다. 이 방법 (이)라고, 침입자가 패스워드 파일을 훔칠 수가 있을지도 모릅니다만, 스탭 어카운트를 찢을 수 없을 것입니다. 또, 비록 root 가 암호화 패스워드를 패스워드 파일에 붙이고 있었다고 해도, 간접적으로는 root 어카운트도 찢을 수가 없을 것입니다. 스탭 멤버가 스탭 어카운트로 로그인하려면 , .Xr kerberos 1 (이)나 .Xr ssh 1 (와)과 같은, 공개열쇠 / 비밀열쇠의 열쇠의 조를 사용한다 안전성의 높은 로그인의 구조를 사용합니다. kerberos 와 같은 장치를 사용하는 경우, 일반적으로, kerberos 서버를 실행하는 머신과 자신의 데스크탑 워크스테이션과의 안전성을 확보하지 않으면 안됩니다. ssh 로 공개열쇠 / 비밀열쇠의 조를 사용하는 경우, 일반적으로, 로그인원머신 (통상은 자신의 워크스테이션) 의 안전성을 확보하지 않으면 안됩니다. 여기서, .Xr ssh-keygen 1 그리고 공개열쇠 / 비밀열쇠의 조를 생성할 때, 열쇠의 조를 패스워드로 방어하는 것으로써, 열쇠의 조에의 방어층을 추가할 수도 있습니다. 스탭 어카운트의 패스워드를\ * 로 제외할 수가 있으면(자), 관리자 자신이 설정 한 안전성의 높은 방법으로 밖에 스탭 멤버를 로그인할 수 없는 것도 프로텍션 할 수 있습니다. 이렇게 해, 많은 침입자가 사용하는 중대한 보안의 구멍 (안전성의 낮은 무관계한 머신으로부터 네트워크를 들여다 보는 방법) (을)를 막는 것 같은 세션을 제공하는, 안전성의 높은 암호화된 코 네크션을 사용하는 것을, 스탭 멤버 전원에게 강제하는 것이 성과 의 것입니다. .Pp 보다 간접적인 보안의 구조에서는, 제한의 강한 서버로부터 제한의 약하다 서버에 로그인하는 것을 전제로 하고 있습니다. 예를 들면, 메인 머신으로, 여러가지 종류의 서버를 실행시키고 있는 경우, 워크스테이션에서는 그러한 서버를 실행시켜 되지 않습니다. 워크스테이션을 충분히 안전에 해 두기 위해서(때문에)는, 실행하는 서버의 수를, 하나도 서버 하지만 실행되어 있지 않다고 할 정도로에까지 할 수 있는 한 줄여야 합니다. 또, 패스워드로 보호된 화면 보호기를 달리게 해 두어야 합니다. 워크스테이션에의 물리적 액세스가 주어졌다고 하면(자), 물론 말할 필요도 없이, 공격자는 관리자가 설정해 도미일까 종류의 보안 (을)를도 쳐 찢을 수가 있습니다. 이것은, 관리자로서 반드시 생각해 언덕 안 되는 문제입니다만, 시스템 파기의 대다수는, 네트워크 경유로 리모트로부터, 워크스테이션이나 서버에의 물리적 액세스 수단을 지 선반 있고 사람들에 의해 행해진다고 하는 사실도 또, 염두에 둘 필요 (이)가 있습니다. .Pp kerberos 와 같은 방법을 사용하는 것으로, 스탭 어카운트의 패스워드의 변경 혹은 정지를 한 개소에서 행하는 것으로, 스탭 멤버가 어카운트를 가진다 모든 머신에 즉시에 그 효과를 미치는 것이 가능해집니다. 스탭 멤버의 어카운트가 위험하게 노출되었을 때에, 모든 머신으로 스탭 멤버의 패스워드를 즉석에서 변경하는 능력을 과소평가 해서는 안됩니다. 패스워드가 분산되고 있는 상황에서는, N 대의 머신으로 패스워드를 변경하면(자), 라고 나 왕이나의 사태를 부를 가능성이 있습니다. kerberos 를 사용하면(자), 패스워드의 재발행에 제한 (re-passwording restriction) (을)를 부과할 수도 있습니다. 이 기능을 사용하는 것으로, 어느 kerberos 티켓을 당분간 지나면(자) 타임 아웃으로 하는 것이 가능할 뿐만 아니라, 일정기간 (예를 들면, 1 개월에 1 회) 지나면(자), 유저에게 새로운 패스워드를 선택하도록(듯이) 요구할 수도 있습니다. .Sh root 의 안전성을 높이는 - root 권한의 서버와 suid/sgid 바이너리 주의 깊은 시스템 관리 책임자는, 자신에게 필요한 서버 프로세스만을 과부족 없고 실행시키는 것입니다. 제삼자제의 서버는, 자주(잘) 버그를 가지고 있기 쉽상이라면 말하는 것에 주의해 주세요. 예를 들면, 낡은 버젼의 imapd 나 popper (을)를 실행 하게 하는 것은, 전세계에 공통의 root 의 표를 주고 있고 같은 것입니다. 스스로 주의 깊게 체크하고 있지 않는 서버는, 결코 실행 해서는 안됩니다. root 로 실행시킬 필요가 있는 서버는 거의 없습니다. 예를 들면, ntalk, comsat, finger demon를, 특별한 「모래 밭 .Pq sandbox 」유저로 실행시킬 수가 있습니다. .\"kuma hellofalot of trouble 는 무엇이나? .\" hell of a lot of trouble 같네요. ;-) (금응논 '99.02. 11) 관리자가 방대한 수의 문제에 직면하고 있지 않다면, 이 「모래 밭」은 완벽한 것은 없습니다만, 보안에 관한 양파적 접근는 여기에서도 성립됩니다. 모래 밭에서 실행되고 있는 서버 프로세스를 경유해 침입을 완수할 수가 있었다고 해도, 공격자는 한층 더 모래 밭에서 밖으로 탈출하지 않으면 되지 않습니다. 공격자가 통과하지 않으면 안 되는 층의 수가 증가하면 증가할수록, 그 만큼 공격자가 침입에 성공하는 확률이 줄어듭니다. root 의 빠져 나갈 구멍은 역사적으로, 기본 시스템 서버도 포함해 root 권한으로 실행되는 거의 모든 서버 프로세스로 발견되고 있습니다. 유저가 sshd 경유에서만 로그인해, telnetd, rshd, rlogind 경유로 로그인하는 것 하지만 결코 없는 머신을 가동시키고 있다면, 그러한 서비스를 정지시켜 주세요. .Pp .Fx 그럼, 지금은 ntalkd, comsat, finger 는 모래 밭에서 실행시키는 것이 디폴트가 되어 있습니다. 다음에 모래 밭에서 실행시켜야 할 프로그램의 후보로서 .Xr named 8 (이)가 있습니다. 디폴트의 rc.conf 파일에는, named 를 모래 밭에서 실행한다 위해(때문에) 필요한 인수가 comment out 된 형식에서 포함되어 있습니다. 새롭다 시스템을 인스톨 하고 있는지, 그렇지 않으면 기존의 시스템을 업그레이드 해 사용하고 있을까에 의존합니다만, 모래 밭으로서 사용한다 특별한 유저 어카운트가 인스톨되어 있지 않을지도 모릅니다. 주의 깊은 시스템 관리 책임자이면, 가능한 한 언제라도 연구를 게을리하지 않고, 서버에 모래 밭을 가르치는 것이지요. .Pp 통상, 모래 밭에서 실행하지 않는 서버가 그 밖에 몇개인가 있습니다. sendmail, popper, imapd, ftpd 등입니다. 이러한 쳐 몇개의 서버에는 대신이 되는 것도 의가 있습니다만, 대신의 것을 인스톨 하려면 , 그 만큼 많은 일이 필요하게 되므로, 결국 이것들을 기꺼이 넣어 버립니다 (편리함이라고 하는 요소가 다시 또 승리를 거두는 것입니다). 이러한 서버는, root 권한으로 실행하지 않으면 습관일지도 모릅니다. 또, 이러한 서버 경유로 생기는 침입 (을)를 검출하기 위해서는, 다른 구조에 의지하지 않으면 안 될지도 모릅니다. .Pp 시스템의 root 권한의 잠재적인 구멍에서 그 밖에 큰 것으로 해, 시스템에 인스톨 된 suid-root/sgid 바이너리가 있습니다. 이러한 바이너리는, rlogin와 같이, .Pa /bin , .Pa /sbin , .Pa /usr/bin , .Pa /usr/sbin 에 존재하는 것이 대부분입니다. 100% 안전한 것은 존재하지 않다고는 해도, 시스템 디폴트의 siud/sgid 바이너리는 비교적 안전이라고 할 수 있습니다. 그런데도 덧붙여 root 의 구멍이 이러한 바이너리에 때때로 발견되고 있습니다. 1998 년에 Xlib 로 발견되었다 root 의 구멍은, xterm (보통, suid 설정되어 있습니다) (을)를 공격 가능하게 하고 있었습니다. 안전한 (분)편이 좋기 때문에, 주의 깊은 시스템 관리 책임자는 유감스럽게 생각하면서도, 스탭만이 실행할 필요가 있는 suid 바이너리는, 스탭만이 액세스 가능한 특별한 그룹에 포함하도록(듯이) 제한을 더해 아무도 사용하지 않는 suid 바이너리는 .Pq Li chmod 000 을 실행해 정리해 버리겠지요. 디스플레이를 가지지 않는 서버는, 일반적으로 xterm 의 바이너리를 필요로 하지 않습니다. sgid 바이너리도 거의 같은 위험한 존재가 될 수 있습니다. 침입자가 kmem 에 sgid 된 바이너리를 찢을 수가 있었을 경우, 그 침입자는 .Pa /dev/kmem (을)를 읽어낼 수가 있게 됩니다. 즉, 암호화된 패스워드 파일을 읽어낼 수가 있다 같게 되므로, 패스워드를 가지는 어느 어카운트도, .Pq 잠재적인 위험하게 쬐게 됩니다. 대신에, kmem 그룹을 물리친 침입자가 pty 를 통해 보내진 키스트로크(keystroke)를 감시할 수 있습니다. 키스트로크(keystroke)에는, 안전한 방법으로 로그인하는 유저가 사용하고 있다 pty 도 포함됩니다. tty 그룹을 물리친 침입자는, 거의 임의의 유저의 tty 에 기입을 할 수 있습니다. 유저가 단말 프로그램이나 키보드를 시뮬레이션 하는 기능을 가진 에뮬레이터를 사용하고 있는 경우, 침입자는 잠재적으로, 결국 그 유저로서 실행되는 명령을 유저의 단말에 에코 시킨다 데이터 스트림을 생성할 수 있을 가능성이 있습니다. .Sh 유저 어카운트의 안전성을 높인다 유저 어카운트는, 보통, 안전성을 높이는 것이 가장 곤란합니다. 스탭에 대해서, 아테네의 드라코와 같이 엄격한 액세스 제한을 부과해, 스탭의 패스워드를\ * 로 제외할 수가 있다고는 해도, 관리자가 가질 수 있다 일반 유저 모든 어카운트에 대해서 같은 것은 할 수 없을지도 모릅니다. 관리자가 충분히 통솔을 취할 수가 있다면, 관리자는 승리해, 유저의 어카운트의 안전을 적절히 확보할 수 있을지도 모릅니다. 그것이 할 수 없다면, 더 한층 배려해 일반 유저의 어카운트를 감시하는 것보다 외 없습니다. 일반 유저 어카운트에 대해 ssh 나 kerberos 를 이용하는 것에는, 시스템 관리가 한층 더 증가하거나 테크니컬 서포트가 필요하게 되는 등의 문제가 있습니다. 그런데도, 암호화 패스워드 파일과 비교와 훨씬 좋은 해입니다. .Sh 패스워드 파일의 안전성을 높인다 가능한 한 많은 패스워드를\ * 로 제외해, 그러한 어카운트의 액세스에는 ssh 나 kerberos 를 사용하도록(듯이) 하는 것이, 유일한 확실한 방법입니다. 비록 암호화 패스워드 파일 .Pq Pa /etc/spwd.db 하지만 root 에서만 읽어내 가능하다고 해도, 침입자가 그 파일의 읽기 액세스권한을 얻는 것은 가능할지도 모릅니다. 비록 root 의 기입 권한을 얻을 수 없는다고 해도입니다. .Pp 보안 스크립트는 항상 패스워드 파일의 변경을 체크해, 보고 하도록(듯이) 해야 합니다 (후술의 「파일의 완전성의 체크」를 참조해 주세요). .Sh 커널의 코어, raw 디바이스, 파일 시스템의 안전성을 높인다 root 의 권한을 찢으면(자), 공격자는 뭐든지 할 수 있습니다만, 좀 더 간편한 일도 몇개인가 있습니다. 예를 들면, 최근의 커널은, 편입의 패킷 들여다 보고 디바이스 .Pq packet sniffing device 드라이버를 갖추고 있는 것이 대부분입니다. .Fx 그럼 .Sq bpf 디바이스로 불리고 있습니다. 침입자는 보통, 위험하게 노출되었다 머신으로 패킷 들여다 보고 프로그램을 실행시키려고 시도합니다. 침입자에게 일부러 그러한 기능을 제공할 필요는 없기 때문에, 대부분의 시스템으로 bpf 디바이스를 짜넣어야 하는 것이 아닙니다. .Pp bpf 디바이스를 제외해, 모듈 로더를 무효로 해도, .Pa /dev/mem (와)과 .Pa /dev/kmem 그렇다고 하는 고민거리가 아직 남아 있습니다. 이 문제에 관해서는, 침입자는 raw 디바이스에 기입할 수도 있습니다. 또, .Xr kldload 8 그렇다고 하는, 다른 커널 기능이 있습니다. 의지 그대로응의 침입자는, KLD 모듈을 사용해 자신 독자적인 bpf 혹은 그 외 들여다 보고 디바이스를 동작중의 커널에 인스톨 할 수가 있습니다. 이 문제를 피하기 (위해)때문에, 시스템 관리 책임자는 커널을 보다 높은 안전 레벨 .Pq securelevel , 적어도 안전 레벨 1 으로 실행시킬 필요가 있습니다. sysctl 를 사용해 kern.securelevel 변수에 안전 레벨을 설정하는 것이 할 수 있습니다. 한번 안전 레벨에 1 을 설정하면(자), raw 디바이스에 대한 기입 액세스는 거부되어 예를 들면 .Sq schg (와)과 같은 특별한 chflags 플래그가 효과를 발휘합니다. 이것에 가세해, 기동시에 있어 중요한 바이너리·디렉토리·스크립트 파일 등, 안전 레벨이 설정될 때까지 에 실행되는 것 모두에 대해서도 .Sq schg 플래그를 확실히 on 로 해 둘 필요가 있습니다. 이 설정을 너무 해도 상관하지 않습니다만, 보다 높은 안전 레벨로 동작하고 있는 경우, 시스템의 업그레이드가 훨씬 곤란하게 됩니다. 시스템을 보다 높은 안전 레벨로 실행시키도록(듯이) 하지만, 텐토님아래에 있는 모든 시스템 파일과 디렉토리에 schg 플래그를 설정하지 않는다고 하는 타협을 하는 방법도 있습니다. 하나 더의 가능성으로서는, 단순하게 / 및 /usr 를 읽어들여 전용으로 mount 하는 것입니다. 여기서 특필 해야 할것은, 시스템을 지키려고 아테네의 드라코 (와)과 같이 엄격하게 너무 엄격하게 하면(자) , 침입을 검출한다고 하는 매우 중요한 일이 할 수 없게 되어 버린다고 하는 것입니다. .Sh 파일의 완전성의 체크: 바이너리, 설정 파일 등 일 이 문제에 이르면(자), 시스템 관리 책임자로 할 수 있는 것은, 편리함이라고 하는 요소가 그 추악한 머리를 올리지 않는 정도로, 코어 시스템의 설정 / 제어 파일을 방어하는 것 뿐입니다. 예를 들면,/ 및 /usr 에 있는 대부분의 파일에 schg 비트를 설정하기 위해서 chflags 를 사용하는 것은, 아마 역효과지요. 왜냐하면, 그렇게 하는 것으로 파일은 보호할 수 있습니다만, 침입을 검출 하는 창을 닫아 버리게도 되기 때문입니다. 보안의 양파의 마지막 층은 아마 가장 중요한 것, 즉 검출입니다. 보안의 나머지의 것은, 갑작스런 침입을 검출할 수 없으면, 전혀 유용한 것은 없습니다(혹은, 좀 더 나쁘면, 잘못한 안전성에 대한 감각을 심어 버립니다 ). 양파의 일의 반은, 균형 상태에 있을 때, 공격중에 검출 측에 공격자를 잡는 계기를 주기 (위해)때문에, 공격자를 막는 것이 아니라 침입을 늦추는 것입니다. .Pp 침입을 검출하는 가장 좋은 방법은, 변경되어 있거나, 사라져 있거나, 넣은 기억이 없는데 들어가 있는 파일을 찾는 것입니다. 변경된 파일을 찾는데 가장 좋은 방법은, 하나 더의 (자주 중앙에 모아진 ) 액세스가 제한된 시스템으로부터 행하는 것입니다. 한층 더 안전해 액세스 제한된 시스템상에서 보안용 스크립트를 쓰면, 스크립트는 잠재적인 크래커들로부터는 거의 안보이게 됩니다. 이것은 중요한 일입니다. 최대한으로 우위에 서기 위해서(때문에), 일반적으로 비지니스로 사용하는 다른 머신에의 중요한 액세스는, 액세스의 제한된 머신에 시키지 않으면 안됩니다. 보통은, 다른 머신으로부터 액세스 제한된 머신에 읽어들여 전용으로 NFS export 하거나 액세스 제한된 머신으로부터 다른 머신에 ssh 를 행하기 위해서(때문에), ssh 열쇠의 페어를 만들거나 하는 것으로 실시합니다. 네트워크의 트래픽을 따로 해, NFS 는 가장 가시성이 없는 방법입니다. 사실상 검출되지 않는 각 클라이언트상의 파일 시스템을 감시할 수 있게 됩니다. 액세스 제한된 서버가 스윗치를 통해 클라이언트에 접속하는 경우, 대부분 NFS 가 보다 좋은 선택사항입니다. 액세스 제한된 서버가 허브를 통하거나 몇개의 루팅층을 통하거나 해 클라이언트에 접속하는 경우, NFS 는 너무 위험한 방법일지도 모르지 않고 (네트워크의 면에서 ), ssh 가 인증의 이치는 자취가 되어 남습니다만, 그런데도 보다 좋은 방법일지도 모릅니다. .Pp 액세스 제한된 머신에, 적어도 감시하는 것을 전제로 했다 클라이언트 시스템에의 읽어들여 액세스를 한번 주면(자), 실제로 감시하기 위한 스크립트를 쓰지 않으면 안됩니다. NFS mount를 하면, .Xr find 1 (이)나 .Xr md5 1 등이 단순한 시스템 유틸리티로 스크립트를 쓸 수가 있습니다. 적어도 1 일 1 회, 클라이언트의 파일을 직접 md5 에 걸쳐 한층 더 좀 더 빈번하게 .Pa /etc 및 .Pa /usr/local/etc 에 있는 것 같은 컨트롤용 파일을 시험하는 것이 이치반입니다. 시험 파일은, 액세스 제한된 머신이 적성이라고 알고 있는, 기가 된다 md5 정보와 비교해 차이가 발견되었을 경우, 시스템 관리 책임자에 조사했으면 좋겠다고 호소하도록(듯이) 해야 합니다. 뛰어난 보안용 스크립트는, .Pa / 및 .Pa /usr 등의 시스템 파티션상에서 부적당하게 suid 된 바이너리나, 새롭게 작성된 파일이나 삭제된 파일도 체크하겠지요. .Pp NFS 가 아니고, ssh 를 사용하는 경우는, 보안용 스크립트를 쓰는 것은 쭉 어려운 일입니다. 스크립트를 클라이언트로부터 보이도록(듯이) 해, 움직이기 위해서(때문에)는, 클라이언트에 대해서 .Pa scp (을)를 반드시 실시하지 않으면 안됩니다. 그리고, 안전이기 때문에, 스크립트가 사용하는 바이너리 ( find 등 )를 scp 할 필요도 있습니다. 클라이언트의 ssh demon는 벌써 위험하게 노출되고 있을지도 모릅니다. 이상로부터, 안전하지 않은 링크상의 경우는 ssh 는 필요할지도 모릅니다만, ssh 를 취급하는 것은 매우 대단한 일입니다. .Pp 뛰어난 보안용 스크립트는, 유저나 스탭 멤버의 액세스 설정 파일도 체크하는 것입니다. .Pa .rhosts , .Pa .shosts , .Pa .ssh/authorized_keys 등이 그것입니다만, MD5 의 체크의 범위외가 되어 버릴지도 모릅니다. .Pp 유저용의 디스크 용량이 매우 큰 경우는, 파티션상의 각 파일을 봐 도는데 대단한 시간이 걸릴지도 모릅니다. 이 경우는, mount 플래그를 설정해, 이 파티션에 suid 된 바이너리나 디바이스를 둘 수 없게 하는 것이 좋은 생각입니다. .Sq nodev 및 .Sq nosuid 옵션 ( .Xr mount 8 참조) 하지만 조사하고 싶은 것으로 짊어진다. 나라면, 여하튼 주에 1 번은 파일 시스템을 스캔 하겠지요. 왜냐하면, 이 층에서의 목적은, 침입이 의미가 있는지 어떤지에 관련되지 않고, 침입을 검출하는 것이기 때문입니다. .Pp 프로세스 어카운팅 ( .Xr accton 8 참조) (은)는, 비교적 오버헤드의 낮은 operating system의 기능으로, 머신에 침입되어 버린 후의 평가의 구조로서 사용하는 것을 추천 합니다. 침입을 받은 다음에도 해당 파일이 상처가 없는 경우에, 침입자가 실제로 어떻게 해 시스템에 침입했는지를 추적하는데 특히 유익합니다. .Pp 마지막으로, 보안 스크립트는 로그 파일을 처리하도록(듯이) 해, 로그 파일 자체도 가능한 한 안전성의 높은 방법으로 .Sq 리모트 syslog 는 지극히 유익하게 될 수 있습니다 생성하도록(듯이) 해야 합니다. 침입자는 자신의 침입의 흔적을 덮어 가리자 (으)로 하고, 또, 로그 파일은 시스템 관리 책임자가 최초의 침입때 각과 방법을 추적해 가기 위해서(때문에) 지극히 중요합니다. 로그 파일을 영구히 남겨 두기 위한 1 개의 방법은, 시스템 콘솔을 시리얼 포트에 이어 달리게 해 콘솔을 감시하고 있는 안전한 머신을 통해 끊임없이 정보를 모으는 것입니다. .Sh 편집광적 방법 다소 편집광적으로 되어도 결코 나쁜 것에는 되지 않습니다. 원칙적으로, 시스템 관리 책임자는, 편리함에 영향을 주지 않는 범위에서 몇 개에서도 보안 기능을 추가할 수가 있습니다. 또, 얼마인가 고려한 결과, 편리함에 영향을 주는 보안 기능을 추가할 수도 있습니다. 좀 더 중요한 일에는, 보안 관리자와는 조금 싸움이 된다 (은)는 두입니다만, 만약 당신이, 이 메뉴얼 페이지에 쓰여져 있다 권고를 그대로 사용하거나 했을 경우는, 예상되는 크래커는 역시 이 메뉴얼을 읽고 있는 것이기 때문에, 방어책을 건네주어 버리게 됩니다. .Sh 서비스 불능 공격 (D.O.S. attack)에 대한 특기 사항 이 섹션에서는 서비스 불능 공격을 취급합니다. 서비스 불능 공격은, 보통은, 패킷 공격입니다. 네트워크를 포화시키는 최첨단의 위조 패킷 .Pq spoofed packet 공격에 대해서 시스템 관리 책임자를 칠 수 있는 손은 그만큼 많이 없습니다만, 일반적으로, 그 종의 공격에 의해 서버가 다운 하지 않는 것을 확실히 하는 것으로, 피해를 있는 한도에 막는다 (일)것은 할 수 있습니다. .Bl -enum -offset indent .It 서버의 fork 의 제한 .It 발판 공격의 제한 .Pq ICMP 응답 공격, ping broadcast 등 .It 커널의 경로 정보의 캐쉬 .El .Pp 보통으로 볼 수 있는 서비스 불능 공격에, fork 하는 서버 프로세스에 대한다 물건이 있습니다. 이것은, 서버에 프로세스·파일 기술자·메모리를 다 먹어 , 머신을 죽이려고 하는 것입니다. inetd ( .Xr inetd 8 참조) 에는, 이런 종류의 공격을 제한하는 옵션이 몇개인가 있습니다. 머신이 다운하는 것을 방지하는 것은 가능합니다만, 이런 종류의 공격에 의해 서비스가 붕괴하는 것을 방지하는 것은 일반적으로 말해 할 수 없는 것에 주의할 필요가 있습니다. inetd 의 메뉴얼 페이지를 주의 깊게 읽어 주세요. 특히, .Fl c , .Fl C , .Fl R 옵션에 주의해 주세요. IP 위조 공격 (spoofed-IP attack) (은)는 inetd 의 .Fl C 옵션을 허를 찌를 수 있으므로, 일반적으로 옵션을 조합해 사용해야 하는 것인 것에 주의해 주세요. 스탠드얼론 서버 의 안에는, 자기 자신으로 fork 를 제한하는 파라미터를 가지고 있는 것이 있습니다. .Pp sendmail 에는, .Fl OMaxDaemonChildren 옵션이 있습니다. 부하에는 지연이 있으므로, sendmail 의 부하에 한계를 마련하는 옵션을 사용하는 것보다도, 이 옵션을 사용하는 (분)편이 온전히 동작할 가능성은 훨씬 높습니다. sendmail 의 실행을 개시할 때에, .Cm MaxDaemonChildren 파라미터를 설정해야 합니다. 그 값은, 통상 전망되는 부하를 취급할 수 있는 정도로 충분히 높지만, 그 만큼의 수의 sendmail 를 조작하려고 하면(자) 머신이 졸도해 버릴 정도로는 높지 않은 것 같은 값으로 설정해야 합니다. sendmail 를 큐 처리 모드 .Pq Fl ODeliveryMode=queued 그리고 실행하는 것이나, sendmail demon .Pq Cm sendmail -bd (을)를 큐 처리용 프로세스 .Pq Cm sendmail -q15m (와)과 따로 실행하는 일도, 주의 깊은 일이라고 말할 수 있습니다. 그런데도 더 리얼타임에서의 배송을 바란다면, .Fl q1m (와)과 같이 하는 것으로, 큐 처리를 훨씬 짧은 시간 간격으로 실시할 수가 있습니다. 어쨌든, .Cm MaxDaemonChildren 옵션에 합리적인 값을 확실히 지정해, sendmail 가 눈사태를 쳐 실패하는 것이 없게 해 주세요. .Pp syslogd 는 직접 공격받을 가능성이 있으므로, 가능하면 언제라도 .Fl s 옵션을 이용하는 것을 강하게 추천 합니다. 이것을 할 수 없으면, .Fl a 옵션을 사용해 주세요. .Pp tcpwrapper 의 역 identd 등의 접속 반환 (connect-back) (을)를 실시하는 서비스에 붙어 충분히 주위를 기울이도록(듯이) 해야 합니다. 이것들은 직접 공격을 받을 가능성이 있습니다. 이런 사정이 있으므로, tcpwrapper 의 역 ident 기능을 사용하려고는 생각하지 않는 것이 일반적입니다. .Pp 경계 라우터의 곳에서 파이어 월(fire wall)를 마련해, 외부로부터의 액세스에 대해서 내부 서비스를 방어한다고 하는 생각은 실로 좋은 것입니다. 이 생각은, LAN 의 외부 (으)로부터의 포화 공격을 막는 것에 있어, root 네트워크 베이스의 root 권한에의 공격으로부터 내부 서비스를 방어하는 것에는, 너무 고려를 지불해 없습니다. 파이어 월(fire wall)는 항상 배타적으로 설정해 주세요. 즉, 「포트 A, B, C, D 와 M 로부터 Z 까지 .Eo * 이외 .Ec * 의 모두에게 방화벽을 마련한다」라고 하는 식으로입니다. 이와 같이 하는 것으로, named (존의 프라이머리인 경우), ntalkd, sendmail 등, 인터넷에 액세스를 제공하는 서비스 (으)로서 특히 지정하는 것 이외의, 작은 번호의 포트 모든 것을 파이어 월(fire wall)에서 방어할 수가 있습니다. 파이어 월(fire wall)를 이 다른 방식, 즉 포함적 혹은 수용적인 파이어 월(fire wall)로서 설정하려고 하는 경우, .Sq close 하는 것을 잊어 버리는 서비스가 몇개인가 나오거나 새로운 내부 서비스를 추가했는데 파이어 월(fire wall)의 갱신을 잊거나 할 가능성이 잘 나옵니다. 파이어 월(fire wall)상의 큰 번호의 포트를 열어 두어, 작은 번호의 포토를 위험하게 쬐는 일 없이 수용적인 동작을 허락할 수가 있습니다. .Fx 그럼, net.inet.ip.portrange 에의 sysctl .Pq Li "sysctl -a | fgrep portrange" (을)를 여러 가지 사용하는 것으로, 동적 바인드에 사용되는 포트 번호의 범위를 제어할 수 있는 것을 기억에 그쳐 두어 주세요. 이것에 의해 파이어 월(fire wall)의 설정의 complex system를 완화할 수 있습니다. 나는, 파이어 월(fire wall)에 통상의 first/last 의 범위로서 4000 에서 5000 을, 고위 포트의 범위로서 49152 에서 65535 를 사용하고 있습니다. 그리고, (몇개의 인터넷 액세스 가능한 포트를 블록으로부터 제외하는 것은 물론입니다만) 4000 보다 아래의 모든 것을 블록 하고 있습니다. .Pp 또 다른 흔히 있던 서비스 불능 공격으로서 발판 공격 (springboard attack) (으)로 불리는 것이 있습니다. 이것은, 서버가 자기 자신, 로컬 네트워크, 그리고 다른 머신을 과부하에 몰아넣는 것 같은 응답을 생성시키는 방법으로 서버를 공격합니다. 이런 종류의 공격 중(안)에서 가장 흔히 있던 것은, ICMP PING BROADCAST 공격이 있습니다. 공격자는, 실제로 공격하고 싶은 머신의 주소를 소스 주소로 설정한 ping 패킷을 위조해, 대상의 LAN 의 브로드캐스트 어드레스를 향해 패킷을 송신합니다. 경계에 있는 라우터가 브로드캐스트 어드레스에 대한 ping 패킷을 잡도록(듯이) 설정되어 있지 않다 경우, LAN는, 사칭 된 소스 주소를 향해 응답 패킷을 생성하는 지경이 되어, 희생이 되는 머신이 포화하는 곳(중)까지 가 버립니다. 공격자가 같은 트릭을 다른 네트워크상의 얼마든지의 브로드캐스트 주소에 대해서 동시에 사용했을 경우, 특히 심하게 됩니다. 지금까지, 120 메가 비트 이상의 브로드캐스트 공격이 관측되고 있습니다. 2 번째의 발판 공격은, ICMP 에러 보고의 장치를 노리는 것입니다. ICMP 에러 응답을 생성하는 패킷을 생성하는 것으로써, 공격자는 서버의 수신 네트워크를 포화시킬 수가 있어 동시에, 서버가 송신 네트워크를 ICMP 응답으로 포화시키도록(듯이) 할 수가 있습니다. mbuf 를 다 소비하는 것으로 , 이런 종류의 공격으로 서버를 크래쉬 시키는 일도 가능합니다. 서버의 ICMP 응답 생성이 너무 빨라, ICMP 응답의 송신이 따라붙지 않는 경우, 특히 심하게 됩니다. .Fx 커널에는, 이런 종류의 공격의 효과를 억제하는 ICMP_BANDLIM 와 불리는 새로운 컴파일 옵션이 있습니다. 3개째의 주요한 클래스에 속하는 발판 공격은, udp echo 서비스와 같은, 어떤 종류의 내부 inetd 서비스에 관련하는 것입니다. 공격자는, 단지 소스 주소가 서버 A 의 echo 포트이며, 데스티네이션 주소가 서버 B 의 echo 포트인것 같이 UDP 패킷을 위조합니다. 여기서 서버 A, B 는 함께 자신의 LAN 에 접속되고 있습니다. 이 2 개의 서버는, 이 하나의 패킷을 양자간에서 서로 상대에 대해서 서로 반격합니다. 이와 같이 해 패킷을 몇개인가 주입하는 것만으로, 공격자는 양쪽 모두의 서버와 LAN 를 과부하 상태로 할 수가 있습니다. 같은 문제가 내부 chargen 포트에도 존재합니다. 유능한 시스템 관리 책임자는 이 손의 inetd 내부 테스트 서비스의 모든 것을 무효로 해 두는 것입니다. .Pp 위조 패킷 공격은, 커널의 경로 정보 캐쉬에 과부하를 일으키게 하기 위해서(때문에) 이용되는 일도 있습니다. net.inet.ip.rtexpire, rtminexpire, rtmaxcache 의 sysctl 파라미터를 참조해 주세요. 터무니없는 소스 IP 를 이용했다 이 위조 패킷 공격에 의해, 커널은, 일시적인 캐쉬 경로를 경로 정보 테이블에 생성합니다. 이것은 .Sq netstat -rna \&| fgrep W3 그리고 볼 수가 있습니다. 이러한 경로는, 보통은 1600 초 정도로 타임 아웃에 됩니다. 커널이 캐쉬 경로 테이블이 너무 커진 것 를 검지하면(자), 커널은 동적으로 rtexpire 를 줄입니다만, rtminexpire 보다 작아지도록(듯이)는 결코 줄이지 않습니다. 여기에 문제가 2 개 있습니다. (1) 부하의 가벼운 서버가 돌연 공격받았을 경우, 커널이 충분히 재빠르게 반응 할 수 없는 것. (2) 커널이 공격에 참고 살아남을 수 있는 만큼 충분히 rtminexpire 가 낮게 설정되어 있지 않은 것. 의 2개(살)입니다. 자신의 서버가 T3 혹은 그것보다 양질의 회선으로 인터넷에 접속되고 있는 경우, .Xr sysctl 8 (을)를 이용해 rtexpire 와 rtminexpire 를 수동으로 덧쓰기해 두는 것이 사려깊은 일 그렇다고 할 수 있습니다. (자신의 머신을 크래쉬 시키고 싶지 않은 것이면 :-)) 어느 쪽인지 한편에서도 0 에 (은)는 결코하지 마세요. 양파라미터를 2 초로 설정하면, 공격으로부터 경로 정보 테이블을 지키기에는 충분하겠지요. .Sh kerberos 및 ssh 를 이용한 액세스의 문제 만약 당신이, kerberos 및 ssh 를 사용하고 싶은 것이라고 하면(자), 양자에 관해서 말할 필요가 있는 문제가 몇개인가 있습니다. kerberos V 는 몹시 뛰어난 인증 프로토콜입니다만, kerberos 처리된 telnet 나 rlogin 는, 바이너리 스트림을 취급하는데 적합하지 않게 되어 버리는 것 같은 버그가 있습니다. 게다가 디폴트에서는, kerberos 는 .Fl x 옵션을 사용하지 않는 한 세션을 암호화해 주지 않습니다. ssh 에서는, 디폴트로 모든 것을 암호화해 줍니다. .Pp ssh 는 모든 장면에서 매우 잘 일해 줍니다. 다만, 암호열쇠를 보내 버리는 경우를 제외하면입니다. 이것은 즉, 암호열쇠를 가진 안전한 워크스테이션이 있어, 이 암호열쇠로 나머지의 시스템과 액세스 할 수 있다 같게 되어 있는 경우에서는, 안전하지 않은 머신에 ssh 를 행할 때에 암호열쇠가 보여 버린다고 하는 것입니다. 실제의 열쇠 그 자체가 보여 버리는 것은 없습니다만, ssh 는, login 를 지속시키기 위해서(때문에) 배송용 포트를 만듭니다. 크래커가 안전하지 않은 머신의 root 를 찢으면(자), 크래커는, 이 포트를 사용해 암호열쇠를 취득해, 암호열쇠로 락이 빗나가는 다른 머신에의 액세스를 얻습니다. .Pp staff 의 로그인에는, kerberos 를 배합한 ssh 를 사용하는 것을 권합니다. ssh 는, kerberos 와 함께 컴파일 할 수 있습니다. 이렇게 하면(자), 보여 끝낼지도 모르는 ssh 열쇠를 그다지 목표로 하지 말고 좋게 됩니다. 또, 그것과 동시에, kerberos 경유로 패스워드를 보호할 수도 있습니다. ssh 열쇠는, 안전한 머신으로부터의 자동화된 태스크 (kerberos 에서는 적합하지 않은 물건 등 ) 용무에만 사용해야 합니다. 또, ssh 의 설정으로 ssh 열쇠를 보내지 않게 하든가, 혹은, .Pa authorized_keys 파일중에서 .Pa "from=IP/DOMAIN" 옵션을 사용해, 특정의 머신으로부터 로그인해 온 것만에 유효하게 되는 열쇠를 ssh 를 생성할 수 있도록(듯이) 하는 일도 권합니다. .Sh 관련 항목 .Xr chflags 1 , .Xr find 1 , .Xr kerberos 1 , .Xr md5 1 , .Xr netstat 1 , .Xr openssl 1 , .Xr ssh 1 , .Xr xdm 1 , .Xr group 5 , .Xr ttys 5 , .Xr accton 8 , .Xr init 8 , .Xr sshd 8 , .Xr sysctl 8 , .Xr syslogd 8 , .Xr vipw 8 .Sh 역사 .Nm 메뉴얼 페이지는, 원래 .An Matthew Dillon 에 의해 쓰여졌습니다. 최초로 나타난 것은, .Fx 3.1 그리고 1998 년 12 월의 일입니다. .\" translated by Norihiro Kumagai, 98-12-29