Kysymys:
PING: n turvallisuusriski?
Mr. Jefferson
2011-06-08 22:31:58 UTC
view on stackexchange narkive permalink

Minulle on kerrottu, että PING aiheuttaa tietoturvariskin, ja se on hyvä poistaa / estää se tuotantopalvelimissa. Jotkut tutkimukset kertovat minulle, että turvallisuusriskejä on todellakin. Onko yleinen käytäntö poistaa PING käytöstä / estää julkisesti näkyvillä palvelimilla? Ja koskeeko tämä muita ICMP-perheen jäseniä, kuten traceroutea ( turvallisuuden wikipedia)?

Mielestäni on sopivampaa kysyä, milloin ICMP-pingin poistaminen käytöstä on tarkoituksenmukaista. Missä uhka-ympäristössä ICMP-ping-vastaukset tulisi poistaa käytöstä? Mitä haavoittuvuuksia ICMP: llä on / saattaa olla? Kuinka voimme rajoittaa altistumista ICMP-haavoittuvuuksille?
Jos ping on turvallisuusriski verkkoosi, sillä on isompia asioita kuin suojaus: P
Kahdeksan vastused:
#1
+63
Thomas Pornin
2011-06-08 23:22:01 UTC
view on stackexchange narkive permalink

ICMP Echo -protokolla (tunnetaan yleensä nimellä "Ping") on enimmäkseen vaaraton. Sen tärkeimmät turvallisuuteen liittyvät kysymykset ovat:

  • Kun väärennetty lähdeosoite ("huijaus") on pyyntöjä, he voivat saada kohdekoneen lähettämään suhteellisen suuria paketteja toiselle isännälle . Huomaa, että Ping-vastaus ei ole olennaisesti suurempi kuin vastaava pyyntö, joten siellä ei ole kerrannaisvaikutusta: se ei anna ylimääräistä voimaa hyökkääjälle palvelunestohyökkäyksen yhteydessä. Se saattaa kuitenkin suojata hyökkääjää tunnistamiselta.

  • Kunnostettu ping-pyyntö voi tuottaa tietoja verkon sisäisestä rakenteesta. Tällä ei ole merkitystä julkisesti näkyville palvelimille, koska ne ovat jo julkisesti näkyvissä.

  • Joissakin laajalle levinneissä TCP / IP-toteutuksissa oli aiemmin turva-aukkoja, joissa väärin muotoiltu Ping pyyntö saattaa kaataa koneen ( "kuoleman ping"). Mutta ne on korjattu asianmukaisesti edellisen vuosisadan aikana, eivätkä ne ole enää huolenaihe.

On yleistä käytäntöä poistaa Ping käytöstä tai estää julkisesti näkyvillä palvelimilla - mutta ne ovat common ei ole sama kuin suositeltava . www.google.com vastaa ping-pyyntöihin; www.microsoft.com ei. Henkilökohtaisesti suosittelen, että annat kaikkien ICMP-passien julkisesti näkyville palvelimille.

Jotkut ICMP-pakettityypit EI SAA olla estetty, etenkin ICMP-viesti "tavoitettavissa oleva", koska sen estäminen yksi rikkoo polun MTU-löydön, oireina on, että DSL-käyttäjät (PPPoE-kerroksen takana, joka rajoittaa MTU: n 1492 tavuun) eivät pääse verkkosivustoille, jotka estävät kyseiset paketit (elleivät he käytä Internet-palveluntarjoajansa tarjoamaa Web-välityspalvelinta) .

tämä ei ole täysin oikein, katso lisätietoja @Ori's-vastauksesta.
Minusta on yhä vaikeampaa selittää verkkoinsinööreille tarvetta päästä PMM-levyille, puristustyypeille ja muille "hyvän ICMP: n" skenaarioille. Katso myös - http://rfc-ignorant.org
@atdre Olen samaa mieltä siitä, että on tarpeellisia tyyppejä, ICMP: n kaiku / vastaus oli todella minne olin menossa. Tavoittamattomat ovat täysin välttämättömiä. @Thomas Rakastan aina "Enimmäkseen harmittomia" (uudestaan ​​Douglas Adams) missään viestissä, se sai minut halun vastata ensiksi.
Kuoleman ping on itse asiassa harhaanjohtava nimi, koska se on itse asiassa hyökkäys IP-tasolle eikä ICMP: lle. Toisin sanoen hyökkäys voisi yhtä hyvin kohdistua mihin tahansa muuhun IP-protokollaan, jota ei suodateta.
kohdetta, jota ei voida saavuttaa, ei käytetä MTU-polkua varten.
Kun käytät IPv6-protokollaa, sinun ei pitäisi estää ping-pyyntöä ja ping-kaiua, koska se rikkoo tukea palvelimellesi yhteyden muodostaville ihmisille teredon kautta
google.com hyväksy ICMP-paketti kyllä, mutta jos paketin kokoa ei muuteta!
#2
+20
Ori
2011-06-08 23:57:58 UTC
view on stackexchange narkive permalink

ICMP: llä on datakomponentti. Sitä voidaan käyttää tunneleiden rakentamiseen, ja tämä ei ole vain teoria, vaan se on saatavana luonnossa. Useat eri tutkijat ovat löytäneet sen osana haittaohjelmia -työkalupaketteja. Puhumattakaan siitä, että tästä aiheesta on merkittävä ohje, puhumattakaan wikistä tai hackadaysta

ICMPTX käyttää ICMP-kaikua ja ICMP-vastausta . ICMP kaiku ei ole aina vaaraton, koska se sisältää datakomponentin, se voi olla suodattavaa dataa tai sitä voidaan käyttää ohjauskanavana tai sitä voidaan käyttää (ICMPTX: n tapauksessa) tunnelointiprotokollana.

Nykyinen jakelu, Howto, (ICMPTX): http://thomer.com/icmptx/

Oikea hyökkäysskenaario, jossa käytetään ICMP-tiedonsiirtoa hyötykuorman injektointi: Open Packet Capture

ICMP-tiedonsiirtoprotokollan käyttö samankaltaisilla menetelmillä kuin ICMPTX (2006) troijalaisille C&C ja Exfiltration: Network World

Voisitteko mainita tutkimukset, jotka löysivät ICMPTX: n haittaohjelmatyökalupaketeista.
On kulunut melkein vuosikymmen, näen onko vielä jotain konkreettista. Tällä hetkellä se on harhaoppia, mutta olen työskennellyt ihmisten kanssa, joilla oli omakohtaista kokemusta joissakin varhaisissa tapauksissa.
Ang Cui antaa demon IOS-hyökkäyksistä käyttäen ICMP: tä ohjauskanavana. http://www.blackhat.com/html/bh-us-11/bh-us-11-briefings.html Tutkin jo tänä iltana olemassa olevia hyödyntämiskehyksiä nähdäksesi, onko olemassa ICMP-hyötykuormaa, joka on yleisesti jaettu hyvin.
Kiitos. Lisäselvityksiä varten: Ang Cui, [tappaa myytti Ciscon IOS-monimuotoisuudesta] (http://www.blackhat.com/html/bh-us-11/bh-us-11-briefings.html): Kohti luotettavaa, suurta - Cisco IOS: n laajuinen hyödyntäminen "Tämän kyvyn avulla hyökkääjä voi käyttää vaarattomien pakettien, kuten ICMP: n, hyötykuormaa peitetyksi komento- ja ohjauskanavaksi."
Joten mitä jos ICMP: tä voidaan käyttää tunnelitietoihin? Niin voi tehdä mikä tahansa muu valitsemasi verkkoprotokolla. Joten voi DNS - estätkö kaiken DNS-liikenteen? Joten voiko HTTP - estätkö kaikki portit 80? Mielestäni tämä on väärä syy estää ping.
Se on yksi "palvelu", jota hyökkääjä voi käyttää monivaiheisessa tilanteessa. Miksi ottaa se käyttöön, jos et tarvitse sitä?
@D.W. Et aio sallia DNS-liikennettä * verkkoosi, eikö? Etkö harkitse portin 80 sallimista mielivaltaiselle palvelimelle, eikö? Lisäksi, jos sille ei ole toiminnallista tai käytettävyyteen liittyvää syytä, se vain suurentaa hyökkäyspintaa tarpeettomasti.
@AviD:, Ping-paketit ovat kuitenkin hyödyllisiä - joskin vain diagnostiikkatyökaluna ulkopuolelta. Se on kompromissi.
@D.W. kysymyksen otsikko on "PINGin turvallisuusriski?" ja tämä vastaus on erittäin hyvä asia, joka tulisi sisällyttää. Vaikka tämä on totta, piilotettu kanavien käyttö ei ole ainoa syy ICMP: n estämiseen (rehellisesti sanottuna ICMP: n estämisen yleisin syy on vain vaikeuttaa tiedusteluyrityksiä). Lisäksi haluan ehdottomasti ladata DNS: n ja HTTP: n ... ja teen, välityspalvelimen lisäksi.
Tarkoitan, että jos haluat lopettaa peitetyn viestinnän, sinun on estettävä KAIKKI viestinnät (molempiin suuntiin riippumatta siitä, mikä päätelaite aloitti yhteyden). Se on selvästi järjetöntä. Joten on typerys estää ping-toiminta salaisen viestinnän estämiseksi; jopa ping-eston jälkeen ihmiset voivat silti kommunikoida salaa. Se ei ole kompromissi turvallisuuden ja toiminnallisuuden välillä: se on sellainen asia, joka saa ihmiset kiroamaan turvallisuushenkilöitä, koska se rikkoo toiminnallisuutta ilman havaittavaa turvallisuusetua.
ICMP ei ole oikeastaan ​​hyödyllinen, ellet puhu jonnekin viereisen verkkoinfrastruktuurilaitteen tai verkon etävalvontalaitteen alueella, ja siinä tapauksessa käytän tekniikkaa lähellä sitä, jolla Daniel vastaa. En usko, että sen pitäisi aina olla * kokonaan * poissa käytöstä, mutta jos se on tarpeetonta, miksi kenenkään pitäisi antaa käyttää sitä?
Olen samaa mieltä @Ori: n kanssa - säännön tulisi olla "sallia vain se, mitä tarvitaan" haavoittuvuusmaiseman vähentämiseksi. Mahdollisten kanavien rajoittaminen tarkoittaa, että niitä on helpompi seurata.
#3
+9
Daniel Miessler
2011-06-10 05:20:02 UTC
view on stackexchange narkive permalink

On totta, että hyökkääjät voivat käyttää ICMP: tä tietojen hankkimiseen, tiedon siirtämiseen peitetysti jne. On myös totta, että ICMP on erittäin hyödyllinen ja että sen poistaminen käytöstä voi aiheuttaa ongelmia. Traceroute käyttää itse asiassa ICMP: tä, joten tiettyjen ICMP-tyyppien kieltäminen rikkoo sen.

Kysymys korostaa klassista turvallisuuden ja toiminnallisuuden tasapainoa, ja sinun on määritettävä, kuinka paljon toimintoja olet valmis menettämään. saadaksesi x määrän turvallisuutta.

Yksi suositus on sallia vain tietyt tyypit (yleisimmin käytetyt) ja poistaa kaikki muut käytöstä. Tässä ovat iptables-säännöt. Muista, että nämä ovat sallittuja, koska kaikki muu on oletusarvoisesti kielletty.

  # Salli saapuva ICMP: ping, MTU-haku, TTL vanhentunut / sbin / iptables -A INPUT -i eth0 -p icmp -d $ YOURBOX --icmp-tyyppi 8/0 -j HYVÄKSY / sbin / iptables -A INPUT -i eth0 -p icmp -d $ YOURBOX --icmp-type 3/4 -j ACCEPT / sbin / iptables -A INPUT -i eth0 -p icmp -d $ YOURBOX --icmp-tyyppi 11/0 -j HYVÄKSY  
hyvä vastaus. En kuitenkaan näe sitä niin paljon kompromissina: pingin estäminen tuo todennäköisesti korkeintaan merkityksetöntä turvallisuusetua. Tietenkin, jos et tarvitse sitä, jatka ja estä se, jos haluat (hei, sallittujen luettelot ovat parempia kuin mustat listat).
ICMP-pohjainen traceroute ei kuitenkaan ole ainoa vaihtoehto - voit käyttää TCP-pohjaista traceroutea (katso esimerkiksi 'tcptraceroute') tai UDP: tä (mikä on Microsoftin tracert-toiminto - vaikkakin tämä vaatii saapuvan ICMP: n).Voit myös lisätä joitain ulkoisia ICMP-kohteita verkkotestaukseen ja hallintaan.
#4
+7
atdre
2011-06-10 08:19:07 UTC
view on stackexchange narkive permalink

Luulen, että lähtevä kaiku on vaarallisempi kuin saapuva kaikupyyntö ICMP-vahvistuksen vuoksi (joko nopeusraja tai kieltää tämän liikenteen). Vuosikymmenien ajan tämän aiheen pohtimisen jälkeen - olen kuitenkin todennut, että ICMP on vaarallisempi kuin hyödyllinen, ja siksi se on estettävä molempiin suuntiin kirjautumalla mahdollisesti väärennettyyn lähtevään liikenteeseen.

Parasta kaikki maailmat ovat tyhjiä reittejä kaikilla, jotka voivat olla tilallisia, mutta ei-toivottuja (TCP-yhteydet) ja heijastavia ACL: itä (suorituskykyä ohjaavat) kaikelle tilalliselle, mutta sallitulle ja / tai ei täysin tilalliselle (UDP-datagrammat), samalla kun muut poistetaan IP-protokollatyypit, koska ne ovat tarpeettomia. IPsec AH / ESP ei ole tarpeellinen, käytä sen sijaan OpenVPN: ää (tai vastaavaa).

Kun olet estänyt ICMP-tracerouten, sinun on myös käytävä UDP-pohjaisen tracerouten kanssa sekä tekniikan käsitteitä, kuten löytyy 0trace-, LFT- ja osstmm_afd-työkalut.

Vaikka Snort / Suricata ei poimi edes Nmap Xmas -tarkistuksia, puhumattakaan SQLi- tai Javascript-pohjaisista hyökkäyksistä (mihin tahansa suuntaan), meidän on tunnustettava riskien merkitys sidottu verkko- ja sovellusturvahyökkäyksiin nykyaikaista infrastruktuuria vastaan. Meidän pitäisi kieltää, testata ja tarkistaa kaikenlainen jalanjälkien liikenne - enkä ymmärrä miksi tämä ei sisältäisi ICMP: tä, mutta oikeastaan ​​se ei ala tai pysähdy siihen.

#5
+6
Christopher Alfred
2015-02-04 20:23:28 UTC
view on stackexchange narkive permalink

Verkkojen vianmäärityksessä tarvitaan Ping ja Traceroute. Nykyaikaisilla palomuureilla ja suojaustyökaluilla on hyvin vähän, ja rajoittuu olemattomiin mahdollisuuksiin käyttää kumpaakin protokollaa onnistuneesti haitallisella tavalla.

Toisen tason tiimien kyky tunnistaa ja korjata yksinkertaiset reititys- ja verkko-ongelmat on palvelujen toimitusongelma, joka vaikuttaa asiakkaan tyytyväisyyteen tarjoamiesi verkkopalveluiden kanssa.
#6
+4
goodguys_activate
2012-01-25 23:08:43 UTC
view on stackexchange narkive permalink

Sen sijaan, että vastaisin ensisijaiseen kysymykseen "mitkä ovat pingin turvallisuusriskit", vastaan ​​alakysymykseesi "Onko hyvä estää / poistaa käytöstä tuotantopalvelimissa?"

Luulen, että voimme löytää tasapainon turvallisuuden ja hyödyllisyyden välillä. Tukihenkilöstö pitää ping-ilmoitusta yleensä hyödyllisenä tarkistaessaan tietyn solmun viivettä tai saatavuutta. Turvallisuushenkilöstö on huolissaan monista tällä sivulla esitetyistä turvallisuuskysymyksistä, ja he ovat usein "pahiksia".

Miksi et harkitse Pingin poistamista käytöstä sallittujen tai mustien listojen muodossa ja ilmoita asiasta tuellesi henkilökunta. Jos ydinyleisösi on tietyllä maantieteellisellä alueella, rajoita pingoinnin mahdollisuutta IANA IP-allokoinnin

perusteella
Todella totta, varsinkin kun otetaan huomioon, että pingin apuohjelmalla on merkitystä saatavuuden kannalta, se usein unohdettu [luottamuksellisuuden ja eheyden veli] (http://en.wikipedia.org/wiki/CIA_triad#Key_concepts).
#7
  0
Furkan Turan
2020-03-10 17:13:42 UTC
view on stackexchange narkive permalink

Kun palvelimelle on annettu ensimmäinen pääsy, haittaohjelma voi käyttää ping-protokollaa kommunikointitapana komento- ja ohjauspalvelimelleen. Esimerkiksi käänteinen kuori, joka käyttää ping-protokollaa: https://github.com/inquisb/icmpsh

Tämä on jo katettu muilla vastauksilla
Mielestäni kysymys koski sitä, onko pingeihin vastaamisessa turvallisuusriskejä, kun ei ole asennettu ohjelmaa, joka voi lähettää pingit.
#8
-4
Tomas Zubiri
2020-03-10 13:51:08 UTC
view on stackexchange narkive permalink

Kohdassa "Internet-isäntäkoneiden vaatimus" arvostettu ICMP-, TCP-, IP- ja muiden protokollien, IETF: n, standardoinnista vastaava viranomainen määrittelee, että isäntien tulisi vastata ICMP-kyselyihin. Joten käytäntö ei ole pelkästään turvallista, mutta sitä pidetään pakollisena standardien noudattamisessa:

Jokaisen isännän PITÄÄ toteuttaa ICMP Echo -palvelintoiminto, joka vastaanottaa kaikupyyntöjä ja lähettää vastaavat vastaukset kaikuihin. Isäntä PITÄÄ myös toteuttaa sovellustason käyttöliittymä kaikupyynnön lähettämiseen ja kaiku-vastauksen vastaanottamiseen diagnostiikkatarkoituksia varten.

IETF-standardikielellä PITÄÄ tarkoittaa, että "kohde on absoluuttinen eritelmän vaatimus. " Vaikka PITÄÄ tarkoittaa, että "tietyissä olosuhteissa voi olla päteviä syitä jättää tämä kohde huomiotta, mutta sen kaikki vaikutukset on ymmärrettävä"

Tämä tarkoittaa, että palvelimen on vastattava ICMP: n kaiku kyselyyn, mutta ei välttämättä tarjota käyttöliittymä heille.

Asiakirjassa viitataan laajaan keskusteluun, joka kävi ennen korjauksen päivämäärää 1989:

"Tämä neutraali säännös johtuu intohimoisesta Keskustelu niiden välillä, joiden mielestä ICMP: n toisto lähetysosoitteeseen tarjoaa arvokkaan diagnostiikkakyvyn, ja niiden välillä, joiden mielestä tämän ominaisuuden väärinkäyttö voi liian helposti luoda pakettimyrskyjä. "

Jopa uudempien 2010) keskustelut teoreettisista hyökkäyksistä ICMP: n kautta RFC 5927: ssä, IETF ei silti alentanut ICMP: n ECHO-vastauksia MUST: sta PITOISI. Tämän RFC: n kohteena ovat ICMP: n ja TCP: n toimittajat ja toteuttajat, ei kuluttajat. Pahimmat mahdolliset skenaariot ovat palvelun heikkeneminen.

Lyhyesti sanottuna ICMP on turvallinen. Poistamista ei suositella.

Jos kunnioitat seisovien jättiläisten hartioita, kunnioitat heidän päätöstään ja vältät poikkeamista sopimuksesta.

"PITÄÄ" tarkoittaa mitään.Mitä IETF aikoo tehdä, jos olen tottelematon?Heillä ei todennäköisesti ole budjettia asianajajan tai hitmanin palkkaamiseen.Lisäksi useilla kuluttajareitittimillä on oletusasetukset saapuvien ICMP-viestien pudottamiseksi, eivätkä ne kaikki räjähdä.
Puhumme ryhmästä, joka suunnitteli ja standardoi icmp: n yhdessä TCP: n, IP: n, DNS: n jne. Kanssa.
Tämä ei vastaa tarkalleen mikään huomautuksistani.Mikä on sen poistamisen haittapuoli?Mikä on tottelemattomuuden haittapuoli?Toimit ikään kuin Internet hajoaisi, mutta ei.
Ymmärrän huolesi, se on vetoomus viranomaiselle, mutta se toimii minulle.Minulla ei ole kiinnostusta kaivaa syvemmälle, vetoomus tälle viranomaiselle näyttää hyvältä syvyysrajalta kaikelle tietoni etsinnälle.Ja se vastaa alkuperäiseen kysymykseen, onko yleinen käytäntö poistaa ICMP käytöstä?ei, onko ICMP: lle vaaraa?ei.
RFC on tunnetusti vanha.Tätä vastausta voitaisiin parantaa lisäämällä https://tools.ietf.org/html/rfc5927.MUST-tilaa ei muuteta, mutta pituudeltaan kuvataan icmp: n mahdollisia teoreettisia riskejä.
Lisäsin linkin RFC 5927: ään, joka linkittää enemmän turvallisuusriskikeskusteluun kuin mitä ikinä tarvitset.
Tomas - mutta olet kirjoittanut väärän lausunnon "ICMP on turvallinen" - kuten kaikki muutkin, se ei ole turvallista.Se aiheuttaa riskin, joka tulisi ymmärtää missä tahansa erityisessä yhteydessä.
Ainakin yksi asia on voitava merkitä turvalliseksi, muuten vastaus kaikkiin kysymyksiin "Pitäisikö tätä turvallisena?"on "kaikella on riski".Panen jalkani alas ICMP: lle.
Tämä ei vastaa kysymykseen ja perustuu massiiviseen virheeseen logiikassa.Ja tulkitset väärin "riskin" turvalliseksi.Meidän ei tarvitse *** merkitä * mitään * turvallisiksi.Kysymys on kirjaimellisesti "mitkä ovat riskit?"Välttät sen kokonaan.
"Ohita vaarallasi" - ok - mikä vaara?Mikä on riski***?
RFC 5927 ei *** ole *** "enemmän turvallisuusriskikeskustelua kuin mitä ikinä tarvitset".Se kattaa kevyesti yhden pienen ulottuvuuden yhden tyyppisestä riskistä.
Ehkä kompromissi on tehdä kaikesta aliverkon alusta virtuaalisten isäntien tai reitittimen pingattava.
Turvallista on riskien puuttuminen, ne ovat antonyymejä.Turvallisten ominaisuuksien pelkäämisen riski on, että sinut ohjataan pois todellisista riskeistä.Se on kuin nuo kauheat rakennukset, jotka tuottavat 5 tuhatta varoitusta, unohdat tärkeät, jos et pysty suodattamaan triviaalia.
@TomasZubiri et ymmärrä riskin käsitettä, eikä se vieläkään auta vastaamaan kysymykseen "mitkä ovat riskit?"Tämä ei ole vastaus.


Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 3.0-lisenssistä, jolla sitä jaetaan.
Loading...