Üdv!

Adott egy Fedora Server-t futtató dedikált vas. Bár a hoszting adna IPv6-ot, egyelőre az általuk adott IPv6 cím egyáltalán nincs belőve, így a szerver csak IPv4-en csatlakozik. Egyelőre nem volt rá szükség.

Viszont most jól jönne egy nagyobb IPv6 blokk, mivel beüzemeltem egy proxyt rajta és azt vettem észre, hogy ha minden kérés egyetlen IP címről hagyja el a vasat, akkor a google meg az összes nagyobb oldal egy idő után captchával kezdi el bombázni a usereket. Tehát az a terv, hogy hozzáadok a proxyhoz egy nagyobb IPv6 blokkot és minden proxy user kap majd egy dedikált címet, vagy az egész round robin lesz (még nem döntöttem el). Mivel a hoszting csupán egyetlen IPv6 címet ad, így a tunnelbroker felé kezdtem el kacsintgatni. Annyit érdemes tudni a szolgáltatásról, hogy ingyen adnak egy /48 IPv6 blokkot kérésre egy sit tunnellel. Egy /48 valószínűleg bőven elég lenne számomra, így ez tökéletesnek tűnik. Szeretném felrakni, viszont az általuk javasolt parancsok nem megfelőek számomra:

modprobe ipv6
ip tunnel add he-ipv6 mode sit remote 216.66.66.66 local <szerveremipv4cime> ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f08:412a::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr

Ugyanis itt egyrészt a /64 blokkot rendeli az interfészhez, nekem pedig a /48 kellene. Így egyszerűen az "ip addr add" sorban a /48-at adtam meg helyette. És ez így működik is szépen. Futtattam még egy sysctl -w net.ipv6.ip_nonlocal_bind=1 és ip -6 route replace local <48asipv6blokkom> dev lo parancsokat és a proxy már tudja is használni a teljes range-t. Igen ám, viszont a default route miatt a teljes rendszer ipv6-os forgalma a tunnelen keresztül fog zajlani, amit nem szeretnék, mivel a tunnel jóval lassabb, mint a fizikai interfészem, illetve csak a proxyn belül van szükségem az IPv6-ra, más programokkal felesleges.

Gondolkoztam, hogy a default route helyett hogyan tudnám megoldani, hogy csak bizonyos programok számára legyen a sit tunnel elérhető. Van egy megoldásom, amit a VPN-ek esetében szoktam használni, hogy csinálok egy felhasználót és annak a forgalmát irányítom egy adott interfészre. Valahogy így néz ki a parancssorom hozzá:

adduser ipv6
id ipv6 # uid: 1004, gid: 1005 az esetemben
modprobe ipv6
ip tunnel add he-ipv6 mode sit remote 216.66.66.66 local <szerveremipv4cime> ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f08::2/48 dev he-ipv6
ip -6 rule add uidrange 1004-1004 table he-ipv6
ip -6 rule add default dev he-ipv6 table he-ipv6

Ennek mennie kellene és az ipv6 user forgalmának elviekben a tunnelt kéne preferálnia, de a gyakorlatban, mintha az uidrange feltétel nem működne ipv6-tal. Ugyanez a módszer ipv4-gyel remekül működik.

Mit tudok tenni? Gondolkoztam VM-men, de az nagyon béna megoldás, illetve network namespace-n/vrf-en, de azt nem sikerült összehozni...

Illetve van egy wireguard VPN kliensem. Meg tudom csinálni, hogy a sit forgalmat VPN-nen keresztül bonyolítom le? Vagy a wireguard L3-on működik, a sit pedig "lentebb van"?

Köszönöm!

Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!

Sziasztok!

Lesz egy hálózati eszközöm (IP kamera) a belső hálózaton ami csak http-t tud, viszont szeretném ezt az eszközt publikus IP-n is biztonságosan elérni. Ezen a belső hálózaton van egy Debian szerver is, ami már képes https-re, érvényes certificate-je van és nyilván autentikációra is képes.

Arra gondoltam, hogy valamilyen módon a szerverbe kellene egy proxy vagy valami ilyesmi.

Közben szétnéztem utána néztem a dolgoknak és találtam egy ilyet:
https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html#page-header

Ha jól értem, akkor ezzel a ProxyPass-al meg lehet oldani?

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

VPN

| MCSE+M/S, MCITP, VCP6.5-DCV - ''Life can be hard, but Scooter is harder :)'

GIT kérdésben kellene egy kis segítség. Van egy GIT szerverem egy belső hálós gépen, amit a belső hálóról így: git clone git@192.168.7.103:/~testrepo.git el is lehet érni. E szerint készült: [link]
Itt nem értem, hogy mit takar a :/~ tag a címben.

Valamint ez a gép ssh-n keresztül elérhető a külvilágból, de nem a 22-es, hanem egy másik porton. (az ssh működik, be tudok lépni a gépre)
Viszont sehogy nem jövök rá, hogy milyen szintaxissal lehetne megoldani, hogy elérjem ezt a git repót itthonról.

Ilyesmikkel próbálkozom: git clone ssh://git@XXX.XXX.XXX.XXX:17722/testrepo.git
de nem találja a repót. Gondolom az a tag a címben amit kérdeztem, annak köze van ehhez.

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

gondolom a git user homejaban van a repo? ~ az a home-ot jelenti.
ssh://[user@]host.xz[:port]/path/to/repo.git/

[link]

az ssh nem használja a gepnev:port formátumot.

[ Szerkesztve ]

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Igen, ott van. És ezzel rá is vezettél a megfejtésre!

git clone ssh://git@XXX.XXX.XXX.XXX:17722/home/git/testrepo

Köszönöm!

[ Szerkesztve ]

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

A ~ az a git user home-ja, mint normálisan. Az első esetben az SCP formátumot használod az elérésre, a másodikban a hagyományos SSH-t. A második is jó, adj meg teljes elérési utat:

git clone ssh://git@XXX.XXX.XXX.XXX:17722/home/git/testrepo.git

Esetleg hivatkozhatsz itt is a home-ra. Itt olvashatsz róla.

Szerk.: Kell nekem hozzászólás írása közben dolgoznom, lekéstem.

[ Szerkesztve ]

Alex

Sziasztok.

Van egy jelszavas zip és jelszavas rar fájlom. Szeretném jelszó hiányában feltörni őket.
A zip2john/rar2john és hashcat kombóval próbálkoznék. Azonban miután létrehozom a hash-t mondjuk a zip fájlból (./zip2john valami.zip > hashes.txt) és indítanám a hashcat-et (./hashcat -a 3 -m 17225 .\hashes.txt) hibába futok:

Hashfile 'hashes.txt' on line 1 (..blah, blah... ): Signature unmatched
No hashes loaded.

Mit szúrok el? A 17225 nem megfelelő a hash-hez? [link]
Ha 23003-at használok, akkor szintén nem megy csak Separator unmatched lesz a hibaüzenet.

[ Szerkesztve ]

Ha jól nézem egy olyan gond lehet talán, hogy a hash '$pkzip$8'-al kezdődik és a hashcat csak '$pkzip2$8'-at ismer.
Hasonló gondom lehet a Rar fájl esetén. Ott '$RAR3$*1*' kellene, de az nincs benne a build-ben csak a táblázatban.

Ilyenkor mi van? Nem találkoztam még ezzel, hogy sudo/root nem engedi írni a fájlt.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Vagy read-only mode-ban van mountolva a meghajtó, vagy esetleg lockolva van a fájl?

[ Szerkesztve ]

Buliban hasznos! =]

Szerintem nem éri meg erre időt pazarolni. Zip-nél attól függ, hogy milyen Zip progi jelszavazta, milyen titkosítással, Rar-nál meg hogy milyen régi volt a tömörítő. A modern Zip progik (pl. 7-zip), meg a 3-asnál újabb Rar AES-t használ, min. 128 bit, néha 256 bit, plusz pár bites kulcserősítés, így nagyon hosszú brute force-szal törni őket, nem nagyon éri meg. Ha meg is csinálod, akkor se a nyereségvágy, hanem csak a tanulás, szakmai kíváncsiság hajtson.

De ha régi fájlok, amiket régi Zip, főleg pkZip, WinZip csomagolt, meg régi Rar, azokat elég könnyen törik kulcsrakész megoldások, pár másodperce egy átlag desktop gépen.

A Zip-pel a legnagyobb baj, hogy nem biztosan szabványos. Ahány Zip progi, annyi féle megoldást használnak. Rar-ból legalább csak egyféle van.

Maga a fájlrendszer, amin az illető fájl van, csak írásvédetten, read only flaggel lett csatolva, vagy mert eleve így volt beállítva, vagy valami fájlrendszerhiba miatt csatolta így. Csatold fel újra, rw módban.

[ Szerkesztve ]

ha authorized_keys fájlra mindenkinek jogokat adsz, akkor lesz még pár dolog, amivel előtte nem találkoztál

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Annyira emlékszem, hogy a zip-et még windows-on a total commander-en belül aes256-al titkosítottam. A rar pedig winrar 3.x verzió volt. Talán 3.80, de nem biztos. Ha érdekes, akkor elő tudok bányászni régi dvd-t amin az install volt.
Esetleg valamelyiket lehetne célirányosabban visszafejteni?

[ Szerkesztve ]

1. Mivel a file a tied, nem kell sudo.
2. Ne adj senki másnak hozzáférést a file-hoz.

https://www.coreinfinity.tech

Lehet SELinux vagy apparmor védi, vagy valami hasonló security modul.

Nem tudom mi volt a gond vele, de újra indítottam, és jó lett.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

bennem felmerülne a gyanú, hogy elkopott az sd kártya és ezért csinált egy emergency remount readonly-t.

még annyit, hogy az általam használt desktop debianok nem veszik figyelembe az authorized_keys-t, ha nem jó a védelmi kulcsa + a .ssh dirnek a kulcsa.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Sajnos az a default action máig, pedig szerintem jóval indokolhatóbb a kernel panic ilyen esetben.

Tény, hogy nem sok hely volt rajta. És igen, sd kártya. Ugye ez egy odroid xu4 gép, a rendszer egy sd kártyán van, a többi adat pedig egy külső hdd-n.
Sokszor van, hogy elfogy az sd-ről a hely. Már gondolkoztam, hogy cron-nal csinálok valami cleanup scriptet, ami törli a régi logokat, cache-ket.

Alapból 600-as jog van rajta, tudni is szoktam írni. Nem is értettem ezt a dolgot. Csak a napokban akadozott minden szolgáltatás rajta. Emiatt léptem be, aztán mivel gép csere is volt, akkor mondom feldobom az új ssh kulcsot is.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

A Rar-verzió csak azért érdekes, mert a 3.x-ig egyszerű CBC-s eljárással titkosított a Rar, meg a WinRar is, és a 4.x-től álltak át AES-re. Ha tényleg 3.80-assal csináltad, akkor mákod van, könnyen törhetőnek kéne lennie, a megfelelő célszoftverrel másodpercek. És azért írom így általánosságban, mert bár csináltam ilyet, hogy 3.x-es .rar archivumról oldottam le a jelszót, de évekkel ezelőtt volt, és akkor Windowst használtam, és arra kiadott célszoftverrel törtem, talán valami Rar Password Cracker vagy már nem is tudom mi volt a neve, pár mp. alatt simán nyitotta az archívumot. Linuxon nem tudom melyik natív tool jó erre.

Az AES256-os zip törése elég reménytelen viszont. Persze, meg lehet próbálni, de mivel csak brute-force lehet, az elég sokáig fog tartani, kivéve ha 12345 vagy password vagy ilyesmi blődség a jelszó.

Huh, jó lenne a Rar jelszó törés. Már csak azértis, mert a két archivum között kevés idő telt el, sanszos hogy ugyanazt a jelszót használtam a zip-nél is vagy valami kombinációját, mint a rar esetében.
Tuti, hogy 3.8x. Na, akkor keresgélek valami hasonló névvel cracker-t.

(sok-sok évvel ezelőtt egyszer járt a kezeim között valami univerzális cd, amivel word, excel, windows és még jópár program, köztük talán rar jelszókat lehetett visszafejteni. már nincs meg, de most az is jól jönne.)

Sziasztok

Lenne megint egy problémám. Igazából elég kicsi az esély, hogy megoldásom is lesz, de hátha együtt sikerül.

Adott egy Arch telepítés KDE-vel. Arcwiki alapján telepítettem most már kb sok-sok éve cc 2016-ban) Használok xfreerdp-t multimonitoron. Van 3 képernyőm, ebből 2-n futtatom a távoli win RD-t. (ez igazából mindegy is, mivel akár mind a 3-on meg tudom jeleníteni)

Plasma 5.20.x-ig minden rendben működött. A plasma váltott 5.21-re, és azóta csak az egyik képernyőmön jelenik meg a win. A winben felismeri, hogy neki 2 vagy 3 monitort kéne használni, és a configban is látható 2. képernyő (tehát a win leképezi), de a Linux csak egy monitort használ hozzá. A többi láthatatlan, nem jelenik meg.
Ha downgardelem plasma 5.20-ra akkor megint tökéletes minden. Több RD-vel is próbáltam, és az eredmény ugyanaz.
Valószínű nálam lesz a hiba. mert USB-re felraktam egy Ubuntut és egy Calam-Arch-KDE-t (Plasma 5.21), és azokon minden jól megy.
Van ötlete/tippe valakinek , hogy mi a kótyagos fityfenét nem állítottam be, vagy állíthattam el?

A freerdp-n már jelentettem mint bug-ot, de félek nem tudnak segíteni.

Azért jelentettem, mert 5.20-ig minden rendben volt.

Legrosszabb esetben felrakom újra az Arch -ot, de ez elvi kérdés, nem szívesen tenném.

Sziasztok!

Bluetooth fülessel kapcsolatban lenne gondolom.
Linux Mint 20.1 Cinnamon
Kernel: 5.4.0-66-generic
Dell Latitude 5490 (Bluetooh 4.2)
Xiaomi Mi True Wireless 2 Basic (TWSEJ08WM/BHR4089GL) (Bluetooth 5.0)
A füles szépen csatlakozik a Bluetooth-on a laptophoz, én tökéletesen hallok, viszont a másik fél engem nagyon rosszul. Kis troubleshoot után rájöttem, hogy nem a füles mikrofonját használja a szoftver, hanem a laptop belső mikrofonját.
2 mp Google (linux bluetooth headset microphone not working) után láttam, hogy ez nem egyedi probléma. feltelepítettem a blueman-t hogy az A2DP-t átváltsam HSP-re [link] de nem sikerült Refused to switch profile to headset_head_unit: Not connected
Próbáltam, hogy a load-module module-bluetooth-policy auto_switch=2 sort hozzáadtam a /etc/pulse/default.pa fájlba, de nem segített
Kipróbáltam Windows-on, és ott simán működik (Dual boot-os a notebook)

Van valakinek valami ötlete, hogy lehetne működésre bírni ezt a BT headset-et Linux-on?

Köszönöm!

VCP7-DCV, CCNA ||| Ami működik, ahhoz nem szabad hozzányúlni!

Elnezest a keresztposztert, de van egy olyan ubuntu problemam ami nem ubuntu specifikus, hatha ti tudnatok segiteni.
A lenyeg, elrontottam a rendszer SSD particioit, emiatt a grub nem tud bootolni, EFI a rendszer.
A grub konyvtarat egyik particion se talalom, ahogyan a kernelt sem.
Ha tovabb akarok menni a /boot konyvtaron, azt mondja a particion kivul szeretnek olvasni es azt nem lehet.
BootRepair USB-rol probaltam, de nem adta be a Repair opciot sajnos.
#38776

Szerintem túlbonyolítod. Ha alapvetően jól hallasz a BT headsettel, akkor lehet csak annyi kéne, hogy a grafikus hangerő-szabályzóban (pavucontrol) a bemeneti eszközöknél átállítod, hogy ne a laptop mikrofonját használja, hanem a BT eszközét.

#31227 PeachMan: ja, ez nagyon jó ötlet, nekem sem jutott volna eszembe. Alapvetőn a Hirenst nem tartom sokra, de egyszerű jelszótöréshez tényleg lehet, hogy most a legjobb, legegyszerűbb megoldás, nem kell külön rar jelszótörőt keresgetni, meg warez oldalakról kétes windowsos dolgokat levadászni, meg szutykokat feltelepíteni. Persze könnyen meglehet, hogy ha türelmesen utánanéznék, találnék rá natív linuxos opensource alternatívát, ami simán töri a Rar3-at, de összességében tovább tartana, mint egy Hirens-en alapuló gyors partizánakció. Natív, tiszta megoldást akkor érdemes csak kikísérletezni, ha többször fog kelleni, nem csak egy egyszer.

Nem kell feltenni, futtatod live-ban, ahogy a Hiren's-t.

[ Szerkesztve ]

https://www.coreinfinity.tech

Igaz, egy célra 3.5 GB sok, de csak egyszer kell letölteni és másra is jó lehet.

Még egy apróság: a Kali nem forensics disztribúció, hanem kimondottan offenzív célú pentester toolok gyűjteménye ( igen, vannak benne forensics eszközök is).

https://www.coreinfinity.tech

A Kali egy bazi nagy gyűjtemény, de sehol nincs rá utalás, hogy a toolok nagy részét még be kell konfigolni első használat előtt. Pl. metasploit framework: használhatod azonnal, csak akkor lassú lesz benne a keresés és nem lehet adatbázisba menteni pl. nmap scan eredményeket - mert nincs adatbázis (van, fut, de nincs beállítva).

Felhasználót egyébként lehet benne csinálni elég régóta, de nem kényelmes a rendszer használata, pörgeti a rendszert a sok háttérfolyamat.

Én inkább azt szoktam, hogy a Debianra raktam nmapet, meg használom a saját kis eszközeimet, vm-ben meg ott a Kali, ha ennél több kell.

https://www.coreinfinity.tech

Nem kell feltétlen Kali, meg Parrot, hanem bármelyik sztenderd disztró tárolójában megtalálhatók ezek a toolok, csak ki kell nyomozni, hogy mi való rá, ami ingyenes, opensource megoldás. Ez az, amihez én is lusta vagyok, főleg, ha csak valamihez egyszer kell.

A Hirens előnye, hogy fut róla minden Live módban, telepítés nélkül is. Régen én is szerettem (egy ideig volt tartva Hirens-es pendrive is), de mióta áttértem Linuxra, felesleges a Hirens, amit az tud, ilyen partíció, fájlrendszerjavítás, mentés, azt a legtöbb disztró Live-ja is simán megcsinálja. Még ilyen windowsos, jelszótörős mókákat is, csak akkor ki kell nyomozni a natív linuxos alternatívát, az már nem szokott default telepítve lenni a Live rendszerekre, hacsak nem Kali tényleg.

A Parrot viszont neked tökéletes, megy a kalózos avatarodhoz

A 2 gigás pennel nem az a gáz, hogy csak 2 giga, vagyis az is, hanem hogy emiatt feltehetőleg egy régi, szutyok lassú, USB2-es drive. Erre tényleg senki ne sajnálja a pénzt, 16 gigás USB3-as penek is jelképes áron mennek, de még egy 60-128 gigás SATA2-SATA3 SSD is kihozható ugyanannyiból, USB-SATA átalakítóstól, és az állva hagy akármilyen szokvány tollhajtányt, és még rendes Linux telepítésre is használható, vagy Windows To Go telepítésre, és gyors is, mint egy belső SSD. 2 gigás pennel ne szenvedjen már 2021-ben senki se. Sok disztró és OS telepítő már 4 giga felett van amúgy is.

[ Szerkesztve ]

Ha valakit érdekel akkor a problémát azonosítottam. Megoldásra vár.
(Kikerülni már ki tudom.)

Sziasztok,
tennék egy elkeseredett kísérletet, hátha tudtok segíteni. Itt írtam egy problémáról.
Remélem, maradhat
Előre is köszönöm.

Sziasztok!

Amerikai kiosztású billentyűzetet magyarra cseréltem. A VC és X11-re vonatkozóan is átállítottam ami kell. localectl set-keymap hu és localectl set-x11-keymap hu. Azonban, boot után, amikor a diszket decrpytelem és beírom a passphrase-t a kiosztás még mindig US. Mi hiányzik? Egyértelműen OS szintű (mi más) a dolog, mert ennél a pontnál már túl vagyunk a systemd-boot-on. Arch Linux dwm-el, Kai Hendry módra, szóval minden kézimunkás.

csináltál új initramfs-t?

Természetesen nem. Nap végén lefuttatom a script-et, ami szerintem megoldja. Köszi a tippet! Megírom majd az eredményt.

Solved. Köszönöm!

[ Szerkesztve ]