☰

고쳐 쓰다

tag-icon • tag-icon bash
고쳐 쓰다

왜 이 일을 하는가?

# grepcidr 5.45.148.0 list.txt

list.txt
5.45.148.0/22
5.45.148.0/24

이게 작동하지 않나요?

# grepcidr 5.45.148.23 list.txt

list.txt
5.45.148.0/22
5.45.148.0/24

CentOS7 저장소에서 제공하는 grepcidr 2.0

답변1

나는 여기에 약간의 단점과 버그가 있을 수 있다는 것을 인정 grepcidr하지만 대부분의 내 추측은 틀렸습니다. 공평하게 말하면 이 답변의 일부도 제대로 이해되지 않았지만 제 의도는 구문과 출력을 처리하는 데 다른 패러다임을 사용하는 경우 v2에도 어느 정도 유용성이 있음을 지적하는 것이었습니다.

grepcidr몇 달 전부터 일부 방화벽 스크립트를 사용하기 시작했기 때문에 이에 대한 이해가 아직 초기 단계입니다. 하지만 내가 수집한 바에 따르면 grepcidr그 효과는 정확히 동일하지 않습니다 grep. 특히 지금까지 내 "정신적 지도"에 따르면 `grepcidr은 문자열(또는 CIDR 사양)이 포함된 입력 파일에서 줄을 찾지 않고 다음을 포함하는 입력 파일에서 줄을 찾습니다. 예CIDR 사양에 포함되어 있습니다.

즉, grep은 건초 더미에서 바늘을 찾는 것입니다. 를 사용하려면 grepcidr건초 더미를 제공하고 grepcidr은 건초 더미에 포함된 모든 바늘을 표시합니다. 이것은 여전히 ​​약간 느슨하지만... grepcidr명령줄 검색 사양의 하위 집합(잘못된 하위 집합일 수 있음)인 파일의 항목을 찾습니다.

다음 스크립트를 고려해보세요.

#!/usr/bin/env bash

cat << EOF > list.txt
5.45.148.0/22
5.45.148.0/24
5.45.149.0/24
5.45.150.0/24
5.45.151.0/24
5.45.152.0/24
5.45.151.17
5.45.151.17 5.45.151.18 5.45.151.19
5.45.151.247
5.44.15.17
5.44.1.0/24
5.44.1.15
5.44.1.5
5.44.1.5/32
EOF

grepcidr -V

j=0

echo $((++j)): "Lines containing entries within 5.45.151.17 (/32)"
grepcidr 5.45.151.17 list.txt

echo $((++j)): "Lines containing entries in the same /24 as 5.45.151.17"
grepcidr 5.45.151.17/24 list.txt

echo $((++j)): "Lines that have no entries within 5.45.0.0/16"
grepcidr -v 5.45.0.0/16 list.txt

echo $((++j)): "Lines with entries within 5.45.151.17/31"
grepcidr 5.45.151.17/31 list.txt

산출:

grepcidr 2.0
Copyright (C) 2004 - 2014  Jem E. Berkes <[email protected]>

1: Lines containing entries within 5.45.151.17 (/32)
5.45.151.17
5.45.151.17 5.45.151.18 5.45.151.19
2: Lines containing entries in the same /24 as 5.45.151.17
5.45.151.0/24
5.45.151.17
5.45.151.17 5.45.151.18 5.45.151.19
5.45.151.247
3: Lines that have no entries within 5.45.0.0/16
5.44.15.17
5.44.1.0/24
5.44.1.15
5.44.1.5
5.44.1.5/32
4: Lines with entries within 5.45.151.17/31
5.45.151.17
5.45.151.17 5.45.151.18 5.45.151.19

구체적인 예에서는 grepcidr"이 특정 IP가 해당 파일에 /32로 표시됩니까?"라고 질문합니다. 아니요, 그렇지 않습니다. 요청하는 경우 IP가 있는 /24가 파일에 나타나고 예, 두 위치에 나타납니다.

# grepcidr 5.45.148.23 list.txt
# grepcidr 5.45.148.23/24 list.txt
5.45.148.0/22
5.45.148.0/24

그렇습니다. V3는 V2보다 개선될 가능성이 높습니다. 그리고 많은 Unix 및 Linux 배포판이 패키지 저장소를 업데이트하는 좋은 날이 될 것입니다. 하지만 그렇다고 V2가 유용하지 않다는 뜻은 아닙니다. 출력에서 어떤 결론을 이끌어내는지 주의해야 합니다.

고쳐 쓰다

"엉성한" CIDR 사양을 허용하기 위해 새 -s플래그를 추가한 후에도 동일하게 보입니다. 내 테스트 사례는 완전하지 않을 가능성이 높습니다.

1: Lines containing entries within 5.45.151.17 (/32)
5.45.151.17
5.45.151.17 5.45.151.18 5.45.151.19
2: Lines containing entries in the same /24 as 5.45.151.17
5.45.151.0/24
5.45.151.17
5.45.151.17 5.45.151.18 5.45.151.19
5.45.151.247
3: Lines that have no entries within 5.45.0.0/16
5.44.15.17
5.44.1.0/24
5.44.1.15
5.44.1.5
5.44.1.5/32
4: Lines with entries within 5.45.151.17/31
5.45.151.17
5.45.151.17 5.45.151.18 5.45.151.19

FWIW, V3에서는 특정 테스트 사례 동작이 변경되지 않았습니다.

# grepcidr -V
grepcidr 3.0
Parts copyright (C) 2004, 2005  Jem E. Berkes <[email protected]>

# grepcidr 5.45.148.23 list.txt

...이 플래그를 사용하라는 @RasoolZiafaty의 제안에 해결책이 있는 것 같지만 -D:

# grepcidr -D 5.45.148.23 list.txt
5.45.148.0/22
5.45.148.0/24

항상 저를 당황하게 만드는 한 가지 질문은 IP 범위가 명시적으로 나열된 IP와 동일하지 않은 이유입니다.

# cat input.txt 
5.45.148.3 5.45.148.4 5.45.148.5
5.45.148.3-5.45.148.5
# grepcidr -D 5.45.148.4 input.txt 
5.45.148.3 5.45.148.4 5.45.148.5

현재 동작은 명령줄의 특정 IP가 파일 줄이 해당 IP를 시작 또는 끝 지점으로 참조하는 경우에만 파일 줄과 일치하는 것 같습니다. 예를 들어 5.45.148.4한 줄에서만 찾을 수 있지만 while 5.45.148.3또는 5.45.148.5두 줄에서 일치합니다.

답변2

명령에 -D를 사용해 보세요.

grepcidr -D 5.45.148.3 list.txt

-D 입력에서 CIDR 범위를 구문 분석하고 검색어가 범위의 일부와 일치하는 경우 일치합니다.

답변3

grepcidrCIDR 네트워크에 있을 수 있는 IP 주소를 검색합니다. 이를 다른 방향(주어진 IP 주소를 포함할 수 있는 CIDR 네트워크 검색)으로 사용하려고 합니다.

function reversegrepcidr() { 
  grep "$( 
    while read; do 
      echo $1 | grepcidr "$REPLY" &>/dev/null && echo $REPLY
    done < <( grep -Eo "[^^\"][0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}/[0-9]{1,2}" "$2" )
   )" "$2"; 
}

이 함수는 CIDR 네트워크처럼 보이는 모든 네트워크를 검색하고, 각 네트워크에 대해 grepcidr첫 번째 인수가 해당 네트워크에 있는지 확인하고, 그렇다면 네트워크를 인쇄합니다.

경고: 이 기능은 모든 버전에서 작동하지 않을 수 있으며 grepGNU 3.4 및 2.0에서만 가볍게 테스트되었습니다.grepgrepcidr

관련 정보