원문 보기: https://dawoum.duckdns.org/wiki/Server_Message_Block
Server Message Block (SMB)는 네트워크의 노드 사이에 파일, 프린터, 직렬 포트, 및 기타 통신을 공유하기 위해 사용되는 통신 프로토콜입니다. Microsoft Windows에서, SMB 구현은 "Server" (ID: LanmanServer)와 "Workstation" (ID: LanmanWorkstation)이라는 두 가지 모호한 이름의 Windows 서비스로 구성됩니다. 그것은 사용자 인증을 위해 NTLM 또는 Kerberos 프로토콜을 사용합니다. 그것은 역시 인증된 프로세스-사이 통신 (IPC) 메커니즘을 제공합니다.
SMB는 원래 1983년 IBM에서 Barry A. Feigenbaum에 의해 IBM의 IBM PC DOS를 실행하는 시스템의 네트워크에 걸쳐 파일과 프린터에 대한 접근을 공유하기 위해 개발되었습니다. 1987년에, Microsoft와 3Com은 OS/2에 대해 LAN Manager에서 SMB를 구현했으며, 당시 SMB는 놓여있는 전송으로 NetBIOS Frames 프로토콜 위에 NetBIOS 서비스를 사용했습니다. 나중에, Microsoft는 Windows NT 3.1에서 SMB를 구현했고 그 이후로 업데이트하여 새로운 기본 전송인 TCP/IP 및 NetBT와 작동하도록 조정했습니다. QUIC를 통한 SMB는 Windows Server 2022에서 도입되었습니다.
1996년에, Microsoft는 사소한 수정을 거쳐 Common Internet File System (CIFS /sɪfs/)라는 이름 아래에서 SMB 1.0 버전을 발표했습니다. CIFS는 LAN Manager를 포함하여 심지어 최초의 SMB와도 호환되었습니다. 그것은 심볼릭 링크, 하드 링크, 및 더 큰 파일 크기를 지원하지만, SMB 2.0 이상의 기능은 전혀 지원하지 않습니다. Microsoft의 제안은, 어쨌든, 인터넷 초안으로 남아 있었고 표준 상태를 달성하지 못했습니다. 그 이후로 Microsoft는 CIFS라는 이름을 사용하지 않았지만 SMB를 계속 개발하고 후속 사양을 발표하고 있습니다. Samba는 SMB 프로토콜과 Microsoft 확장 기능을 다시 구현한 자유 소프트웨어입니다.
Features
서버 메시지 블록 (SMB)은 컴퓨터 네트워크에 걸쳐 파일 공유, 프린터 공유, 네트워크 탐색, 및 (이름-지은 파이프를 통해) 프로세스-사이 통신을 가능하게 합니다. SMB는 Microsoft의 분산 파일 시스템 구현의 기반 역할을 합니다.
SMB는 전송을 위해 TCP 및 IP 프로토콜을 사용합니다. 이 조합은 공용 인터넷을 포함한 복잡하고, 상호 연결된 네트워크에 걸쳐 파일 공유를 허용합니다. SMB 서버 구성 요소는 TCP 포트 445를 사용합니다. SMB는 원래 IEEE 802.2 - NetBIOS 프레임 또는 NBF - 및 IPX/SPX에 걸쳐 NetBIOS에서 작동했고, 나중에는 TCP/IP에 걸쳐 NetBIOS (NetBT)에서 작동했지만, Microsoft는 이후 이들 프로토콜을 더 이상 사용하지 않습니다. NetBT에서, 서버 구성 요소는 세 개의 TCP 또는 UDP 포트: 137 (NETBIOS 이름 서비스), 138 (NETBIOS 데이터그램 서비스), 및 139 (NETBIOS 세션 서비스)를 사용합니다.
Microsoft Windows에서, 두 개의 모호하게 이름-지은 Windows 서비스가 SMB를 구현합니다. "서버" 서비스 (ID: LanmanServer)는 공유 자원을 제공하는 역할을 합니다. "워크스테이션" 서비스 (ID: LanmanWorkstation)는 컴퓨터 이름을 유지 관리하고 다른 컴퓨터의 공유 자원을 접근하는 데 도움을 줍니다. SMB는 Kerberos 프로토콜을 Windows 도메인 네트워크에서 Active Directory에 대해 사용자를 인증하기 위해 사용합니다. 더 간단한 피어-투-피어 네트워크에서, SMB는 NTLM 프로토콜을 사용합니다.
Windows NT 4.0 SP3 이상은 일부 중간자 공격을 방지하기 위해 SMB 메시지에 디지털 서명을 할 수 있습니다. SMB 서명은 ("LanmanServer" 서비스에 의해) 들어오는 SMB 연결과 (LanmanWorkstation 서비스에 의해) 나가는 SMB 연결에 대해 개별적으로 구성될 수 있습니다. Windows Server 2003 이상을 실행하는 Windows 도메인 컨트롤러에 대해 기본 설정은 서명되지 않은 들어오는 연결을 허용하지 않는 것입니다. 이를테면, 처음부터 SMB 서명을 지원하지 않는 이전 버전의 Windows (Windows 9x 포함)는 Windows Server 2003 도메인 컨트롤러에 연결할 수 없습니다.
SMB는 성능을 개선하기 위해 파일에 대한 기회적 잠금 (아래 참조)을 지원합니다. 기회적 잠금 지원은 각 Windows Server 릴리스마다 변경되어 왔습니다.
Opportunistic locking
SMB 프로토콜에서, 기회 잠금은 클라이언트에 의해 네트워크 파일의 캐싱을 제어함으로써 성능을 향상시키도록 설계된 메커니즘입니다. 기존 잠금과 달리, 기회 잠금 (OpLocks)은 엄밀히 말해서 파일 잠금이 아니거나 상호 배제를 제공하기 위해 사용되지 않습니다.
기회주의적 잠금에는 4가지 유형이 있습니다.
Batch Locks : 배치 OpLocks는 원래 파일이 짧은 기간 동안 여러 번 열리고 닫히는 DOS 배치 파일 실행 작업의 특정 동작을 지원하기 위해 만들어졌으며, 이는 성능 문제입니다. 이를 해결하기 위해, 클라이언트는 "배치" 유형의 OpLock을 요청할 수 있습니다. 이 경우에서, 클라이언트는 닫기 요청을 보내는 것을 지연하고 후속 열기 요청이 제공되면, 두 요청이 서로를 취소합니다.
Level-1 OpLocks / Exclusive Locks : 응용 프로그램이 임의의 다른 프로세스 (또는 다른 클라이언트)에 의해 열리지 않은 SMB 서버에 호스팅된 파일을 "공유 모드"로 열 때, 클라이언트는 서버로부터 배타적 OpLock을 받습니다. 이것은 클라이언트는 이제 이 특정 파일에 접근할 수 있는 유일한 프로세스라고 가정할 수 있고, 클라이언트는 이제 서버에 그것을 커밋하기 전에 파일의 모든 변경 사항을 캐시할 수 있음을 의미합니다. 이것이 성능을 향상시키는데, 왜냐하면 파일을 읽고 쓰는 데 필요한 왕복 횟수가 줄어들기 때문입니다. 만약 또 다른 클라이언트/프로세스가 같은 파일을 열려고 하면, 서버는 클라이언트에 메시지를 보내며 (중단 또는 해지라고 합니다), 이는 이전에 클라이언트에 제공된 배타적 잠금을 무효화합니다. 그런-다음 클라이언트는 파일의 모든 변경 사항을 플러시합니다.
Level-2 OpLocks : 만약 배타적 OpLock이 클라이언트에 의해 보유되고 있고 잠긴 파일이 제3자에 의해 열려 있으면, 클라이언트는 다른 클라이언트의 쓰기/읽기 접근을 허용하기 위해 배타적 OpLock을 포기해야 합니다. 그런-다음 클라이언트는 서버로부터 "레벨 2 OpLock"을 받을 수 있습니다. 레벨 2 OpLock은 읽기 요청의 캐싱을 허용하지만 쓰기 캐싱은 제외합니다.
Filter OpLocks : Windows NT 4.0에 추가된, 필터 Oplock은 수준 2 OpLocks와 유사하지만 파일 열기와 잠금 수신 사이의 공유-모드 위반을 방지합니다. Microsoft는 여러 리더를 허용하는 것이 중요한 곳에서만 필터 OpLocks를 사용하고 다른 상황에서 수준 2 OpLocks를 사용할 것을 권장합니다. OpLock을 보유한 클라이언트는 실제로 파일에 대한 잠금을 보유하지 않고, 대신 그것들은 또 다른 클라이언트가 잠금과 일치하지 않는 방식으로 파일에 접근하려고 할 때 중단을 통해 알림을 받습니다. 다른 클라이언트의 요청은 중단이 처리되는 동안 보류됩니다.
Breaks : SMB 프로토콜의 "표준" 동작과 대조적으로, 중단 요청은 서버에서 클라이언트로 전송될 수 있습니다. 그것은 OpLock이 더 이상 유효하지 않음을 클라이언트에 알립니다. 이것은, 예를 들어, 또 다른 클라이언트가 OpLock을 무효화하는 방식으로 파일을 열려고 할 때 발생합니다. 그런 다음 첫 번째 클라이언트는 OpLock 중단을 받고 모든 지역 변경 사항 (배치 또는 배타적 OpLocks의 경우)을 보내고, 어떤 것이라도 있다면, OpLock 중단을 확인해야 합니다. 이 확인에 따라, 서버는 일관된 방식으로 두 번째 클라이언트에 응답할 수 있습니다.
Performance
SMB 프로토콜의 사용은 종종 네트워크의 브로드캐스트 트래픽에서 상당히 증가와 상관 관계를 가져왔습니다. 어쨌든, SMB 자체는 브로드캐스트를 사용하지 않습니다—SMB와 공통적으로 결합된 브로드캐스트 문제는 실제로 NetBIOS 서비스 위치 프로토콜에서 발생합니다. 기본적으로, Microsoft Windows NT 4.0 서버는 NetBIOS를 서비스를 공시하고 찾기 위해 사용했습니다. NetBIOS는 특정 호스트에서 사용 가능한 서비스를 정기적으로 브로드캐스트함으로써 작동합니다. 이것은 보통 호스트 수가 적은 네트워크에서는 허용 가능한 기본값이지만, 증가된 브로드캐스트 트래픽은 네트워크의 호스트 수가 증가함에 따라 문제를 야기할 수 있습니다. Windows Internet Naming Service (WINS) 또는 Domain Name System (DNS)의 형태에서 이름 확인 인프라의 구현은 이 문제를 해결합니다. WINS는 Windows NT 4.0 네트워크에서 사용되는 독점 구현이었지만, Microsoft 네트워크의 설계와 유지 관리에서 고유한 문제와 복잡성을 가져왔습니다.
Windows 2000이 출시된 이래로, 이름 확인을 위한 WINS의 사용은 Microsoft에 의해 중단되어 왔으며, 계층적 동적 DNS가 이제 모든 Windows 운영 시스템의 기본 이름 확인 프로토콜로 구성되었습니다. DNS에 의한 (짧은) NetBIOS 이름의 확인은 DNS 클라이언트가 짧은 이름을 확장하고, 보통 DNS 조회 쿼리에 연결-지정 DNS 접미사를 덧붙임을 요구합니다. WINS는 여전히 레거시 Windows 환경과 응용 프로그램과의 상호 운용성을 위해 클라이언트에서 보조 이름 확인 프로토콜로 구성될 수 있습니다. 게다가, Microsoft DNS 서버는 DNS를 지원하지 않는 레거시 (Windows 2000 이전) 환경과의 이름 확인 통합을 지원하기 위해 레거시 WINS 서버로 이름 확인 요청을 전달할 수 있습니다.
네트워크 설계자들은 지연이 SMB 1.0 프로토콜의 성능에 상당한 영향을 미쳐 왔고, FTP와 같은 다른 프로토콜보다 성능이 떨어진다는 것을 발견했습니다. 모니터링 결과, 높은 수준의 "채팅성"과 호스트 사이의 네트워크 지연 무시가 드러났습니다. 예를 들어, 인터넷을 통한 VPN 연결은 종종 네트워크 지연을 발생시킬 것입니다. Microsoft는 성능 문제가 주로 SMB 1.0이 원래 소규모 LAN을 위해 설계된 스트리밍 프로토콜이 아니라 블록-수준이기 때문에 발생한다고 설명해 왔습니다; 그것은 64K로 제한된 블록 크기를 가지며, SMB 서명은 추가 오버헤드를 생성하고 TCP 윈도우 크기가 WAN 링크에 최적화되지 않았습니다. 이 문제에 대한 해결책은 업데이트된 SMB 2.0 프로토콜, 오프라인 파일, TCP 윈도우 크기 조정 및 SMB 1.0과 2.0을 캐시하고 최적화하는 다양한 네트워크 공급업체로부터 WAN 최적화 장치를 포함합니다.
History
SMB 1.0
Barry Feigenbaum은 원래 1983년 초 IBM에서 DOS INT 21h 지역 파일 접근을 네트워크 파일 시스템으로 전환의 목표와 함께 SMB를 설계했습니다. Microsoft는 가장 공통적으로 사용되는 버전을 상당히 수정하고 1990년경 3Com과 함께 OS/2에 대한 개발을 시작한 LAN Manager 운영 시스템에 SMB 지원을 포함했습니다. Microsoft는 Windows for Workgroups (1992년경) 및 이후 Windows 버전에서 프로토콜에 기능을 계속 추가했습니다. LAN Manager 인증은 IBM "LAN Manager" 암호를 사용해야 하는 원래 레거시 SMB 사양의 요구 사항을 기반으로 구현되었지만, 암호가 해독될 수 있는 결함있는 방식으로 DES를 구현했습니다. 나중에, Kerberos 인증도 추가되었습니다. Windows 도메인 로그온 프로토콜은 더 강력한 128-비트 암호화에 대한 수출 제한으로 인해 미국 외부에서는 처음에 40-비트 암호화를 사용했습니다 (이후 1996년 빌 클린턴 대통령이 행정 명령 13026에 서명하면서 해제되었습니다).
SMB 1.0 (또는 SMB1)은 원래 NetBIOS 프레임 (IEEE 802.2를 통한 NetBIOS)에서 실행되도록 설계되었습니다. 그 이후로, 그것은 IPX/SPX를 통한 NetBIOS (NBX) 및 TCP/IP를 통한 NetBIOS (NetBT)로 조정되어 왔습니다. 역시, Windows 2000부터, SMB는 TCP 포트 445를 사용하는 TCP에서 실행되며, 이 기능은 "직접 호스트 SMB"라고 알려져 있습니다. SMB와 TCP 사이에는 여전히 얇은 계층 (NetBT의 세션 서비스의 세션 메시지 패킷과 유사)이 있습니다. Windows Server 2003, 및 레거시 NAS 장치는 기본적으로 SMB1을 사용합니다.
SMB1은 매우 수다스러운 프로토콜로, 대기 시간이 짧은 지역 영역 네트워크 (LAN)에서는 그렇게 문제가 되지 않습니다. 그것은 프로토콜의 왕복 핸드셰이크가 그러한 네트워크의 고유한 높은 대기 시간을 확대하기 때문에 광역 네트워크 (WAN)에서는 매우 느려집니다. 프로토콜의 이후 버전은 핸드셰이크 교환 횟수를 줄였습니다. 프로토콜에서 비효율성을 완화하는 한 가지 방법은 Riverbed, Silver Peak, 또는 Cisco에 의해 제공되는 것과 같은 WAN 최적화 제품을 사용하는 것입니다. 더 나은 방법은 최신 버전의 SMB로 업그레이드하는 것입니다. 여기에는 NAS 장치와 Windows Server 2003을 모두 업그레이드하는 것이 포함됩니다. SMB1 트래픽을 식별하기 위한 가장 효과적인 방법은 Wireshark와 같은 네트워크 분석기 도구를 사용하는 것입니다. Microsoft는 역시 SMB1을 사용하는 장치를 추적하기 위한 Windows Server 2016에서 감사 도구를 제공합니다.
Microsoft는 2013년 6월에 SMB1을 더 이상 사용하지 않는 것으로 표시했습니다. Windows Server 2016 및 Windows 10 버전 1709에는 기본적으로 SMB1이 설치되어 있지 않습니다.
CIFS
1996년, Sun Microsystems는 WebNFS를 발표했을 때, Microsoft는 SMB의 이름을 Common Internet File System (CIFS)로 바꾸고, 심볼릭 링크, 하드 링크, 더 큰 파일 크기 지원, 및 NetBIOS를 전송 수단으로 요구하지 않고 TCP 포트 445를 통한 직접 연결을 지원하려는 초기 시도 (추가적인 개선이 필요한 대부분 실험적 노력)를 포함한 더 많은 기능을 추가하는 이니셔티브를 시작했습니다. Microsoft는 일부 부분 사양을 IETF에 인터넷 초안으로 제출했습니다. 이들 제출은 그 이후로 만료되었습니다.
SMB 2.0
Microsoft는 2006년 Windows Vista와 Windows Server 2008과 함께 새로운 버전의 프로토콜 (SMB 2.0 또는 SMB2)을 도입했습니다. 이 프로토콜은 독점적이지만, 해당 사양은 새 프로토콜을 사용하는 Microsoft 운영 시스템과 다른 시스템이 상호 운용할 수 있도록 공개되었습니다.
SMB2는 명령과 하위-명령의 수를 100개 이상에서 19개로 줄임으로써 SMB 1.0 프로토콜의 '수다스러움'을 줄입니다. 그것은 파이프라인에 대한 메커니즘을 가지며, 즉, 이전 요청에 대한 응답이 도착하기 전에 추가 요청을 보내며, 이에 따라 높은-지연 링크에서 성능을 개선합니다. 그것은 여러 동작을 단일 요청으로 합성하는 기능을 추가하여, 클라이언트가 서버로 이동해야 하는 왕복 횟수를 크게 줄여, 결과적으로 성능을 개선합니다. SMB1에는 역시 여러 동작을 합성하는 AndX라고 알려져 있는 합성 메커니즘이 있지만, Microsoft 클라이언트는 AndX를 거의 사용하지 않습니다. 그것은 역시 "내구성 있는 파일 핸들"이라는 개념을 도입했습니다: 이를 통해 무선 네트워크에서 일반적인 것처럼 새 세션을 다시 협상하는 오버헤드가 발생하지 않고도 SMB 서버에 대한 연결이 짧은 네트워크 중단을 견뎌낼 수 있습니다.
SMB2는 심볼릭 링크에 대한 지원을 포함합니다. 다른 개선 사항은 다른 것들 중에서 파일 속성의 캐싱, HMAC SHA-256 해싱 알고리즘을 갖는 향상된 메시지 서명, 및 서버당 사용자, 공유와 열린 파일 수를 늘려 더 나은 확장성을 포함합니다. SMB1 프로토콜은 16-비트 데이터 크기를 사용하며, 이는 무엇보다도 최대 블록 크기를 64K로 제한합니다. SMB2는 32-비트 또는 64-비트 폭의 저장 필드를 사용하고, 파일-핸들의 경우에서 128 비트를 사용하여, 이에 따라 블록 크기에 대한 이전 제약 조건을 제거하여, 빠른 네트워크를 통한 대용량 파일 전송 시 성능을 향상시킵니다.
Windows Vista/Server 2008와 이후 운영 시스템은 SMB2를 사용할 수 있는 다른 기계와 통신할 때 SMB2를 사용합니다. SMB1은 오래된 버전의 Windows와 다양한 공급 업체의 NAS 솔루션과 연결하는 데 계속 사용됩니다. Samba 3.5는 역시 SMB2에 대한 실험적 지원도 포함됩니다. Samba 3.6은 Windows 할당량 관리 도구를 사용한 사용자 할당량의 수정을 제외하고 SMB2를 완전히 지원합니다.
SMB2가 도입되었을 때, 그것은 SMB 프로토콜의 제3자 구현자에게 SMB1에 걸친 여러 가지 혜택을 가져왔습니다. SMB1은, 원래 IBM에 의해 설계되었으며, 역 엔지니어링되었고, 나중에 Xenix, OS/2, 및 VMS (Pathworks)와 같은 다양한 비-윈도우 운영 시스템의 일부가 되었습니다. 그것은 부분적으로 X/Open 표준화되었습니다; Microsoft는 2000년 12월 네트워크 파일 시스템의 공식적인 IETF 표준화에 대한 부분적 응답으로 IETF RFC 3010으로 SMB2를 IETF에 설명하는 인터넷-초안을 IETF에 제출했습니다; 어쨌든, 그것들 SMB-관련 인터넷-초안은 IETF 표준-트랙 승인 또는 임의의 다른 IETF 승인을 얻지 않고 만료되었습니다. (역사적 세부 사항에 대해 http://ubiqx.org/cifs/Intro.html을 참조하십시오.) SMB2는 역시 과거와 비교적 깨끗한 휴식입니다. Microsoft의 SMB1 코드는 다양한 SMB 클라이언트와 서버와 동작해야 합니다. SMB1은 유니코드 지원과 같은 기능이 나중에 복고풍에 적합했기 때문에 SMB1은 명령에 대한 정보 (특정 요청을 위해 어떤 구조를 반환할 것인지 선택)를 특징으로 합니다. SMB2는 프로토콜의 구현자를 위한 호환성 테스트를 크게 줄입니다. SMB2 코드는 훨씬 적은 변동성이 존재하기 때문에 상당히 복잡성이 적습니다 (예를 들어, 비-유니코드 코드 경로는 유니코드 지원을 요구함에 따라 중복하게 됩니다).
Apple은 OS X 10.9 "Mavericks"부터 시작하여 (현재 레거시, 자신의 Apple Filing Protocol로부터) SMB2로 마이그레이션했습니다. 이 전환은 호환성 문제로 가득 차 있었습니다. SMB2에 대한 비-기본 지원은 실제로 Samba가 GPLv3를 채택한 후 Apple은 SMBX라는 자체 SMB 구현을 선호하여 Samba를 포기했을 때 실제로 OS X 10.7에 나타났습니다.
리눅스 커널의 CIFS 클라이언트 파일 시스템은 버전 3.7 이후 SMB2를 지원합니다.
SMB 2.1
Windows 7 및 Server 2008 R2와 함께 소개된 SMB 2.1은 새로운 기회 잠금 메커니즘으로 약간의 성능 향상을 도입했습니다.
SMB 3.0
SMB 3.0 (이전에 SMB 2.2)은 Windows 8 및 Windows Server 2012와 함께 소개되었습니다. 그것은 특히 가상화된 데이터 센터에서 기능을 추가하고 SMB2 성능을 향상시키기 위해 의도된 몇 가지 중요한 변화를 가져왔습니다:
그것은 역시 엔드-투-엔드 암호화 및 새로운 AES 기반 서명 알고리즘과 같은 몇 가지 보안 향상을 소개합니다.
SMB 3.0.2
SMB 3.0.2 (당시 3.02로 알려짐)는 Windows 8.1 및 Windows Server 2012 R2에서 도입되었습니다; 그것들과 이후 릴리스에서, 이전 SMB 버전 1은 보안을 높이기 위해 선택적으로 비활성화될 수 있습니다.
SMB 3.1.1
SMB 3.1.1은 Windows 10 및 Windows Server 2016과 함께 소개되었습니다. 이 버전은 SMB3에 추가된 AES-128 CCM 암호화 외에도 AES-128 GCM 암호화를 지원하고, SHA-512 해시를 사용하여 사전-승인 무결성 검사를 구현합니다. SMB 3.1.1은 역시 그것을 지원하는 SMB 버전을 사용하여 클라이언트에 연결할 때 필수적으로 안전한 협상을 만듭니다.
Specifications
SMB에 대한 사양은 독점적이고 처음에는 폐쇄형이며, 이에 따라 다른 공급 업체와 프로젝트가 프로토콜을 그것과 상호 작용하도록 역 엔지니어링해야 합니다. SMB 1.0 프로토콜은 역 엔지니어링 된 후 얼마 지나지 않아 SMB 2.0 프로토콜은 처음부터 Microsoft의 Open Spections Developer Center에서 제공되었습니다.
Third-party implementations
Samba
1991년, Andrew Tridgell은 SunOS에서 파일을 접근하기 위해 DEC Pathworks 클라이언트를 실행하는 PC 클라이언트틀 허용하기 위해 SMB 서버를 구현하기 위해 유닉스-계열 시스템에 대해 SMB/CIFS 네트워킹 프로토콜의 자유-소프트웨어 재-구현 (역 엔지니어링 사용), Samba의 개발을 시작했습니다. 광범위한 Microsoft Windows 플랫폼과 상호 작용할 때 SMB 프로토콜의 중요성으로 인해, Samba는 유닉스-계열 운영 시스템과 같은 비-윈도우 운영 시스템에게 Windows와 상호 운용하도록 허용하기 위해 호환 가능한 SMB 클라이언트와 서버의 인기있는 자유 소프트웨어 구현이 되었습니다.
버전 3 (2003) 기준, Samba는 Microsoft Windows 클라이언트에 대해 파일 서버와 인쇄 서비스를 제공하고 Primary Domain Controller (PDC) 또는 도메인 구성원으로 Windows NT 4.0 서버 도메인과 통합할 수 있습니다. Samba4 설치는 Windows 2008 도메인 및 숲(forest) 기능 수준에서 Active Directory 도메인 컨트롤러 또는 구성원 서버 역할을 할 수 있습니다.
리눅스 배포판에서 패키지 관리자는 cifs-utils 패키지를 검색할 수 있습니다. 패키지는 삼바 관리자로부터 온 것입니다.
Netsmb
NSMB (NETSMB 및 SMBFS)는 BSD 운영 시스템에서 커널-내 SMB 클라이언트 구현의 가족입니다. 그것은 Boris Popov에 의해 FreeBSD에 처음 기여되었고, 현재 NetBSD와 macOS를 포함한 다양한 BSD 시스템에서 발견되었습니다. 구현은 그 이후로 크게 분기되어 왔습니다.
NSMB의 macOS 버전은 symlinks를 대표하는 지금-공통 체계에 유명합니다. 이 "Minshall-French" 형식은 symlinks를 .symlink 확장자와 Xsym\n 마법 번호를 갖는 항상 1067 바이트 길이 텍스트 파일로 표시합니다. 이 형식은 역시 네이티브 SMB 서버 또는 지원되지 않는 파일 시스템에 symlinks를 저장하는 데 사용됩니다. Samba는 mfsymlink 옵션을 갖는 이 형식을 지원합니다. Windows에서 Docker도 그것을 사용하는 것 같습니다.
NQ
NQ는 1998년 이전의 Siemens Data Communications의 CEO, Sam Widerman에 의해 설립된 이스라엘-기반 회사, Visuality Systems에 의해 개발된 휴대용 SMB 클라이언트와 서버 구현의 가족입니다. NQ 가족은 임베디드 SMB 스택 (C로 작성), 순수한 자바 SMB 클라이언트, 및 스토리지 SMB 서버 구현으로 구성됩니다. 모든 솔루션은 최신 SMB 3.1.1 방계를 지원합니다. NQ for Linux, NQ for WinCE, iOS, Android, VxWorks, 및 기타 실시간 운영 시스템은 모두 구성 가능한 NQ 솔루션에 의해 지원됩니다.
MoSMB
MOSMB는 리눅스에 대한 사용자 공간 SMB 구현입니다. 그것은 SMB 2.X 및 SMB 3.X를 지원합니다. 주요 기능에는 클라우드-규모 활성-활성 스케일-아웃 클러스터, SMB Direct (RDMA), SMB 다중-채널, 투명한 장애-조치, 및 지속적인 가용성이 포함됩니다. MOSMB는 역시 ext4, ZFS, Lustre, Ceph, 등과 같은 POSIX 파일 시스템 외에도 Amazon S3 객체 스토리지를 스토리지 백엔드로 지원합니다.
Fusion File Share by Tuxera
Tuxera에 대해 Fusion 파일 공유는 Tuxera에 의해 개발된 커널 또는 사용자 공간에서 실행될 수 있는 독점적인 SMB 서버 구현입니다. 그것은 SMB 3.1.1 및 모든 이전 버전을 추가하고, 추가적으로 연속 가용성 (영구 핸들) 스케일 아웃, RDMA (SMB Direct), SMB 다중-채널, 투명 압축, 그림자 사본과 같은 고급 SMB 기능을 지원합니다.
Likewise
마찬가지로 2009 년에 CIFS/SMB 구현 (버전 1.0, 2.0, 2.1 및 SMB 3.0)을 개발하여 리눅스/유닉스 기반 장치에 구축된 OEM 스토리지 제품에 사용되는 파일에 대한 네트워크 접근을 위한 다중- 프로토콜, ID-인식 플랫폼을 제공했습니다. 그 플랫폼은 기존 NAS, 클라우드 게이트웨이, 및 클라우드 캐싱 장치에 네트워크에 걸쳐 파일에 대한 안전한 접근을 제공하는 데 사용될 수 있습니다. 마찬가지로 2012년 EMC Isilon이 구입했습니다.
KSMBD
KSMBD는 리눅스 커널에 대해 오픈 소스 커널-내 CIFS/SMB 서버 구현입니다. 사용자-공간 구현과 비교하여, 그것은 더 나은 성능을 제공하고 SMB Direct와 같은 일부 기능을 보다 쉽게 구현할 수 있습니다. 그것은 SMB 3.1.1 및 이전 버전을 지원합니다.
Security
수년에 걸쳐, Microsoft가 직접 의존하는 프로토콜 또는 구성 요소 구현에는 많은 보안 취약점이 있었습니다. 다른 공급 업체의 보안 취약점은 주로 NTLMV1, LanMan, 또는 일반-텍스트 암호와 같은 프로토콜을 선호하여 NTLMv2 및 Kerberos와 같은 더 최신 인증 프로토콜에 대한 지원의 부족에 놓여 있습니다. 실시간 공격 추적은 SMB가 침입 시도의 주요 공격, 예를 들어, 2014 Sony Pictures 공격, 및 2017 년의 WannaCry 랜섬웨어 공격에 대한 주요 벡터 중 하나임을 보여줍니다. 2020년에, 2개의 SMB 고세 취약성이 SMBGhost (CVE-2020-0796) 및 SMBleed (CVE-2020-1206)로 공개되고 더빙되었으며, 이는 함께 묶을 때 RCE (원격 코드 실행) 특권을 공격자에게 제공할 수 있습니다.
