User Controls
Options For Attacking A Web Server That Aren't Web Application Related
-
2017-02-02 at 1:43 AM UTC
Originally posted by SBTlauien Guess I'm going to have to start learning about some these tools(Metasploit specifically). Bufferoverflows as well.
reading about buffer overflows is a good idea because it'll give you a lot to think about in terms of the way the CPU handles memory and how exploit code actually works
in a practical sense though, it's not something that's generally of great use against a webserver. memory attacks are much easier to execute locally to elevate privileges, and a lot has been done over the years to mitigate their potential.
most processors nowadays support the NX bit, marking memory as No eXecutable, meaning that you can't dump exploit code there and have the processor pick it up. software protections like DEP do similar; stopping execution of certain segments of memory (where data buffers are typically stored), ASLR randomises memory addresses so it makes it very difficult to know where to jump to once you've injected your code... there are a few ways around the protections, returning to core libraries etc (see: return oriented programming or return to c), but it's a lot more complicated than it was a decade or two ago and situations where it's effective are a lot more limited -
2017-02-02 at 3:43 AM UTC
-
2017-02-02 at 6:08 AM UTC
Originally posted by -SpectraL You left out the fact that the 8 attempts per IP is not permanent. I could cycle through the IP addresses again and again.
Well that's true. Would you like me to redo the prior calculation but replacing the latency figure with the minimum possible amount of time between consecutive failures an address can average? Because it's like thousands of times higher. -
2017-02-02 at 12:03 PM UTC
Originally posted by Lanny Well that's true. Would you like me to redo the prior calculation but replacing the latency figure with the minimum possible amount of time between consecutive failures an address can average? Because it's like thousands of times higher.
Sure. Let's see it. -
2017-02-02 at 4:18 PM UTC
Originally posted by -SpectraL Sure. Let's see it.
You get 3 attempts in 10 minutes with a ban time of 30 minutes meaning it's faster to stay under the ban than keep hitting it so you get one attempt per IP per 3min 33sec for 7.121×10^301 years average time to brute force. Assuming you controlled 100% of the IPv6 address space and can run every address on this schedule in parallel (lol) the figure comes down to 2.093×10^263 years. -
2017-02-02 at 4:23 PM UTCoh, I left the 8 figure in there so it's actually 8 times longer than that but it hardly seems to matter at this point
-
2017-02-02 at 5:32 PM UTC
Originally posted by Lanny You get 3 attempts in 10 minutes with a ban time of 30 minutes meaning it's faster to stay under the ban than keep hitting it…
No, no, no, kid. I wouldn't "stay under the ban" at all. If I have three permitted attempts before being banned, I will use all three attempts, and then the IP will become banned. Then I will move to the next IP and try three more times, and so on. That's the fastest way. And if the IP is banned for 30 minutes, that is inconsequential, because I will already have moved on to the next unbanned IP. Once I reach the limit of all my available unbanned IPs, the 30 minutes will have passed, and the once-banned IPs will have already been unbanned. I didn't just fall off the turnip truck last night, you know.
-
2017-02-02 at 6:37 PM UTC
Originally posted by -SpectraL No, no, no, kid. I wouldn't "stay under the ban" at all. If I have three permitted attempts before being banned, I will use all three attempts, and then the IP will become banned. Then I will move to the next IP and try three more times, and so on. That's the fastest way. And if the IP is banned for 30 minutes, that is inconsequential, because I will already have moved on to the next unbanned IP. Once I reach the limit of all my available unbanned IPs, the 30 minutes will have passed, and the once-banned IPs will have already been unbanned. I didn't just fall off the turnip truck last night, you know.
You completely misunderstood the math. The last figure is how long it would take you to use every IP in the world and in parallel at the fastest possible rate with no network latency. What you don't seem to grasp is the biggest part of the time here is the keyspace, not the banning strategy. Like I said in my first post, if I never banned an ip address and you were able to continuously try at a rate of one attempt per 50ms (about as low network latency as you could possibly hope for) per computer, and you used 2^128 computers in parallel (the number addressable, and vastly more than exist in all the world today) it would still take you hundreds of orders of magnitude longer on average than the universe has existed to bruteforce the ssh login. -
2017-02-02 at 6:40 PM UTCThanks encryption!The following users say it would be alright if the author of this post didn't die in a fire!
-
2017-02-02 at 8:45 PM UTC
Originally posted by Lanny You completely misunderstood the math. The last figure is how long it would take you to use every IP in the world and in parallel at the fastest possible rate with no network latency. What you don't seem to grasp is the biggest part of the time here is the keyspace, not the banning strategy. Like I said in my first post, if I never banned an ip address and you were able to continuously try at a rate of one attempt per 50ms (about as low network latency as you could possibly hope for) per computer, and you used 2^128 computers in parallel (the number addressable, and vastly more than exist in all the world today) it would still take you hundreds of orders of magnitude longer on average than the universe has existed to bruteforce the ssh login.
Errr.. how long has the universe existed? -
2017-02-02 at 9:50 PM UTC
Originally posted by -SpectraL Errr.. how long has the universe existed?
13.7 Billion years give or take. -
2017-02-02 at 10:16 PM UTCWhat would the equation be when using multiple field-programmable gate arrays?
-
2017-02-03 at 2:35 AM UTCThe lack of SSL would be a good place to start, but that's only worth what a single account is worth, probably less valuable than a facebook account.
Breaking RSA/DSA/EC will never happen, even if lanny used something supposedly insecure like 512 bit RSA it would be way to difficult to crack. -
2017-02-03 at 2:50 AM UTC
Originally posted by -SpectraL What would the equation be when using multiple field-programmable gate arrays?
FBI knocking on your door -
2017-02-03 at 2:57 AM UTC
Originally posted by aldra FBI knocking on your door
I better get my ultra-violet lamp out then. :) -
2017-02-03 at 4:10 PM UTC
Originally posted by -SpectraL What would the equation be when using multiple field-programmable gate arrays?
Exactly the same, an FPGA doesn't do anything for network latency -
2017-02-03 at 4:12 PM UTC
Originally posted by Lanny Exactly the same, an FPGA doesn't do anything for network latency
How about ultra low latency FPGAs? What's the equation then? -
2017-02-03 at 4:43 PM UTCwhat is an ultra low latency fpga spectral?
-
2017-02-03 at 4:59 PM UTC
Originally posted by Lanny what is an ultra low latency fpga spectral?
Real-Time FPGA Numerical Computing for Ultra-Low Latency High Frequency Trading (ULL-HFT)
Khaled Aly, Technical Author & Research Analyst
2/18/2015 03:55 PM EST
2 comments post a comment
NO RATINGS
1 saves
Login to Rate
inShare38
Emerging capital market high-frequency trading (HFT) is bringing strong FPGA use cases in networking, messaging, and financial computing acceleration.
This article is a sequel to my previous column: Introducing FPGA-Based Acceleration for High-Frequency Trading. This new column elaborates on the merits of Decimal Floating Point Arithmetic (DFPA) acceleration and presents a numerical computing model for ULL-HFT (Ultra-Low Latency High Frequency Trading) environments, developed while I headed Technical Business Development at SilMinds, Inc. A use case synopsis is as follows:
The ongoing struggle to minimize "slippage" -- which is broadly defined as the latency between the instances of trader order execution and transaction actualization at the exchange -- with consequent uncalculated monetary variations motivates HFT technology towards a theoretical 'zero-latency' objective. Conventional approaches such as exchange proximity hosting, colocation, hardware ticker plants, and lossless LAN switches have been superseded by deploying FPGA acceleration to offload network and application protocols, and to run trader processes such as portfolio order and execution management. The merit for intense, real-time numerical computing of hundreds of financial indicators and/or indices at sub-millisecond tick rates is often associated with decimal accuracy compliance requirements.
Decimal Floating-Point Arithmetic (DFPA) in a nutshell
Binary Floating Point Arithmetic (BFPA) runs efficiently in native processor hardware, but is unable to accurately represent/maintain decimal real numbers. This is because 1/2 + 1/4 + 1/8 + ... does not cover the entire decimal fraction numeric space; in fact, even the decimal quantity of 0.1 cannot be accurately represented. The choice of whether, and how, to implement decimal real number accuracy is left up to the software developer. The statistical nature of most trading computations inherently affords higher tolerance to binary real number inaccuracies than deterministic financial applications (e.g., banking). However, financial regulations and some algorithmic and operational considerations may require DFP encoding and arithmetic.
Approaches to maintain DFP accuracy include the following:
Deploy server platforms with DFPA processor support, such as the IBM Power and Oracle SPARC, which support basic operations like addition and multiplication in hardware and build the more demanding operations algorithmically in software.
Scale up all real numbers to integers, perform all-integer computations, and then down-scale them before they are passed to other processes. This approach results in poor code management, especially among non-uniform precisions, possibly reaching 14 places beyond the decimal point (Ref: S&P Dow Jones Indices, "S&P Global 1200 Methodology," Apr. 2011).
Use software DFPA libraries, such as the Intel Math Decimal Floating Point Library, and bear with the consequent computational latency.
In order to address this issue, SilMinds offers a patented, extensively-verified, 64/128-bit IEEE 754-2008 standard compliant DFPA IP units library that covers operations like division, power, square rooting, and indexed summation. Units internally employ the hardware-efficient BCD-like DPD (Densely Packed Decimal) encoding, but their I/O interfaces support the more compact software-oriented BID (Binary Integer Decimal) and ASCII "string"-based encodings.
Real-time out-of-band numerical computing model
Many algorithmic traders choose to conduct real number arithmetic in a software DFP form or workaround, and then bear with the undesirable increased slippage. By comparison, with currently available FPGA clock rates, the SilMinds library offers order of nanosecond DFPA operations.
Integrating "performance costly" cross conversions from/to computation-agnostic "string" number representations of standard Financial Information exchange (FIX) and other legacy proprietary protocols with DFPA units is a major value added. Since BFPA units are available at low cost and small area, thanks to their ubiquitous use as DSP blocks, it is easy to optimize FPGA utilization with a combination of integer, BFP, and DFP arithmetic units.
The out-of-band model comprises real-time hardware numeric computation of any number of indicators and/or indices using string-to-DPD values passed by the FIX decoder -- all within the tick period so that resultant decimal values become accessible in a pre-allocated RAM space by the following tick to be simultaneously used by all algorithms that may be implemented in an arbitrary combination of software and hardware. DFPA engines can be integrated with network stack offloads on a single FPGA or on a multi-FPGA PCI-e card employing the appropriate amount of parallelism to meet the desired frequency.
Benchmarking has proved that hardware DFPA yields accurate, jitter-free speed-up as high as 1000X woth respect to optimized software; implying sub-microsecond operation run time, hundreds-to-thousands as many operations per "future-proof" tick (one second to a microsecond), and/or deeper moving averages across arbitrarily larger number of securities (symbols). While most exchanges currently publish trade prices at millisecond ticks, trader algorithms may require sub-microsecond rate computations to control slippage.
The following generically portrays three use cases of the described model:
-
2017-02-03 at 9:53 PM UTCSocial engineering is still the best method, get Lanny's dox, ring up his Server host, or domain provider and SE your way in.The following users say it would be alright if the author of this post didn't die in a fire!
