Ugrás a lényegre

242 poszt a "Hírek" címkével

Összes címke megtekintése

· 2 perc olvasmány

Páran jeleztétek felénk, hogy túlforgalmazás után ki lettetek tiltva (ez eddig oké), majd ennek lejárta után ismét tiltást kaptatok.

Ennek az az oka, hogy mint azt bizonyára tudjátok, a hálózaton csúszóablakos rendszer van érvényben, azaz ha kitiltódtok, akkor a rendszer egészen addig tiltani fog, amíg ki nem kerül az adott ablakból a forgalom.

Ez eddig is így volt, de nem volt belőle általában probléma, mert ha valaki kitiltódott a 1 napos ablak miatt, akkor minimum 1 napra kapott tiltást és ez idő alatt a forgalma “kicsúszott” az egy napos ablakból, a 4 napos ablaknál pedig nem nagyon lehetett egyszerre összehozni, mivel az illető előbb kitiltódott az 1 napos túllépés miatt.

Mivel nemrég eltöröltük az 1 napos ablakot, így most már össze lehet hozni a 32 gigás forgalmat viszonylag rövid idő alatt. Ekkor megtörténik a kitiltás, majd első tiltás esetén 24 óra múlva a visszaengedés. Ekkor azonban a rendszer azt látja, hogy a 4 napos ablakotokban még mindig ott a kitiltást indikáló forgalom, így ismét kitiltásra kerültök. Legrosszabb esetben emiatt 6 napig ki lesztek tiltva (1+2+3 napos tiltások).

Megoldást jelent a sávkorlátos rendszer bevezetése, amely tervezésénél már számoltunk ezzel a problémával. Viszont ennek megvalósítására az ünnepekig biztosan nem lesz kapacitásunk, így addig is csak egy dolgot tudunk tanácsolni: ne forgalmazzatok túl (4 nap alatt ne töltsetek fel 32 gigát egyetemen kívülre).

· Egy perc olvasmány

Sikerült a WiFi hálózat hibáit javítani. Próbáljátok ki Ti is, nekünk Win7, Win8, Linux, Android, WinPhone és Mac rendszereken ment.

admin.sch.bme.hu -n ne felejtsétek beregisztrálni a WiFi MAC címeiteket.

Úgyszintén admin.sch-n a hálózat/wifi menüpontban tudjátok megnézni a WiFi jelszavaitokat. Felhasználói nevetek az schacc-otok (amivel admin.sch-n is beléptek).

Továbbá a Windows-nak van egy olyan “feature”-je, miszerint ugyanazt az IP nem hajlandó felvenni egymásután több interface-en. Ezért ajánlott letiltani a vezetékes adaptert próba elött.

Észrevételeitek, esetleges hibákat a support.sch.bme.hu oldalon írjátok meg nekünk!

· Egy perc olvasmány

Mikulás az előremutató technológiák híve. Éjszaka megállt a KSZK szervertermében és álomport hintett Netwatcherre, így az elfelejtette, hogy rögzítenie kéne az IPv6 forgalmat.

Jövőre is csokit és nem virgácsot szeretnénk kapni a csizmánkba, így nem ellenkeztünk. Visszavonásig megszűnik az IPv6 feltöltési korlátozás.

itsanta

· 4 perc olvasmány

Október második hétvégéjén megrendezésre került Magyarország egyik legszínvonalasabb IT biztonsági fesztiválja, amin mi is részt vettünk.

Hacktivity Logó

A konferencia előtti héten egy előzetes wargame zajlott le, amiért a Securiteam felelt. Ebben különböző nehézségű IT biztonsági témájú feladattal küzdhettek meg a résztvevők, több kevesebb sikerrel.

Az előadások péntek reggel kezdődtek, a MOM Kulturális Központban, ahol kedves hoszteszlányok fogadták az érdeklődőket. A megnyitó után Charlie Miller – a Twitter biztonsági főnöke – beszélt a mobil operációs rendszereket fenyegető veszélyekről, összehasonlítva a saját eredményeit azzal, amit a sajtó kihozott belőle. Utána Mikko Hypponen – a finn F-Secure cég kutatási vezetője – a virtuális fegyverkezési versenyről számolt be. A hétvége során még számos neves magyar és külföldi előadó adott elő, ám ezen kívül más programokon is részt lehetett venni a konferencián.

· Egy perc olvasmány

Az este folyamán váratlan kiesést tapasztalhattatok az IPv4 hálózati hozzáférési szolgáltatásunkban. A probléma forrása egy – már korábban is tapasztalt – bug a core switch szoftverében. A hibát jelentettük a gyártónak, remélhetőleg hamarosan érkezik hozzá javítás.

A kellemetlenségekért elnézéseteket kérjük.

· 2 perc olvasmány

Megjelent egy új kiadás a hálózati eszközeinken futó operációs rendszerből, az IOS-ből. A release számos bugot javít az általunk is használt NetFlow-val és SNMP-vel kapcsolatban, így a használata mellett döntöttünk. A frissítés hétvégén fog lezajlani, hogy minél kevesebb felhasználó érezze a kiesést. Először csak egy eszközzel végezzük el, majd pedig siker esetén a maradék eszközökön is végrehajtjuk. Egy eszköz frissítése kb. 15 perc, ha nem történik semmi hiba. A szinti rendezőbeli switchek frissítésekor a kiesés három szintet érint, a core-switch-eink frissítése pedig az egész hálózatot (szervereket is), de igyekszünk a forgalmat egy backup eszközre terelni, hogy a kiesést minimalizálhassuk.