it-swarm-korea.com

무차별 강제로부터 보호하는 방법

무차별 강제력에 대한 방어를 어떻게 올바르게 구현합니까? 누군가 X 로그인 시도 후 로그인을 시도한 횟수를 저장하는 것이 가장 좋습니까? 그리고 "누군가"는 어떻게 식별됩니까? 세션으로? IP?

24
Andreas Arnold

계정 잠금은 한 번의 옵션으로, x 번 로그인 실패 후 계정이 영구적으로 또는 일정 기간 동안 잠 깁니다. 여기서 문제는 공격자가 암호를 추측하려고 시도하고 계정을 재설정 할 때 관리 오버 헤드가 발생하는 경우 서비스 거부 위험이 있습니다 (자동 재설정을 사용할 수 없다고 가정)

또 다른 옵션은 로그인 프로세스에 보안 문자를 도입하는 것입니다. 이는 자동 공격을 제한하고 계정 잠금에서 서비스 거부를 막기위한 것입니다. 문제는 접근성 요구 사항과 자동화 된 보안 문자 크래킹 일 수 있습니다. 내가 본 것 중 일부 보안 문자는 다른 보안 문자보다 소프트웨어가 크랙하기 쉽다.

세 번째 옵션은 로그인 프로세스에 점진적인 지연을 도입하여 각 잘못된 로그인에 대해 프로세스 속도가 느려지는 것입니다. 이는 실제 사용자에게는 영향을 미치지 않지만 자동 무차별 강제 실행을 훨씬 더 어렵게 만듭니다.

공격을하는 "누군가"를 식별하는 것에 대한 귀하의 질문의 두 번째 부분의 관점에서, 그것은 그들이하는 일에 달려 있습니다. 그들이 단일 사용자를 공격하는 경우 사용자 이름은 식별자이며 작업은 해당 계정에 연결됩니다. 그들이 광범위한 사용자들에 대해 무차별 적으로 강제하는 경우 소스 IP (아마도 브라우저 에이전트와 결합 된)가 옵션입니다. 완벽하지는 않지만 (예 : 봇넷 사용, 에이전트 스푸핑) 아마도 당신이 계속해야 할 유일한 정보 일 것입니다.

9
Rory McCune

무차별 대항 거부에 대한 대답은 많은 시도를 거부하는 것이며, 여기서 큰 시도는 핵심 공간과 위험 수용으로 정의됩니다.

각 상황마다 다른 솔루션이 있습니다.

고기 공간

  • 문은 무차별 대미지로 강화됩니다.
  • 경찰에게 경고 할 수있는 기회로 문을 통한 충돌이 완화됩니다.
  • 키에는 약 5 개의 변수 만 있지만 각 키 중 하나를 갖기 위해서는 리소스가 필요합니다 (강력하지 않은 다른 방식으로 잠금을 공격하는 것이 더 쉬움).

컴퓨터

  • 무차별 대입 공격을 자동화하면 어떤 방식 으로든 속도를 제한해야합니다. 속도 제한을 사용하면 일정 시간 동안 상위 시도 횟수를 절대적으로 알 수 있습니다.
  • 모니터링 : 무차별 대입 시도를 특정 비율 (아마도 500/일)로 제한 할 수있는 경우 모니터링 및 경고를 통해 상황을 자세히 살펴볼 수 있습니다. 수용 할 수없는 특정 위험 수준에 도달하려면 몇 번의 시도가 필요합니까?
  • 큰 키 공간 : 암호 요구 사항이 복잡하면 암호를 찾을 확률이 높아질 수 있습니다.
  • 이중 인증 :이 경우 암호를 강제 실행하는 것만으로는 충분하지 않습니다

모든 솔루션에는 인생의 다른 모든 것들과 같은 절충점이 있습니다.

  • 속도 제한 : DoS가 합법적 인 사용자 일 수 있으며, 공격이 가장 광범위한 경우에는 효과적이지 않습니다. 두 번째로 시도하기 전에 각 계정에 대해 한 번의 시도
  • IP 별 속도 제한 : 분산 공격 인 경우 효과적이지 않습니다
  • 암호 복잡성 : 일반적으로 사용 편의성에있어 사용자가 암호를 적어 무차별 대입 위협보다 보안을 크게 줄입니다.
  • 두 가지 요소 : 고가로 보일 수 있으며 토큰을 잃을 수 있음
13
Bradley Kreider

중요한 것은 '누군가'를 어떻게 식별합니까?

IP 주소로는 할 수 없습니다. 많은 사용자가 동일한 클라이언트 주소를 가지고있는 것처럼 보일 수 있습니다 (IPV4 주소 기아의 지속적인 문제로 인해 더 빈번해질 것입니다).

한 명의 사용자가 여러 클라이언트 주소에서 연결 한 것처럼 보일 수 있습니다 (예 : AOL의로드 밸런싱 프록시를 사용하거나 덜 합법적으로.

다른 것은 클라이언트가 제공 한 데이터이므로 사용자가 설정 한 쿠키, 사용자 에이전트 문자열 등을 잠재적으로 수정할 수 있습니다.

유일한 실제 접근 방식은 이전 시도와 비교하기 위해 요청에 휴리스틱 스코어링을 적용하는 것입니다. 그러나 정교한 공격과 합법적 인 사용자를 구별하는 것은 여전히 ​​불가능합니다.

클라이언트가 사이트를 무차별 대우하려고하는 점수 임계 값을 설정하십시오 (예 : -20).

세션 쿠키가 참조하는 현재 유효한 세션을 요구하는 것 (사용자 이름/암호를 묻는 페이지에 not으로 설정 됨)은 시작입니다. 쿠키에 인증 세부 정보가 표시되지 않으면 별도의 쿠키로 리디렉션됩니다 쿠키를 삭제하고 클라이언트 IP 주소에 대해 점수 -10, 세션 점수 -2로 세션을 초기화하는 페이지입니다. 동일한 주소에서 여러 유효한 사용자를 볼 때 동적 스코어링 메커니즘을 사용할 수 있습니다. 마찬가지로 사용자 에이전트 및 사용자 이름별로 동적 스코어링을 유지할 수 있습니다.

존재하지 않는 사용자에 대해 cookie + auth가 표시되면 세션에 점수 -5를, 클라이언트 주소에 -1을, 사용자 이름에 -5를 추가하십시오.

Cookie + auth에 유효하지 않은 비밀번호가 표시되면 세션에 점수 -3을, 클라이언트 주소에 -1을, 사용자 이름에 -4를 추가하십시오.

Cookie + auth + valid 비밀번호가 클라이언트 주소 점수에서 +4를 사용자 이름에 +3, 사용자 에이전트에 +2를 추가하면.

NB 또한 클라이언트 주소/사용자 에이전트/사용자 이름에 대해 보유한 점수를 복구 할 수 있도록 부패를 설정해야합니다 (예 : + 2/시간)

점수가 임계 값을 초과 할 때 발생하는 상황에 대해 생각해야합니다. 누구나 사이트에 대한 액세스를 차단할 수있는 메커니즘을 제공 했습니까?

실제 사용자 이름에 대해 높은 점수로 액세스를 차단 한 경우 해당 계정의 등록 된 사용자에게 재설정 URL이 포함 된 전자 메일을 보내 사용자 이름에 대한 점수를 재설정하고 사용자 에이전트에 대한 점수를 줄일 수 있습니다 /주소.

4
symcbean

내가 제안한 것처럼 웹 응용 프로그램에서 로그인/암호를 무차별 적으로 사용한다는 것을 의미합니다.

아무도 수동으로 무차별 대입하지 않습니다. 따라서 인증을 시도하는 사람이 의심 스럽다면 3d 로그인 시도 실패에서 Captcha를 보여주십시오. 또한 로그인 시도 사이에 시간 초과를 설정할 수 있지만 다른 IP의 분산 공격에는 작동하지 않습니다. 다음으로, 무작위 로그인/암호를 시도하고 일부 사용자에 대한 공격을하는 두 가지 유형의 무차별 공격이 있습니다. 마지막 공격의 경우 한동안 계정을 차단하고 전자 메일로 사용자에게 알리는 것과 같은 기능을 구현하는 것이 효과적입니다. 맹인의 경우 특히 사이트가 인기가있는 경우 무차별 대입 완화를 구현하기가 더 어려울 수 있습니다. 이 경우 IP/Country/Browser/etc와 같은 사용자 정보를 추적 할 수 있으며이 정보의 조합을 알아 내면 이것이 유효한 사용자인지를 가정 할 수 있습니다. 이것에 대한 추가 정보로서, 사용자가 성공적으로 로그인하고 쿠키를 저장 한 후 나중에 확인하면 장기 쿠키를 사용할 수 있습니다.

웹 애플리케이션 유형 솔루션이 없으면 Apache의 mod_evasive와 같은 서버 레벨 솔루션을 구현할 수 있습니다. 또는 특히 그러한 목적을 위해 자체 웹 서버 모듈을 작성하십시오.

물론, 무차별 대입 공격 완화를 강화하는 방법에는 여러 가지가 있지만, 종종 소음이 많고 쓸모없고 불쾌합니다. 키스를 유지하십시오.

3
anonymous

이전 로그인 및 로그인 시도의 긴 IP를 저장하십시오.

N 번의 시도가 실패하면 보안 문자에 맞서게됩니다.

기록에 성공적으로 로그인하지 않고 여러 번 시도한 주소를 신속하게 차단합니다.

동시 소스 주소 또는 비인간적 인 속도/지속적인 시도가있는 주소를 신속하게 차단합니다.

3
hpavc

또한 이러한 답변 중 어느 것도 공격자가 하나의 암호를 사용하고 모든 계정에 대해 암호를 시도하는 일반적인 방법, 일반적인 프로세스의 반전 및 일반적으로 보호되지 않는 강제 방법을 고려하지 않습니다.

물론 동일한 암호로 다른 계정에 대한 여러 번의 시도에 대한 프로세스 모니터링을 수행하는 것이지만 IP를 차단하는 것처럼 단일 주소에서 온 경우에도 차단하기가 매우 까다 롭습니다. 유효한 사용자도 사용할 수 있거나 해당 비밀번호로 유효한 사용자를 잠글 위험이있는 비밀번호로 로그인을 삭제합니까?

물론 공격자가 분산 네트워크에서 또는 장기간에 걸쳐 이러한 종류의 작업을 실행하는 경우 인시던트를 공격 프로필과 어떻게 연관 시키는가?

일반적인 산업 메커니즘에는 잠금이 포함됩니다.

  • 직접 시도시 (3 이상, 보통 20 미만)
  • 점진적 지연
  • 분산 된 무차별 강제력처럼 보이는 사건을 차단하는 통계 도구
2
Rory Alsop

먼저, 어떤 시나리오/공격을 처리 하려는지 이해하는 것이 좋습니다.

  • 유효한 사용자가 실수로 잘못된 비밀번호를 잘못 입력
  • 유효한 사용자는 실제로 비밀번호를 잊어 버렸습니다. 생각할 수있는 모든 것을 수동으로 시도합니다
  • 공격자가 다른 사람의 비밀번호를 수동으로 추측하려고합니다.
  • 공격자는 자동화 된 도구를 사용하여 특정 사용자의 암호를 무차별 공격합니다
  • 공격자는 자동화 된 도구를 사용하여 가능한 모든 사용자 암호 (예 : 너비 우선 검색)를 무차별 처리합니다.
  • 공격자는 특정 사용자가 사이트에 액세스하지 못하도록 차단하려고합니다
  • 공격자는 대부분의 사용자가 사이트에 액세스하지 못하도록 차단하려고합니다.
  • 공격자가 관리자가 사이트에 액세스하는 것을 차단하려고합니다.
  • 공격자는 많은 수작업을 만들거나 다른 방법으로 조직에 많은 비용을 지불하려고합니다.

(그렇지 않습니까? 그렇게 간단하지는 않습니다 ...) 그리고 이것들 각각에 대해 다른 해결책들이 있습니다 ...

  • 사용자 이름 목록을 공개하지 마십시오. 더 쉽게 만들지 마십시오 ... 여기에는 로그인을 거부 할 때 사용자 이름이 유효한지 여부가 표시되지 않습니다.
  • 길고 복잡한 강력한 비밀번호 정책이 필요합니다.
  • "암호 분실"메커니즘을 쉽고 눈에 띄게 만드십시오. (물론, 그것이 안전한지 확인하십시오).
  • 로그인 요청이 실패 할 때마다이를 데이터베이스에 기록하십시오. 사용자 이름, IP 주소, 시간 등을 작성하십시오.
  • 특정 사용자 이름에 대해 수많은 실패한 요청이 수신되면 데이터베이스에서 해당 사용자를 잠깐 동안 잠긴 것으로 표시하십시오. 또한 동일한 세션에있는 경우 "암호를 잊어 버렸습니다"기능을 사용하도록 권장하십시오.
  • 실패한 요청은 몇 개입니까? 따라 다름 . 요컨대, 귀하의 사이트에 어떤 의미가 있더라도 정확한 숫자는 중요하지 않습니다.
  • 사용자는 얼마나 오랫동안 잠겨 있어야합니까? 짧은 간격. 수학적으로 강력한 암호 정책이있는 한 실제로 중요하지 않습니다. 실제로 몇 분의 매우 짧은 간격으로 시작한 다음 계속 진행하면 점진적으로 더 길어집니다. 예 : 5 번의 잘못된 시도 후 5 분간 잠그십시오. 또 다른 3 번의 잘못된 시도 후에 15 번 잠그십시오. 다른 2 후, 30 동안 잠그십시오. 기타.
  • 사용자 계정을 영구적으로 잠그지 마십시오. 이는 계정 DoS로 이어집니다. 또한 지원 담당자에게 많은 시간과 비용이들 수 있습니다.
  • 이전 시점에도 불구하고 사이트가 매우 민감한 경우 (예 : 뱅킹 앱의 경우 추가 통지가있을 때까지 영구적으로 잠금하는 것을 고려할 수 있습니다 (예 : 고객이 자신의 지점으로 오도록합니다.
  • 잠금은 데이터베이스에서 사용자 이름으로해야합니다. 웹 서버 세션이 아닌 sessionId에 의해 Not .
  • 사용자 이름이 다르지만 동일한 IP 주소에서 많은 실패한 요청을 수신하는 경우 위와 같이 증분 잠금을 구현하지만 유예 기간이 짧고 간격이 짧습니다.
  • 비밀번호를 잊어 버렸을뿐 아니라 "사용자 이름을 잊어 버렸습니다"기능을 제공하십시오.
  • 관리자 계정은 유예 기간이 짧고 간격이 길어야하며 영구적으로 잠그지 않아야합니다.
  • 어쨌든 사용자 또는 IP를 잠글 때 관리자에게 경고를 보냅니다. 그러나 반복되는 잠금은 아닙니다. 관리자의받은 편지함을 넘치게하고 싶지 않습니다. 그러나 계속되면 몇 번 후에 경고 수준을 높입니다.
  • 보안 문자를 사용하지 마십시오. 사용자 비밀번호 액세스의 가치와 관련하여 최소한의 추가 어려움은 사소한 것입니다. (주변에는 여러 가지 방법이 있으며, 보안 문자는 기본적으로 구현에 관계없이 중단됨 ).
  • 물론 @ rox0r에서 언급했듯이 다중 요소 인증이 적합 할 수 있습니다.
  • 또 다른 대안은 "adaptive authentication"으로 알려진 것입니다. 사용자가 로그인에 실패한 경우 추가 정보 (사전 등록 된 정보)를 요청하십시오. 추가 위험 요소 (예 : 위치, 평소와 다른 시간 패턴 등)에 따라 성공적으로 인증하는 데 필요한 정보를 에스컬레이션합니다. 예를 들어 RSA의 AdaptiveAuthentication 제품이이를 수행합니다.
1
AviD

비즈니스 웹 사이트 인 경우 인증서와 비밀번호 인증을 사용하십시오. 유효한 인증서가 없으면 암호를 추측하려고 시도하지 않습니다. 인증서 대신 RSA SecurID와 같은 것을 사용할 수도 있습니다.

0
sdanelson