Szia
ennek a problémának és hasonlóak megoldására tudnám javasolni egy rendes central logging szerver kialakítását. Kibana (ELK) vagy Graylog, én utóbbit javaslom. Erre van is egy megoldásom, csináltam egy repot gyorsan: https://gitlab.com/markv9401/pfsense-w-graylog
Graylog-hoz és Cerebro-hoz egyszer már volt szerencsém amikor Grafana-ban akartam logot megjeleníttetni, de sajnos nem jártam sikerrel. Odáig már eljutottam, hogy a Graylog megkapta a pfSense-től a logokat, de a nyers logokat már nem tudtam szétválogatni, úgy meg azért még elég erősnek éreztem, hogy bármit kezdjek vele, így azt a projektet egyelőre jegeltem és a VM-et is töröltem, de ennek fényében nekiállok akkor majd még egyszer valamikor a közeljövőben. Amennyiben kérdés lenne (és tuti lesz 
, pl. mit kezdjek a linkelt repo-val 
) jöhetek velük? Illetve nem gondolkodtál-e esetleg egy logout-os íráson, hogy mindenki okulhasson belőle? És köszönet a munkáért! 
El Psy Kongroo
Nos, fut a Graylog, kapja a logokat a pfSense-től. Mielőtt nagyon beszaladnék abba a bizonyos erdőbe:
1. Ha vannak olyan portjaim amik egyediek azokat fel kell vennem külön a service-names-port-numbers.csv -ben? Vagy ezt nem piszkálnom?
2. A graysense-contentpack.json fájlban az opnsense szavakat simán átírhatom pfsense-re?,
3. Tudom, hogy az opnsense egy pfsense fork, de vajon mindent ugyanolyan logika mentén logolnak mint pfsense-ben? Tehát betölthetem majd nyugodtan a contentpack-ot?
El Psy Kongroo
1. Ha egyedi portokról van szó és látni szeretnél ilyesmit, hogy 1234 helyett azt írja, hogy "Véreshurka_srv" akkor igen, szerintem, bár ebbe én nem mentem bele, nem szeretem az aliasokat 
2. - 3. Azt hiszem abban a content packban opn és pf is benne van
1. Ok, lehet hagyom akkor az egyedi portokat. De gondolom ha bármikor meggondolnám magam akkor csak szerkesztem a fájlt.
2. Csak a description tartalmazza a pfsense szót:
"description": "Analyse OPNSense Logs and maybe pfsense too". De ahogy lesz időm majd rámegyek és meglátom mi lesz belőle
Jelentkezem még...
El Psy Kongroo
köszi, sikerült! volt beállítás ebben a spec típusban, és megmaradt az iptv is.
Sounds like your fix is worse than your problem...
Sziasztok!
Arra esetleg tudja valaki a választ, hogy miért nem használja a pfsense a beállított dns-szervereket?
folyamatosan a magenta dns-én kötök ki...
Előre is köszi
Üdv,
T.
A general settings alatt van pipa a DNS Server Override mellett? Ha igen akkor amiatt. Ha nincs akkor passz és valaki más hátha tud segíteni.
El Psy Kongroo
kivettem az override pipát... épp ez a gondom
Újra is indítottad a routert? Hátha... Egy gyors keresés után pedig a legtöbb helyen ezt tanácsolják.
Amíg nem jön valaki aki tudna érdemben is válaszolni, addig ezt akár áttanulmányozhatod: Redirecting Client DNS Requests. Mintha ilyesmire lenne kitalálva.
El Psy Kongroo
Én azt olvasom több helyen is, hogy a pfsense-nek nincs valami hatalmas előnye egy OpenBSD-vel szemben. Annyi, hogy CLI helyett GUI van, de az is limitált. Esetleg tudtok még különbséget mondani, ami miatt megéri? Nekem lehet inkább OpenBSD lesz, mert az alapoktól szeretném megérteni az egészet, hogy hogyan működik, és állítólag arra jobb nulláról indulni.
Buliban hasznos! =]
Most, hogy mondtad, restartoltam, de still magenta..
Ennek a redirect dolognak utánaolvasok, köszönöm.
Akkor amíg nem érkezik más valaki addig próbálj rá arra amit küldtem. Előtte esetleg csinálj egy teljes mentést a pfsense config-ról ha valami balul sülne el. Most én is DNS problémával küzdök, mindjárt írok is egy kérdést .
El Psy Kongroo
Természetesen, a pfSense valóban csak egy BSD + egy jó gyűjtemény pl Suricata stb.
Hogy jobb-e, azt nem tudom. Én előtte évekig ezt csináltam, csak nem BSD hanem Linux -szal meg iptables -sel. Jó azt is tudni és átlátni, de napi szinten, akár csak otthoni mértékben is de nagyobb rendszert fentartani, hát úgy annyira nem már Az is kérdés, hogy mennyire nulláról indulsz? Láttál-e már tűzfalat meg úgy az egész internet architektet átlátod-e alapszinten. Ha nem akkor még a gui is sok leszelsőre, nem egy bsd nesze. Szóval ezek alapján te döntesz, mi való neked
R̲e̲m̲ ez új.. látatlanban sajnos nem is tudnék semmit mondani rá. Ha nem sikerül és számodra elfogadható VPN -en keresztül szívesen megnézem, több szem többet lát
Egy kis segítséget kérnék én is. Próbálok egy külön hálózatot létrehozni virtuális környezetben (Virtualbox / KVM), de nem igazán sikerül a dolog. A pfsense-re kötött vendég op. rendszereken nem működik a névfeloldás. Magán a virtuális pfsense-en tudom pingelni a goolge.com-ot, vagy bármit amit szeretnék, de ha ezt egy olyan op. rendszerről teszem ami a virtuális pfsense-hez kapcsolódik és onnan kapja az IP címét akkor ezt a hibaüzenetet kapom: ping: google.com: Temporary failure in name resolution.
Még amit próbáltam:
- pfsense shell alól a ping google.com működik
- pfsense shell alól az nslookup google.com ezzel jön vissza:Server: 192.168.122.1 --> ez a KVM alap hálózatának a gateway címe
Address: 192.168.122.1#53
Non-authorative answer
... (itt behozza az infokat)
- pfsense shell az nslookup google.com 127.0.0.1 ezzel jön vissza:Server: 127.0.0.1
Address: 127.0.0.1#53
** Server can't fiond google.com: SERVFAIL
pfSense WAN címe: 192.168.122.95 --> ezt a címet kapja a KVM alap hálózatától
pfSense LAN hálózat: 192.168.1.1/24
pfSense LAN címe: 192.168.1.1
kapcsolódó op. rendszer IP címe: 192.168.1.100 --> még DHCP-n kapja a címét
Ha megváltoztatom a pfsense-re kapcsolódó op. rendszer resolve.conf fájlában a nameserver-t 192.168.1.1-ről 192.168.122.1-re akkor működik újra a névfeloldás. A System --> General Setup alatt már ezek kombinációit remélhetőleg mind végigvettem: DNS szerver, DNS Server Override, Disable DNS Forwarder de még mindig nem sikerült megoldani a gondot. Egyébként ugyanez a gondom Virtualbox alatt is. Néztem egy youtube videót erről, ott csak annyit csinált emberünk, hogy adott a pfsense-nek egy + NIC-et amit Internal Network-ként allított be, elnevezte a hálózatot (pfsense), telepítette a pfsense-t, a virtuális op. rendszer beállításaiban a hálózati beállításnál a NIC-et a már létrehozott (pfsense) internal network-re állította, telepítette az op. rendszert, a gui segítségével bekonfigolta a pfsense-t, majd már működött is a névfeloldás. Én viszont el nem tudom képzelni, hogy mi lehet a gondom. Elég új nekem a virtualizáció, és mivel látom, hogy itt azért használják jó páran a pfsense-t virtuálisan is, gondoltam tudnátok segíteni.
Előre is köszönöm a válaszokat!
El Psy Kongroo
Úgy nagyjából világos az internet meg a tűzfal működése. Azt hiszem ki kéne próbálnom, hogy mit ad a pfsense, aztán utána megnézni, hogy mi az, amit ebből nem használok. Ha túl sok minden van, amit nem használok, vagy olyan dolgok kellenének, amit pfsense-el nem tudok megoldani, akkor van értelme elgondolkodni az OpenBSD-n vagy FreeBSD-n.
Buliban hasznos! =]
Olvastam még, hogy van snort, ami hasonló, mint a suricata. Van az is pfsense-re? Egyáltalán mi a különbség közöttük?
Buliban hasznos! =]
Hasonló a szabálykészletük, de a Snort nem tud pl. protokoll anomáliát detektálni, és tudtommal csak egy szálon fut.
Otthonra kb. tökmindegy.
"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)
Mindkettő IPS detection tool. Mélyebben nem tudom mi a különbség, de a Suricata (a pfsense -es is) tudja és használja is a snort ruleokat is
Véreshurka szerintem nem virtualizációs probléma, egyszerűen nameserver gond. A pfSense -ben a DHCP server kiküldi a nameservert? (Services ->DHCP server, lap közepe DNS Servers, legyen kitöltve) Választhatod azt, hogy kiküldöd a külső pl 1.1.1.1 vagy 8.8.8.8, vagy küldheted saját magát, a pfSense -t, de akkor a pfSense -nek legyen megadva egy upstream a generalban és legyen engedélyezve a dns forwarding is (az is services)
[ Szerkesztve ]
Egyáltalán mi a különbség közöttük?
ITT van egy összehasonlítás.
Először a Snort-ot vesézi, multi threading-et említve.
Aztán jön a Suricata és tadaaaam:
"Multi-Threaded - Snort runs with a single thread meaning it can only use one CPU(core) at a time.
Régen a SNORT valóban sokáig volt single thread-es a Suricata-val szemben. De ma ?
Szóval: pontosabb cikket legközelebb, kedves blogoló.
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
DHCP-n nincs DNS beállítva, illetve a forwarder service sincs engedélyezve, csak a resolver. Most úgy sikerült működésre bírnom, hogy a Services --> DNS resolver menüben a DNS Query Forwarding-ot engedélyeztem, így már van névfeloldás. Esetleg erre gondoltál a forwarding-nál, vagy magára a DNS Forwarder menüre? Ehhez viszont lenne egy kérdésem. Megnéztem pár video-t amiben pfsense-t telepítenek, és sehol nem engedélyezik a DNS Query Forwarding-ot és így is működik a névfeloldás, illetve én sem emlékszem, hogy bármikor be kapcsoltam volna ezt, vagy adtam volna a DHCP szerveren belül bármikor DNS szerver címet, mégis mindig ment a névfeloldás. Ez így akkor most hogyan működik? Pl. ebben a videóban [(link)] sincs semmi extra állítva, csak az elején a gui alapján az a pár dolog ami van, mégis rögtön utána be tudott tölteni egy weboldalt.
El Psy Kongroo
Köszönöm válaszod
Egy bugyuta kérdés következik: az lehetséges, hogy a saját címemet kapom vissza dns szerverként?
a whatsmydnsserver.com is azt adja vissza.
ha b@romság, akkor hogyan tudom a legegyszerűbben lecsekkolni, hogy ténylegesen kicsoda a névfeloldó?
Arra gondoltam, igen. Hát őő, fogalmam sincs, hogy hogy megy? Gondolom amint a forwardingot engedélyezted automatikusan kitölti a DHCP server saját magával, ha üresen hagyod, ez a legerősebb tippem. Vagy valamelyik IP protokoll alapján és/vagy önkényesen az oprendszerek alapból a DHCP servert szolongatják DNS -ként, ha külön másként nem kapják utasításba, hogy őszinte legyek erről fogalmam sincs, de biztosa kettő közül valamelyik, csodák nincsenek Épp a "csodák" elkerülése végett szeretem explicit kifejezni mit akarok, ezért nálam a DHCP server megfelelő sorai ki vannak töltve
R̲e̲m̲ elméletileg lehetséges, persze, csak nem tudom mi lenne a gyakorlati haszna? Lehet, hogy 127.0.0.1 küld ki a DHCP mint DNS resolver.. Neked is ugyanezt tudnám javasolni, amit lehet azt explicit módon definiálni, hogy ilyenek ne történjenek Linuxon vagy látom, ott a legegyszerűbb a cat /etc/resolv.conf
Gondolom van egy default DNS szerver a kódjában, és ha nincs megadva semmi, akkor ahhoz csatlakozik. Ezt mondjuk nem tartom jó dolognak, mert könnyen elfelejthet foglalkozni vele az ember, de ez van, ha mindent a segge alá raknak.
szerk:
Nem találok ezzel kapcsolatban semmit a pfsense kódjában. Ha jön is valahonnan egy alapbeállítás, akkor elképzelhető, hogy a FreeBSD-ből jön.
[ Szerkesztve ]
Buliban hasznos! =]
Köszi!
Még próbálkozok, ha semmi nem fog működni akkor megyek tovább az általad javasolt DHCP szervernél megadni DNS-t. Jelentkezem majd ha jutottam valamire!
El Psy Kongroo
Sziasztok!
Csatlakozom én is, tegnap sikerült itt Hardverapróról lőnöm egy HP T620 Plus vékonyklienst, előre konfigolva pfSense-el (16GB mSATA SSD, 2x2GB RAM) + egy 4 portos Intel hálózati kártyával.
Lehet, hogy majd lesznek kérdéseim.
Eladó: Apple iPad mini 1 (2db)
ja hogy azt Te vitted el...
haddent
resolv.conf -ban szerkesztve viszont csak az adott gépen fog úgy működni, ahogy szeretném
a cél nyilván az lenne, hogy az egész hálózat a megadott dns szervert használja
[ Szerkesztve ]
És ha bejelölöd te is a Services --> DNS Resolver menüben a DNS Query Forwarding-ot akkor mi történik?
El Psy Kongroo
Isten hozott!
Az előtelepített pfSense-el fogod használni, vagy újratelepíted?
El Psy Kongroo
Yes.
[ Szerkesztve ]
Eladó: Apple iPad mini 1 (2db)
Az eladó a legfrissebbet rakta fel rá, amit én kezdtem el konfigolni a nulláról.
Eladó: Apple iPad mini 1 (2db)
sikerült saját magamnak válaszolni
Véreshurka
este megnézem, bár lehet már próbálkoztam azzal is...
[ Szerkesztve ]
Ahogy írta Véreshurka + ha nem megy az előzőleg említett DHCP serverben is legyen benne 
Nevezzetek alusapkás, paranoid, chemtrail hívőnek, de mielőtt belevágtam a pfsense-be sok helyen olvastam - ok, főleg kínai minipc-kre előre telepített verzióval kapcsolatban -, hogy nem célszerű előre telepített alapokról építkezni, főleg egy tűzfalnál és én ezzel csak egyet tudok érteni.. Bár kicsi a valószínűsége bármilyen hátsó ajtónak, de az ördög sosem alszik... Én még az SSD-t is gyalulnám első használatkor mondjuk egy live linux alól dd paranccsal és /dev/urandom-al, vagy a kényesebbek kedvéért valamilyen az SSD-t jobban kímélő módszerrel. Szerintem érdemes elgondolkodni rajta, és még legalább tapasztalatot is lehet szerezni közben.
El Psy Kongroo
Azt gyanítom, hogy ez a box itthon, cégektől levedlett múlttal az eladó kezében vált pfSense box-szá, tehát így nem kínai backdoor, szerintem De persze, ilyen dolgokat (is) mindig jó, ha te magad friss, saját isoból rakod fel
SSD-nél a firmware-be is beteszik a vírust, nem érsz semmit a dd-vel. (vagy hát teljes körű védelmet nem ad)
[ Szerkesztve ]
Buliban hasznos! =]
Világos! Ezzel mélyebben még nem foglalkoztam, de majd beleásom magam! Kössz, hogy rávilágítottál! Akkor ezek szerint ezzel a paranccsal: hdparm --user-master u --security-erase-enhanced PasSWorD /dev/sdX sem megyek semmire - feltételezve, hogy az előfeltételeknek már eleget tettem, mint mondjuk a Password létrehozása és ellenőriztem, hogy az adott SSD "not frozen"?
[ Szerkesztve ]
El Psy Kongroo
Igen! Mostanában sok linux ISO-val próbálkozom virtuális gépként és mindig csak akkor telepítek, illetve hagyom meg az ISO-t ha nem csak a SHAxxx, vagy MDA értékeket tudom ellenőrizni, de ha az aláírásokat is a megfelelő GPG kulcsokkal. Sajnos a pfSense ISO-hoz még csak SHA256-os ellenőrzést találtam, ha jól néztem körbe a dokumentációjukban sajnos GPG kulccsal aláírt ISO még nincs a repertoárjukban.
[ Szerkesztve ]
El Psy Kongroo
Azt nem mondom, hogy semmire nem mész vele, mert legatterolod, ami rajta van az általad látott részen. Viszont pl az USA-ban olyan vírusokat ír a CIA, hogy felteszi magát a firmware-be, és az SSD-n is lefoglal magának egy tárhelyet úgy, hogy nem is látod. Ugyanúgy működik maga az SSD, tudod partícionálni, stb, de az ő cuccuk által lefoglalt hely, vagy hogy azon mi van, az egyáltalán nem látszik normál felhasználóknak, mintha nem is lenne. A kínaiak, oroszok, stb. valszeg ugyanúgy képesek erre. A te szempontodból nincs jelentősége, mert akik erre képesek, azok már komoly szinten tolják, és nem fogod tudni megvédeni magad tőlük, bármit csinálsz. Valszeg nem vagy annyira fontos, hogy célpont legyél, úgyhogy amíg nem jön el a skynet, addig nincs jelentősége, inkább csak megemlítettem, mint érdekességet. Esetleg nézd meg ezt, ha érdekel, hogy mire képesek: [link]
[ Szerkesztve ]
Buliban hasznos! =]
Hát erre ennyit tudok frappánsan, röviden: https://stallman.org/intel.html
Meg ahogy Qui-Gon Jinn mondta, mindig van egy nagyobb hal
Ja hát ez is része a dolognak, de bármit veszel, mindegyikben lesz jó eséllyel backdoor, hogy a gyártó ország titkosszolgálata könnyebben hozzáférjen. Nekünk ez addig nem számít, amíg valami hacker csoport nem találja meg és kezdi el kihasználni pl botnet építésre.
[ Szerkesztve ]
Buliban hasznos! =]
Köszönöm mégegyszer, ez megoldotta a problémát
& inf3rno meg akit esetleg érdekel
Az Intel Management Engine-el tisztában vagyok. Pont múlt hónapban vettem fel a kapcsolatot újra a 3mdeb csapattal és érdeklődtem tőlük úgy nagy vonalakban a Coreboot-ról és, hogy esetleg az általuk is forgalmazott Protectli gépeken az IME ki van-e pucolva annyira amennyire lehetséges és ha nincs, akkor hallottak-e a me_cleaner-ről. Viszont válaszukban írták, hogy nincs kipucolva az IME a Protectli-ken, de elgondolkodnak róla, hogy teszteljék és esetlegesen a későbbiekben ezzel a lehetőséggel is bővítsék a kínálatukat. És ez szerintem nem csak a Protectli gépeket érintené hanem a mellette is forgalmazott PCEngine APU-kat is amik már most is ugyanúgy Coreboot+SeaBIOS-al is kérhetőek. Azért is van nagy bizodalmam a lengyel srácokban, mert nagyban hozzájárulnak - amennyire meg tudom ítélni - a Coreboot fejlesztéséhez. Úgyhogy lehet, hogy nem csak régi HW-ekre lehet majd megbízhatóan pfSense-t, vagy bármi tűzfal programot rakni, hanem egy kicsit modernebb gépekre is. Én már nagyon várom... Remélem jövőre már a boltokba is kerül
El Psy Kongroo
Örülök, hogy működik! Már csak arra kellene rájönni, hogy enélkül miért nem működik . Nálam is ugye hasonló a helyzet, csak míg nálad a szolgáltatói DNS működik enélkül, addig nálam nincs névfeloldás. De még megpróbálom körbejárni a hibát, hátha.
El Psy Kongroo
Azt le tudná írni valaki hogy kell pppoe kapcsolatot setupolni vlanon.
A nyomorult szolgáltatói eszköz csak vlan 10-en tud bridgelni és sehogy se akar működni.
Fura hogy egy régi linksys router mindenféle varázslás nélkül megy.
Mindenki nyugodjon le a p***ba, újratelepítettem magam friss letöltésből és újrakonfigoltam az alapokat. (Még szerencse, hogy nem jutottam tovább.) 
Asszony így is már várta mikor leszek kész, mert NAS-ról megy az esti sorozat..
Eladó: Apple iPad mini 1 (2db)
Így már legalább nyugodtan hajthatom álomra a fejemet...
[ Szerkesztve ]
El Psy Kongroo
Ha jól értelmezem, akkor a dns resolver okozta, hogy a 127.0.0.1 volt a DNS szerverem.
ha úgy van, ahogy gondolom, akkor engedélyezett dns resolver-el a pfsense a root dns-ektől kérdezi le a címhez az ip-t aztán cache-eli...
Egy újabb kérdésem lenne:
Megoldható-e, hogy az itthoni hálózat egyik fele a pfsense-ben beállított vpn-t használja, a másik fele meg vpn nélkül menjen a netre? Gondolok arra, hogy az egyik vlan és a hozzá beosztott portok a switch-en vpn mögött vannak, a másik vlan meg a vpn "mellett" megy ki a netre?
Illetve ha a switch egyik portjára dugok egy wireless ap-t, akkor a portnak megfelelő vlan-ba kerülnek?
ha baromság, mondjátok nyugodtan.
[ Szerkesztve ]
Minden gond nélkül megoldható, nálam is így van
De van némi előfeltétele, valahogy el kell tudd szeparálni a hálózatokat. VLAN tökéletes megoldás, de ehhez a pfSense -t futtató gép NIC -jének tudnia kell a VLAN tagginget.
Ha ez megvan, akkor vagy managelhető switch kell (amin tud portokra VLAN -t natívban kirendezni), vagy nem managelhető, de olyan amin a VLANok sértetlenül átmennek ettől függetlenül. Ekkor viszont a WiFi AP -nak kell tudnia a VLAN tagginget. Tehát vagy switch szinten választod szét és a switch portok külön-külön VLAN -ok, de natívban, vagy a "buta" switchre ráküldesz egy trunk -ölt cuccot, natívban a sima hálózattal és egy VLAN -ban a VPN cuccod és a WiFi AP -d szemezi ki magának a megadott VLAN -t.
Vagy bónusz megoldás ahogy nálam van, hogy a switch és a wifi ap is kezeli, ezért egészen a wifi ap is trunk portot kap és van egy rendes itthoni wifi hálózat meg egy "dirty" vpn hálózat is wifiből
