Messages posted by: rcrackvn

mrro wrote:

lý do kô đọc được email cũ đơn giản là email cũ được mã hóa bằng public-key cũ (nằm trong cert cũ), nên cái private key mới được cấp không thể giải mã được chúng.

mgẫm nghĩ thì thấy có cách là lấy cái cert cũ, xuất hết thông tin trong đó ra, như là common name, email, đặc biệt là public key, rồi dựa vào những thông tin này để tạo ra một cái cert mới, làm sao cái cert mới khác với cert cũ ở chỗ expired date thôi. đương nhiên là phải ký lại rồi.

cái này thì phải biết cách xử lý thủ công X.509 cert. bạn phải coi phần mềm mà bạn đang sử dụng để làm CA có làm được hay không. nếu mà nó không làm được, thì có một option khác là tìm hiểu OpenSSL hay là Cryptlib để tự làm. còn nếu không nữa thì liên hệ mình, mình viết cho một cái utility nhỏ, giá cả phải chăng :-D.

mà đã thử coi email client nó có cho phép import nhiều private key khác nhau, rồi khi cần decrypt thì cho phép user chọn key chưa? mình xài Thunderbird/Enigma nó hỗ trợ phẻ re cái này mà.

cập nhật: giải thích tại sao không đọc được email cũ khi dùng cert mới.

-m

Mình không hiểu process của mrro ở các điểm sau:
- CA không sign certificate, CA chỉ tạo ra signed certificate từ CSR (certificate signing request). Sau đây là kết quả mình sign trực tiếp 1 crt (modified crt theo concept của mrro) để tạo ra newly-signed crt:
Code:

# openssl x509 -req -days 365 -in client.crt -signkey ca.key -out new.crt
1194:error:0906D06CEM routinesEM_read_bio:no start line:/usr/src/lib/libssl/src/crypto/pem/pem_lib.c:650:Expecting: CERTIFICATE REQUEST

- OpenSSL cho phép tạo ra CSR mới từ old cert:
Code:

# openssl x509 -in client.crt -signkey client.key -x509toreq -out new.csr
Getting request Private Key
Generating certificate request

- Nội dung của new.csr:
Code:

Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=VN, ST=HCMC, L=HCMC, O=Test org, OU=Email Users, CN=user1/emailAddress=user1@test.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:d6:6c:b7:cd:9b:7a:27:6d:b0:10:13:d1:d6:e2:
e5:55:4d:fc:42:16:ca:55:a9:0e:6e:02:cc:48:85:
75:96:80:d9:f9:2e:23:5a:e4:28:58:e5:5f:24:59:
49:23:5d:21:66:09:e0:aa:1b:96:58:7a:51:d6:8c:
8b:0f:ac:83:bc:cf:98:c7:ae:54:62:eb:a1:17:22:
23:87:9c:73:92:40:6e:56:44:7f:87:81:d7:67:38:
77:f9:6a:61:4b:09:1d:8f:1a:80:75:5d:10:46:0a:
73:49:f5:6a:0d:87:0c:c9:4f:ac:06:6e:75:a4:0d:
9b:35:be:45:91:ba:93:f0:29
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha1WithRSAEncryption
0b:6e:7c:cf:d2:1a:57:fd:ea:0f:b7:1d:88:65:4a:c7:50:97:
55:85:55:ef:55:4d:60:eb:9d:5b:b7:52:0e:2b:93:f1:d5:6a:
24:6c:a8:98:6e:e0:95:a4:ac:e1:ea:fe:bd:85:ff:1d:4a:75:
56:14:da:15:34:54:96:b0:0d:fd:ab:13:ec:0b:3c:80:6c:9b:
ce:5d:6f:86:bf:19:b6:24:5c:f3:eb:73:b4:0b:df:62:6c:00:
a3:62:d9:e0:74:9a:b3:28:40:15:02:eb:4d:02:84:df:b9:7b:
78:30:30:aa:0b:07:2b:51:8b:8b:b4:c7:bc:d2:a4:f6:25:86:
a3:b4
-----BEGIN CERTIFICATE REQUEST-----
MIIBxDCCAS0CAQAwgYMxCzAJBgNVBAYTAlZOMQ0wCwYDVQQIEwRIQ01DMQ0wCwYD
VQQHEwRIQ01DMREwDwYDVQQKEwhUZXN0IG9yZzEUMBIGA1UECxMLRW1haWwgVXNl
cnMxDjAMBgNVBAMTBXVzZXIxMR0wGwYJKoZIhvcNAQkBFg51c2VyMUB0ZXN0Lm9y
ZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1my3zZt6J22wEBPR1uLlVU38
QhbKVakObgLMSIV1loDZ+S4jWuQoWOVfJFlJI10hZgngqhuWWHpR1oyLD6yDvM+Y
x65UYuuhFyIjh5xzkkBuVkR/h4HXZzh3+WphSwkdjxqAdV0QRgpzSfVqDYcMyU+s
Bm51pA2bNb5FkbqT8CkCAwEAAaAAMA0GCSqGSIb3DQEBBQUAA4GBAAtufM/SGlf9
6g+3HYhlSsdQl1WFVe9VTWDrnVu3Ug4rk/HVaiRsqJhu4JWkrOHq/r2F/x1KdVYU
2hU0VJawDf2rE+wLPIBsm85db4a/GbYkXPPrc7QL32JsAKNi2eB0mrMoQBUC600C
hN+5e3gwMKoLBytRi4u0x7zSpPYlhqO0
-----END CERTIFICATE REQUEST-----

- CSR request được encode bởi ASN.1, mình parse thử content của nó:
Code:

# openssl asn1parse -in new.csr
0:d=0 hl=4 l= 452 cons: SEQUENCE
4:d=1 hl=4 l= 301 cons: SEQUENCE
8:d=2 hl=2 l= 1 prim: INTEGER :00
11:d=2 hl=3 l= 131 cons: SEQUENCE
14:d=3 hl=2 l= 11 cons: SET
16:d=4 hl=2 l= 9 cons: SEQUENCE
18:d=5 hl=2 l= 3 prim: OBJECT :countryName
23:d=5 hl=2 l= 2 prim: PRINTABLESTRING :VN
27:d=3 hl=2 l= 13 cons: SET
29:d=4 hl=2 l= 11 cons: SEQUENCE
31:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
36:d=5 hl=2 l= 4 prim: PRINTABLESTRING :HCMC
42:d=3 hl=2 l= 13 cons: SET
44:d=4 hl=2 l= 11 cons: SEQUENCE
46:d=5 hl=2 l= 3 prim: OBJECT :localityName
51:d=5 hl=2 l= 4 prim: PRINTABLESTRING :HCMC
57:d=3 hl=2 l= 17 cons: SET
59:d=4 hl=2 l= 15 cons: SEQUENCE
61:d=5 hl=2 l= 3 prim: OBJECT :organizationName
66:d=5 hl=2 l= 8 prim: PRINTABLESTRING :Test org
76:d=3 hl=2 l= 20 cons: SET
78:d=4 hl=2 l= 18 cons: SEQUENCE
80:d=5 hl=2 l= 3 prim: OBJECT :organizationalUnitName
85:d=5 hl=2 l= 11 prim: PRINTABLESTRING :Email Users
98:d=3 hl=2 l= 14 cons: SET
100:d=4 hl=2 l= 12 cons: SEQUENCE
102:d=5 hl=2 l= 3 prim: OBJECT :commonName
107:d=5 hl=2 l= 5 prim: PRINTABLESTRING :user1
114:d=3 hl=2 l= 29 cons: SET
116:d=4 hl=2 l= 27 cons: SEQUENCE
118:d=5 hl=2 l= 9 prim: OBJECT :emailAddress
129:d=5 hl=2 l= 14 prim: IA5STRING :user1@test.org
145:d=2 hl=3 l= 159 cons: SEQUENCE
148:d=3 hl=2 l= 13 cons: SEQUENCE
150:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption
161:d=4 hl=2 l= 0 prim: NULL
163:d=3 hl=3 l= 141 prim: BIT STRING
307:d=2 hl=2 l= 0 cons: cont [ 0 ]
309:d=1 hl=2 l= 13 cons: SEQUENCE
311:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption
322:d=2 hl=2 l= 0 prim: NULL
324:d=1 hl=3 l= 129 prim: BIT STRING

- Trong CSR không có field nào chứa validity period info để request CA phải approve 1 validity period.

Mình download source của openssl 0.9.8j về check thử, file apps/x509.c, line 1201-1240
Code:

static int sign(X509 *x, EVP_PKEY *pkey, int days, int clrext, const EVP_MD *digest,
CONF *conf, char *section)
{
EVP_PKEY *pktmp;
pktmp = X509_get_pubkey(x);
EVP_PKEY_copy_parameters(pktmp,pkey);
EVP_PKEY_save_parameters(pktmp,1);
EVP_PKEY_free(pktmp);
if (!X509_set_issuer_name(x,X509_get_subject_name(x))) goto err;
if (X509_gmtime_adj(X509_get_notBefore(x),0) == NULL) goto err;
/* Lets just make it 12:00am GMT, Jan 1 1970 */
/* memcpy(x->cert_info->validity->notBefore,"700101120000Z",13); */
/* 28 days to be certified */
if (X509_gmtime_adj(X509_get_notAfter(x),(long)60*60*24*days) == NULL)
goto err;
if (!X509_set_pubkey(x,pkey)) goto err;
if (clrext)
{
while (X509_get_ext_count(x) > 0) X509_delete_ext(x, 0);
}
if (conf)
{
X509V3_CTX ctx;
X509_set_version(x,2); /* version 3 certificate */
X509V3_set_ctx(&ctx, x, x, NULL, NULL, 0);
X509V3_set_nconf(&ctx, conf);
if (!X509V3_EXT_add_nconf(conf, &ctx, section, x)) goto err;
}
if (!X509_sign(x,pkey,digest)) goto err;
return 1;
err:
ERR_print_errors(bio_err);
return 0;
}

- Mình thấy validity period được set khi CA sign() certificate, không được set trong CSR của client.

Vậy mình nghĩ process của mrro sẽ gặp khó khăn ở các điểm sau:
- Không thể trực tiếp tạo 1 modified crt với các thông tin lấy từ crt cũ và bảo CA sign nó. Chỉ có thể tạo 1 csr mới từ crt cũ, csr này không mang thông tin về validity period (client không thể tự chỉ định mình muốn certificate của mình xài được trong bao lâu). csr này sau đó được gửi đi cho CA để tạo 1 crt mới với validity period mới.
- Để tạo được csr mới từ certificate cũ, bạn cần private key cũ tương ứng, private key này probably nằm trong certificate store trên máy client, bạn không thể bảo vài trăm user supply passphrase của họ để decrypt cái privatekey được

mrro có thể cho vài hướng giải quyết được không ?

secmask wrote:

....
code php ở đây chỉ làm công việc là kết nối đến memcacheq server và set một giá trị vào memcacheq.
....

....
code php kết nối đến memcacheq local của riêng mình.
....

1. Kết nối local giữa php tới memcached tại sao không xài Unix domain socket mà xài TCP socket chi vậy ? Unix domain socket không phải chịu các overhead của TCP socket như encap, decap, checksum calculate, verify, flow control,... Tui coi PHP manual của memcache_connect thì thấy nó cũng support Unix domain socket.

2. Nếu ông vẫn quá khoái xài AF_INET socket, mà mỗi lần kết nối từ php-cgi vào memcacheq chỉ để set 1 giá trị, tại sao không thử xài UDP thay vì TCP ? Thay vì tốn nhiều memory cho TCP socket creation/destruction, memory đó được memcache tận dụng thì vẫn hơn.

chào vietwow,
ông gửi tới rickb@rapidvps.com mà ? Hình như là ông test postfix = vietwow@gmail.com, trong khi đó lại test qmail = rickb@rapidvps.com.

http://www.4shared.com/file/43597167/edae057b/Design_Patterns.html

inside:

http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612
http://www.amazon.com/Design-Patterns-Explained-Perspective-Object-Oriented/dp/0201715945
http://www.amazon.com/J2EE-Design-Patterns-William-Crawford/dp/0596004273
http://www.amazon.com/PHP-Architects-Guide-Design-Patterns/dp/0973589825
http://www.amazon.com/Model-Driven-Design-Using-Business-Patterns/dp/3540301542

tui up bản ebook cho ai cần nè

http://www.4shared.com/file/43550230/54dc0f7c/Head_First_Design_Patterns.html

đây là bản ebook thật sự, không phải OCR scan.

hint nè: ông google kiếm cái thứ gọi là big-O notation 0(n). Hoặc down cuốn 'Introduction to Algorithms, 2ed' (MIT press). Tui nhớ lúc trước đọc có đề ra các phương pháp để tìm bigO cho các giải thuật, như merge sort, quick sort v.vv.

Trên trang ocw.mit.edu hình như cũng có video của mấy ông thầy dạy cái course về algo đó, textbook là cuốn trên, nếu đọc sách hông hiểu thì có thể nghe thêm để hiểu.

tui nghĩ ông hiểu lầm tui,
ở đây ông chỉ việc generate dsa public key của log server, append nó vào authorized_keys2 trên mỗi server ông muốn nhận log, viết cron để log server scp logfile từ các server kia. Nếu log server này chỉ làm mỗi việc logging thì ông disable mọi services khác.

>>quanta: tui cũng nghĩ nên dùng syslog-ng thay thế cho cái syslogd cũ, và disable hoàn toàn cơ chế nhận log remotely thông qua UDP.

không nên cấu hình syslogd chấp nhận remote logging, vì syslogd chấp nhận message từ remote client gửi tới UDP port 514, một người với mục đích xấu có thể viết 1 chương trình nho nhỏ để send junk data tới log server, nhanh chóng fill-up hết server disk space về lâu dài, hoặc fill up udp receive buffer tại log server ngay tức thời, dẫn tới việc drop các log data thực sự từ các client khác, hoặc khiến việc log audit về sau trở nên khó khăn hơn do phải parse 1 đống rác lẫn lộn với data hữu ích.

Tốt hơn vẫn là viết crob job để scp logfile lên 1 server tập trung.

tmd wrote:

Không sử dụng Linux, chỉ sài windows của Microsoft, tui sử dụng được 2 windows trên vmware. OS chính là XP sp2, 2 os trên vmware là XP sp2 và server 2003 sp1. Ram lúc đó là 256+128. Tui kiên nhẫn ngồi chơi với nó, thao tác chậm, ngồi chờ dài cổ( 2 cái OS trên vmware cùng chạy). Ram tối thiểu để cho 1 OS trên vmware chạy là 128 MB.
Nếu máy bạn có 1gb, bạn mất chừng 300-400mB cho cái windows thật. Coi như còn 600, nên dùng 256 cho mỗi vmware để nó chạy nhanh nhẩu. Còn chơi kiểu ngồi chờ, 128 mỗi em. COi thêm 4 em OS nữa. Nên chơi 2GB Ram cho sướng.

cái này chưa chắc đâu nhe, RAM tui có 512 à nhưng tui cài 1 win2k3 128Mb, 1 xp 64mb, 1 minix 32mb chạy phà phà nè smilie

.

KZM wrote:

Thanks bác zorro! Mình đã send, recv được structure mình tạo ra.
Nhưng đến đây mình nhận thấy là việc mỗi kiểu gói tin lại tạo ra 1 kiểu structrure mới có vẻ không hợp lý lắm.
Mình muốn tạo 1 header cho giao thức mới này( có tạm gọi như thế cho oai ). Các bác có thể cho ý kiến giúp đỡ không ạ.
Thứ 2 là mình muốn hỏi là phải thêm những câu lệnh gì để chỉ cần viết 1 lần nhưng có thể biên dịch để chạy trên nhiều OS(cái này mình thấy họ dùng ifdef j` đo',nhưng chưa hiểu lắm).

Vụ "tạo header" thì ông kiếm cái giao thức đơn giản như socks 5, đọc rfc của nó (khoảng vài trang), kiếm 1 socks server trên sourceforge đọc là hiểu.
Còn vụ ông muốn viết code không phụ thuộc vào platform, cơ bản ông có thể làm như hướng dẫn của bạn Zorro, nhưng làm như vậy là thủ công, và đòi hỏi ông phải có access và hiểu rõ những đặc tính của 1 platform, để biết thứ gì platform này có mà platform kia không mà write checks cho đúng. Cách mọi người thường làm là sử dụng bộ GNU Build System như autoconf, automake.

Về phần các structure của ông, ngoài cách của bạn Zorro là pack lại những data chung thành 1 struct. Nếu không muốn nest các struct lại, còn 1 cách nữa là sử dụng writev(). writev() có thể collect data source từ nhiều buffer để write thành 1 khối thống nhất, như ông muốn. Cái này gọi là gather write technique (data được "gather" từ nhiều source để write)

cao kiến thì không có, và Mr.Khoai cũng trả lời hầu hết rồi. Tui chỉ có 1 bổ sung:

Đoạn bạn không hiểu "Time spent blocking in a system call does not count against the process". Các syscalls trong Linux có thể chia làm 2 cat: blocking và non-blocking, ví dụ các blocking syscalls như là read(), recv(), recvfrom(), tổng quát hơn là recvmsg() là blocking syscalls, vì 1 process gọi những hàm trên không có cách nào để biết khi nào data available for reading. Ví dụ 1 server khi gọi 1 hàm trên khi có 1 client connect tới, nếu client chỉ ngồi đó k0 provide gì hết thì các hàm trên không return thứ gì cho server. Process khi đó được gọi là blocking. Điểm quan trọng liên quan tới scheduler là 1 blocking process sẽ KHÔNG bị đặt trở lại vào run queue, cho tới khi nó bị preempted bởi scheduler. Do đó quãng thời gian này không được tính vào user time, hoặc system time, mà tính vào tổng quãng thời gian tồn tại của process.

>>minhquan: win là closed source nhưng khoảng 3,4 năm trước đây, source của win2k đã từng bị leak 1 phần. Vụ này ku xillwillx admin của illmob bị bắt vì bán source, tui biết đồng chí này lúc nó còn tham gia governmentsecurity.org và 1 số forum trojan lúc đó. Bạn công khai tìm kiếm những thứ như vậy thì nên tham khảo tính hợp pháp của nó, không thì có ngày mang vạ đấy.

>>ThangCuEm: source của anh là bộ source leaked đó luôn hay từ nguồn khác, vì bộ source bị leaked chỉ khoảng 400mb, mà toàn là ba cái gì đâu không.

Ai muốn nghiên cứu sâu về system programming có lẽ nên tìm đọc cuốn "Microsoft Windows Internals" của Russinovich và Solomon. Riêng win2k thì có cuốn "Inside Microsoft Windows 2000" cũng của 2 vị này luôn.

chào FaL,

1 cách mì ăn liền trên Windows là sử dụng Outpost Firewall, set cái Blacklist, đặc filter. Ví dụ đặc filter những site chứa chữ "pussy" chắc cũng cấm được 90% xxx smilie

không phải đâu khoai,

những option đó hoàn toàn set được sử dụng setsockopt(). Ở đầu nhận cũng có thể nhận được nó qua getsockopt(), bên cạnh các option thường gặp như SO_KEEPALIVE, SO_REUSEADDR mà khoai nói. Do đó nếu ở A set nó, đầu B có thể reply lại sử dụng source routing bằng cách reverse ip list

hừm, A send packet tới B sử dụng source routing, tới B thì B không "thiết lập", mà nó "đọc" giá trị các options, A setsockopt(), B getsockopt()

Bạn tracert dĩ nhiên là các giá trị không đúng, vì tracert từ B tới A đâu chỉ thị source routing ?

source routing là khi bạn muốn intermediate router không lookup routing table để forward packet, mà sử dụng list các ip build trong ip header để send, do đó để làm được source routing trong môi trường có intermediate router, yêu cầu có
- router phải enable source routing
- bạn phải biết chính xác ip của các router thuộc path A-B, và build list đó tuần tự từ A tới B, ở đây chia thêm 2 trường hợp nữa
+ loose source and record routing: nếu IP_OPTIONS value là IPOPT_LSRR thì dọc đường có thể packet pass vài router trung gian không nằm trong list, nhưng bắt buộc phải pass đủ các node trong list trước khi tới B
+ strict source and record routing: IP_OPTIONS value là IPOPT_SSRR thì bắt buộc packet phải pass qua chính xác các node trong list, không thêm thắt gì, do đó các router trung gian phải là directly connected theo đúng trình tự source route

Việc A set IP_OPTIONS thì packet nhận ở B cũng có IP_OPTIONS tương ứng, nhưng việc B reply lại cho A thì lúc đó còn tùy B có set IP_OPTIONS không.

#which gcc
/usr/local/sbin

bash-3.00# echo $CC
/usr/local/bin/gcc

Sao lúc thì lúc thì gcc nằm ở chỗ này, lúc thì ở chỗ kia thế, cài multi version à ?

Compile không được cả helloworld.c là tại cái gcc của ông
Kiếm mà không thấy là do tự cài gcc thiếu gói libiconv, nếu vậy thì vào đây, chọn đúng cái platform máy ông (intel/sparc/i386), kiếm cái gói libiconv-1.xx-sol10-$platform$-local.gz về cài thêm vô
ftp://ftp.sunfreeware.com/pub/freeware/

ông cat và post config.log lên đây
thử "echo $CC" xem
thử compile 1 "hello world" program xem.
thử luôn "grep CFLAGS Makefile" và post lên đây

Lối này do nhiều thứ
vd: CFLAGS, gcc version mismatched, thiếu assembler/linker (version mismatched chẳng hạn)

đúng:

[rcrackvn@slackware: /usr/local/src/fuse-2.5.3]$ echo $CFLAGS
-Wall -W -g -O2
[rcrackvn@slackware: /usr/local/src/fuse-2.5.3]$ make
Making all in kernel
make[1]: Entering directory `/usr/local/src/fuse-2.5.3/kernel'
gcc -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -pipe -msoft-float -I/usr/src/linux-2.4.34.2/include -I. -D__KERNEL__ -DMODULE -D_LOOSE_KERNEL_NAMES -DFUSE_VERSION=\"2.5.3\" -c dev.c -o dev.o
......................
.....................

CFLAGS sai:

[rcrackvn@slackware: /usr/local/src/fuse-2.5.3]$ export CFLAGS="asd"; echo $CFLAGS
asd
[rcrackvn@slackware: /usr/local/src/fuse-2.5.3]$ ./configure
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/ginstall -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... /usr/bin/gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.

CFLAGS đúng nhưng thiếu linker (or assembler)

[root@slackware: /usr/local/src/fuse-2.5.3]# mv /usr/bin/ld /root/Desktop
[root@slackware: /usr/local/src/fuse-2.5.3]# ./configure
checking build system type... i686-pc-linux-gnuoldld
checking host system type... i686-pc-linux-gnuoldld
checking target system type... i686-pc-linux-gnuoldld
checking for a BSD-compatible install... /usr/bin/ginstall -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... /usr/bin/gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.

ps: kêu help thì post đại lên, ai biết được thì help chứ đừng thêm vô 3 cái chữ cao thủ nghe phản cảm quá.

export CC=`which gcc`

mingw dw2 patch post trên gnu-patches tháng 05/07. Tui không có mingw nên không test, hope it works for you.
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg02051.html

chào anh conmale
theo em biết thì icmp tunneling đề cập lần đầu tiên trong Project Loki (phrack vol 7, issue #49, file #06).

Còn 1 covert technique nữa là ACK tunneling, (http://www.ntsecurity.nu/papers/acktunneling/)

Nhưng cả 2 cái này đều đòi hỏi phải "own" cái target host trước mà. Nếu chỉ mới "biết" được IP thì chắc chưa đụng được tới 2 thứ này.

mấy cha geek cũng geek vừa vừa thôi, thời buổi này đào đâu ra MSDOS để mà thảo luận. Tui nghĩ ý của OP là làm 1 console app chạy trên 1 DOS emulator

hi,
__u32 là 1 kernel datatype, được define bởi <linux/types.h>. Sở dĩ có lỗi trên vì 1 userspace app include trực tiếp 1 kernel header file (ở đây là if_packet.h). "__u32" chỉ visible only in kernelspace. Có thể hiểu ntn: libpcap include trực tiếp if_packet.h, trong đó có 1 struct

Code:

struct tpacket_auxdata
{
__u32 tp_status;
__u32 tp_len;
__u32 tp_snaplen;
__u16 tp_mac;
__u16 tp_net;
};

có các datatype được define ở 1 kernel header khác là linux/types.h. Các datatype này declared bên trong 1 block bảo vệ bởi __KERNEL__ macro, gcc khi compile 1 userspace app sẽ ignore những thứ được protect bên trong '#ifdef __KERNEL__ ... #endif' block.

Giờ có 4 cách giải quyết:
- typedef thẳng các datatype trên trong kiểu như 'typedef unsigned int __u32' trong app của mình
- copy header file sang 1 file .h nào đó, redeclare lại cái struct trên kiểu như

Code:

struct tpacket_auxdata
{
unsigned int tp_status;
unsigned int tp_len;
unsigned int tp_snaplen;
unsigned short tp_mac;
unsigned short tp_net;
};

rồi include file đó thay vì file linux/if_packet.h

- edit makefile lại và thêm vào compiler option -D_KERNEL_
- include 1 userspace header file khác là glibc

Code:

#ifdef HAVE_NETPACKET_PACKET_H
# include <netpacket/packet.h>

ở đây glibc's packet.h cũng chẳng làm việc gì khác ngoài việc include linux/if_packet.h, nhưng ngoài ra nó abstract các kernel datatypes để chúng visible ở userspace.

Còn về phiên bản mới lỗi, phiên bản cũ thì không là vì phiên bản cũ không include kernel header file, nên compile được, nhưng nó thiếu đi 1 tính năng mà phiên bản mới định thêm vào là PACKET_MMAP

http://www.uwsg.iu.edu/hypermail/linux/net/0403.3/0021.html
-------------------------------------------------------------------------------
+ Why use PACKET_MMAP
--------------------------------------------------------------------------------

In Linux 2.4/2.6 if PACKET_MMAP is not enabled, the capture process is very
inefficient. It uses very limited buffers and requires one system call
to capture each packet, it requires two if you want to get packet's
timestamp (like libpcap always does).

In the other hand PACKET_MMAP is very efficient. PACKET_MMAP provides a size
configurable circular buffer mapped in user space. This way reading packets just
needs to wait for them, most of the time there is no need to issue a single
system call. By using a shared buffer between the kernel and the user
also has the benefit of minimizing packet copies.

Một số thông tin có thể giúp bạn:
1. http://lwn.net/Articles/113349/

When a portion of a kernel header file is found to be needed by user space, it would be placed into a separate file in one of those directories, and the new file would be included into the old one. At this point, the definitions needed by user space will have been separated out, but no visible changes will have been made; user space can still include the old file and get what it needs.

2. proposal của 1 người ở redhat (glibc giải quyết vấn đề trên theo cái này)
http://lwn.net/Articles/113006/
3. 1 thảo luận liên quan tới userspace app behavior khi thấy __KERNEL__ macro
http://lkml.org/lkml/2007/4/19/211

chào bạn,
1. nói tiếp về số 1 ở trên. Tui vẫn cho câu phát biểu của mình không sai. Có thể rephrase lại nó như thế này: "1 layer không biết những thứ được xác định ở layer khác và function ở layer khác". Như tui đã nói ở trên, việc IP header có 1 field là Protocol chỉ giúp cho nó biết chính xác cái PROTOCOL HANDLER để tiếp tục forward những gì còn lại, sau khi nó đã làm xong nhiệm vụ là decapsulate cái ip header. Đó là ý của tui, còn tui nghĩ nếu bạn interpret ý của tui như bài vừa post thì bạn cần đọc lại bài trên của tui.
Mà nói thiệt, không cần refer tui tới 1 tool như hping, nếu muốn tui có khả năng viết 1 tool để craft 1 raw packet như hping. Còn việc protocol ID nào được kernel process, cũng nói với bạn luôn, khỏi test mất công: hầu hết kernel chỉ auto process normal packet có Protocol field value là 1 (ICMP), 2 (IGMP), 6 (TCP), và 17 (UDP) và drop mọi packet khác, trừ phi bạn obtain thẳng raw data từ datalink layer rồi tự process nó, xây dựng custom procol handler để process mấy cái datagram có Protocol field value khác. Đây là điều mà mấy route processor trong mỗi router làm để process routing packets.

Tui quote lại câu mà bạn cho là bạn hiểu đúng ý tui:

như tôi đã nói tôi khẳng định 100% như đã nói ở trên là nếu TCP/IP ko dựa vào trường Protocol, ehternet type hay port thì nó ko tài nào xử lý được gói tin nữa

Tui không hề tuyên bố như thế trong bất cứ post nào của tui trong thread này, bạn có thể dẫn chứng ra nếu tìm thấy. Tui nói là 1 layer chỉ làm đúng chức năng của nó, không cần biết chức năng của layer khác là như thế nào. Network layer sử dụng Protocol field để tiếp tục forward cái decapsulated payload sang cho đúng cái protocol handler, không có nghĩa là nó CÓ KHẢ NĂNG hiểu và làm được những gì cái protocol handler đó sẽ làm.
Bạn có lẽ nhầm lẫn ở chỗ này, việc bạn biết được số điện thoại của nhà mình không làm cho bạn biết được phương thức đánh số của nhà cung cấp (xin lỗi, poor example).

2.

"Bạn bảo TCP/IP Stack chẳng xử lý gì cả vì chẳng biết gì để xử lý ? Nope, HTTP Protocol là gì ? Nó là giao thức nằm trong bộ TCP/IP ở tầng App, nó chính cái cái biêt cách xử lý như thế nào với 1 gói tin có Dst port là 80"

Câu này thì tui để mọi người đánh giá. Bạn đi từ sai lầm này đến sai lầm khác. HTTP có thể sử dụng TCP như là underlying transport protocol, nhưng chẳng có ai cấm việc bạn thay thế TCP/IP bằng IPX/SPX để carry HTTP traffic, HTTP KHÔNG THỂ nhìn thấy cái gì thực sự carry traffic của nó ở lớp dưới. Need proofs ? google thử xem có tồn tại IPX web server không thì biết.
Một điều nữa là việc "xử lý gói tin có DST port 80" không thuộc thẩm quyền của HTTP. HTTP quy ước là quy ước các quy tắc xử lý "nội dung" của gói tin, không phải xử lý TCP info liên quan tới cái gói tin đó. Nói thẳng ra: HTTP biết gì về SYN, ACK, FIN flag, port của gói tin ? Nó có cơ hội nhìn thấy đâu mà xử lý ? Xử lý ở đây là xử lý data nhận được từ kernel IO subsystem hoàn thành tác vụ của nó và notify kernel để copy data từ kernel-space lên user-space.

Bạn đọc hết cái HTTP rfc xem nó có chữ nào là chữ port không ?
http://www.w3.org/Protocols/rfc2616/rfc2616.html

Không tin nữa thì bạn kiếm quách 1 web server code mà nhìn cái core function của nó xem chỗ nào nó hiểu và xử lý Transport layer info. Thứ duy nhất có số 80 chắc chỉ là lúc nó declare server socket. Còn việc thực sự xử lý các network IO liên quan tới socket này không còn thuộc chức năng của web server nữa.

4. Tui cũng đã xác nhận là tui misread bạn vì bạn refer tới TCP/IP MODEL, tui lại hiểu là bạn refer tới TCP/IP layer thuộc về OSI MODEL. Hy vọng bạn cũng do some favor và đọc lại ý của tui. Việc bạn refer tui tới những tài liệu, website "nổi tiếng" thì tui cám ơn bạn, mặc dù thực sự không helpful lắm với tui vì tui đã đọc 3 cái đó từ đời tám hoánh nào rồi.

Liên quan tới Cisco, do bạn đề cập nó trước, và make 1 assumption là tui đã từng học CCNA smilie

nên lậm OSI. Sorry bạn, nhưng cá nhân tui, dù dốt, nhưng cũng đã có cơ hội thảo luận với không ít người tài giỏi khác, nhưng tui không quan tâm tới cái background của họ, tui cũng không bao giờ hỏi, hoặc giả định rằng kiến thức của họ từ cái nguồn nào ra. Việc bạn đã tiếp xúc với bao nhiêu người có CCIE tui cũng chẳng quan tâm, tui quan tâm duy nhất tới cái khía cạnh bạn đưa ra ở topic này, còn bạn học ở đâu để đưa ra thì tui mackeno. Mà nói thiệt với bạn nhé, tui chẳng cần phải nhờ tới 1 "chuyên gia" Cisco để thảo luận với bạn, nếu bạn cứ tiếp tục diễn đạt mức hiểu của bạn về networking như vậy.

Về thái độ thảo luận, hy vọng bạn có thể làm được điều này
- Nếu cho rằng tui đã nói cái gì, vui lòng quote chính xác lại, và diễn dịch lời nói của tui theo cách hiểu của bạn. Điều này giúp tui biết được tui và bạn không đồng ý ở điểm nào trong lời nói của tui, tui sẽ sửa nếu quan điểm của bạn đúng.
- Không nên cho rằng người nào tham gia thảo luận đều là "thắc mắc chỗ nào chứ nói".
- Không nên assume bất cứ điều gì về technical background của người ta.
- Không nên bảo người ta phải nhờ tới "chuyên gia" để tiếp tục thảo luận với mình, bạn hơi tự cao đấy.

Cuối cùng là tui refer bạn đọc về OS concept, về kernel subsystems, để xem bao nhiêu thứ được dùng trong khi implement OSI 7 layers, để biết tới lớp nào thì kernel perform context switch từ userspace sang kernelspace khi handle data to/from network. Bạn học OSI mà không hiểu lớp nào đang được phần nào của kernel handle thì cũng như học vẹt, chả tác dụng gì đâu.

Tui bắt đầu cảm thấy đủ với việc tiếp tục thảo luận trong topic này.

>> OP: về post đầu tiên của bạn
- bạn try to dissect ymsg message nhưng lại không sử dụng ymsg dissector, ethereal report như vậy vì nó sử dụng http dissector để mổ xẻ ymsg traffic.
- bạn cần tìm kiếm thêm thông tin về ymsg protocol để có thể hiểu được nó

Có lẽ bạn cần check thêm 2 thứ sau đây:
- search ethereal-dev mailinglist tìm xem ymsg dissector là thứ gì
- đọc thêm cái này http://www.venkydude.com/articles/yahoo.htm

chúc bạn vui vẻ.

2. Bạn nhầm lẫn: 1 protocol có thể trải dài nhiều layer, nhưng 1 layer không thể hiểu những quy định của layer khác. ARP/RARP có thể có những specification nằm ở 2 layer, nhưng nếu nói vậy rồi cho rằng datalink layer hiểu về những thứ defined ở network layer là trật lất. Nói thẳng ra luôn, trong 1 OS, phần IP trong TCP/IP kernel stack làm gì ? một là logical addressing, 2 là packet routing. Trong những thứ đó, datalink hiểu gì ? Chẳng hiểu gì hết.

- Ví dụ của bạn về sự tồn tại của field 'Protocol' trong IP header không chứng minh được là Network layer HIỂU về những thứ xác định ở Transport layer, nó ở đó chỉ với mục đích là để TCP/IP stack biết đường mà forward cái datagram đó lên đúng cái protocol handler tương ứng. Việc interpret và process data không thuộc về chức năng của nó nữa, nên tui nói nó không hiểu về các định nghĩa của lớp trên là không sai.

- Riêng về ví dụ port của bạn, cũng nói luôn với bạn rằng trong chức năng của TCP/IP stack, TCP không biết/không cần biết những app nào sẽ handle cái data này, những gì nó làm khi nhân được data là tách header ra, notify kernel là data available for reading trong cái socket receive buffer của cái socket descriptor nào đang associate với port đó, ngay bản thân việc read cái data từ cái socket buffer cũng chẳng còn thuộc về phần chức năng của TCP nữa, mà thuộc về IO và virtual file subsystem, chứ đừng nói tới việc TCP biết app nào đã request để open cái descriptor đó, và expect data kiểu gì. Bạn đừng gom luôn chức năng nhiều kernel subsytems lại với nhau và cho rằng đó là chức năng riêng của TCP chứ. Bạn sai khi cho rằng TCP/IP stack xử lý cái header "tiếp theo" sau TCP header. Nó chẳng xử lý gì cả vì chẳng biết gì để xử lý.

3. Tui đồng ý ở điểm này, sở dĩ có sự tranh luận ở bài trên vì tui nghĩ bạn đang refer tới 2 layer thuộc OSI model. my bad ! btw, có lẽ bạn không cần phải mở mang cho tui về các mailling list, tui frequent những maillist như vậy từ lâu lắm rồi.

4. Những giao thức vừa kể không phải là hỗ trợ thêm, mà chúng predate OSI, chúng không còn được sử dụng nhiều vì thiếu những đặc điểm của OSI, đặc điểm quan trọng nhất có lẽ là không phân biệt rõ ràng giới hạn chức năng của 1 layer, dẫn đến khó khăn cho 3rd-party vendor khi develop 1 product để interoperate với 1 product trước đó. Nếu bạn vẫn cho rằng OSI không make clear separation giữa các layer, chứng tỏ bạn vẫn chưa nắm được nguyên nhân ra đời của OSI. Bạn nghiên cứu về networking bao lâu để nói như vậy ?

1. Còn riêng về việc bạn muốn biết tui học networking ở đâu thì xin trả lời sơ sơ, tui self-trained, chả có cisco ciskiet nào cả, và cũng self-employed luôn. Cũng nhân tiện xin bạn rút lại những lời cho rằng dân học cisco thì lặm OSI, bởi vì theo tui biết, cisco là biggest vendor về networking hardwares, và nó nếu cisco không hỗ trợ nhiều networking model thì chắc cũng chẳng ai hỗ trợ nhiều cả. Đừng nên claim cái gì mà mình không biết, kẻo dân học cisco chính gốc lại vào gây chuyện đấy.

1. Tui không rõ bạn nghĩ chữ ngôn ngữ như thế nào nên mới hỏi lại. Tui không make any statement rằng bạn không hiểu chữ ngôn ngữ. Protocol thiếu nhiều đặc tính của 1 ngôn ngữ nếu nói về khía cạnh linguistic, chính xác hơn nó được định nghĩa là tập hợp những "quy ước" về giao tiếp.

2. Ở khái niệm "đường dây mạng" KHÔNG tồn tại khái niệm packet. OSI make clear separation giữa các layer mới nhau, layer này hoàn toàn không biết và không cần thiết phải biết tới những gì định nghĩa ở layer khác. Khái niệm "đường dây mạng" của bạn nằm ở tầng mấy của OSI ? Khái niệm packet nằm ở tầng mấy của OSI ? Nên nói "packet đi trên đường dây mạng là tín hiệu điện" liệu có chính xác ? Nếu bạn đã không phân biệt rõ ở chỗ này, dĩ nhiên bạn sẽ không phân biệt rõ giữa cái gì khái niệm 1 packet và khái niệm 1 "view" của nó, bởi vì 2 khái niệm này nằm ở 2 tầng khác biệt nhau của OSI.

Do vậy, ý tui muốn phản bác với bạn nằm ở câu này trong bài post trên của bạn: "Bộ có packet nào ko phải là mã hexa à". Bởi vì ở đây, bạn cho rằng 1 packet (khái niệm ở Network layer) và cái nội dung in vào mắt mình (Application layer) làm một. Và do đó tui make 1 statement là "Hoàn toàn có thể code 1 sniffer để hiển thị NỘI DUNG của packet dưới dạng khác hex".

Và ý cuối cùng của bạn cũng có cái đáng để nói:
- Có vẻ bạn cho rằng TCP/IP là bộ network protocol duy nhất. Điều này bạn xem lại nhé, tui đưa thêm vài thứ cho bạn tham khảo: APPLETALK, DECNET, thậm chí là NETBEUI, tất cả đều là network protocol suite.
- OSI chứa TCP/IP, TCP/IP là 1 phần của OSI, nói cái này là "hoạt động thực sự", cái kia là "chuẩn" để tham khảo là sai, cả 2 đều là chuẩn.

edited: tui vừa post xong thì hình như bạn edit lại post của mình, nên tui quote tiếp phần này

vietwow wrote:

Còn hexa ở trên là do các chương tình sniffer & analyer Ethereal hiển thị. Như vậy thì việc hiển thị hexa hay decinmal hay ASCII là do chương trình sniff sử dụng quy định chứ ko phải là do "packet content" như bạn nói

- Phần tô đậm là bạn lặp lại ý của mình ở trên, vui lòng xem lại
- Vui lòng xem lại luôn là tui nói ở đâu trong bài post trước là "packet content là hex" ? Người nói ý đó là bạn, khi cho rằng "Bộ có packet nào ko phải là mã hexa à " và tui phản bác lại chính ý đó.

vietwow wrote:

Bạn ko thấy 2 dấu trong ngoặc hay là giả vờ ko thấy vậy ? Ngôn ngữ ở đây chính là protocol (đừng nói với tôi protocol ko phải ngôn ngữ nhá :lol ). Mã hex lù lù thì sao ? Bộ có packet nào ko phải là mã hexa à ? Cho dù là SSL hay VPN hay SSH mã hoá hay có qua cả chục protocol khác thì sniff lên đều ra mã hexa thôi, nếu bạn tìm được cái packet nào sniff lên mà ko phải là mã hexa thì xin up lên đây, tôi xin bái bạn làm sư phụ

Lần sau tìm hiểu kỹ TCP/IP rồi hãy nói nhé

bạn tìm hiểu tcp/ip kỹ chưa mà khuyên người ta ?
1. Theo ngữ cảnh của bạn, "ngôn ngữ" là gì ?
2. packet chẳng mắc mớ gì tới hex hay cái gì gì hết. packet PAYLOAD được hiển thị ở dạng hex thì khả dĩ (bởi vì packet không chỉ gồm nội dung, vậy những thứ liên quan tới header có được ethreal hiển thị dạng hex không ?, rõ ràng là không!). Khái niệm packet được define ở OSI Network layer, hex/bin/dec là cách application interpret cái view của mình tùy theo packet content. Ethereal display packet payload ở dạng hex, không có nghĩa là không có ai có quyền code cái packet sniffer hiển thị thông tin sniff được ở dạng bin, octal hay cái gì khác.

>>tphong: tui thắc mắc:
- nếu ids check mọi traffic để match 1 signature nào đó, chuyện gì sẽ xảy ra nếu signature đó nằm ở payloads của 2 packet khác nhau. trojan coder đủ thông minh để bypass ids kiểu này. Còn nếu ids phải resemble mọi packet trước khi check signature, vậy đòi hỏi hardware utilization cao hơn là cái chắc, chưa kể delay time sẽ tăng đáng kể. Không hiểu cái ids bạn đề cập hoạt động thế nào nhỉ ?

>>thangdiablo: cái tui muốn đề cập dưới đây chỉ là giải pháp thêm vào, không thể replace hoàn toàn các giải pháp của những bạn khác:
- bạn thử deploy snort với clamav preprocessor đặt nằm sau border gateway xem. Lợi ích là nó rẻ, cả snort và clamav đều là opensource. Bạn có thể code 1 preprocessor hoạt động với bất kỳ AV, không chỉ clamav. response cũng có thể control thông qua flexresp, thay vì AV. AV dễ bị false alarm, với critical system thì 5% nhầm lẫn dẫn đến 5% dataloss theo kiểu "you are probably (not) a virus, i will kill my connection to you" của AV. Ưu điểm thứ 2 là bên cạnh AV functionality, bạn có thể deploy các kiểu detection/protection khác với snort.
- khuyết điểm thì như nói ở trên, snort là 1 ids tốt, nhưng không phải là perfect, vẫn bị bypass bởi các ids bypass technique.
- nếu bạn muốn thử, thì check bleedingsnort.com, bản patch clamav preprocessor với snort 2.6.0.2 http://www.inliniac.net/blog/?p=47

chết cười với cái code trên

/* begin of my comment-whoring */
* the following few lines are there to serve only one purpose: wasting precious internet resource

- "127.0.0.23" chắc hẳn làm code mình "cool" hơn và type nhanh hơn "127.0.0.1"
- không có khái niệm gì về perror(), viết nguyên cái 'static void bail' smilie

, sử dụng 1 hàm anh em với perror() là strerror()
- author là comment-whore, comment ngay cả những thứ hiển nhiên. close(s) cũng đi comment là "Close the socket and exit" smilie

. Nếu e-paper được làm từ e-tree thì ku này mang tội hủy hoại e-tree smilie

-

>> nil: OP không có ý đó, tui nghĩ ý của OP là làm sao remove cái restriction khi sử dụng dùng xp sp2 để làm terminal server, vì mặc định xp sp2 chỉ cho 1 terminal session, nghĩa là nếu có ai đó đang logged in, 1 người khác remote vào thì user đang logged in phải logout.

>>OP: nếu tui hiểu đúng như vậy, thì bạn dl patch sau: 'sala terminal server patch'
http://www.kood.org/terminal-server-patch/

tui từng apply trên máy mình thì thấy ok, hy vọng nó work đối với bạn