Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Ondřej Caletka

Stran: 1 ... 41 42 [43] 44 45 ... 55
631
Server / Re: Nefunguje autentizace pres cram-md5
« kdy: 03. 08. 2011, 15:39:13 »
A proti jaké databázi hesla ověřuješ? Pokud proti /etc/shadow, tak to nemůže fungovat, protože metoda CRAM-MD5 potřebuje heslo buď v plaintextu, nebo ve správné hashované podobě (jiné, než se používá v /etc/shadow).

Zde je to rozepsáno do podrobna:
http://wiki2.dovecot.org/Authentication/Mechanisms

632
Server / Re: koupe SSL certifikatu
« kdy: 01. 08. 2011, 09:26:08 »
Pokud vám doteď stačil selfsigned certifikát, pravděpodobně si nyní vystačíte s certifikátem zdarma od StartSSL.com. Jen dejte pozor, aby webový server posílal kompletní cestu certifikátů, protože mezilehlá CA, která certifikáty zdarma vydává, nemá přímou důvěru v prohlížeči, ale je podepsaná důvěryhodnou Starcom CA.

Pokud nepošlete celou cestu, bude to někde fungovat a jinde ne, podle toho, zda už vám nějaký jiný web poslal certifikát mezilehlé CA.

633
Jenom doplním, že manuálová stránka procmailex(5) obsahuje i velice sofistikovanou náhradu programu vacation pomocí skriptu procmailu. Ta se stará o to, aby neodpovídala do diskuzních skupin, aby každému odpověděla nejvýše jednou a aby zabránila vytvoření smyčky, pokud by na automatickou odpověď dorazila automatická odpověď.

634
Sítě / Re: Jak zastavit útoky z ip (jinak, než u mne)?
« kdy: 26. 07. 2011, 10:30:51 »
Navic neni tak tezke napsat si pravidlo pro iptables, ktere vam ssh presune zpet na 22 na interfacu z vnitrni site, odkud se stejne vetsinou asi budete prihlasovat casteji a nebudete tak muset zadavat port.
Další možnost, jak nepsat číslo portu, je konfigurační soubor klienta (~/.ssh/config nebo /etc/ssh/ssh_config):
Kód: [Vybrat]
Host jmenohosta.example.com
        Port 2222

635
Server / Re: DNSSEC - výměna KSK
« kdy: 26. 07. 2011, 10:19:46 »
Ve výše uvedeném příkladu je zase omylem jedno -k navíc, bohužel fórum neumožňuje editaci...

636
Server / Re: DNSSEC - výměna KSK
« kdy: 26. 07. 2011, 10:18:29 »
Vypadá to na chybějící přepínač -k před druhým KSK klíčem - utilita signzone se ho pak snaží interpretovat jako zónový soubor, což se ji nedaří.

Testoval jsem to teď a dopadlo to dobře:
Kód: [Vybrat]
dnssec-signzone -o dnssec-test.cz. -r /dev/random -a -k $(readlink ksk-current.key ) -k -k $(readlink ksk-new.key )  -N unixtime  ../master/dnssec-test.cz.zone $(readlink zsk-current.key )
Verifying the zone using the following algorithms: RSASHA512.
Zone signing complete:
Algorithm: RSASHA512: KSKs: 2 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 1 stand-by, 0 revoked
../master/dnssec-test.cz.zone.signed

637
Sítě / Re: SSH tunel a traffic na něm
« kdy: 26. 07. 2011, 10:04:23 »
Nebude-li zapnutý u SSH keepalive, , nemělo by to sežrat vůbec nic (samozřejmě kromě handshakingu při každém navazování spojení). SSH posílá po TCP spojení zprávy a posílá je pouze tehdy, má-li co posílat.

Problém je v tom, že je-li na cestě stavový firewall nebo NAT, spojení se po určité době nečinnosti zruší. To je případ snad všech GPRS a podobných spojení. Takže nějaký keepalive potřeba bude a ten něco málo sežere (Změř si to třeba v IPtables - zaveď pravidlo, které nebude nic dělat a sleduj na něm počítadla).

638
/dev/null / Re: Hosting pro warez - v jake zemi?
« kdy: 25. 07. 2011, 09:24:04 »
Podle mě v ČR si pro dedikovaný server policie nepřijde, pokud tam nebude vyloženě nějaké probourávání se do ministerstva vnitra.
V housingovém centru na Strahově je díra po zabaveném PC doteď. A pochybuju, že by se kamkoli probourával, policie jednala „na objednávku“ velkého obsahu.

639
Sítě / Re: Nejede DNSSEC v síti T-Mobile
« kdy: 27. 06. 2011, 18:45:23 »
Tak ještě jednou já: Teď jsem otestoval připojení přes UMTS-TDD alias Internet 4G a musím bohužel potvrdit to, co zde bylo napsáno.

T-Mobile u služby Internet 4G transparentně proxuje a zároveň podvrhuje systém DNS!

Klient může požádat jakoukoli adresu o překlad kořenové zóny, vždy dostane prázdnou odpověď pouze s GLUE záznamem
Kód: [Vybrat]
.                       65535   IN      A       62.141.6.172

Následuje pár needitovaných příkladů:
Kód: [Vybrat]
oskar@esprimo ~ $ dig +dnssec @1.2.3.4 aaaa

; <<>> DiG 9.7.3 <<>> +dnssec @1.2.3.4 aaaa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49355
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;.                              IN      NS

;; ADDITIONAL SECTION:
.                       65535   IN      A       62.141.6.172

;; Query time: 123 msec
;; SERVER: 1.2.3.4#53(1.2.3.4)
;; WHEN: Mon Jun 27 18:21:44 2011
;; MSG SIZE  rcvd: 44

oskar@esprimo ~ $ dig +dnssec @1.2.3.4 a

; <<>> DiG 9.7.3 <<>> +dnssec @1.2.3.4 a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29406
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;.                              IN      NS

;; ADDITIONAL SECTION:
.                       65535   IN      A       62.141.6.172

;; Query time: 100 msec
;; SERVER: 1.2.3.4#53(1.2.3.4)
;; WHEN: Mon Jun 27 18:21:46 2011
;; MSG SIZE  rcvd: 44

oskar@esprimo ~ $ dig . @2.2.8.3 txt

; <<>> DiG 9.7.3 <<>> . @2.2.8.3 txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48758
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.                              IN      TXT

;; ANSWER SECTION:
.                       65535   IN      A       62.141.6.172

;; Query time: 94 msec
;; SERVER: 2.2.8.3#53(2.2.8.3)
;; WHEN: Mon Jun 27 18:40:25 2011
;; MSG SIZE  rcvd: 33

oskar@esprimo ~ $ host .
. has address 62.141.6.172
. has address 62.141.6.172
. has address 62.141.6.172

Bohužel, vzhledem k tomu, že jde o proxování transparentní, nedá se to vyřešit (kromě reklamace a doufání, že to spraví) jinak než šifrovaným tunelem.

640
Sítě / Re: Router a alternativní firmware
« kdy: 27. 06. 2011, 09:10:26 »
OT:
Když ale odejde nějaká součástka vinou přílišného stáří (během těch dvou let), budou v servise hledět na firmware, nebo budou snad rozumní? Mám nějakou záruku?  :)
Odejde-li součástka vlivem přílišného stáří, zákonná záruka se na ni nevztahuje. To je častý omyl. Zákonná záruka pokrývá skryté vady výroby, nikoli vady vzniklé opotřebením.

Například klasická žárovka - má záruku 2 roky, ale životnost 1000 hodin. Při provozu 24/7 tedy může svůj život skončit po nějakých 42 dnech a není to výrobní vada, zákazník tedy nemá nárok na zákonnou reklamaci.

641
Sítě / Re: nejede DNSSEC v siti T-Mobile
« kdy: 26. 06. 2011, 17:56:33 »
Teď jsem otestoval připojení přes T-Mobile EDGE a tam k výše popsanému prasení nedochází. O jaký jde přesně druh připojení? Je to 4G, nebo ADSL?

642
Sítě / Re: nejede DNSSEC v siti T-Mobile
« kdy: 23. 06. 2011, 14:14:14 »
Tak ještě něco, stáhnul jsem si ty dumpy a jsem si jist, že T-mobile modifikuje data na cestě:

Předvedu to dvojicí shodných dotazů na shodný server i.root-servers.net s adresou 192.36.148.17. Nejprve O2:
Kód: [Vybrat]
No.     Time        Source                Destination           Protocol Info
      4 0.042980    192.168.0.1           192.36.148.17         DNS      Standard query DNSKEY <Root>

Frame 4: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)
Ethernet II, Src: CameoCom_b7:be:ee (00:40:f4:b7:be:ee), Dst: CompalEl_d3:59:53 (00:0f:b0:d3:59:53)
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.36.148.17 (192.36.148.17)
User Datagram Protocol, Src Port: 34272 (34272), Dst Port: domain (53)
Domain Name System (query)
    [Response In: 5]
    Transaction ID: 0xf27a
    Flags: 0x0010 (Standard query)
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        <Root>: type DNSKEY, class IN
            Name: <Root>
            Type: DNSKEY (DNS public key)
            Class: IN (0x0001)
    Additional records
        <Root>: type OPT
            Name: <Root>
            Type: OPT (EDNS0 option)
            UDP payload size: 4096
            Higher bits in extended RCODE: 0x0
            EDNS0 version: 0
            Z: 0x8000
                Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
                Bits 1-15: 0x0 (reserved)
            Data length: 0

No.     Time        Source                Destination           Protocol Info
      5 0.079378    192.36.148.17         192.168.0.1           DNS      Standard query response DNSKEY DNSKEY DNSKEY RRSIG

Frame 5: 925 bytes on wire (7400 bits), 925 bytes captured (7400 bits)
Ethernet II, Src: CompalEl_d3:59:53 (00:0f:b0:d3:59:53), Dst: CameoCom_b7:be:ee (00:40:f4:b7:be:ee)
Internet Protocol, Src: 192.36.148.17 (192.36.148.17), Dst: 192.168.0.1 (192.168.0.1)
User Datagram Protocol, Src Port: domain (53), Dst Port: 34272 (34272)
Domain Name System (response)
    [Request In: 4]
    [Time: 0.036398000 seconds]
    Transaction ID: 0xf27a
    Flags: 0x8410 (Standard query response, No error)
    Questions: 1
    Answer RRs: 4
    Authority RRs: 0
    Additional RRs: 1
    Queries
        <Root>: type DNSKEY, class IN
            Name: <Root>
            Type: DNSKEY (DNS public key)
            Class: IN (0x0001)
    Answers
        <Root>: type DNSKEY, class IN
            Name: <Root>
            Type: DNSKEY (DNS public key)
            Class: IN (0x0001)
            Time to live: 2 days
            Data length: 136
            Flags: 0x0100
            Protocol: 3
            Algorithm: RSA/SHA-256
            Key id: 34525
Všechno je v pořádku, dotaz zněl na DNSKEY, DNSKEY byl vrácen...

Nyní ten samý dotaz na tu samou adresu přes T-M:
Kód: [Vybrat]
No.     Time        Source                Destination           Protocol Info
     29 2.700126    89.24.27.50           192.36.148.17         DNS      Standard query DNSKEY <Root>

Frame 29: 72 bytes on wire (576 bits), 72 bytes captured (576 bits)
Linux cooked capture
Internet Protocol, Src: 89.24.27.50 (89.24.27.50), Dst: 192.36.148.17 (192.36.148.17)
User Datagram Protocol, Src Port: 65418 (65418), Dst Port: domain (53)
    Source port: 65418 (65418)
    Destination port: domain (53)
    Length: 36
    Checksum: 0x732b [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Domain Name System (query)
    [Response In: 30]
    Transaction ID: 0x02ff
    Flags: 0x0010 (Standard query)
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        <Root>: type DNSKEY, class IN
            Name: <Root>
            Type: DNSKEY (DNS public key)
            Class: IN (0x0001)
    Additional records
        <Root>: type OPT
            Name: <Root>
            Type: OPT (EDNS0 option)
            UDP payload size: 4096
            Higher bits in extended RCODE: 0x0
            EDNS0 version: 0
            Z: 0x8000
                Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
                Bits 1-15: 0x0 (reserved)
            Data length: 0

0000  00 04 02 00 00 00 00 00 00 00 00 00 00 00 08 00   ................
0010  45 00 00 38 29 62 00 00 40 11 88 d3 59 18 1b 32   E..8)b..@...Y..2
0020  c0 24 94 11 ff 8a 00 35 00 24 73 2b 02 ff 00 10   .$.....5.$s+....
0030  00 01 00 00 00 00 00 01 00 00 30 00 01 00 00 29   ..........0....)
0040  10 00 00 00 80 00 00 00                           ........

No.     Time        Source                Destination           Protocol Info
     30 2.785972    192.36.148.17         89.24.27.50           DNS      Standard query response OPT

Frame 30: 88 bytes on wire (704 bits), 88 bytes captured (704 bits)
Linux cooked capture
Internet Protocol, Src: 192.36.148.17 (192.36.148.17), Dst: 89.24.27.50 (89.24.27.50)
User Datagram Protocol, Src Port: domain (53), Dst Port: 65418 (65418)
    Source port: domain (53)
    Destination port: 65418 (65418)
    Length: 52
    Checksum: 0xe84d [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Domain Name System (response)
    [Request In: 29]
    [Time: 0.085846000 seconds]
    Transaction ID: 0x02ff
    Flags: 0x8580 (Standard query response, No error)
    Questions: 1
    Answer RRs: 1
    Authority RRs: 0
    Additional RRs: 1
    Queries
        <Root>: type DNSKEY, class IN
            Name: <Root>
            Type: DNSKEY (DNS public key)
            Class: IN (0x0001)
    Answers
        <Root>: type OPT
            Name: <Root>
            Type: OPT (EDNS0 option)
            UDP payload size: 4096
            Higher bits in extended RCODE: 0x0
            EDNS0 version: 0
            Z: 0x8000
                Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
                Bits 1-15: 0x0 (reserved)
            Data length: 0
    Additional records
        <Root>: type A, class IN, addr 62.141.6.172
            Name: <Root>
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 18 hours, 12 minutes, 15 seconds
            Data length: 4
            Addr: 62.141.6.172 (62.141.6.172)

0000  00 00 02 00 00 00 00 00 00 00 00 00 00 00 08 00   ................
0010  45 00 00 48 85 99 00 00 ff 11 6d 8b c0 24 94 11   E..H......m..$..
0020  59 18 1b 32 00 35 ff 8a 00 34 e8 4d 02 ff 85 80   Y..2.5...4.M....
0030  00 01 00 01 00 00 00 01 00 00 30 00 01 00 00 29   ..........0....)
0040  10 00 00 00 80 00 00 00 c0 0c 00 01 00 01 00 00   ................
0050  ff ff 00 04 3e 8d 06 ac
Dotaz zněl stejně, v odpovědi chybí DNSKEY, naopak sekce ADDITIONAL tvrdí, že root zóna má A záznam (!!!) s adresou 62.141.6.172.

Můžete hádat třikrát, na jakou reverzní adresu se tato IP adresa mapuje:
Kód: [Vybrat]
$  host 62.141.6.172
172.6.141.62.in-addr.arpa domain name pointer ums.internet.t-mobile.cz.

T-Mobile vás tedy připojil k něčemu, čemu se nedá říkat Internet. Zbývá vám tedy jediné - reklamovat, reklamovat, reklamovat, když to nepůjde tak odejít. Od takovéhoto NATování je jen krůček k tomu aby Vám příště dělali MitM na SSL  komunikaci či podobná zvěrstva.

643
Sítě / Re: nejede DNSSEC v siti T-Mobile
« kdy: 23. 06. 2011, 12:53:28 »
Jediné, co mě teď napadá, je že někde v síti T-M neprojdou příliš dlouhé UDP zprávy. To by vysvětlovalo záznamy v logu:
Kód: [Vybrat]
Jun 21 19:54:59 alpha named[1323]: error (FORMERR) resolving './DNSKEY/IN': 192.36.148.17#53
Jun 21 19:54:59 alpha named[1323]: DNS format error from 128.8.10.90#53 resolving ./DNSKEY: reply has no answer

Zkuste spustit na obou připojeních DNSSEC tester, ten by takový problém mohl pomoci odhalit.

644
O serveru Root.cz / Re: Chybicka?
« kdy: 22. 06. 2011, 11:41:39 »
Přitom není nic jednoduššího, než se přihlásit a Captcha otázky zmizí.

645
Sítě / Re: nejede DNSSEC v siti T-Mobile
« kdy: 22. 06. 2011, 11:28:20 »
Skoro to vypadá, jako by T-M používal transparentní DNS resolvery, možná za účelem ještě účinnější ochrany před Kinderpornem. A možná jejich transparentní resolvery stripují RRSIG záznamy...

Ani bych se nedivil, potom co jsem zjistil, co provádějí sítě T-M (včetně ADSL) s protokolem SIP.

Zkusím to taky vyzkoušt, dám vědět, jestli se mi to taky projevuje.

Stran: 1 ... 41 42 [43] 44 45 ... 55