Security-all

F-secure policy manager 7.20 for linux Debian Etch ala

Fórumok

Sziasztok!

A problema forrasa a kovetkezo:
Adott egy szerver amelyen debian etch n half futkos. Csak ez a verzio tudott felmenni a szerverre.
Megkertek, hogy tegyek fel f-secure policy manager-t a szerverre. Letoltottem az f-secure oldalarol a 7.20-as verziot, de sajnos ez csak sarge-ra jo, mivel nem nagyon akar felmenni. Illetve felmegy, de a web report resze ami jo lenne, ha mukodne nem nagyon akar felkuszni a szerverre. Esetleg valakinek volt tapasztalata az emlitett szoftverrel?

Jo lenne megcsinalni, mert nagyon szeretnek. Bar lehet, hogy a vegen felrakok egy xen-t inkabb aztan azon futtatok majd direkt erre a celra egy sarge-t, bar remelhetoleg az teljesen felesleges.

Koszi a segitseget elore is.

ssh tunel --> firefox üres kép [megoldva]

Fórumok

Üdv,

SSH tunelt nyitok (ssh -D 9999 myserverip.com), majd Firefox-ban beállítom a manuális proxyt (localhost:9999). És fehér üres képernyőt kapok, mindegy milyen url-t nézek.

Iceweasel 2.0.0.14 és 3.0-val is ugyanaz a helyzet.
Ha megszakítom az SSH kapcsolatot, akkor panaszkodik a firefox, hogy kiszolgáló nincs. Úgyhogy azt érzékeli szerintem hogy proxy beállítások vannak.

Rendszer: Debian Lenny/Testing

Ötlete esetleg valakinek?
Előre is köszi.

Védekezés a SPAM-ak ellen. ( A tökéletes megoldás a problémára:)

Fórumok

Hali!

Na jó legalábbis egy újabb ötlet a spamek elleni harcban.A gondolat a következőkből indul:
Nem olyan rég nézegetem az exim reject logomat. A legtöbb bejegyzés valamilyen botnet-ből jött.
Jelenlegi védekezési módszerek a spam-ek ellen (nagy vonalakban)
1. Felhasználói oldalon: friss vírusirtó szoftver használata.

2. ISP oldalon: az stmp portot csak a saját smtp szerverükre engedje ki. És ha egy elvetemült user az útlok-ot akarja használni. Azt csak ezen keresztül tehesse meg. Pont.

3.Smtp szerver oldalon:
3.a amavis, spamassassin és egyéb progik.
3.b A legfontosabb pedig mostanában pár rbl használata.

Eddig az alapfeltevés. A gondolatom pedig a következő:
Itt vannak az rbl-ek. Amik egy nagy adatbázisok a legtöbb spammer gép/isp-ről. (Igen az szolgáltató is hibás a dologban, sőt szerintem az smtp port tiltása egy nagyon fontos lépés lenne. ) Tehát ezt az adatbázist csak az smtp szerverek használják fel. De mi lenne akkor ha egy másik felhasználási módot is adnánk ennek az adatbázisnak. Nevezetesen a figyelem felhívást. Elődlegesen az isp figyelmeztetése az smtp port letiltására. Másodlagosan a vírusirtó használatára.

A megvalósítás nem is olyan bonyolult.
Pl: Egy apacs modul írása ami az rbl-ben szereplő ip címeket egy hiba oldara küldni. Vagy egy jomoola, drupal modul készítése ugyanilyen céllal.

Persze ennek az egésznek csak akkor lehetne valami értelme ha több nagyobb weboldal is csatlakozna az elképzeléshez.

Érdekelne, hogy kinek mi a véleménye a dologról.

Syn Scan

Fórumok

Sziasztok!

Hogy tudom apache-ban azt beállítani, hogy ne kotyogja ki magáról a lenti információkat?

Köszi

Z.

SYN Scan...

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2008-07-07 09:32 CEST
Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port
Interesting ports on xxxxxxxxxxxxxxxxxxxxxx:
Not shown: 1675 filtered ports
PORT STATE SERVICE VERSION
25/tcp open smtp Postfix smtpd
80/tcp open http Apache httpd 2.2.3 ((Debian) PHP/5.2.0-8+etch11 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_perl/2.0.2 Perl/v5.8.8)
443/tcp open ssl/http Apache httpd 2.2.3 ((Debian) PHP/5.2.0-8+etch11 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_perl/2.0.2 Perl/v5.8.8)

Támadások?

Fórumok

Beállítottam a soho-routeremet mar korabban( web oldal tesztelés, egyebb routing problema miatt) dmz-re a sajat(lan) belso ip-m cimere. Mostanaban vettem eszre hogy 1-2 percenkent próbálgatnak különböző portokon UDP csomagokat küldeni. Mennyire vegyem ezeket komolyan?
Mi az-az elfogadható szint ami fölött érdemes ezzel komolyabban foglalkozni?

Gondolom egy dyndns regeles(a weblap miatt) csak növelte a támadás veszélyét.

Fájltitkosító szoftver fejlesztése - projectbejelentés

Fórumok

A téma valahol programozás, biztonságtechnika, s projectbejelentés is egyben, tehát ha nem feltétlen ide illik, elnézéseteket kérem :)

Tehát:
egyik barátom részére kerestem Windows alá fájltitkosító programot. Meg is találtuk a neki szimpatikus alkalmazást, de elkezdett mocorogni a kisördög odabent. No, nekiálltím kutakodni, hogy linux alatt milyen programok vannak a témában.
Találataim között csupa olyat találtam, amit laikus elég nehezen tud használni, illetve egy-két olyat, ami nem túl bonyolult, de nincs hozzá GUI. Ez elég könnyen orvosolható lenne, de mivel másnap azon kaptam magam, hogy munkahelyen algoritmus vázlatokat vetek papírra, nyilvánvalóvá vált számomra, hogy nem ezt az utat választottam. :) Sebaj, legalább növekszik a csomagok száma.

Itt jön a project bejelentése:
egy olyan szoftvert terveztem meg, mely fájlok titkosítását végzi, mindezt olyan formában, hogy az egyszeri felhasználónak se okozzon különösebb fejtörést. Rendelkezik GUI-val, de parancssorból is elérhető. A feljesztést Mono-ban kezdtem (lehet fujjogni!). Hogy miért is nem C/C++ lett a vége? Hordozhatóvá szerettem volna tenni. Tudom, GTK-val C-ből is lehetne ilyet csinálni (egyébként még ez sincs elvetve, nem tart túl sokból átültetni az algoritmust). Itt jön az első kérdésem (lesz még pár, szertném a felhasználók igényeihez igazítani a project-et): mi a véleményetek, melyikben szülessen a végeredmény?
A Mono ilyen téren azért tűnik számomra jobb megoldásnak, mert a programot csak egyszer kell fordítani, a keretrendszer pedig minden OS-en elfuttatja azt. GTK esetén sem úsznánk meg pl.: Windows alatt a plusz telepítést, tehát installálási számban ugyanott van a user. Azaz Mono esetén számomra kényelmesebb a közreadás, hiszen nem kell minden egyes OS-re fordítgatni. Ellene az szól, hogy a Mono körüli huzavona mit fog eredményezni a jövőben, lesznek-e licensz problémák.
A keretrendszer működik, az általam most rábízott feladatot ellátja, egyelőre nem találtam hibás működést a készülő programban.

Leírás:
alapvetően matematikai alapon működik (mi máson lehetne) a titkosítás. Két darab 4 jegyű "PIN"-kódot kér, s ezekkel, no meg még sok egyéb mással karöltve hozza létre a végeredményt. A két kód összesen 100.000.000 variánst enged, ami egy BruteForce-al való törésnél már elég meredek vállalkozás lenne (gondolom én).
A két "PIN"-re utaló bejegyzés nem kerül bele a titkosított fájlba, tehát az alapján nem fejthető meg a két kulcs. A választott módszer ugyan biztonságosabbá teszi a titkosított fájlt, viszont van egy szépséghibája, mégpedig az, hogy ha jó a "PIN", ha nem, akkor is legyártja a fájlt (még ha hibás lesz a végeredmény, akkor is). Ez jócskán nehezíti a BruteForce módszert, hiszen százmillió fájlt átnézni nem egy leányálom :)
Második kérdés: valakinek van ötlete a "lecsekkolás" megoldására olyan módon, hogy az alap koncepció ne sérüljön, azaz ne kelljen fájlba helyezni a két kódot? Sajnos én még nem jöttem rá, pedig lehet, hogy pofon egyszerű (vagy mégsem).

szerk: olyan jutott még eszembe, hogy az eredeti fájl md5 értékét beleteszem, s visszakódolás után ezt leellenőrzi. Ennek ismeretében vajon könnyedén visszakódolható a fájl? Létezik olyan eszköz, ami helyre tudja állítani az md5 értéket? Illetve visszaszámolhatóvá válna a "PIN" ez alapján?

A módszeremnek szerintem az az előnye, hogy nyugodt szívvel teszem nyílt forrásúvá, ugyanis hiába ismerjük a kódolási algoritmust, szinte lehetetlen a fájl kikódolása (kivéve ugye a százmilliós brute módszert), ellenben a fájlban elhelyezett kulcsra utaló "nyomokkal", ahol az algoritmus és a kódolt fájl párosával már sokkal reálisabb esély mutatkozik a visszafejtésre.
Harmadik kérdés: nagyon szeretném a közösség részére átadni a forrást, de felmerült bennem a kétely, hogy biztonságtechnikai program lévén jó ötlet-e. A fentiek alapján mi a véleményetek? Közzé lehet tenni a forrást anélkül, hogy bárki is vissza tudjon élni vele?

A jövő:
ha időm is úgy engedi, 1-2 hónap múlva már elő tudok rukkolni az első stabil kiadással. Most még ugyan nem látom át, hogy az algoritmusban mit lehetne majd a jövőben továbbfejleszteni, de szolgáltatásokban biztosan lehet bővíteni (halovány elképzeléseim már derengenek).

Várom véleményeiteket, javaslataitokat!

Dávid