aelius

Inca 7 zile ban, de la nasu mare

Am sters toate posturile aiurea + un warn si am redeschis threadul. E categoria RST Market, daca va trebuie, vorbiti cu omul si nu comentati aiurea ca va ard pe rug

Am sters toate posturile aiurea + un warn si am redeschis threadul. E categoria RST Market, daca va trebuie, vorbiti cu omul nu comentati aiurea ca va ard pe rug

Omule, un router bunicel costa 15.000 euro. Tu vrei sa-ti faci datacenter cu 8000 ?

@x00x: Ai dreptate, se fac abuzuri peste tot dar nu trebuie sa fim limitati si sa gandim asa. Iti spun din experienta, am avut parte de multe abuzuri din partea lor. Prezenta oamenilor care lucreaza in diverse structuri ale statului (SRI, MAI, etc) cred ca este binevenita la orice conferinta ce are legatura cu securitatea informatica. Chiar asta este si ideea, sa vada diferenta dintre un expert in securitate informatica (sa-i spunem generic: hacker) si un infractor care se uita sa fure banuti sau sa sparga diverse retele aiurea. Eu nu vin la DefCamp din alte motive dar va recomand sa mergeti. Aveti ocazia sa cunoasteti oameni buni si sa discutati multe.

Asa i-a invatat sistemul comunist. - Esti sysadmin si ai instalat apache + php + mysql pe un server abia instalat ? Pai esti vinovat, tu stii ca proprietarul serverului a facut spam de pe el ? - Scrii tutoriale si faci cursuri pentru elevi si studenti ? Pai nene, ala e site de hacking. - De ce folosesti linux si nu folosesti si tu windows ca toata lumea ? - Inculpatul avand o foarte buna pregatire tehnica constituie un real pericol pentru ordinea si linistea publica. - Am gasit instalata aplicatia NMAP ! Si da, sunt chestii reale, toate.

Sunt mai aberante legile in SUA de 1000 de ori fata de Romania.

Ce dracu ma, chiar la noi veniti cu rahaturi deastea ieftine?

Ai un pipe acolo in loc de argument awk -F "@" '{print $2}' | sort --unique > lista.txt

1. Solutie Pentru a le vedea: awk -F "@" '{print $2}' lista.txt Pentru a le salva: awk -F "@" '{print $2}' lista.txt > domenii.txt 2. Exemplu Am o lista: marian@hp:~$ cat lista.txt ion@hotmail.com george@usinternet.com vasile@yahoo.com Vreau sa vad doar domeniile: marian@hp:~$ awk -F "@" '{print $2}' lista.txt hotmail.com usinternet.com yahoo.com Vreau sa salvez domeniile in fisierul domenii.txt: marian@hp:~$ awk -F "@" '{print $2}' lista.txt > domenii.txt Au fost salvate: marian@hp:~$ cat domenii.txt hotmail.com usinternet.com yahoo.com

Este vorba de CVE-2013-1775 doar ca e cam prost explicata in acel PDF. Vulnerabilitatea este din 2013. Adaug userul marian in sudoers si verific daca este ok: root@hp:~# echo "marian ALL=(ALL:ALL) ALL" >> /etc/sudoers root@hp:~# grep marian /etc/sudoers marian ALL=(ALL:ALL) ALL Incerc intr-un terminal: marian@hp:~$ sudo su - [sudo] password for marian: root@hp:~# La cateva secunde, incerc in al II-lea terminal. Se pare ca-mi cere iar parola. marian@hp:~$ sudo su - [sudo] password for marian: Functioneaza pe versiunile 1.6.0 - 1.7.10 Mai multe detalii aici: - Authentication bypass when clock is reset - CVE - CVE-2013-1775 

Dincolo era mai ieftin; Da-l ma si tu GRATUIT la un student de aici; Macar o fapta buna sa faci in viata ta mizerabila ))))

E al lu Radu Tofan (si in spate se afla Eugenie Staicut, bosorogul de la RoTLD care nu mai vrea sa moara odata). Manereli cu domenii si srl-uri capusa.

E categorie Off-topic -> Non-IT; si invatati sa folositi EDIT la futaiu de post.

Salutari, Am un BlackBerry Curve 8520 si nu-mi vede sim-ul din alta retea. Cum nu-mi place sa fac pe meseriasul si ma ocup de altele las sa faca altul treaba. Simplu: Trimiteti mesaj privat cu ce detalii aveti nevoie + adresa de paypal si costul. Multumesc

Hai sictir

There is special type of DDoS attacks, application level DDoS, which is quite hard to combat against. Analyzing logic which filters this type of DDoS attack must operate on HTTP message level. So in most cases the logic is implemented as custom modules for application layer (usually nowadays user space) HTTP accelerators. And surely Nginx is the most widespread platform for such solutions. However, common HTTP servers and reverse proxies were not designed for DDoS mitigation- they are simply wrong tools for this issue. One of the reason is that they are too slow to combat with massive traffic (see my recent paper and presentation for other reasons). If logging is switched off and all content is in cache, then HTTP parser becomes the hottest spot. Simplified output of perf for Nginx under simple DoS is shown below (Nginx’s calls begin with ’ngx’ prefix, memcpy and recv are standard GLIBC calls): % symbol name 1.5719 ngx_http_parse_header_line 1.0303 ngx_vslprintf 0.6401 memcpy 0.5807 recv 0.5156 ngx_linux_sendfile_chain 0.4990 ngx_http_limit_req_handler The next hot spots are linked to complicated application logic (ngx vslprintf ) and I/O. During Tempesta FW development We have studied several HTTP servers and proxies (Nginx, Apache Traffic Server, Cherokee, node.js, Varnish and userver) and learned that all of them use switch and/or if-else driven state machines. The problem with the approach is that HTTP parsing code is comparable in size with L1i cache and processes one character at a time with significant number of branches. Modern compilers optimize large switch statements to lookup tables that minimizes number of conditional jumps, but branch misprediction and instruction cache misses still hurt performance of the state machine. So the method probably has poor performance. The other well-known approach is table-driven automaton. However, simple HTTP parser can have more than 200 states and 72 alphabet cardinality. That gives 200 x 72 = 14400 bytes for the table, which is about half of L1d of modern microprocessors. So the approach is also could be considered as inefficient due to high memory consumption. The first obvious alternative for the state machine is to use Hybrid State Machine (HSM) described in our paper, which combines very small table with also small switch statement. In our case we tried to encode outgoing transitions from a state with at most 4 ranges. If the state has more outgoing transitions, then all transitions over that 4 must be encoded in switch. All actions (like storing HTTP header names and values) must be performed in switch. Using this technique we can encode each state with only 16 bytes, i.e. one cache line can contain 4 states. Giving this the approach should have significantly improve data cache hit. We also know that Ragel generates perfect automatons and combines case labels in switch statement with direct goto labels (it seems switch is used to be able to enter FSM from any state, i.e. to be able to process chunked data). Such automatons has lower number of loop cycle and bit faster than traditional a-loop-cycle-for-each-transition approach. There was successful attempt to generate simple HTTP parsers using Ragel, but the parsers are limited in functionality. However there are also several research papers which says that an automaton states is just auxiliary information and an automaton can be significantly accelerated if state information is declined. So the second interesting opportunity to generate the fastest HTTP parser is just to encode the automaton directly using simple goto statements, ever w/o any explicit loop. Basically HTTP parsers just matches a string against set of characters (e.g. [A-Za-z_-] for header names), what strspn(3) does. SSE 4.2 provides PCMPSTR instructions family for this purpose (GLIBC since 2.16 uses SSE 4.2 implemenetation for strspn()). However, this is vector instruction which doesn't support accept or reject sets more than 16 characters, so it's not too usable for HTTP parsers. Results I made a simple benchmark for four approaches described above (http_ngx.c - Nginx HTTP parsing routines, http_table.c - table-driven FSM, http_hsm.c - hybrid state machine and http_goto.c - simple goto-driven FSM). And here are the results (routines with 'opt' or 'lw' - are optimized or lightweight versions of functions): Haswell (i7-4650U) Nginx HTTP parser: ngx_request_line: 730ms ngx_header_line: 422ms ngx_lw_header_line: 428ms ngx_big_header_line: 1725ms HTTP Hybrid State Machine: hsm_header_line: 553ms Table-driven Automaton (DPI) tbl_header_line: 473ms tbl_big_header_line: 840ms Goto-driven Automaton: goto_request_line: 470ms goto_opt_request_line: 458ms goto_header_line: 237ms goto_big_header_line: 589ms Core (Xeon E5335) Nginx HTTP parser: ngx_request_line: 909ms ngx_header_line: 583ms ngx_lw_header_line: 661ms ngx_big_header_line: 1938ms HTTP Hybrid State Machine: hsm_header_line: 433ms Table-driven Automaton (DPI) tbl_header_line: 562ms tbl_big_header_line: 1570ms Goto-driven Automaton: goto_request_line: 747ms goto_opt_request_line: 736ms goto_header_line: 375ms goto_big_header_line: 975ms Goto-driven automaton shows the better performance in all the tests on both the architectures. Also it's much easier to implement in comparison with HSM. So in Tempesta FW we migrated from HSM to goto-driven atomaton, but with some additional optimizations. Lessons Learned ** Haswell has very good BPU ** Core micro-architecture has show that HSM behaves much better than switch-driven and table-driven automatons. While this is not the case for Haswell - the approach loses to both the approaches. I've tried many optimizations techniques to improve HSM performance, but the results above are the best and they still worse than the simple FSM approaches. Profiler shows that the problem (hot spot) in HSM on Haswell is in the following code if (likely((unsigned char)(c - RNG_CB(s, 0)) <= RNG_SUB(s, 0))) { st = RNG_ST(s, 0); continue; } Here we extract transition information and compare current character with the range. In most cases only this one branch is observer in the test. 3rd and 4th branches are never observed. The whole automaton was encoded with only 2 cache lines. In first test case, when XTrans.x structure is dereferenced to get access to the ranges, the compiler generates 3 pointer dereferences. In fact these instructions (part of the disassembled branch) sub 0x4010c4(%rax),%bl cmp 0x4010c5(%rax),%bl movzbl 0x4010cc(%rax),%eax produce 3 accesses to L1d and the cache has very limited bandwidth (64 bytes for reading and 32 bytes for writing) on each cycle with minimal latency as 4 cycles for Haswell. While the only one cache line is accessed by all the instructions. So the test case bottle neck is L1d bandwidth. If we use XTrans.l longs (we need only l[0], which can be loaded with only one L1d access, in all the cases) and use bitwise operations to extract the data, then we get lower number of L1d accesses (4G vs 6.7G for previous cases), but branch mispredictions are increased. The problem is that more complex statement in the conditions makes harder to Branch Prediction Unit to predict branches. However, we can see that simple branches (for switch-driven and goto-driven automatons) show perfect performance on Haswell. So advanced Haswell BPU perfectly processes simple automatons making complex HSM inadequate. In fact HSM is only test which is slower on Haswell in comparison with Core Xeon. Probably, this is the difference between server and mobile chips that ever old server processor beats modern mobile CPU on complex loads... -O3 is ambiguous Sometimes -O3 (GCC 4.8.2) generates slower code than -O2. Also benchmarks for -O3 show very strange and unexpected results. For example the below are results for -O2: goto_request_line: 470ms However, -O3 shows worse results: goto_request_line: 852ms Automata must be encoded statically whenever possible Table-driven and HSM automaton are encoded using static constant tables (in difference with run-time generated tables for current DPI parser). This was done during HSM optimizations. Sometimes compiler can't optimize code using run-time generated tables. And this is crucial for real hot spots (for HSM the table is used in the if-statement described above which gets about 50-70% of whole the function execution time) - after the moving to the static data the code can get up to 50% performance improvement (the case for HSM). Source: High Performance Linux: Fast Finite State Machine for HTTP Parsing Refs: - Tempesta FW is a hybrid solution which combines reverse proxy and firewall at the same time. It accelerates Web applications and provide high performance framework with access to all network layers for running complex network traffic classification and blocking modules - http://natsys-lab.com/tpl/tempesta_fw.pdf

Sa-i dam la muie de sobolan de stepa. Thread closed.

Doua servere la preturi f. bune. (fara setup fee) Intel Core i5-3570 @ 3.4 GHz 4 Cores, 4 Threads, 6 MB Cache 32 GB DDR3 Memory 2 x 500 GB SATA [Raid 1 Software] 2 IP Addresses with reverse dns 100 Mbps Guaranteed Monthly traffic: 20 TB Monthly cost: 50 euro Activation time: 10 minutes Haswell Intel CPU Intel i5-4570 @ 3.2 Ghz 4 Core, 4 Threads, 6MB L2 Cache 16 GB DDR3 Memory 1 x 240 GB SSD Force 3 (6Gb/s, 85.000 IOPS) 100 Mbps (to any destination) 20 TB Monthly traffic Monthly traffic: 20 TB Monthly cost: 40 euro Activation time: 10 minutes // edit: i5-4570 s-a dat; Doar primul mai este disponibil. // edit: s-au dat ambele.

Tuning the initial congestion window parameter (initcwnd) on the server can have a significant improvement in TCP performance, resulting in faster downloads and faster webpages. In this article, I will start with an introduction to how TCP/IP connections work with regards to HTTP. Then I will go into TCP slow start and show how tuning the initcwnd setting on the (Linux) server can greatly improve page performance. In our follow-up article we show data on the value of the initcwnd setting for the various CDNs: Initcwnd settings of major CDN providers. Three-way handshake Imagine a client wants to request the webpage Example Domain from a server. Here is an over simplified version of the transaction between client and server. The requested page is 6 KB and we assume there is no overhead on the server to generate the page (e.g. it's static content cached in memory) or any other overhead: we live in an ideal world ;-) Step 1: Client sends SYN to server - "How are you? My receive window is 65,535 bytes." Step 2: Server sends SYN, ACK - "Great! How are you? My receive window is 4,236 bytes" Step 3: Client sends ACK, SEQ - "Great as well... Please send me the webpage http://www.example.com/" Step 4: Server sends 3 data packets. Roughly 4 - 4.3 kb (3*MSS1) of data Step 5: Client acknowledges the segment (sends ACK) Step 6: Server sends the remaining bytes to the client 1. MSS = Maximum Segment Size After step 6 the connection can be ended (FIN) or kept alive, but that is irrelevant here, since at this point the browser has already received the data. The above transaction took 3*RTT (Round Trip Time) to finish. If your RTT to a server is 200ms this transaction will take you at least 600ms to complete, no matter how big your bandwidth is. The bigger the file, the more round trips and the longer it takes to download. Congestion control/TCP Slow Start As illustrated in the video and as you have seen in our example transaction in the section above, a server does not necessarily adhere to the client's RWIN (receivers advertised window size). The client told the server it can receive a maximum of 65,535 bytes of un-acknowledged data (before ACK), but the server only sent about 4 KB and then waited for ACK. This is because the initial congestion window (initcwnd) on the server is set to 3. The server is being cautious. Rather than throw a burst of packets into a fresh connection, the server chooses to ease into it gradually, making sure that the entire network route is not congested. The more congested a network is, the higher is the chances for packet loss. Packet loss results in retransmissions which means more round trips, resulting in higher download times. Basically, there are 2 main parameters that affect the amount of data the server can send at the start of a connection: the receivers advertised window size (RWIN) and the value of the initcwnd setting on the server. The initial transfer size will be the lower of the 2, so if the initcwnd value on the server is a lot lower than the RWIN on the computer of the user, the initial transfer size is less then optimal (assuming no network congestion). It is easy to change the initcwnd setting on the server, but not the RWIN. Different OSes have different RWIN settings, as shown in the table below. OS RWIN Linux 2.6.32 3*MSS (usually 5,840) Linux 3.0.0 10*MSS (usually 14,600) Windows NT 5.1 (XP) 65,535^2 Windows NT 6.1 (Windows 7 or Server 2008 R2) 8,192^2 Mac OS X 10.5.8 (Leopard) 65,535^2 Mac OS X 10.6.8 (Snow Leopard) 65,535^2 Apple IOS 4.1 65,535^2 Apple IOS 5.1 65,535^2 2. Some Operating Systems dynamically calculate RWIN based on external factors. The value here is based on SYN packets sent to CDN Planet. The Win flag can also be increased by the client before the transfer actually starts. A you can see from the table, Windows and Mac users would benefit most from servers sending more bytes in the initial transfer (which is almost everybody!) Changing initcwnd Adjusting the value of the initcwnd setting on Linux is simple. Assuming we want to set it to 10: Step 1: check route settings. sajal@sajal-desktop:~$ ip route show 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100 metric 1 169.254.0.0/16 dev eth0 scope link metric 1000 default via 192.168.1.1 dev eth0 proto static sajal@sajal-desktop:~$ Make a note of the line starting with default. Step 2: Change the default settings. Paste the current settings for default and add initcwnd 10 to it. sajal@sajal-desktop:~$ sudo ip route change default via 192.168.1.1 dev eth0 proto static initcwnd 10 Step 3: Verify sajal@sajal-desktop:~$ ip route show 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100 metric 1 169.254.0.0/16 dev eth0 scope link metric 1000 default via 192.168.1.1 dev eth0 proto static initcwnd 10 sajal@sajal-desktop:~$ Results The entire transaction now happened in 400ms, rather than 600ms. That is a big win and this is just for one HTTP request. Modern browsers open 6 connections to a host which means you will see a faster load time for 6 objects Here is a before and after comparison of accessing a 14 KB file (13,516 bytes transfered ~10*MSS) from across the globe with different settings. It is clear that when initcwnd is larger than the payload size, the entire transaction happens in just 2*RTT. The graph shows that the total load time of this object was reduced by ~50% by increasing initcwnd to 10. A great performance gain! Interested in more info and insight on tuning initcwnd? Read Google's paper An Argument for Increasing TCP's Initial Congestion Window. It's a great resource. Source: Tuning initcwnd for optimum performance - CDN Planet

Merci, am de toate. Dam un ban permanent la Onbuxuser, da-l in ma-sa )

Adica ... ban. Conform regulamenului orice rahat ce faciliteaza intr-un fel sau altul frauda atrage ban permanent. Asa cum ai mentionat, ai blat western union si moneygram. Astea doua nu sunt buticuri cu gogosi calde, sunt institutii ce se ocupa de transfer de bani. Sanatate si drum bun.

Matzo, da-i edit la post cand vrei sa mai adaugi ceva, ai 6 posturi unu dupa altu

))))) Da-l in cacat si pe Ponta si biserica ortodoxa si pe tine. Decat cu un fost procuror cu diplome luate prin spaga mai bine cu un neamt. Cred ca ar fi si mai bine sub ocupatie germana ) Luati pwula dezbatere. Sunt satul de politica.

ce saracia e threadul asta bre ?