이것은 램프 스택 보안에 대한 정식 질문입니다

LAMP 서버 보안을위한 절대적인 지침은 무엇입니까?

David의 대답은 서버 강화의 일반적인 원칙에 대한 좋은 기준입니다. 다윗이 지적했듯이 이것은 큰 질문입니다. 사용하는 특정 기술은 환경 및 서버 사용 방법에 따라 크게 달라질 수 있습니다. 경고 : 테스트 환경에서 빌드하고 올바르게 수행하려면 많은 작업이 필요할 수 있습니다. 프로덕션 환경과 비즈니스 프로세스에 통합하기위한 많은 작업이 뒤 따릅니다.

그러나 먼저 가장 직접적으로 관련이있는 강화 정책이 조직에 있는지 확인하십시오. 그렇지 않은 경우, 귀하의 역할에 따라이를 구축하기에 좋은시기입니다. 또한 각 구성 요소를 상향식에서 별도로 처리하는 것이 좋습니다.

L
당신을 도울 수있는 좋은 안내서가 많이 있습니다. 이 목록은 배포판에 따라 도움이되거나 도움이되지 않을 수 있습니다.

• 인터넷 보안 벤치 마크 센터 -주요 특징에 따른 배포
• CentOS 강화 방법-CIS RHEL5 가이드를 따르지만 훨씬 쉽게 읽을 수 있습니다
• NIST SP800-123-일반 서버 보안 안내서
• NSA 강화 사실 표-CIS 만큼 최근에 업데이트되지는 않았지만 여전히 대부분 적용 가능
• Tiger- 라이브 시스템 보안 감사 소프트웨어

A
Apache는 보안을 유지하는 것이 재미있을 수 있습니다. Apache 또는 PHP보다 OS를 강화하고 사용성을 유지하는 것이 더 쉽다는 것을 알았습니다.

• Apache Server 강화 -IT 보안 자매 사이트에 관한이 질문에는 많은 정보가 있습니다.
• 인터넷 보안 벤치 마크 센터 -Apache 벤치 마크.
• Apache 보안 팁 -Apache 프로젝트에서 바로 기본 사항을 다루는 것처럼 보입니다.
• DISA 강화 검사 목록-DoD Information Assurance 직원의 검사 목록

M

• 인터넷 보안 벤치 마크 센터 -다시 말하지만 MySQL 벤치 마크
• OWASP MySQL 강화
• 일반 보안 지침 -프로젝트 개발자의 기본 점검 목록

P
이것은 보안 프로그래밍 실습에 대한 전체 아이디어로, 그 자체의 전체 학문입니다. SANS와 OWASP는이 주제에 관한 우스운 양의 정보를 가지고 있으므로 여기서 복제하지는 않겠습니다. 런타임 구성에 중점을두고 개발자가 나머지 부분에 대해 걱정하도록하겠습니다. 때때로 LAMP에서 'P'는 Perl을 가리 키지 만 보통 PHP를 말합니다. 나는 후자를 가정하고 있습니다.

• PHP 강화 -IT 보안 SE 사이트에서도 약간의 토론이 있습니다.
• 강화 된 PHP 프로젝트 - 특정 유형의 공격에 대비하여 PHP 응용 프로그램을 패치하려는 Suhosin 을 생성하는 주요 프로젝트입니다 .
• Suhosin으로 PHP 강화-Suhosin을 위한 간단한 HowTo
• php.ini에서 PHP 강화 -일부 보안 관련 런타임 옵션에 대한 짧지 만 나쁘지 않은 토론

솔직히이 주제에 관한 몇 권의 책에 합당한 질문을했습니다. 그러나 잘 작동하는 일반적인 기본 지침이 있습니다.

1. 업데이트 유지. 이것은 운영 체제, 모든 서비스 및 특히 실행중인 모든 웹 응용 프로그램을 의미합니다.
2. 불필요한 서비스를 비활성화하고 필요한 노출을 최소 노출로 제한하고 (원격으로 MySQL에 연결하지 않고 TCP에서 수신 대기하지 않는 경우) 호스트 기반 방화벽을 실행하십시오. (엄격히 LAMP 인 경우 80 및 443에는 적합하지만 관리에는 SSH가 필요할 수 있습니다.)
3. 강력한 비밀번호를 사용하십시오. 더 나은 방법은 SSH를 사용하는 경우 키 기반 인증 만 사용하는 것입니다.
4. 루트로 로그인하지 않았는지 확인하십시오. 사용자로 로그인하고 su & sudo를 사용하십시오.
5. 더 안전하지는 않지만 서버에서 무슨 일이 일어나고 있는지 알 수 있도록 logwatch와 같은 도구를 실행해야합니다.

시작하는 데 도움이되기를 바랍니다.

여기에 내가 좋아하는 점검표가 있습니다.

방화벽

• 좋은 접근 방식은 트래픽이 시작되지 않도록 하고 필요한만큼만 열어야 합니다. 그 결과 작동을 위해 최소 포트 / IP를 열어 노출을 최소화합니다.
• LAMP 서버의 경우 http / https의 포트를 월드로, ssh는 sysadmins의 포트만 열면됩니다.
• ipv6 트래픽과 같은 것을 사용하지 않으면 잠겨 있어야합니다.
• AWS는 보안 그룹, Linux에는 iptables 및 다양한 패키지를 제공합니다.

SSH 및 사용자

• SSH 액세스를위한 비밀번호 가 없습니다 (개인 키 사용)
• root가 ssh를 허용하지 않도록 하십시오 (적절한 사용자가 ssh를 입력 한 다음 su 또는 sudo해야 함)
• 사용자에게 sudo를 사용하여 명령을 기록하십시오.
• 무단 로그인 시도 기록 (fail2ban과 같이 서버에 너무 여러 번 액세스하려는 사용자를 차단 / 금지하는 소프트웨어 고려)
• 비표준 포트의 ssh
• ssh를 필요한 IP 범위에만 고정하십시오 (큰 범위는 범위가없는 것보다 낫습니다)

데이터 베이스

• 사용자 데이터 삭제
• 검색어 매개 변수화
• DB를 자체 머신으로 추상화하십시오. 이렇게 분리하면 공격자가 웹 스택에 접근하는 것이 더 어려워지고 그 반대도 마찬가지입니다.
• 최신 소프트웨어를 유지하는 것이 중요합니다.
• 각 목적을위한 사용자 . 사용자를 만들 때는 권한없이 시작하여 역할을 수행하는 데 필요한 권한 만 추가하십시오. 다른 응용 프로그램 (또는 때로는 응용 프로그램의 다른 부분)에 대해 별도의 사용자를 보유하면 공격자가 한 계정을 손상시키는 이점을 줄일 수 있습니다. 가볍게 할당해서는 안되는 GRANT와 같은 특별한 권한에주의하십시오.
• 정기적으로 비밀번호를 변경하는 정책을 갖는 것이 좋습니다. 필요한 노력의 양이 걱정된다면 덜 자주 기억하는 것이 결코 낫지 않다는 것을 기억하십시오.
• 비밀번호 암호화 이해 소금 암호 . md5를 사용하지 마십시오!

소프트웨어

• 소프트웨어를 최신 상태로 유지하십시오 (OS, 웹 서버, 스크립팅 언어, CMS). 많은 사람들이 이전 (패치되지 않은) 버전에서 알려진 취약점을 검사합니다.
• 필요없는 소프트웨어 제거
• 파일 권한이 잠겨 있는지 확인하십시오 (특히 사용자 업로드 및 구성 파일과 같은 경우).
• 웹 서버 수준에서 CMS의 관리 영역을 암호로 보호 ( http 인증 은 취약한 CMS 앞에 앉아 액세스를 차단할 수 있으므로 공격을 방지하는 좋은 방법 임)
• 관리 영역 및 기타 중요한 데이터에 SSL 사용
• 서버 및 인프라 관리를 자동화하십시오 (Puppet, Chef 또는 SaltStack과 같은 것. AWS CloudFormation을 사용하는 경우에도). 이를 통해 많은 서버에 패치를 적용하고 서버 A에 대한 권한을 수정하지만 서버 B에 대해서는 잊어 버리는 등의 시나리오를 줄일 수 있습니다.
• 가능한 경우 CMS, PHP 또는 WebServer의 특정 버전을 제공하지 마십시오. 이 정보를 모호하게하는 것은 보안이 아니지만 많은 다른 소프트웨어 버전을 검색하는 사람들이 많으며 공격자가 더 많은 작업을할수록 자유롭게 제공하는 정보가 적습니다. 이것은 교수형 과일이 아닌지 확인하는 좋은 방법입니다. 물론 이것은 조금 더 노력을 기울이고 싶은 사람에게는 아무것도하지 않을 것입니다.
• 서버에 액세스 할 수있는 사람을 제한하십시오

David가 제안한 것에 덧붙여, 모듈 식 설치 일수록 한 작업을 위해 특별히 생성 된 특정 사용자 / 그룹에 대한 액세스를 제한하고 범위를 제한할수록 LAMP 스택이 더 안전 해집니다. 예를 들어 Apache 사용자가있는 것입니다. 중요한 시스템 파일 / 폴더에 액세스 할 수있는 그룹이 아닌 권한이 설정된 Apache 파일 / 폴더의 경우 서비스 할 웹 사이트와 관련된 MySql 테이블에 액세스 할 수있는 사용자 및 해당 테이블 만. 또한 PHP 호출에서 최소한의 액세스 권한을 제공하도록 액세스를 제한 할 수 있습니다. 또한 PHP 파일을 통해 사용 / 노출 된 MySQL 사용자 이름이 다른 사용자에 사용 된 것과 동일한 사용자 이름 또는 비밀번호가 아닌지 확인하십시오.

의미 : 아파치 사용자 또는 MySql 사용자가 손상된 경우 아파치가 액세스 할 수있는 폴더 범위 (아파치 사용자의 경우)와 테이블 외부에 피해를 줄 수 없습니다 ( s) / 데이터베이스 (MySQL 데이터베이스 사용자의 경우).

예를 들어, MySQL 사용자가 손상을 입었다면 데이터베이스에 액세스하여 MySQL에서 모든 데이터베이스를 삭제하고 모든 데이터를 망칠 수 없었습니다. 어떤 상황에서는 격리 된 데이터베이스의 테이블을 삭제하거나 일부 테이블에 정보를 삽입 할 수 있습니다. 따라서 절대적으로 필요한 경우에만 테이블 액세스 권한을 부여하고 필요한 권한 만 부여하는 것이 중요합니다 ... 테이블 삭제 권한이나 업데이트 권한이 없어도 해당 사용자에게 부여하지 마십시오.

또한 어떤 이유로 든 관리 계정 사용자 이름과 비밀번호가 MySQL에 대해 발견 된 경우, 시스템의 사용자 이름과 다른 사용자 이름을 사용하는 경우 데이터베이스를 손상시키기 전에 먼저 시스템 보안을 해제해야합니다. 아파치 사용자와 파일에 대한 액세스도 마찬가지입니다.

시간 예! 아이디어를 단순화하는 시스템 예제를 제공 할 것입니다.

시스템에 사용자가 있다고 가정하십시오 (루트는 umod -l 또는 passwd -l 등을 통해 보안을 위해 비활성화되어야 함) : john, barney, terence 및 lisa.

bigbird라는 이름으로 MySQL에서 사용자를 만들 수 있습니다 (해시 된 암호를 사용해야합니다). Bigbird에는 선택 권한과 업데이트 권한 만 있지만 삭제하거나 만들 수 없으며 확실하지 않습니다 . 또한 MySQL 데이터베이스에서 작업하기 위해 이름이 garfield 인 다른 관리 MySQL 사용자를 작성하고 루트 사용자를 MySQL 데이터베이스에서 삭제하여 사용자가이를 이해할 수 없게합니다. 가필드가 부여되었습니다 . MySQL 전체에 대한 권한 (효과적으로 루트의 이름을 바꿉니다).

이제 아파치 그룹 또는 사용자를 생성하고이를 apweb2라고합니다. Appweb2는 다른 그룹의 구성원이 아니며 아파치의 모든 파일 / 폴더는 / home / apweb2 /에 저장됩니다. 각 가상 호스트에는 자체 하위 폴더가 있으며 이러한 각 호스트에는 해당 하위 폴더로 설정된 문서 루트가 있습니다. 실수로 나머지 시스템에 대한 액세스를 제공하지 않기 위해 심볼릭 링크가 비활성화됩니다.

또한 ssh 액세스를 특정 사용자 (또는 특정 그룹, ssh 그룹에 넣고 ssh를 사용할 수있는 유일한 항목)로 제한 할 수 있습니다.

또한 sudo 권한을 가진 사용자를 선택하여 더 제한 할 수 있습니다. 추가로 취할 수있는 또 다른 단계는 ssh 사용자가 sudo를 수행 할 수 없도록하는 것입니다. ssh를 사용할 수없는 sudo를 사용할 수있는 특수 사용자를 작성할 수 있으므로 ssh에 로그인하면 다른 사용자로 로그인해야합니다. sudo에 액세스하십시오.

따라서 각 세그먼트를 모듈화하여 하나의 세그먼트가 손상되면 전체 스택이 손상되지 않으며 처음부터 다시 시작하지 않고 1 개의 문제를 해결할 수 있습니다.

SANS.org에서이 문서가 도움이된다는 것을 알았습니다. http://www.sans.org/score/checklists/linuxchecklist.pdf

현재 컨테이너 가상화, 즉 Docker, systemd-nspawn 및 컨테이너 가상화 메커니즘 (네임 스페이스, cgroup)을 무시하지 마십시오. 컨테이너 가상화를 사용하면 예를 들어 서비스 중 하나가 손상된 경우 공격자가 다른 서비스에 액세스 할 수없는 프로세스를 격리 할 수 ​​있습니다.

LAMP의 경우, 예를 들어 SSH-server, Apache, MySQL, PHP-FPM / Python / Perl / etc와 함께 4 개의 Docker 컨테이너를 사용할 수 있습니다.