[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <705163.61268.qm@web65404.mail.ac4.yahoo.com>
Date: Fri, 14 Jan 2011 08:00:36 -0800 (PST)
From: Aaron <apconole@...oo.com>
To: Nelson Brito <nbrito@...ure.org>, dailydave@...ts.immunitysec.com,
bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Subject: Re: [Dailydave] [TOOL RELEASE] T50 Sukhoi PAK FA
Mixed Packet Injector v2.45r-H2HC
This will be my last post on the thread. You can think I'm trying to troll you
all you want - doesn't mean that is my intent.
The goal, as I understand it, of T50 is to be a software based version of a
SmartBits tester, yes? You aim to saturate a network link with as much traffic
as possible, and that traffic needs to be predictable. In that case, you need to
keep a few important requirements in mind:
1 - if we want to saturate multiple links simultaneously, having multiple
contexts of execution being able to feed multiple network devices would be a
good thing(tm). Additionally, you need a way to measure what's being done on the
link - best way to do that is with a second nic which is able to capture the
packets. Preferably, this is not just done with tcpdump/wireshark and manually
trying to correlate.
2 - You failed to understand what packet_mmap is, or what I meant by checksum
recalculation. Here's a quick logical proof:
a - Time spent working on the packet is time spent not transmitting
b - Time spent not transmitting is time that the network may have to absorb
your attempt at saturation
c - Time spent computing checksums, rebuilding packets from the header, from
the very beginning is time spent working on the packet
d - Time spent memcpy()'ing from userspace to kernel space is additionally,
time spent not transmitting
e - Using these mechanisms (like the packet_mmap tx ring) reduces your latency
for transmission and tries to push the bottleneck as close to the hardware as
possible.
Your code makes at least 2 memcpy()s. Additionally, you don't use the ethtool
IOCTLs to try and increase the actual nic buffers, which I think we can both
agree is just a smart idea.
3 - TCPREPLAY has far more advantage than T50; don't bother trying to deny it.
It floods a link just as well as T50, and since you control the pcap, you
control the packets transmitted - and can do anything with them, not just
whatever options T50 allows. Tcpreplay can also flood with the captured packet's
MAC included, meaning that if you do this to test your network, you can test
your ability to detect which macs/ports can be turned off/on to alleviate an
internal attack. The fact that you can even use real-world packet captures is
just gravy. I can take emacs in hex mode and stamp out a TCP-SYN. Heck, I can
use a packet capture of HPING and have a tcp-syn. Pcaps of interesting traffic
are all over the internet, just use some google-fu. Heck, I can get captures of
3gpp traffic searching google. You have any SCTP generation? Any RRC or NBAP
message flooding? When can I expect T50 to have this functionality? tcpreplay
has it, as long as I have the packets.
4 - You still didn't explain how this isn't just hping --flood? I've gone
through the code - what am I missing? I'm curious - you just decided to attack
me, and call me stupid - I've refrained from juvenile responses. What am I
missing? What power do I get with this tool that I don't already have?
5 - I'm not trying to have you give me, or anyone else credit - and nowhere in
my email did I say such. I, frankly, don't care who gets their name plastered on
what piece of if/then/else code; I do care to evaluate potentially better
network saturation solutions, since that's part and parcel of my day-to-day life
at work (network flood testing). I've used smartbits, tcpreplay, and tried using
T50. It's not even close to either of those tools in terms of features. It
doesn't have any clear advantage, either. I'm just trying to help you not spend
your time re-inventing a wheel that is inferior to readily available ones. You
can take that any way you want.
Regards,
-Aaron
From: Nelson Brito <nbrito@...ure.org>
To: Aaron <apconole@...oo.com>; dailydave@...ts.immunitysec.com;
bugtraq@...urityfocus.com; full-disclosure@...ts.grok.org.uk
Sent: Fri, January 14, 2011 9:10:15 AM
Subject: RE: [Dailydave] [TOOL RELEASE] T50 Sukhoi PAK FA Mixed Packet Injector
v2.45r-H2HC
I do appreciate any feedback, but I've been asking myself if you are really
seriously writing this or just making a joke with all the list members... Did
you bring the TCPREPLAY to this discussion??? I cannot imagine what kind of
unsound mind could bring this comparison.
Two main factors led me to write this message:
1. TCPREPLAY and T50 have different approaches for different goals. How could
you compare T50 to TCPREPLAY? T50 doesn't play with captured files (PCAP), in
opposite T50 does play with its own packets and can be used to feed TCPREPLAY.
2. Do you really think packet_mmap could help any Stress Testing tool (Flooder
and/or Packet Injector) to get a better performance? Delta calculation with
random packet field? Come on... We are talking about different things here,
aren't we?
And lastly, but not least, how could you pretend to do something to get a
high-performance fashion playing with multi-core (multi-thread) if you are still
limited by Kernel's network device queue??? Are you insane???
Please, you don't have to answer any of my questions... Please, don't. It could
be much more embarrassing.
T50 plays in an user level, and this was explained during the H2HC 7th Edition.
The reason I did this is to show that cool things can be done in this space
(user space), with no Kernel patch or Kernel driver module. The concept is not
new, and I didn't say it is. IRC old-school (old is cool [?] =D) will remember
all things I did with this code. T50 is the very first public tool applying
multi-protocol injection using a single socket - AFAIK. That said, how you dare
to compare T50 and TCPREAPLY? I am not a TCPREPLAY expert, but I am not aware of
any feature of TCPREPLAY that makes it able to inject packet without a PCAP
file.
I do refuse myself to enter in another battle, but do you really believe on what
you said?
I will not explain anything else to you, if you want to see the slide-desk, be
my guest:
http://www.slideshare.net/nbrito01/the-hangover-a-modern-high-performance-approach-to-build-an-offensive-computing-tool
BTW, if you really think I have to give you any credit, please, give me
evidences of something I should give credit to you or to anybody else, a credit
other than: "you are an excellent and freaking great Internet troll". Otherwise,
please, just stop trolling me with all your frustration and find something
really interesting to do with your life...
Nelson Brito
Security Researcher
http://fnstenv.blogspot.com/
From: Aaron [mailto:apconole@...oo.com]
Sent: Thursday, January 13, 2011 1:35 PM
To: Nelson Brito; dailydave@...ts.immunitysec.com; bugtraq@...urityfocus.com;
full-disclosure@...ts.grok.org.uk
Subject: Re: [Dailydave] [TOOL RELEASE] T50 Sukhoi PAK FA Mixed Packet Injector
v2.45r-H2HC
I don't see the "wow" factor from this tool? Perhaps I forgot to take my "super
l33t" pills, but I fail to see how this is different from something like
tcpreplay, which not only does any packet(s) desired, but can pull them from an
existing packet capture (and even edit those packets on the fly) allowing one to
truly customize the traffic as much as possible. Additionally, I looked at this
tool hoping for some "exciting" new code, but found nothing which people writing
router / gateway software haven't known for years. In fact, you didn't even do
intelligent checksum recalculation (ie: store a "base" checksum somewhere, and
just do some quick delta calculation on it), and you didn't take advantage of
packet_mmap on linux (zero copy seems like good juju for high-speed network
transmission); HECK you're running from a single context of execution, instead
of trying to execute on all available cores (which could add some scalability,
depending on the architecture).
I don't want to sound like I'm a total negative nancy - and certainly security
is a hobby domain, not my primary area of expertise, but you posted this to a
publicly available forum, so I suppose you were looking for some type of
vetting, criticism, and feedback. My feedback would be to contribute to
tcpreplay. There's nothing that your tool offers as an advantage (from a cursory
glance, your tool appears to be hping --flood) to any available options; there's
nothing unique that I saw.
Additionally, my noscript caught a click-jacking attempt from your homepage when
I went to download the file. I might suggest a better file serving mechanism.
-Aaron
________________________________________
From: Nelson Brito <nbrito@...ure.org>
To: dailydave@...ts.immunitysec.com; bugtraq@...urityfocus.com;
full-disclosure@...ts.grok.org.uk
Sent: Tue, January 11, 2011 2:43:35 PM
Subject: [Dailydave] [TOOL RELEASE] T50 Sukhoi PAK FA Mixed Packet Injector
v2.45r-H2HC
T50 Sukhoi PAK FA Mixed Packet Injector (f.k.a. F22 Raptor) is a tool
designed to perform "Stress Testing". It is a powerful and an unique packet
injection tool, that is capable of:
1. Send sequentially (i.e., ALMOST on the same time) the following
protocols:
- ICMP: Internet Control Message Protocol
- IGMP: Internet Group Management Protocol
- TCP: Transmission Control Protocol
- UDP: User Datagram Protocol
2. Send an (quite) incredible amount of packets per second, making it a
“second to none” tool:
- More than 1,000,000 pps of SYN Flood (+50% of the network’s uplink) in
a 1000BASE-T Network (Gigabit Ethernet).
- More than 120,000 pps of SYN Flood (+60% of the network’s uplink) in a
100BASE-TX Network (Fast Ethernet).
3. Perform “Stress Testing” on a variety of network infrastructure, network
devices and security solutions in place.
4. Simulate Denial-of-Service attacks, validating the Firewall rules and
Intrusion Detection System/Intrusion Prevention System policies.
Further information can be found @ http://fnstenv.blogspot.com (demo video
and source code).
PS: Yes, there are some "anti-kiddo" tricks, so, please, don't blame me for
doing that...
The new version of the "T50 Sukhoi PAK FA Mixed Packet Injector" (v5.2-NG)
will be unleashed on "WEB Security Forum" (http://websecforum.com.br/evento/
/ April 9th-10th 2011 / São Paulo, Brazil).
The next release will include:
1. New License: It is still not licensed under GPL or any other common
Open-source license, but the source code will be available and the use of
any piece of source code for any free or commercial software is denied.
2. CIDR Support: Classless Inter-Domain Routing support for destination IP
address, using a really tiny C algorithm. This would allow the "T50 Sukhoi
PAK FA Mixed Packet Injector" to simulate DDoS in a laboratory environment.
001 netmask = ~(0xffffffff>>cidr);
002 hostid = (int)(pow(2,(32-cidr))-2);
003 __1st_host = (ntohl(addr)&netmask)+1;
004 __lst_host = (ntohl(addr)&netmask)+hostid;
3. TEN NEW Protocols: TEN (10) more protocols supported by "T50 Sukhoi PAK
FA Mixed Packet Injector" (IGMPv3, EGP, DCCP, RSVP, RIPv1, RIPv2, GRE, ESP,
AH and EIGRP).
4. Exotic Protocols: Advanced options and protocol crafting for EIGRP and
GRE were added, allowing users to make any combination while using those
exotic protocols. By the way, EIGRP is a proprietary protocol developed by
CISCO Systems, Inc.
5. TCP Options Support: TCP Options (MSS, NOP, EOL, WSCALE, TSTAMP, T/TCP CC
and SACK) are supported to improve the TCP protocol.
6. DATA Payload Support: The data payload support is back, and it can be
rand or user defined.
Best regards.
Nelson Brito
Security Researcher
http://fnstenv.blogspot.com/
_______________________________________________
Dailydave mailing list
Dailydave@...ts.immunityinc.com
https://lists.immunityinc.com/mailman/listinfo/dailydave
Content of type "text/html" skipped
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists