5일 전국 인터넷 접속장애, 방화벽 교체 과정에서 발생
알림
|
페이지 정보
작성일
2024.09.06 15:17
본문
* 전자신문 기사 내용 일부
https://www.etnews.com/20240906000175
… 과기정통부 측은 “보안 소프트웨어(SW) 업체의 방화벽 교체작업 시 인터넷 트래픽이 과다 발생했고 일부 무선공유기에서 해당 트래픽을 처리하지 못해 인터넷 접속 장애가 발생한 것으로 현재까지 파악하고 있다”고 밝혔다.
해당 보안SW 업체는 I사, 장애가 발생한 무선공유기 모델 제조사는 머큐리와 아이피타임이다.
I사가 보안 SW 업그레이드 작업 과정에서 패킷 설정 단위를 변경하면서 다량의 패킷이 전송됐고 이를 미디어텍 칩셋을 사용한 특정 공유기에서 제대로 처리하지 못해 오류가 발생한 것이 현재까지 밝혀진 장애 원인이다. 패킷은 네트워크를 통해 보내기 쉽도록 자른 데이터 전송단위다.
머큐리 관계자는 “자체적으로 성능 개선 펌웨어 업데이트를 진행한 적 없는데 갑자기 장애가 발생했다”면서 “보안SW 업체에서 해당 작업을 원복했더니 정상화됐다”고 말했다.
보안 회사 측은 방화벽 시스템 자체에는 문제가 없다는 입장이다. 패킷 설정 변경으로 늘어난 트래픽을 일부 공유기 모델에서만 수용하지 못해 벌어진 문제라는 것이다.
I사 관계자는 “네트워크 개선을 위한 방화벽 작업을 진행했고 자사 서비스나 통신망은 이상 없었다”면서 “이번 장애는 미디어텍 칩셋을 탑재한 특정 공유기 모델 일부가 트래픽을 제대로 처리하지 못해 발생한 것”이라고 말했다.
[이후 내용 생략]
- 게시물이 없습니다.
댓글 26
/ 1 페이지
무적전설님의 댓글
아이피타임과 머큐리 이외에 미디어텍 쓰는 다른기기들도 말썽이 났죠.
그리고 https://n.news.naver.com/mnews/article/008/0005086970?sid=105 이 기사에는 I사를 가린게 나와있네요.
그리고 https://n.news.naver.com/mnews/article/008/0005086970?sid=105 이 기사에는 I사를 가린게 나와있네요.
팝이좋아님의 댓글
사고는 보안SW 가 쳐놓고 공유기 업체가 제대로 처리를 못해서 문제!! 정말 뻔뻔하네요 ㅋㅋㅋ
I 이니고 A사 예전에도 윈도우 관련 장애도 낸걸로 아는데 무슨 뻔뻔함인지 모르겠네요
I 이니고 A사 예전에도 윈도우 관련 장애도 낸걸로 아는데 무슨 뻔뻔함인지 모르겠네요
포니님의 댓글
iptime 펌웨어는 오전 10시에 배포 되었다 하는데
장애는 오후 5시에 발생 했으니 인과관계는 없어 보이고
스케쥴러에 의해 펌웨어 유무 체크를 했을 수는 있겠지만요
그렇다 하더라도 이건 iptime 한정이고 머큐리는 이유를 알 수가 없구요
진정 미디어텍 칩셋을 사용한 공유기 한정에 문제가 발생 한 것이라면
미디어텍 공유기가 특정 패킷을 처리하지 못하고 쌓아두고 있다가 시스템에 장애를 일으키는 현상으로 봐야 할 것 같네요
문제는 해당 패킷이 잠깐 발생 해서 그 이후 재부팅 하면 그냥 해결 되는 가?
다음에도 또 발생 하면 또 장애가 발생 하는 가?
를 따져야 하는데 무슨 제로데이 취약점 같은데요...
장애는 오후 5시에 발생 했으니 인과관계는 없어 보이고
스케쥴러에 의해 펌웨어 유무 체크를 했을 수는 있겠지만요
그렇다 하더라도 이건 iptime 한정이고 머큐리는 이유를 알 수가 없구요
진정 미디어텍 칩셋을 사용한 공유기 한정에 문제가 발생 한 것이라면
미디어텍 공유기가 특정 패킷을 처리하지 못하고 쌓아두고 있다가 시스템에 장애를 일으키는 현상으로 봐야 할 것 같네요
문제는 해당 패킷이 잠깐 발생 해서 그 이후 재부팅 하면 그냥 해결 되는 가?
다음에도 또 발생 하면 또 장애가 발생 하는 가?
를 따져야 하는데 무슨 제로데이 취약점 같은데요...
NSGR님의 댓글
미디어텍 칩셋만 발생한 문제면 미디어텍이 유력한 범인이긴 하죠..
근데 미디어텍 칩셋이 글로벌로 많을텐데 비슷한 이슈가 없었으려나요..
근데 미디어텍 칩셋이 글로벌로 많을텐데 비슷한 이슈가 없었으려나요..
DannyPark님의 댓글
과다한 트래픽이 발생한 것은 문제가 아니고, 그걸 처리 못한 공유기가 잘못이 되는 군요.
칸느님의 댓글의 댓글
@DannyPark님에게 답글
도둑질한 사람이 아니라, 도둑질 당한사람을 뭐라하는거죠...
피스타치오님의 댓글
1. 보안SW업체(안랩)가 통신사 방화벽 업그레이드
2. 패킷설정변경되며 과다트래픽 발생
3. 일부 공유기 과다트래픽 받아들이지 못해 공유기 다운….
4. 보안SW업체(안랩) 방화벽 업그레이드 원복
누가봐도 통신사에서 잘못한건데…..
IPTime 탓을?!? 신박하네요
2. 패킷설정변경되며 과다트래픽 발생
3. 일부 공유기 과다트래픽 받아들이지 못해 공유기 다운….
4. 보안SW업체(안랩) 방화벽 업그레이드 원복
누가봐도 통신사에서 잘못한건데…..
IPTime 탓을?!? 신박하네요
NSGR님의 댓글의 댓글
@피스타치오님에게 답글
단순히 다운이면 재부팅 후 정상 작동해야하는데
패킷 설정 원복하니 돌아온다는건 변경된 패킷 설정에서 패킷 처리를 못하는거죠. 미디어텍 제외한 다른 칩셋들은 처리 하는거고. 트래픽 늘었다는 얘기를 하는거 보니 패킷 사이즈를 키워서 생긴 문제같은데..
과기정통부 멘트가 ddos마냥 트래픽을 보내서 다운시킨것 마냥 얘기해놨네요..
패킷 설정 원복하니 돌아온다는건 변경된 패킷 설정에서 패킷 처리를 못하는거죠. 미디어텍 제외한 다른 칩셋들은 처리 하는거고. 트래픽 늘었다는 얘기를 하는거 보니 패킷 사이즈를 키워서 생긴 문제같은데..
과기정통부 멘트가 ddos마냥 트래픽을 보내서 다운시킨것 마냥 얘기해놨네요..
칸느님의 댓글의 댓글
@NSGR님에게 답글
거꾸로 잘못알고 계십니다
ddos마냥 12배이상 트래픽 과하게 보내서 다운된거 맞아요.
!!!
장애원인:
안랩에서 무료백신 업데이트 배포시 MTU Size를 128바이트로 설정 배포 (표준설정 1500바이트)
복구: 안랩 서버쪽 트래픽이 패켓 Fragmentation이 많이 발생되는 것을 분석하여, 이상요인으로 추정하여 안랩 IP 차단 및
안랩쪽 작업여부 등 문의 한 결과, 안랩축 무료백신 배포작업 확인 및 MTU설정값을 128바이트로 변경한 것을 확인
안랩측에서 MTU Size. 1500바이트로 원복 이후고장 복구
!!! 출처: 이전동네.
ddos마냥 12배이상 트래픽 과하게 보내서 다운된거 맞아요.
!!!
장애원인:
안랩에서 무료백신 업데이트 배포시 MTU Size를 128바이트로 설정 배포 (표준설정 1500바이트)
복구: 안랩 서버쪽 트래픽이 패켓 Fragmentation이 많이 발생되는 것을 분석하여, 이상요인으로 추정하여 안랩 IP 차단 및
안랩쪽 작업여부 등 문의 한 결과, 안랩축 무료백신 배포작업 확인 및 MTU설정값을 128바이트로 변경한 것을 확인
안랩측에서 MTU Size. 1500바이트로 원복 이후고장 복구
!!! 출처: 이전동네.
NSGR님의 댓글의 댓글
@칸느님에게 답글
사실상 통신사는 상관 없는 안랩 백신 업데이트 이슈였군요..? 통신사 장비 변경사항인줄 알았네요
칸느님의 댓글의 댓글
@NSGR님에게 답글
통신사는 네트워크서비스를 하니까 모니터링 의무가 있죠. 원인자는 아니지만요.
율리시스님의 댓글
아이피타임 A8004T 쓰고 있으나 인터넷 장애를 느끼지 못했는데... 칩셋별로 차이가 있는건가보네요
가사라님의 댓글
안랩이 패킷설정을 바꿨다는데 이게 뭔지는 기사에 자세히 안나오지만, 어쨌든 그 결과로 트래픽량이 늘었다라는게 요지같네요.
방화벽에서 갑자기 많은 양의 패킷이 댁내 공유기로 쏟아졌는데 그게 통신사에서 제공한 공유기가 제대로 받아주지 못하고 뻗었다면, 그 공유기가 잘 버틸 수 있는지 여부에 대한 검수가 통신사 내부에서 진행되지 않았다는 문제가 있는거고요.
그런 검수까지는 필요없는 상황이라고 판단했었던 거라거나 혹은 아예 상황을 모르고 있었던 거라면 방화벽에서 그렇게 많은 패킷이 나가게 한 안랩과 그 변경을 승인해준 통신사가 문제인거죠.
이게 미디어텍 칩셋이나 펌웨어가 후지냐 아니냐의 문제가 아닌거네요.
다른 칩셋의 공유기에서 잘 받아주었다면 그건 오버스펙을 구현한거라 잘 받아준 것이었을 수도 있고요.
진작에 통신사에서 이런 스펙까지 구현해야 한다고 했다면 일반 소비자 판매용에도 그런 식으로 대응을 해두었을 거니 말이죠.
방화벽에서 갑자기 많은 양의 패킷이 댁내 공유기로 쏟아졌는데 그게 통신사에서 제공한 공유기가 제대로 받아주지 못하고 뻗었다면, 그 공유기가 잘 버틸 수 있는지 여부에 대한 검수가 통신사 내부에서 진행되지 않았다는 문제가 있는거고요.
그런 검수까지는 필요없는 상황이라고 판단했었던 거라거나 혹은 아예 상황을 모르고 있었던 거라면 방화벽에서 그렇게 많은 패킷이 나가게 한 안랩과 그 변경을 승인해준 통신사가 문제인거죠.
이게 미디어텍 칩셋이나 펌웨어가 후지냐 아니냐의 문제가 아닌거네요.
다른 칩셋의 공유기에서 잘 받아주었다면 그건 오버스펙을 구현한거라 잘 받아준 것이었을 수도 있고요.
진작에 통신사에서 이런 스펙까지 구현해야 한다고 했다면 일반 소비자 판매용에도 그런 식으로 대응을 해두었을 거니 말이죠.
타락한영혼님의 댓글
저도 미디어텍 모델을 사용하고 있지만 아무 이상 없었습니다.
모델마다 다른 상황이었는지 궁금합니다.
모델마다 다른 상황이었는지 궁금합니다.
lazyzeus님의 댓글
iptime 공유기 쓰는 경우 성능이 낮은 저가 공유기가 많을 겁니다. 안랩sw가 패킷 부어버렸을 때 성능이 좋은 공유기는 버틴거구 성능 안 좋은 기기는 못 버텼다고 보면 돠겠죠. 특히나 저가는 메모리가 작아서 12배 늘어난 패킷은 감당이 안 되었겠죠
그나저나 astx 도 문제여서, 제 기준 진짜 없어져야할 회사입니다.
그나저나 astx 도 문제여서, 제 기준 진짜 없어져야할 회사입니다.
알룰로스님의 댓글
IDC의 방화벽을 업데이트 했는데, 우리집 공유기가 죽었다라니..
흥미롭네요. 좀더 구체적인 과정이 밝혀지기를 기대해봅니다.
흥미롭네요. 좀더 구체적인 과정이 밝혀지기를 기대해봅니다.
화신님의 댓글
뭐 MTU를 size를 1,500에서 128로 바꾼거면,
정말 단순히 예를 들어 보면…
3,000 짜리 데이를 기존 1,500 설정 상태에는 2번이면 보내면 되었고, 그 과정에서 sync - ack 같은 3way handshake 같은 것들을도 2번이면 되었겠지만…
그걸 128로 바꾸게 되면…
3,000/128=23.4…. 이니, 최소한 24번은 패킷을 쪼개서 보내야 했을꺼고…
그 패킷을 보내면서도 필요한 과정도 더 많아졌을테니…
최소 받는 장비 입장에서는 24배 이상의 부하가 걸리게 된 것이겠네요.
사실 내부 10G 망 같은 곳에서는 점보프레임이라고해서 MTU를 9,000까지 올려서 쓰기도 하는데…
저건 대체 왜 128로 낮췄는지도 궁금하군요…
정말 단순히 예를 들어 보면…
3,000 짜리 데이를 기존 1,500 설정 상태에는 2번이면 보내면 되었고, 그 과정에서 sync - ack 같은 3way handshake 같은 것들을도 2번이면 되었겠지만…
그걸 128로 바꾸게 되면…
3,000/128=23.4…. 이니, 최소한 24번은 패킷을 쪼개서 보내야 했을꺼고…
그 패킷을 보내면서도 필요한 과정도 더 많아졌을테니…
최소 받는 장비 입장에서는 24배 이상의 부하가 걸리게 된 것이겠네요.
사실 내부 10G 망 같은 곳에서는 점보프레임이라고해서 MTU를 9,000까지 올려서 쓰기도 하는데…
저건 대체 왜 128로 낮췄는지도 궁금하군요…
kingzone32님의 댓글