Security-all

A körülmények pontos részletezése nélkül kérdezném mindenkitől, hogy a következő szituban:
1) van-e értelmesebb megoldás és csak nem látom a fától az erdőt
2) láttok-e bármilyen gyenge pontot a rendszerben
3) mi legyen a kulcshossz

Alapfelállás: személyes kontakt nélkül, úgy, hogy nincs egyéni titkok cserélésére és ráadásul nem tárolhatok a leendő felhasználókról semmilyen adatot kellene egyéni hozzáférési adatokat (felhasználónév/jelszó) kiosztani viszonylag kis számú embernek. A csoporton belül megoldható a zárt kommunikáció, de azt a csoport összes tagja látja, az egyes emberekkel egyedül e-mailben lehet kommunikálni [ráadásul azt se mindenkivel, de ez az a pont, amikor nem érdekel, nem tudok vele mit kezdeni, szépen slattyogjon be az irodámba és igazolja magát].

Amit kitaláltam: a zárt csoportban terjesztek egy közös, osztott jelszót (ez lesz az authorizáció része a dolognak, nagyjából feltételezhető, hogy a zárt csoporthoz más nem fér hozzá és a felhasználók harmadik félnek nem fogják kiadni) és e-mailben kiküldök mindenkinek egy levelet, amiben egy url tartalmazza a szükséges adatait és egy digitális aláírást (ő az authentikáció). Ha a megadott adatokhoz érvényes aláírással küld, kap egy formot, megadja a kívánt jelszavát, az osztott jelszót és elfogadja, hogy tárolhatom róla a szükséges adatokat, elkészítem a felhasználói fiókját és megkapja a usernevét - itt már akkor tudom az e-mail címét tárolni [adott rá engedélyt], az alapján az újrapróbálkozókat tudom követni.
Ha ezt még megfejelem egy időbélyegzővel, és egy link mondjuk csak 24 órán át érhető el, akkor már akár biztonságosnak is lehetne tekinteni - ahhoz, hogy valaki illetéktelenül szerezzen hozzáférést benne kell lennie a zárt csoportban és hozzá kell férnie egy a szintén a csoportban levő másik user postájához; és még ebben az esetben is legfeljebb 24 órára szerez ugyanolyan szintű hozzáférést, mint amivel eleve rendelkeznie kellene, mondjuk megszemélyesítve valaki mást. Ennek az esélye viszont vállalhatónak tűnik.

Vélemények? Milyen hosszú legyen a kulcs? Elég az 1024 bit (azzal viszonylag vállalható hosszú az aláírás - base64 kódolva 172 karakter), vagy 2048 (344 karakter)/4096 (684 karakter) legyen inkább?

Az ötleteket, tippeket, javaslatokat előre is kösz.

hello

tud valaki olyan külső eszközt ami úgy viselkedik mint egy HW primary kulcs és nélküle a rendszer nem bootolható mivel a bitlocker/dm-crypt nem tudja a jelszót csekkoli? valami olyanra godolok mint egy USB ami a primary kulcsot tárolja vagy TPM-ként működik.

nézegettem a neten de csak Ironkey találtam de az egy hardwaresen titkosított USB és nekem nem az kell.

előre is köszönöm a válaszokat.

Az normalis, h ha a firefoxot bezarom ugy, h az aktualis session-ket (ablakokat) elmentem, akkor az ujrainditas utan egybol ott van netbank belse, ahogy elotte?

Egy ismerősöm azzal keresett meg, hogy talált egy olyan weboldalt, ahonnan felhasználók adatait lehet egyszerűen kinyerni.

Az eset úgy történt, hogy Google-ben rákeresett egy e-mail címe, és az eredmények között volt a szivárgtató weboldal...

Nevezzük az oldalt: munkaado.com-nak... Ezen létezik egy email_keres.php szkript, egy legördíthető listával. Mindenféle titkosítás, azonosítás nélkül elérhetők felhasználók adatai.

Az ismerős felhívta az oldal "ügyfélszolgálatát", ahonnan enyhén szólva elhajtották...

Mit lehet ilyenkor tenni? Kinek lehet szólni? Szolgáltatónak? Ombudsman-nak?

(A domain és a szkript nevét csak kitaláltam.)

Update:
Részlet az oldalon tárolt adatmezőkből:

--snip--
Távmunkás neve:
Munkavállalás tipusa:
Lakcím:
Anyja neve:
Születési idő/hely/név:
Állampolgárság:
Adószám:
TAJ szám:
Bankszámla szám:
Nyugdíj jogviszony típusa:
Magánnyugdíj pénztár tagság van-e?
--snip--

Sziasztok!
Windows XP alatt szívta meg egy ismerős ezzel (tudom, hogy lejárt a támogatás, 2014. áprilisa előtt jeleztem neki, azt mondta, bonyolult lenne mindent átvinni. Most még bonyolultabb lesz.)
A Google cryptowall 3.0 removal and decrypt találatoknál kb az 5. oldalig minden olvasottnak van jelölve nálam, és nem találtam megoldást. Windows 7-es op. rendszernél vannak megoldások, de ez ugye XP. Ami ígéretesnek látszott, hogy fut a ransomware, kommunikál egy szerverrel, amiből snifferrel ki lehet valami RSA kulcsot szedni, megint kilőve, mert ransomware egy előbbi keresés alapján le lett törölve.
Photorec-et futtatok most, hátha visszanyerek valamit, de nem reménykedem.
Ráadásul amit ajánlottak, hogy backup-ból visszarakni: haver fizetett érte, aztán meghalt a NAS és úgymaradt a backup.

Tudnátok ajánlani akár fizetős komolyabb sebezhetőség tesztelőket és vizsgáló eszközöket weboldalakhoz és webes szolgáltatásokhoz?

Köszönöm.

Update: köszönöm az ajánlatokat, tesztelni fogom őket és visszajelzek. Tesztjeim:

https://ovs.acunetix.com - az ingyenes demó változatot néztem, komolynak tűnő eredményt ad, network és web scan-t tud, az eredményben részletes magyarázatot és megoldási javaslatot is ad. A demó verzióban nem érhető el a web scan részletes eredménye, csak a network-é.

Egy ideje átirányítunk egy weboldalon minden kérést HTTPS-re.

Most hoztunk egy döntést, hogy az átirányítás ezentúl nem tartalmazza az útvonalat és paramétereket csak a host nevet, minden megy a főoldalra. Így aki beírja az oldal nevét az átkerül a HTTPS oldalra, de a régi HTTP linkek is ott fognak kikötni, illetve az összes úgyfelejtett URL sem fog működni.

Az egyik fejlesztő elég hangosan ellenzi ezt a változtatás. Azzal érvel, hogy az első hívással már így is úgy is kimentek az érzékeny adatok titkosítás nélkül, session, cookie ... stb. Semmi értelme a főoldalra dobni az embert, mert MITM estén azt az infót már elkapták, bármit csinálunk.

Szerintem viszont egy ilyen átirányítás csak elfedi a problémát és hamis biztosnágérzetet kelt. Volt egy döntés, hogy abszolút mindennek HTTPS-en kell mennie. Úgy gondolom, hogy ha nem úgy jön a kérés, akkor annak láthatónak kell lennie és nem transzparens módon ugyanúgy működnie mintha minden jó lenne.

Mit gondoltok?
Ti megtartjátok a teljes URL-t ha ilylen átirányítást csináltok?

Sziasztok!

Most kértem a UPC-től wifis routert.
Előnyök: 2 eszöz helyett egy, ingyen van 5GHz, ha elromlik kapok másikat:)

Ami viszont eszembe jutott mennyire rizikós szerintetek a szolgáltató routerét, tűzfalát használni otthoni környezetben?

Céges helyre biztos nem használnám:)

http://net-security.org/malware_news.php?id=3041

Rosszul, hiányosan konfigoltuk a Windows-os Apacheunkat (2.4) http_proxy-val: az egyik aldomainre (ceg.exmaple.com) rálógattunk egy háttérszolgáltatást, ami a 40001-es porton lóg, de kívülről az aldomain alatt látszik. Két hete megy is.

Mivel hiányos volt a config (?), a proxy (most már tudjuk) a beérkező fals kéréseket kiszolgálja: ha befut hozzánk egy GET google.com/?query=vacak HTTP/1.1, akkor a szerverünk elmegy a google szerverre, végrehajtja a lekérdezést és visszaadja. Normálisan nem jutna el a szerverünkre a google.com kérés, de hamis (?) DNS-ek által el tud.

A jelenlegi állapot az, hogy a világ különböző gépein megjelenő reklámdobozok (xy.ad.baidu.com, stb.) kérései hozzánk futnak be, ezzel teljesen leterhelve a szerverünket. Nem igazi DDOS, de nekünk az, mert az apache füstöl.

Amiben a segítségeteket kérném:
- Mit tudunk tenni, hogy a sok beérkező kéréstől megszabaduljunk? URI, QueryParams, Referrer alapján való szűrés (HTTP réteg) ugyanúgy megeszi az apache-ot. Jelenleg 301-et küldünk a nem valós kérésekre, de ezt is az apache szűri.
- Mi az indítéka annak (csak hogy tanuljunk ma is valamit), hogy egy másik szerver kérése hozzánk fut be? Miért irányítják át, amikor minket közbeékelve ugyanaz a szerver fogja a kérést kiszolgálni, csak közben elfüstöl a gép?
- Miként lehet a http_proxy-t rendesen használni?

Köszönöm, ha a tapasztalataitokat megosztjátok!