[Megoldva] Tűzfal beállítása Fedorán

Red Hat, Fedora, CentOS

Ezt miért csinálja velem?


firewall-cmd --permanent --add-port=1793/udp
Error: IO_Object_XMLGenerator instance has no attribute '_out'

Természetesen root joggal. GUI-ról ugyanez a helyzet. Mivel azt hittem, a GUI vacak, ezért próbáltam CLI felől egyezkedni vele. Egyelőre vesztésre állok.

Megoldás:

A debug alapján kiderült, mit hívott, hol keletkezett a hiba. Megnéztem, az adott függvényt melyik csomag tartalmazza. Feltűnt, hogy ez egy Fedora 19-es, azaz korábbi csomag. A Fedora build szerveren, megnéztem, nincs belőle újabb. Ekkor úgy döntöttem, leszedem ezt a csomagot, annál is inkább, mert egy másik gépen nem volt ez a csomag. Függőségként nem is vitt magával semmit. Nem feszítem tovább a húrt:

rpm -q PyXML
PyXML-0.8.4-29.fc19.x86_64

yum erase PyXML

Most már működik a tűzfal beállítása. :)

  • 4988 megtekintés

( uid_7086 | 2014. 07. 29., k – 07:03 )

Mivel a google még csak nem is hallott erről (leszámítva ezt a topikot), feltételezném, hogy egyedi gond:
- upgrade-elt rendszer, az upgrade során elkefélődött beállításokkal
- egyszer belepiszkáltál, esetleg a konfig fájlokba és az egyikben ottmaradt valami, ami a korábbi állapotot nem zavarta
- nyelvi beállítások nem tetszenek neki
- stb. ;)
(Ilyenkor mindig magamban keresem a hibát, mert olyan nem létezik, hogy egy bug csak nálam...)

Egyébként pontosan milyen verzió?
(Esetleg felrakok egyet és megnézem, nálam mit csinál)

( tomeeSAN | 2014. 07. 29., k – 08:09 )

Megnézném, hogy sérült-e a csomag.

rpm -verify iptables-services

Mindenképpen változást fog jelezni mert konfiguráltad. Ettől nem kell megilyedni.
Ha olyan file-ra is változást mutat ami nem konfig file-nak tűnik akkor telepitsd ujra a csomagot.

üdv
T

( locsemege v | 2014. 07. 29., k – 09:35 )

A csomagok jók, de tény, hogy virtualizációban i686 architektúrán működik. A host-on x86_64-en meg nem. Na jó, akkor most jön az, hogy mit szúrtam el. :(

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Fedora 20-ról van szó, up to date a host és a guest is. A host valódi vason x86_64, a guest VirtualBox-ban i686, mindkettőn 3.15.7-es kernel. A guest csak „kontroll csoport”, azt vizsgálom vele, hogy ott működik a tűzfal beállítása, míg a host-on nem.

Amire a systemctl status firewalld után jutottam, az az, hogy nem tudta felolvasni a custom xml file-okat. Megnéztem, s kiderült, hogy ezek 0 hosszúságúak voltak. Tehát írásnál meg tudja nyitni a file-t, de az XML generátora valamiért összeesik. A kiírt hibaüzenet is erre utal. Egyébként a /etc/firewalld környékén kellene lenniük a file-oknak.

Itt tartok most. Jó volna tudni, melyik library generálja az XML-t, hogy verziót, vagy bármit nézni tudjak.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az rkhunter-től jött egy ilyen e-mail a saját gépemről, ettől egyáltalán nem vagyok boldog:

---------------------- Start Rootkit Hunter Scan ----------------------
Warning: Package manager verification has failed:
         File: /usr/bin/curl
         Try running the command 'prelink /usr/bin/curl' to resolve dependency errors.
         The file hash value has changed
         The file size has changed
Warning: Package manager verification has failed:
         File: /usr/bin/wget
         Try running the command 'prelink /usr/bin/wget' to resolve dependency errors.
         The file hash value has changed
         The file size has changed

----------------------- End Rootkit Hunter Scan -----------------------

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem találtam meg a hibát, ezt mondtam neki:

yum reinstall \*

Azért nem distro-sync, mert néhány csomag a koji-ról frissebb, mint ami az update repókban van, ezeket nem szeretném, ha downgrade-elné. Most letölt 1.7 GB-ot, feltelepít 5.1 GB-ot. Nincs jobb ötletem, ami gyors is. Minden python kezdetű csomagot, meg a libxml2-t újratelepítettem, nem segített. Azért ezt, mert strace-ből úgy tűnt, ezt használja. Viszont sok száz kilobyte strace logot nézni sem kellemes, maradt a reinstall. Kíváncsi vagyok, mi lesz belőle.

Az rpm -V bash yum rpm nem ad hibát, 0 a visszatérési érték.

Szerk.: fsck megvolt, filerendszer nem beteg.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Talán a perl ami még érintett lehet. XML Generator ...

Ha a filerendszer rendben van az jó. Én az adataim miatt aggódnék. clamav befigyelne azt hiszem, meg a létező összes rootkit detektor.
Én lehet, hogy script-fu -hoz folyamodtam volna.
for i in $(rpm -qa); do rpm -V $i; if [[ $? -eq 0 ]]; then echo rendben; else echo "rpm -i $i"; fi; done
vagy valami hasonló ami működik is :)

Cron-ból futott, manuálisan még nem futtattam. Mindenesetre az rpm -V nem panaszkodik, legalább is a curl és wget vonatkozásában biztosan nem.

Annyi történt időközben, hogy egy másik általam telepített 64 bites gépen is megnéztem a tűzfal beállítását, gond nélkül működött, tehát a hiba valóban csak nálam lép fel. Mivel azt a gépet is én telepítettem, nagyon hasonló az enyémhez, a saját szokásaim szerint raktam össze, éppen ezért jó ellenőrzés volt. Természetesen Fedora 20 van azon is.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Elmondom, miért gyanús a dolog. Az rpm -V szerint is változott a fileméret. A modification time-ot lehet, hogy meghamisították, de a change time a két file esetében 3 másodpercen belül van, mégpedig 2014-07-20 21:15:22.153300578 +0200, illetve 2014-07-20 21:15:24.497246652 +0200. A change time-ot ritkán nézik, erre lehet, nem számítottak. Már feltéve, hogy valami rosszindulatú dologról beszélünk. Az is gyanús, hogy a curl és a wget teljesen más rpm csomagban van, semmi közük egymáshoz, nem függenek egymástól, ám funkcionálisan hasonlók, és éppen ők változtak meg. A jogok jónak látszanak egyébként:

ls -Z curl wget
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       curl
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       wget

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 07. 30., sze – 01:42 )

Ha nem fut a firewalld, offline is lehetne generálni megfelelő file-okat. Ez sem sikerült:

strace -f -o f.txt firewall-offline-cmd --new-service=ihu
ERROR: Failed to load service file '/etc/firewalld/services/ihu.xml':
IO_Object_XMLGenerator instance has no attribute '_out'

A relevánsnak tűnő rész:

28230 open("/etc/firewalld/services/ihu.xml", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
28230 fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
28230 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fff2c929920) = -1 ENOTTY (Inappropriate ioctl for device)
28230 fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
28230 lseek(3, 0, SEEK_CUR)             = 0
28230 lseek(3, 0, SEEK_CUR)             = 0
28230 lseek(3, 0, SEEK_CUR)             = 0
28230 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
28230 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f48ddff6000
28230 write(1, "IO_Object_XMLGenerator instance "..., 56) = 56
28230 close(3)                          = 0
28230 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f48dd814750}, {0x7f48ddb336a0, [], SA_RESTORER, 0x7f48dd814750}, 8) = 0
28230 exit_group(2)                     = ?
28230 +++ exited with 2 +++

Pirossal szedtem, ami nekem gyanús. Mi okozhatja?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 07. 30., sze – 09:59 )

A chkrootkit ezt mondja:
Searching for Suckit rootkit... Warning: /sbin/init INFECTED
Checking `bindshell'... INFECTED (PORTS: 465)

Ez első diagnózisa szerintem téves, mindössze abból következik, hogy a /sbin/init egy symlink a /lib/systemd/systemd-re. A chkrootkit nem ismeri a systemd-t.

Az viszont nem világos, mit értünk bindshell alatt, és azzal mi a baja.

Szerk.: Megnéztem másik gépen is, valószínűleg a második is false pozitív.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2014. 07. 30., sze – 11:02 )

Így néz ki a megdöglés:

2014-07-30 10:51:13 DEBUG1: config.addService('ihu')
2014-07-30 10:51:13 Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/firewall/server/decorators.py", line 53, in dbus_handle_exceptions
    return func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/firewall/server/config.py", line 501, in addService
    obj = self.config.new_service(service, settings)
  File "/usr/lib/python2.7/site-packages/firewall/core/fw_config.py", line 365, in new_service
    service_writer(x)
  File "/usr/lib/python2.7/site-packages/firewall/core/io/service.py", line 170, in service_writer
    handler.startDocument()
  File "/usr/lib64/python2.7/site-packages/_xmlplus/sax/saxutils.py", line 239, in startDocument
    self._out.write('<?xml version="1.0" encoding="%s"?>\n' %
AttributeError: IO_Object_XMLGenerator instance has no attribute '_out'

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Majdnem ez volt. Valaha upgrade-eltem Fedora 19-ről 20-ra, és a PyXML Fedora 19-es csomag fennmaradt, mivel ennek nincs Fedora 20-as verziója. Tehát senki sem frissítette, le sem szedte. Gondolom, más nevű csomagban vannak a megfelelő függvények.

A lib64 nem túl meglepő, hiszen 64 bites az oprendszer.

Szerk.: Az a meglepő, hogy én ezt 8 hónapon át nem vettem észre. Ezek szerint Fedora 20-on még nem nyúltam a tűzfalamhoz. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

De, pont azért meglepő, mert ami 64bites gépem van, az mind a /usr/lib-et használja, a jelenleg használt rendszeremen nincs is lib64 könyvtár.

Azt meg kellene nézni, hogy a python XML feldolgozóját most milyen néven csomagolják, mert tartok tőle, nem ez az egyetlen hely, ahol gondot okoz, csak a többit még nem találtad meg.

Kétféle van:

locate -b '\saxutils.py'
/usr/lib64/python2.7/xml/sax/saxutils.py
/usr/lib64/python3.3/xml/sax/saxutils.py

A csomagok, amelyben vannak:

rpm -qf `locate -b '\saxutils.py'`
python-libs-2.7.5-13.fc20.x86_64
python3-libs-3.3.2-17.fc20.x86_64

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE