Meikän pitäisi tehdä qRadariin plug-in, joka hakee tiettyä dataa (eräänlainen IPFIX-laajennus) paketeista ja näyttää sen qRadarin käyttöliittymässä. Ongelmana on, että virtuaalikoneen CentOS, jolla qRadarin palvelin pyörii hylkää kyseiset paketit (UDP porttiin 4740) palauttaen virheen "port unreachable". Wireshark näyttää, että kyseiseen porttiin osoitetuista paketeista tulee odotetusti kyseinen virhe.
En ole kovin kokenut iptablesin (jota kyseinen CentOS käyttää) kanssa, mutta tutkimalla sääntölistaa päättelin, että lisäämällä sääntö "-p udp --dport 4740 -j ACCEPT" sopivaan kohtaan inputtia ja "-p udp --sport 4740 -j ACCEPT" outputiin pitäisi toimia ja lisäsin sellaiset ennen rejectejä, Mutta Wireshark näyttää edelleen, että paketeista tulee sama virhe.
Pitäisikö iptables käynnistää uudelleen vai teinkö jotain väärin ?
En ole kovin kokenut iptablesin (jota kyseinen CentOS käyttää) kanssa, mutta tutkimalla sääntölistaa päättelin, että lisäämällä sääntö "-p udp --dport 4740 -j ACCEPT" sopivaan kohtaan inputtia ja "-p udp --sport 4740 -j ACCEPT" outputiin pitäisi toimia ja lisäsin sellaiset ennen rejectejä, Mutta Wireshark näyttää edelleen, että paketeista tulee sama virhe.
Pitäisikö iptables käynnistää uudelleen vai teinkö jotain väärin ?
Vastaukset 6
Vanhimmat
Ilmeisesti virtuaali alustassi on ongelma.
Tämä on sivuhuomautus, joka ei varsinaisesti liity tuohon ketjun aloittaneeseen kysymykseen. Mutta jos iptablesista ei ole hirveästi kokemusta, niin minusta olisi oikeastaan parempi opetella iptablesin sijasta nftablesin käyttö. Ainakin uusimmassa Debianissa vanha iptables on korvattu nftablesilla. Nftables tulee varmaankin yleistymään myös muissa distroissa. Asia on toki eri, jos jo on kokemusta iptablestista, mutta jos nyt alkaa opeteelemaan palomuurin hallintaa, niin järkevämpää on opetella heti alusta alkaen nftablesin käyttö. Palomuurin käyttöä helpottavista työkaluista ja niiden graafisista käyttöliittymistä ainakin firewalld ja sen graafinen käyttöliittymä firewall-config tukevat nftablesia. Ufw ja sen graafinen käyttöliittymä gufw eivät ole itselläni käytössä, joten niistä en osaa sanoa mitään varmaa.
T. miksuh
qRadar on ilmeisesti suunniteltu käyttämään iptablesia siinä määrin, ettei sitä voi helposti vaihtaa. Esmes iptablesin asetustiedostossa on viittauksia qRadarin omiin asetuksiin (pre- ja post). Googlaamisen perusteella CentOS:issa olisi vaihtoehtona myös FirewallD, mutta se ei ole käytössä ja jos sen yrittäisi pakottaa käyttöön se saattaisi rikkoa toiminnan.
Mutta jos olen ymmärtänyt iptablesin toiminnan oikein ensimmäinen asetuslistassa oleva sääntö, joka sopii paketille (esmes oikea protokolla, osoite ja portti) valitaan ja suoritetaan sen toiminta (esim. ACCEPT päästää paketin eteenpäin). Ja jos ei mikään sääntö päde käytetään kyseisen taulukon (esim. INPUT) oletustoimintaa. Jos siis määrittelen ennen ensimmäistä rejectiä/dropia säännön, jossa UDP paketit, jotka on osoitettu porttiin 4740 päästetään läpi ei ongelmia pitäisi olla ?
Lisäys: huomasinpa, että tuo palvelin-CentOS ilmeisesti hakee säännöllisin välein asetukset pysyvästä varastosta. Kun katsoin aikaisemmin INPUT-taulukon asetuksia (sudo iptables -L INPUT) lisäämäni ACCEPT-sääntö oli toisena ennen alkuperäistä QChain-uudelleenohjausta (ykkösenä oli ACCEPT tcp/ezmeeting-2), sen jälkeen REJECT tcp:lle ja udp:lle. Mutta kun tarkistin hetki sitten uudelleen lisäämäni sääntö oli kadonnut. Eipä se tosin aikaisemminkaan tuntunut auttavan.
Päättelen ongelmana olevan palomuurin blokkauksen, koska input-taulukon lopussa on udp:lle sääntö "reject-with icmp-port-unreachable" ja Wireshark näyttää nimen omaan sellaisen virheen vastauksena noille paketeille.
Ongelma kuiteskin varmaan virtuaali alustassa, jossa portti on suljettu,
En usko, että ongelma on virtuaalialustassa, koska osa kyseiseltä liitännältä tulevasta datasta menee kuitenkin ongelmitta läpi ja jotkut UDP-paketitkin näyttäisivät menevän läpi (Wiresharkissa ei näy noita port unreachable-virheitä). Ja qRadarin omassa network activity näkymässäkin on liikennettä, ei kuitenkaan noita haluttuja paketteja. Osa paketeista siis menee läpi, osa ei. Tuo kyllä tuntuisi viittaavan palomuuriin.
# iptables -A OUTPUT -p udp –sport 4740 -j ACCEPT
# service iptables save