Security-all

Hi,

A környezet java 1.6, o/s rhel5.
Gyártottam annak rendje és módja szerint egy cert requestet, amire kaptam egy 30 napos ideiglenes tanúsítványt a CA-tól.
Beimportáltam a keystore-ba sikeresen. Közben elkészült az 'igazi' cert, ugyanavval a cert requesttel (a keystore nem változott).
Mivel azonban már be lett importálva egy a requesthez passzoló cert, így a beimportált cert trustedCertEntry lesz, ami nem sok jót jelent. Kérdés, hogy miként lehet ezt helyrehozni ? (Évente egyszer foglalkozom a témával, dobáljatok kővel nyugodtan. :).

[root@backup01 conf]# ../java/bin/keytool -list -keystore keystore Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

tomcat, Sep 15, 2012, PrivateKeyEntry,
Certificate fingerprint (MD5): AE:A7:E6:1A:DB:09:60:30:80:37:2E:DB:67:6B:0C:9A
tomcat1, Oct 2, 2012, trustedCertEntry,
Certificate fingerprint (MD5): 00:D4:E1:E2:33:61:FB:64:04:55:EA:5F:16:BF:2C:07

Jobb helyet nem találtam a kérdésemnek. Egyébként meg azt hiszem túl régóta vagyok rendszergazda.
Követem egy Lengyel fotográfus munkáját. Naponta zip-ben lehet letölteni a képeit. Ma rsync-el frissítettem a másik gépen található backup-ot. Ekkor vettem észre hogy az egyik ilyen zip két helyen is megvan.

Mezei user az állomány hosszának ellenörzése után törölné az egyiket. Power user-ként nekiestem md5sum-al ellenőrizni, ugyanaz-e a kettő. Persze nem, holott utólag megnézve hosszra ugyanaz a kettő. Akkor az egyik sérült lehet. Próba kitömörítés, mindkettő sértetlen, ugyanazok az állományok vannak benne. Egyre gyanusabb.

Képek md5sum értékei különbözőek a két zip-ből. Hosszra pedig itt is egyezés van. Úgy jelenítettem meg azokat, hogy space vált közöttük, de akárhogyis, egyezőnek látom azokat.
Aha! Biztos az EXIF-ben van valami. Részletes megjelenítés, de itt is egyezés van.
Egyre morcibb vagyok, dd if=kep1 of=resz1 bs=1024 count=2 és kep2-re ugyanígy egyeznek a részek.

Ha se az eleje, se a vége (EXIF) nem tér el, hosszra megegyeznek, vizuálisan ugyanazok, akkor miben tér el a két kép? md5sum árulkodik... Ilyen titkosítás kell nekem! :)
Tudom, hibáztam az elején, elég lett volna az 'ls -l', kellett nekem md5sum-al kezdenem.

Nektek is kitiltja a böngészőből az oldalt, vagy csak nálam fordul elő a hiba...:) szép kis reklám...

Ebbe ma botlottam bele. Nem új, de érdekes. Mármint, hogy egyesek biztonsági garanciát vállalnak az általuk készített szoftverre:

http://www.and.org/and-httpd/#security-guarantee

Nem ez az egyetlen:

http://cr.yp.to/djbdns/guarantee.html

Egy időben a vsftpd-nél is volt hasonló, de ahogy néztem, az már megszűnt. Aki tud még hasonlót, ne titkolja.

Sziasztok!

Párom nemrég küldte át a számlavezető bankomtól jött levelet, amelyben ezt írják:

"Bankunk tudomására jutott információk alapján feltételezhető, hogy az Ön xxxxxxx számú Maestro típusú bankkártyájának adatai illetéktelenek kezébe kerültek és ezáltal bankkártyájával visszaélést követhetnek el.

Fentiek és az xxxxx Bank Lakossági Bankkártya Általános Szerződési Feltételei alapján bankkártyáját biztonsági okok miatt és az esetleges visszaélések megelőzése érdekében 2012.09.11. napján költségmentesen letiltjuk.

Kérjük pótkártyájának díjmentes igényléséhez jelen levelünkkel szíveskedjen befáradni bármelyik bankfiókunkba.

...

Budapest, 2012 augusztus 29."

Első körben meglepődtem.
Másodikban kicsit elgondolkodtam:
- Csak nekem "lopták" el a kártyám adatait? Kapott már más is ilyen levelet mostanában?
- A kártyákat mindig ki szokták küldeni. Most miért nem?
- Miért ilyen módon értesítenek? Augusztus 29 és szeptember 4.-e között eltelt idő nem fontos senkinek? Nem lett volna jobb, ha felhívnak? 11.-éig meg tűkön ülhetek? :D

U.i.: Bocs, ha nem pont ide illik ez a topic.

Nézem az RSA-séma működési elvét, és azt látom, hogy a ma elterjedt kettős kulcsú titkosításnál mind a titkos, mind a nyilvános kulcs két számból áll (N, e ill. N, d). Ezt a két számot ki lehet-e valahogy nyerni a .ssh/id_rsa* fájlokból? Van valami specifikáció valahol erre vonatkozóan?

Üdv mindenkinek,

Egy kis segítséget szeretnék kérni SecRule RESPONSE_BODY témában.

Próba képpen egy alap debian apache,mod_security (apache2 2.2.16-6+squeeze7, libapache-mod-security 2.5.12-1+squeeze1) teszt rendszeren szeretnék kipróbálni pár dolgot. A mod_security modul betöltve és működik a RESPONSE_BODY kivételével.

Az alapértelmezett konfig fájl mellett egy saját konfig fájlban a következők vannak:

SecRuleEngine On
SecResponseBodyAccess On
SecRule RESPONSE_BODY "teszt" "log,deny"
SecRule REQUEST_URI "teszt2.txt" "deny"

Ha a következő kérést intézem a szerver felé http://172.16.200.148/teszt.txt aminek az egyik sorában benne van a "teszt" szöveg akkor a szerver rendesen kiszolgálja a kérést nem utasítja el és nem kerül bejegyzés a logba miszerint illeszkedett volna egy szabályra.

A http://172.16.200.148/teszt2.txt kérést rendben elutasítja a szerver.

Mit rontok el? Miért nem működik a RESPONSE_BODY szabály?

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

Sziasztok!

Van egy Debian szerver, rajta Apache, plusz Tomcat6, két app-pal.
Az Apache-on futó oldalak SSl-en keresztül kommunikálnak (GlobeSSL wildcard).

Be kéne lőnöm a tanúsítványt Tomcat alá is. Vajon ha mod_jk-val "bemountolom" a tomcat-appokat az apache alá, fognak az appok is SSL-en keresztül kommunikálni? Vagy telepítenem kell a tanúsítványt Tomcat alá is?

Sziasztok,

windows topicba tettem be a kérdést, mert MS plarformon érdekel a probléma megoldása, de valószínűleg ez igazából egy platform-semleges téma:

arról keresek leírást, hogy egy megfelelőn kitöltött (common name, organization, organization unit, locality, stb.) és elküldött certificate request-ben szereplő adatok közül melyek jutnak el ténylegesen is a CA-hoz a request fájlban, ezek közül a CA milyen okból ignorál(hat) bizonyos sorokat (pl. startssl szolgáltató csak a publik key-t nézi a request-ből, a common name, locality stb.-t nem) ill. ha a CA valamely paramétert önkényesen megváltoztatta, akkor az igénylőhöz visszajutó answer fájlt az igénylő szónélkül befogadja v. elutasít(hat)ja? ("én nem ilyen lovat akartam" effektus)

Techneten sok kereséssel sem találtam választ, cert-el foglalkozó MS könyvekben pedig mindenféle üzemeltetési dolgokkal fárasztanak, de igazán jó alapozó könyvet nem találtam.

Sziasztok,

Keresünk egy olyan céget, aki windowsos számítógépeket vizsgálna át egy előző rendszergazda esetleges rosszindulatú cselekményei miatt.

Kereshettek itt, vagy privátban is.

Köszönöm,
Sulc