INTEL CPU 버그 -> 커널 스페이스 메모리가 유저 스페이스로 유출


https://lkml.org/lkml/2017/12/27/2

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/?id=a89f040fa34ec9cd682aed98b8f04e3c47d998bd

Xen : XSA-253 : https://xenbits.xen.org/xsa/advisory-253.html


Xen은 Paravirtual만 해당 된다는 얘기가 있다. AWS Korea는 전부 HVM이므로 해당이 없을지도..


Softlayer는 1월 6일 00시부터 이틀에 걸처 전체 Host를 리부팅 해서 패치 한다.


패치로 인해 성능이 5%~30% 저하된다는 벤치마크 결과가 있다. 특히 IO 쪽이 문제되는 듯.

http://www.phoronix.com/vr.php?view=25767


=======================================================================

지난 10 년 동안 생산 인텔 프로세서는 치명적인 칩 수준의 보안 버그를 가지고 있습니다.  OS 레벨에서 수정 사항이 나와야한다고보고하고, 수정본을 사용할 수있는 경우에도 주목할만한 성능 저하가있을 것입니다.

 

이 보고서는이 시점에서 버그에 대해 알려진 바가 크지 않다고 설명하지만, "지난 10 년 간 생산 된 최신 인텔 프로세서에 존재하는"근본적인 설계 결함 "이라고 지적했다.


이 버그로 인해 사용자 프로그램은 보호 된 커널 메모리의 내용을 식별 할 수있게되어 해커가 다른 보안 버그를보다 쉽게 ​​악용 할 수 있습니다. 등록 메모에 따르면, 실제로는 그보다 더 나쁠 수 있습니다. 커널 메모리에 대한 액세스를 제공하는이 버그는 "프로그램과 로그인 한 사용자가 커널 메모리의 내용을 읽을 때 악용 될 수 있습니다."


커널의 메모리 공간은 암호, 로그인 키, 디스크에서 캐시 된 파일 등과 같은 모든 종류의 비밀을 포함 할 수 있으므로 사용자 프로세스 및 프로그램에서 숨겨집니다. 브라우저에서 실행되는 JavaScript 또는 공유 된 공용 클라우드 서버에서 실행되는 악성 소프트웨어가 민감한 커널 보호 데이터를 스니핑 할 수 있다고 상상해보십시오.


이 칩 레벨 보안 버그에 대한 패치도 그리 좋지 않습니다. 이 보고서는이 시점에서 더 구체적인 정보가 명확하지 않더라도 수정으로 인해 5 % ~ 30 %의 속도 저하가 발생할 수 있다고 설명합니다. 속도 저하는 프로세서가 캐시 된 데이터를 덤프하고 메모리에서 정보를 다시로드해야하는 방식으로 인해 발생합니다.


현재 Microsoft 및 Linux 개발자는이 문제를 해결하기 위해 노력하고 있습니다. 이 결함은 인텔의 x86 하드웨어에 결함이 있기 때문에 인텔 기반 맥에도 영향을 미치지 만, 애플의 수정 작업은 불분명하다. 결함이 하드웨어 자체에 있기 때문에 정상적인 마이크로 코드 업데이트로 해결할 수는 없지만 오히려 OS 레벨의 수정이 필요합니다.


이러한 커널 페이지 테이블 격리 패치는 커널을 완전히 별도의 주소 공간으로 이동하므로 실행중인 프로세스에서 보이지 않을뿐 아니라 전혀 존재하지 않습니다. 실제로는 필요하지 않지만 Intel의 실리콘에는 커널 액세스 보호가 어떤 식 으로든 무시 될 수있는 결함이 있습니다.


이 분리의 단점은 모든 시스템 호출과 하드웨어의 모든 인터럽트에 대해 두 개의 개별 주소 공간을 전환하는 것은 비교적 비용이 많이들고, 시간이 많이 걸린다는 점입니다. 이러한 컨텍스트 스위치는 즉시 발생하지 않으며 프로세서가 캐시 된 데이터를 덤프하고 메모리에서 정보를 다시로드하도록합니다. 이렇게하면 커널의 오버 헤드가 증가하고 컴퓨터 속도가 느려집니다.


개발자가 패치 작업을 할 때 버그에 대한보다 구체적인 정보가 현재 금하고 있다고 추측합니다. 다음 주 곧 Intel에서 직접 더 많은 세부 정보를 얻을 수 있습니다.

/etc/strongswan/ipsec.confLinux는 IPSec VPN을  위해서 기본적으로 OpenSwan 또는 StrongSwan 패키지를 지원한다.

Windows도 RRAS를 통해 자체적으로 지원한다. 

http://docs.aws.amazon.com/ko_kr/AmazonVPC/latest/NetworkAdminGuide/customer-gateway-windows-2012.html

http://techgenix.com/configure-vpn-windows-server-2012-r2/


아무래도 Linux가 설정이나 트러블 슈팅하기가 더 쉽다. Linux 머신만 있으면 VPN장비 부럽지 않다.

고급 설정이 좀 더 가능한 StrongSwan을 사용해보자. (물론 여기서 고급기능을 쓰지는 않지만...)


사실 AWS, Azure, Softlayer, Alibaba 아무관계가 없다. 모두 IPSec VPN 서비스가 있지만, 가끔 이렇게 직접 구축이 필요할 때가 있다.

다만 Softlayer는 Router Roll은 vyatta에 한정되어 있으므로, 서버에 VPN을 구축할 경우

모든 서버의 라우팅에 VPN서버를 별도 추가 해주어야 하는 불편함은 있다. (하지만, 그냥 하면 되므로 불편한거지 어려운 부분은 아니다)

vyatta을 쓰면 vyatta에서 모두 지원하므로 이렇게 쓸일이 없지만, vyatta는 비싸므로 서버만 쓰는 경우를 예로 든다.


CentOS7 기준으로 설명한다. 

설정 편의를 위해 PSK(PreSharedKey)로 설정한다. 네트워크 정보는 아래를 예시로 했다.

 

 VPN 서버 Public IP

 Network 사설 대역

 A쪽 Network

 169.11.22.33

 10.100.50.0/24

 B쪽 Network

 211.66.77.88

 192.168.20.0/24


일단 ip_forward를 활성화한다. 그리고 strongswan을 설치 및 자동 실행 설정을 한다.

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.d/ip_forward.conf
sysctl -p /etc/sysctl.d/ip_forward.conf
cat /proc/sys/net/ipv4/ip_forward

yum install -y epel-release
yum install -y strongswan

systemctl enable strongswan
systemctl start strongswan


설정은 ipsec.conf 만 해주면 되고, PSK는 ipsec.secret에 적어주면 끝이다.

아래 설정은 A쪽 설정이다, B쪽은 left와 right쪽 정보만 반대로 해주면 된다.

/etc/strongswan/ipsec.conf

# ipsec.conf
config setup
  strictcrlpolicy=no
  uniqueids=no
  charondebug="cfg 2, ike 2, knl 2"
#  charondebug="dmn 2, mgr 2, ike 2, chd 2, job 2, cfg 2, knl 2, net 2, enc 2, lib 2"

conn %default
  ikelifetime=14400
  keylife=3600
  keyexchange=ikev2

conn sample
  authby=secret
  auto=start
  type=tunnel
  leftauth=psk
  rightauth=psk
  left=169.11.22.33
  right=211.66.77.88
  leftsubnet=10.100.50.0/24
  rightsubnet=192.168.20.0/24
  ike=aes256-sha256-modp2048
  esp=aes256-sha256-modp2048


/etc/strongswan/ipsec.secret

# ipsec.secret
169.11.22.33 : PSK "Cloud1004@Test"
211.66.77.88 : PSK "Cloud1004@Test"


양단 설정이 다 되었으면 재 시작 하고 터널 상태를 확인한다.

strongswan restart
strongswan statusall



잘 안될경우 로그를 확인한다.  로그 레벨과 파트는 ipsec.conf에서 charondebug 부분을 참조 해서 변경한다. 경우에 따라 tcpdump 를 볼 필요성도 있다.

tail -f /var/log/message /var/log/secure

AWS/Alibaba는  라우팅 설정에서 상대편 대역은 해당 서버로 가게 끔 추가 해 준다.

IBM Cloud는 vyatta를  안쓰면 라우팅 설정을 못 바꾸므로 연결되는 모든 서버에서 각각 라우팅을 추가 해주어야 한다.
(VPN 장비의 사설 IP가 10.100.50.100 이라고 할 때)

리부팅 되도 유지되도록 설정한다.

Windwos의 경우 route add 명령에 -p 옵션만 주면 영구 설정이 되며 재부팅시 유지된다.
실제 다음 레지스트리에 기록된다.
HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\TCPIP\PARAMETERS\PERSISTENTROUTES

route -p add 10.100.50.0 MASK 255.255.255.0 10.100.50.100 METRIC 1
route print

Linux는 /etc/sysconfig/network-scripts/route-eth0 넣고 
systemctl restart network 해주면 된다.

echo "10.100.50.0/24 via 10.100.50.100" >> /etc/sysconfig/network-scripts/route-eth0
systemctl restart network
ip route


단순히 테스트 할 때는 아래 처럼 하면 된다. 

Windows

route add 10.100.50.0 MASK 255.255.255.0 10.100.50.100 METRIC 1
route print

Linux

ip route add 10.100.50.0/24 via 10.100.50.100
ip route


'OS > Linux' 카테고리의 다른 글

firewalld 설정  (0) 2018.11.04
SAMBA 설치 at CentOS 7  (0) 2018.08.29
vimdiff 사용법  (0) 2018.04.21
Linux 에서 IP 추출  (0) 2018.04.21
랜덤 내용 특정 사이즈 더미 파일 만들기  (0) 2018.02.21

+ Recent posts