Palomuurin lokissa on rivi, jota et odottanut: ACK-paketti, conntrack-tila NEW, lähdeosoite joka ei ole sinun, kohdeportti auki. Kiusaus on lukea se tuoreeksi saapuvaksi yhteydeksi, jota kukaan ei valtuuttanut. Mitä rivi itse asiassa sanoo, on kapeampaa: kun tuo paketti saapui tähän hookiin, seuraajalla ei ollut vastaavaa tilaa, ja paketti kantoi ACK:ta. Ne ovat kaksi tosiasiaa kahdesta eri asiasta, eikä kumpikaan ole kättelyn täydellinen litterointi. Tässä on järjestys, jonka käyn läpi ennen johtopäätöstä.

Aloita paketista, älä tuomiosta

Erottele havainnot ennen kuin tulkitset niitä. TCP-liput kuvaavat tätä pakettia, seuraajan tila kuvaa mitä se tiesi tuossa hookissa, ja tallenteesi kuvaa vain sitä ikkunaa, jonka nauhoitit.

Näiden kolmen sekoittaminen on se tapa, jolla ACK:sta tulee ”palveluntarjoaja päästi jonkun sisään”.

Mitä NEW hookissa todella tarkoittaa

iptablesin conntrack-täsmäytys dokumentoi NEW:n paketiksi, joka aloittaa yhteyden, tai sellaiseksi, joka liittyy yhteyteen, joka ei ole vielä nähnyt liikennettä molempiin suuntiin. ESTABLISHED tarkoittaa, että seuraaja on nähnyt paketteja molempiin suuntiin. Kumpikaan määritelmä ei sano, että paketti oli SYN, eikä että se saapui ilman historiaa.

Seuraaja, joka alkaa tarkkailla virtaa keskeltä, luokittelee seuraavan paketin sen mukaan, mitä tietää, ja se voi olla ei mitään. Se on väite seuraajan muistista, ei etäisen isännän aikomuksesta.

Löyhä seuranta selittää useimmat ACK-yllätykset

Ydin dokumentoi nf_conntrack_tcp_loose, mikä antaa seuraajalle mahdollisuuden ottaa haltuunsa TCP-yhteyksiä, joiden alkua se ei nähnyt. Asetuksen oletusarvolla virran keskeltä tuleva ACK voidaan hyväksyä vakiintuneeksi virraksi. Kytke se pois, ja sama paketti luokitellaan todennäköisemmin INVALID:ksi kuin NEW:ksi. Molemmat tulokset kuvaavat seuraajan sääntöjä, eivät sovelluksen historiaa.

Tarkista siis tuo asetus ennen kuin rakennat teoriaa tunnisteen päälle.

Sulje pois tylsät syyt tässä järjestyksessä

Useimmat seuraamani NEW-ja-ACK-tapahtumat päättyivät johonkin näistä, ja kaikki on halpaa tarkistaa:

  • Conntrack-taulu tyhjennettiin tai seuraaja käynnistettiin uudelleen.
  • Isäntä käynnistettiin uudelleen tai virta siirtyi toiseen namespaceen tai laitteeseen.
  • Epäsymmetrinen reititys lähetti SYN:n polulle, jota et tallenna.
  • NAT kirjoitti tuplen uudelleen, joten merkintä ei enää vastaa lukemaasi.
  • Tallennus alkoi myöhään eikä nähnyt alkua koskaan.

Jokainen näistä poistaa aiemmat paketit seuraajan näkymästä ja jättää myöhemmät koskemattomiksi. Uudelleenkäynnistys tai taulun tyhjennys on helpointa vahvistaa uptimen ja lokien perusteella. Epäsymmetrinen reititys näkyy yksisuuntaisena tallennuksena. NAT on ovela, koska se tuple, jonka seuraaja tallensi, ei ole se tuple, joka lokiin tulostettiin.

Kirjoita muistiin, mitkä näistä suljit pois ja miten, ennen kuin jatkat.

Lue tuple, rajapinta ja hook

Conntrack-merkinnän avaimena ovat osoitteet, portit ja protokolla, joten jokainen käännös muuttaa sitä, mikä merkintä täsmää. Kirjaa myös rajapinta ja hook, sillä väärällä rajapinnalla tai toisen ketjun jälkeen nähty paketti kertoo, ettei polku ole se, mikä kaaviossa on. Kun tapahtuma koskee VPN:ää, päätä, katsotko sisempää pakettia vai ulompaa kantajaa. Vertaa sitten siihen, mitä yhdyskäytävä kirjasi samalle viisiosaiselle tuplelle.

Kaksi näkymää samasta virrasta, jotka ovat ristiriidassa, kertovat enemmän kuin kumpikaan yksin.

Milloin kannattaa eskaloida

Eskaloi, kun voit osoittaa palvelun, joka on saavutettavissa eikä pitäisi olla, sekä virran, sen sallineen käytännön ja todisteet molemmista päistä. Älä raportoi palveluntarjoajan virhettä yhden tilatunnisteen tai yhden osittaisen tallennuksen perusteella, sillä se raportti suljetaan juuri lukemallasi selityksellä. Jos palvelu on todella altistettu, sen rajan omistaja on oikea henkilö korjaamaan sen, ja delegoitu porttimääritys tai tahaton kuuntelija on todennäköisempi syy kuin bugi.

Sulje sitten se näkyvyysaukko, joka sai yhden paketin näyttämään koko istunnolta.

Aiheeseen liittyvät artikkelit