Ez azt jelenti, hogy az OpenBSD 3.7-hez sem biztonsági figyelmeztetők, sem patch-ek nem fognak már megjelenni. Aki OpenBSD 3.7-et használ, annak javasolt frissíteni mihamarabb a két aktívan karbantartott kiadás egyikére (nyilván a 3.9-re érdemesebb).
A bejelentés itt.
- A hozzászóláshoz be kell jelentkezni
- 1500 megtekintés
Hozzászólások
ha már frissít, 3.9-re javaslom, a pf keep/modulate state része sztem jobb lett. vagy ha nem is az, de vmit ártottak neki, az biztos, mert 3.8-cal gyakran megállt pl a képek letöltése, v nagyobb oldalak (pl distrowatch a sok listájával) betöltése stb; 3.9-en egyelőre nem jelentkeznek ilyen problémák (kopp-kopp). Mondjuk nem tudom, hogy ennek van-e köze ahhoz, hogy még szinte semmi nincs fent, és félig üres a bazisok memória (64mb), de majd kiderül :-)
-------------------------------------------
Make your choice...
- A hozzászóláshoz be kell jelentkezni
Én meg azt hittem, hogy nálam van vmi szétkonfigurálva, azért nem jönnek bizonyos képek, oldalak...
- A hozzászóláshoz be kell jelentkezni
:-)
bennem is felmerült hasonló gondolat, de akk már ketten vagyunk =)
-------------------------------------------
Make your choice...
- A hozzászóláshoz be kell jelentkezni
Fura, mert elég régóta használok már obsd-t és sose volt ilyen problémám... Meg ez így egyébként is elég megfoghatatlan. Mi az, hogy megállt a képek letöltése meg a nagyobb oldalak? Az ilyesmit illik kinyomozni. MTU gond? TCP Window Scaling probléma? PF misconfiguration? ;)
- A hozzászóláshoz be kell jelentkezni
ahha, na én nem nyomoztam ki, valszeg nem is tudtam volna rájönni, h mi a gond, na mind1. a lényeg, h most , teljesen ua rulesettel tökéletes _eddig_. + nem csak képek, ezt értsd bármire, ami netről jött.
-------------------------------------------
Make your choice...
- A hozzászóláshoz be kell jelentkezni
OpenBSD 3.8, stateful filtering bridge, soha semmi gond nem volt. Nem az ICMP-t tiltod túlságosan?
- A hozzászóláshoz be kell jelentkezni
nézd meg te, szakértő szemmel, nem tom mien a túlzott tiltás:)
itt a 3.8 rulesetje:
#MACROS
nicext = "rl0"
nicint = "rl1"
tcpext = "{ 21 80 }"
protovia = "{ tcp udp icmp }"
trusted = "{ 192.168.0.21, 192.168.0.22, 192.168.0.23 }"
#OPTIONS
set block-policy return
set debug urgent
set loginterface $nicext
set optimization normal
#set state-policy floating
#SCRUB
scrub in all
scrub on $nicext all reassemble tcp
#NAT, REDIRECTS
nat on $nicext from $trusted to any -> ($nicext)
rdr on $nicint proto tcp from $trusted to any port 21 -> 127.0.0.1 port 8021
#FILTER
#default deny policy
block all
#pass traffic on loopback interface
pass quick on lo0 all
#pass through traffic
pass in on $nicint proto $protovia from $trusted to any modulate state
pass out on $nicext proto $protovia from any to any modulate state
#pass in from outside
pass in on $nicext proto tcp from any to ($nicext) port $tcpext modulate state
-------------------------------------------
Make your choice...
- A hozzászóláshoz be kell jelentkezni
scrub on $nicext all reassemble tcp
ezt kikommentezve próbáld meg, ha nem jó, akkor az optimizationt vedd conservative-ra. Más ötletem nincs.
- A hozzászóláshoz be kell jelentkezni
hát jó, kösz a visszajelzésért, de mint mondottam, 3.9-cel többnyire ugyanez a ruleset tökéletesen megy eddig, egyedül az ftp-proxy-s részt barmoltam azóta. az ftp-proxy még nem teljesen világos, betettem az ajánlott sorokat, nem ment, aztán kivettem, most megy. na mind1... :-)
-------------------------------------------
Make your choice...
- A hozzászóláshoz be kell jelentkezni
Ha megy, akkor jó. Bár szerintem az a 8021 rdr nem kell, ha rdr-anchor, nat-anchor és anchor is benn van. Meg persze pass out quick proto tcp from $intnet to any port 21 flags S/SA modulate state vagy mi a nyavalya. :-)
- A hozzászóláshoz be kell jelentkezni
:-)
na igen, megy, de csak passzívban. majd utánanézelődök én még, egyelőre a régi cuccokat hozom helyre, cherokee, ftp userek, cron stb.
egyébként van egy gondom, hátha tudsz ebben segíteni, mester :-)
szóval a cpu passzív hűtésben van, és arra gyanakszom, hogy a túl nagy cpu loadnál lelövi magát. vagy a fene tudja, de az biztos, hogy utána "retesz"elni kell a gépet, semmire se reagál, egyedül a háló él utána. De nem biztos, h a magas cpu loadtól van, én csak erre gyanakszok; eddig csak olyankor fordult elő, amikor forrásból próbáltam vmit telepíteni. pl cherokee is megdöglik make-nél, ha jól emlékszem, parse_date finomság van a dologban. Az mondjuk még oké, retesz, make megint, utána felmegy, de php5 abszolút nem akar, az is make-nél hal le. Arra van is egy shotom:
http://users.atw.hu/bervi/tmp/php5_make.png
Szóval megpróbáltam ügyeskedni, korlátozni a cputerhelést login.conf-ból, de mint kiderült, az erre nem jó, a cputime-mal csak azt érem el, ha a cputime nagyobb mint x, akkor szétlövi a folyamatot, úgyh nem mentem vele semmire. Nekem olyan kéne, ami engedi futni a folyamatot, de csak mondjuk x %-ban használhatja a cpu-t. Ilyesmi létezik?
És a make-es csodára van ötleted? Most így belegondolva, csak cherokee meg php van forrásból telepítve, és mind2 igencsak ugyanannál áll le, ennél a parse_date-es akárminél (ami 1ébként gőzöm sincs ,h mire jó:) )
-------------------------------------------
Make your choice...
- A hozzászóláshoz be kell jelentkezni
Passzolom. Próbáld lelőni a prioritást. De ha a háló megy tovább, akkor én első körben nem vasra gyanakodnék. Thuglife?
- A hozzászóláshoz be kell jelentkezni
na majd utánanézek a prioritás-állításnak...
szóval, h bővebben kifejtsem, mi történik ilyenkor:
- ssh megáll, de nem kapcsolódik le, az utolsó képernyőnél marad
- ftp nincs
- http nincs
- ha jól emlékszem, ping sincs, de ebben nem vok biztos, most ezért, ha nem muszály, nem fagyasztom le :-)
- átmenő forgalom megy
- előtte a cpu load jellemzően magas, 3 fölött mondjuk
ez a parse_date.c meg lo egyáltalán mire jó?
-------------------------------------------
Make your choice...
- A hozzászóláshoz be kell jelentkezni
szerintem rossz rovatba lett rakva a cikk(adamantix)..
- A hozzászóláshoz be kell jelentkezni