trac과 전복을 설정했습니다. 어떤 사람들은 티켓을 추가 할 수있게하고 싶지만 저장소에 액세스하는 것을 원하지 않습니다. trac을 통해 repo에 액세스 할 수있는 다른 사용자가있을 것입니다. 현재 인증을 위해 Apache 2를 사용하고 있습니다.Trac의 소스 코드 보안
trac은 얼마나 안전합니까? 제한된 액세스 권한을 가진 사람이 trac를 통해 소스에 액세스하는 것이 얼마나 어렵습니까?
trac을 통해 소스에 액세스하지 못하게하는 방법을 묻지 않습니다. 나는 그것을하는 방법을 안다.
다시 한 번 질문합니다. 출처에 접근하지 않고 출처를 알 수없는 사람이 얼마나 힘들습니까?
모든 Trac 사용자에게 set permissions 수 있습니다. 예를 들어 티켓 시스템에만 액세스 할 수 있지만 소스 브라우저, 타임 라인 또는 위키에는 액세스 할 수없는 사용자 계정을 가질 수 있습니다. 특히
, 당신은 다음과 같은 권한을 부여하지하려면 :BROWSER_VIEW # View directory listings in the repository browser
LOG_VIEW # View revision logs of files and directories in the repository browser
FILE_VIEW # View files in the repository browser
CHANGESET_VIEW #View repository check-ins
난 당신이 "안전한"무슨 뜻인지 모르겠습니다. Trac은 모든 웹 액세스에 대해 설정 한 권한을 시행합니다. 적절한 권한이없는 사람에게 소스 브라우저 페이지를 표시하지 않습니다. 그 외에도 익명 저장소 읽기 액세스를 허용하지 않으려면 SVN을 구성해야합니다 (그렇지 않으면 Trac을 우회하여 저장소에 직접 액세스 할 수 있음).
내 질문을 놓친 것 같아. 소스 코드 액세스를 금지하는 방법이 아닙니다. : 해당 사용자에 대한 소스 코드 액세스를 허용하지 않더라도 어쨌든 액세스가 어려울 수 있습니까? –
Trac에 치명적인 보안 버그가없는 한 "Trac은 설정 한 권한을 시행합니다". 따라서 Trac을 통해 소스에 액세스 할 수 없습니다. 그런 다음 저장소 (svn, 서버 자체 해킹)에 액세스하고 Trac 사용자 계정 (암호, 사회 공학 추측)을 해킹하는 다른 방법으로 귀결됩니다. – Thilo
가능합니다.
trac-admin /path/to/project permission remove <user> BROWSER_VIEW
trac-admin /path/to/project permission remove <user> LOG_VIEW
trac-admin /path/to/project permission remove <user> FILE_VIEW
trac-admin /path/to/project permission remove <user> CHANGE_VIEW
이렇게하면 저장소 관련 권한이 모두 제거됩니다. 우리는 trac을 사용하고, 잘 작동하며, 아직 보안 문제가 없다.
Trac의 자체 저장소에 액세스 할 수있는 경우그건 내가 물었던 것이 아닙니다. –
, 및이 손상 도착은, 공격자는 정의하여 저장소 에 액세스 할 수 있습니다. Trac 설치를 맡은 공격자로부터 저장소를 보호하려면 Trac 자체가 저장소에 액세스하는 것을 차단해야합니다. 그러나 이것은 또한 누구에게나 저장소에 대한 액세스를 제공하는 것을 막을 것입니다.
손상된 시스템은 여전히 손상되기 전에 있던 모든 액세스 권한을 가지고 있으며 손상된 사람은 액세스 권한으로 원하는 모든 것을 수행 할 수 있습니다.
귀하의 질문은 본질적으로 대답하기 어렵습니다. 알려진 보안 구멍에 대해 알고 싶다면, 자신이나 배포판의 버그 추적기를 확인해야합니다. 예 : Debian doesn't report any security related bugs in trac. 그래서 내 지식을 최대한으로 추적 자체를 크랙하고 ungranted 액세스를 얻는 것은 불가능합니다.
물론 보안상의 결함이있는 것은 아닙니다. 그것은 단지 그들이 좋은 사람들에 의해 발견되지 않았다는 것을 의미합니다 (누가 그들을보고했을 것입니다). 그러나 전체 소스 감사를 수행하는 (또는 사람들을 고용하는 것) 일은 아니지만 보안과 관련하여 얻을 수있는 최선의 방법입니다.
재미있는 점은 실제로 제공된 답변에 의존 할 수 없다는 것입니다. 정확한 접근법은 Trac이 안전하지 않다는 것을 결론 짓고 잠재적 인 위험을 줄이려고 시도하는 것이라고 말할 수 있습니다.
귀하의 목표는 "사용자"와 "개발자"가 공동 작업을 할 수 있다고 가정하지만 모든 상황에서 사용자는 소스에 액세스 할 수 없습니다 (이는 매우 좋음).
가 그물에 관련 조리법의 꽤 많은,하지만 난이 간단한 일 제공 :
기본적으로 Trac의 내부 보안에 의존하지 않으려면 가능한 한 빨리 사용자를 필터링하는 것이 좋습니다.
또한 Trac을 직접 테스트 할 OWASP Zed Attack Proxy Project를 사용할 수 있습니다
이
데이빗 공격 프록시 (ZAP)는 웹 애플리케이션의 취약점을 찾기위한 통합 침투 테스트 도구를 사용하기 쉽습니다.
광범위한 보안 경험을 가진 사람들이 사용하도록 설계되었으며 이므로 침투 테스트에 새로운 인 개발자 및 기능 테스터에게 이상적입니다. ZAP은 자동화 된 스캐너는 물론도구 모음을 제공하여 보안 취약점을 수동으로 찾을 수 있습니다.
서버 구성과 프로그래밍에 관한 질문이 아니기 때문에 나 때문이 아니 었습니다. – mikerobi
주제 외에도 질문에 대답하기가 어렵습니다. 기본적으로 Trac이 얼마나 안전한지 묻습니다. 알아야 할 유일한 방법은 열린 보안 관련 문제가 있는지 확인하거나 코드 검토 (오픈 소스)입니다. Trac이 버그가 없다고 보장 할 수는 없습니다. – Matteo