서버 속도를 저하시키는 FAPolicyD 오버헤드

Question

실행된 프로그램 목록을 허용하는 것은 가장 효과적인 보안 기능 중 하나입니다. 그렇지 않으면 손상된 사용자 계정이 임의의 페이로드를 실행할 수 있습니다. 또는 사용자는 설치해서는 안되는 프로그램을 홈 디렉토리에 설치합니다. 활성화 여부를 결정하는 선택적 기능이지만.

이러한 모든 파일 시스템 호출을 검사하면 성능이 저하됩니다. 규칙과 데이터베이스를 최적화하면 오버헤드를 최소화할 수 있습니다.

사용자 관점에서 성능이 수용 가능한지 측정합니다. "애플리케이션 API 호출의 99.9%가 1초 이내에 완료됩니다"와 같은 응답 시간 중심 목표는 리소스 활용 추세뿐만 아니라 실제 문제도 감지합니다.

먼저 fapolicyd에 대한 배경 지식을 보려면 다음의 성능 소개를 참고하세요.읽어보기:

성능

프로그램이 파일을 열거나 execve를 호출하면 해당 스레드는 fapolicyd가 결정을 내릴 때까지 기다려야 합니다. 결정을 내리기 위해 fapolicyd는 프로세스와 액세스되는 파일에 대한 정보를 조회해야 합니다. 각 시스템 호출 fapolicyd는 시스템 속도를 저하시켜야 합니다.

작업 속도를 높이기 위해 fapolicyd는 조회하는 모든 항목을 캐시하므로 후속 액세스에서는 처음부터 항목을 조회하는 대신 캐시를 사용합니다. 하지만 캐시는 너무 큽니다. 하지만 당신은 그것을 통제할 수 있습니다. 주제와 객체 캐시를 모두 더 크게 만들 수 있습니다. 프로그램이 종료되면 다음과 같은 일부 성능 통계가 /var/log/fapolicyd-access.log 또는 화면에 출력됩니다.
Permissive: false
q_size: 640
Inter-thread max queue depth 7
Allowed accesses: 70397
Denied accesses: 4
Trust database max pages: 14848
Trust database pages in use: 10792 (72%)

Subject cache size: 1549
Subject slots in use: 369 (23%)
Subject hits: 70032
Subject misses: 455
Subject evictions: 86 (0%)

Object cache size: 8191
Object slots in use: 6936 (84%)
Object hits: 63465
Object misses: 17964
Object evictions: 11028 (17%)
이 보고서에서 내부 요청 큐의 최대값이 7임을 알 수 있습니다. 이는 데몬이 최대 7개의 스레드/프로세스를 대기하고 있음을 의미합니다. 이는 약간 백업되었지만 요청을 매우 빠르게 처리했음을 보여줍니다. 이 숫자가 200보다 큰 경우 q_size를 늘려야 할 수 있습니다. 1015개를 초과하면 systemd에 1024개 이상의 설명자를 허용하도록 지시해야 할 수도 있습니다. fapolicyd.service 파일에 LimitNOFILE=16384 또는 대기열보다 큰 숫자를 추가해야 합니다.

살펴볼 가치가 있는 또 다른 통계는 퇴거에 대한 적중 비율입니다. 요청에 정보를 넣을 곳이 없으면 공간을 확보하기 위해 무언가를 제거해야 합니다. 이는 사용되지 않는 것을 자연스럽게 결정하고 해당 메모리를 재사용할 수 있도록 만드는 LRU 캐시에 의해 수행됩니다.

위 통계에서 과목 적중률은 95%였습니다. 개체 캐시는 그다지 운이 좋지 않았습니다. 이를 위해 우리는 79%의 적중률을 얻습니다. 이것은 여전히 좋지만 더 좋아질 수 있습니다. 이는 해당 시스템의 작업 부하에 대해 캐시가 조금 더 커질 수 있음을 의미합니다. 캐시 크기에 사용된 숫자가 소수인 경우 공통 분모가 있는 경우보다 충돌로 인한 캐시 변동이 더 적습니다. 캐시 크기에 대해 고려할 수 있는 소수는 1021, 1549, 2039, 4099, 6143, 8191, 10243, 12281, 16381, 20483, 24571, 28669, 32687, 40961, 49157, 57347, 등

또한 정책에 규칙이 많을수록 결정을 내리기 위해 반복해야 하는 규칙도 많아진다는 점을 언급해야 합니다. 시스템 성능에 미치는 영향은 작업 부하에 따라 크게 달라집니다. 일반적인 데스크톱 시나리오에서는 실행 중인 것을 알 수 없습니다. 짧은 시간 동안 무작위로 많은 파일을 여는 시스템이 더 큰 영향을 미칠 것입니다.

성능에 영향을 미칠 수 있는 또 다른 구성 옵션은 무결성 설정입니다. sha256으로 설정하면 객체 캐시의 모든 누락으로 인해 액세스 중인 파일에 대한 해시가 계산됩니다. 한 가지 절충점은 sha256 대신 크기 확인을 사용하는 것입니다. 이는 안전하지는 않지만 성능에 문제가 있는 경우 선택 사항입니다.

do_stat_report = 1통계 보고서를 활성화하려면 구성에서 최근에 활성화하지 않은 경우 fapolicyd를 다시 시작하세요. /var/log/fapolicyd-access.log 어떤 PID가 어떤 파일을 여는 패턴을 분석 하고 기록해 둡니다.

"적중"과 "실패"의 비율을 확인하세요. 적중률이 높을수록 더 좋고, 메모리 내 데이터베이스에 액세스하는 것이 파일 시스템 액세스 및 처리보다 훨씬 빠릅니다. obj_cache_size시스템이 한 번에 보유하는 파일 수만큼 구성을 늘립니다 . 가능한 상한은 df -i출력에서와 같이 데이터 파일 시스템에서 사용되는 inode의 수입니다. 너무 많을 수도 있지만 메모리가 있다면 수십만 개의 항목을 캐시하는 것은 어떨까요?

fapolicyd.conf의 구성을 검토합니다. 또는 integrity이외의 값은 체크섬을 계산하고 오버헤드가 발생합니다. 특히 새 파일을 처리하는 데 많은 실수가 있는 경우 이는 상당한 양의 CPU를 차지할 수 있습니다. 액세스 보고서의 "최대 대기열 깊이"보다 커야 하지만 대기열 크기를 늘려야 할지 의문입니다.nonesizeq_size

rule.d의 컴파일된.rules에서 규칙을 검토합니다. RHEL 및 Fedora는 rpm에서 신뢰할 수 있는 파일을 채우고, 알 수 없는 파일의 실행을 허용하지 않으며, ld.so 트릭을 허용하지 않으며, 대부분의 열기를 허용합니다. 규칙을 수정하는 경우 공개 syscall이 기다리는 동안 더 많은 작업을 수행하면 성능에 미치는 영향을 생각해 보세요.

언제나 그렇듯이 문제 해결 중에 정확히 무슨 일이 일어나고 있는지 프로파일링할 수 있습니다. perf topCPU에 어떤 기능이 있는지 인쇄하며 debuginfo가 설치되면 더욱 좋습니다. bcc-tools 패키지에는 실시간으로 열린 호출과 exeve 호출을 나열하는 opensnoop 및 execsnoop라는 몇 가지 깔끔한 스크립트가 있습니다.

궁극적으로 승인되지 않은 프로그램의 실행만 허용하기 위해 어떤 제어 장치를 배치할지 결정하는 것은 귀하의 결정입니다. fapolicyd와 같이 exec 호출에서 즉시 허용 목록은 물론 매우 강력합니다. 덜 포괄적인 대안은 쉘 액세스를 제한하는 것입니다. 즉, 사람들에게 대화형 쉘을 허용하지 않고 홈 디렉토리의 권한을 잠그는 것입니다. 또는 데이터 파일 시스템에 프로그램이 전혀 없어야 하는 경우 noexec로 마운트하는 것을 고려하십시오. 좋은 보안 감사는 체크리스트를 변경할 수 없는 것으로 간주하지 않고 대체 제어 장치와 그 이유를 나열합니다.

Answer 1