Forgot your password?
typodupeerror
Security

Black Ops of TCP/IP: Paketto Keiretsu 1.0 Release 319

Posted by timothy
from the read-among-the-lines dept.
Effugas writes "After pushing OpenSSH to perform feats of secure tunneling far beyond what I ever expected it could do, it became clear that some genuinely useful modes of network operation were simply inaccessable without either replacing or manipulating core network protocols. Since the basic infrastructure of the Internet isn't likely to change any time soon, that left...creative manipulation and reconstruction of the Lingua Reseaux: TCP/IP. Taking advantage of expectations, pitting layers against eachother, finding new uses for old options and data fields -- instead of simply unleashing the latest incarnation of some "Ping of Death", could such work unveil hidden functionality within existing networks? As I discussed at Black Hat 2002 and the inimitable Defcon X, the answer is yes. And now, proof of this is ready. BSD Licensed (in deference to the very source of TCP/IP), The Paketto Keiretsu, Version 1.0, is a collection of five interwoven "proof of concepts" that explore, extract, and expose previously untapped capacities embedded deep within networks and their stacks, at Layers 2 through 4. The five -- scanrand, minewt, lc ( linkcat ), paratrace, and the OpenQVIS cross-disciplinary-a-go-go phentropy -- demonstrate Stateless TCP Scanning, Inverse SYN Cookies, Guerrila Multicast, Parasitic Tracerouting, Ethernet Trailer Cryptography, and quite a bit more. (For details, stop by DoxPara Research or check out the latest slides. The academic paper is coming "soon".) In terms of actual usefulness, scanrand is no nmap, but it's still interesting: During an authorized test inside a multinational corporation's class B, scanrand detected 8300 web servers across 65,536 addresses. Time elapsed: approximately 4 seconds."
This discussion has been archived. No new comments can be posted.

Black Ops of TCP/IP: Paketto Keiretsu 1.0 Release

Comments Filter:
  • ...wha? (Score:3, Funny)

    by Anonymous Coward on Monday November 18, 2002 @07:19PM (#4702093)
    ...how I wish Babel Fish would have a Geek->English translation option...

    Anyone here want to sum it up IN PLAIN ENGLISH, without involving beowulf clusters or "Profit!"?
    • Re:...wha? (Score:4, Funny)

      by Anonymous Coward on Monday November 18, 2002 @07:32PM (#4702199)
      1. Set up a Beowulf cluster of secure tunnelers.
      2. Detect thousands of networks in seconds.
      3. ?????
      4. Profit!
    • Re:...wha? (Score:4, Funny)

      by unicron (20286) <unicron&thcnet,net> on Monday November 18, 2002 @07:42PM (#4702278) Homepage
      Roughly translated it means they have all 3 CCIE's and get money thrown at them.
    • Re:...wha? (Score:4, Informative)

      by m1a1 (622864) on Monday November 18, 2002 @11:20PM (#4703363)
      I'll try and hook you up here. Seeing as most of the replies to this I have checked were ridiculous. Basically what these guys are looking at is new ways to use the lower parts of the OSI model.

      The networking model is divided into seven layers. These guys are looking at mainly levels 2-4. These layers are: 2) Data Link, 3) Network, 4) Transport. It looks like most of this focuses on the Network and Transport Layer, where TCP/IP live (reverse respectively). There are basic things you can do with tcp/ip values and protocols, such as trace route, ping, etc. They are finding new things. An example of the typical tcp/ip function is the traceroute. You send a packet with TTL(Time to Live) set to 1. Whoever it hits tells you it died. Then you do 2. Slowly you find your way to the destination, tracing each hop along the way. They are finding new, similar uses for tcp/ip.
  • Go Dan! =) (Score:2, Interesting)

    by dew (3680)
    I roomed with the guy and can attest to the year or so he spent cobbling this stuff together. Go Dan!!

    -david
  • That's insane! (Score:3, Interesting)

    by DJayC (595440) on Monday November 18, 2002 @07:21PM (#4702107)
    "During an authorized test inside a multinational corporation's class B, scanrand detected 8300 web servers across 65,536 addresses. Time elapsed: approximately 4 seconds."

    That is crazy! Does anyone have information, for comparison, on what a scan like that would take using other tools?
    • Re:That's insane! (Score:4, Interesting)

      by Anonymous Coward on Monday November 18, 2002 @07:33PM (#4702201)
      Um, not that I would know anything about scanning that many addresses, but most of the portscanners out now can only handle 20 or so simultaneous connections and have a 2-3 second timeout. So it would depend how fast the hosts respond and what % have servers. I imagine it would be in the realm of 30 minutes or so for this network.
  • Please be nice (Score:5, Informative)

    by thalakan (14668) <jspence AT lightconsulting DOT com> on Monday November 18, 2002 @07:22PM (#4702110) Homepage
    Hi - www.doxpara.com is temporarily pointed at shaitan.lightconsulting.com, a quad Xeon hosted at Via.net in Palo Alto. Please be nice to my server so I don't have to drive over there and fix it...
  • by hemingwaynet (206789) <bbwerner@msn.com> on Monday November 18, 2002 @07:25PM (#4702137) Homepage
    How come I go through my day feeling my little code is soo smart until I log in to Slasdot and read about C-level hacking of the core infrastructure of the internet by gods on human thrones and feel like a little 1st grader who has to deliver a note to a sixth grade teacher and marvels at the complex stuff on the chalk board....

    *sigh*... I'm important! I swear...
  • Greek (Score:2, Insightful)

    by andyring (100627)
    Granted, most of that post was Greek to me, it's still interesting in that I think in any technology or practically any invention, people will find ways to make them do things never even conceived of by the originator. Coming up with new uses for obscure parts of the TCP/IP stack isn't really any different than other inventive uses for common, everyday items. In all actuality, I think it's all about the oft-used phrase, "thinking outside the box."
  • I will post a comment here when I'm done reading the main abstract and supplementaries. I'm also hoping to earn a PhD by proxy. Anyone got a text to speech adapter, it might be nice to hear this in my sleep. Seriously, this d00d got skillz.
  • by Anonymous Coward
    This is similar to the work we did at UANC in the 1996 era. We did a lot of thing with source fragmenting of ethernet moduli, so to speak. This person's research is eerily similar, but clearly his own. I am not posting to claim copyright, blah blah. Just to point out the respect I have for someone who made it "this far!"

    One of the things we did was design an ethernet hashing system that would function sort of like a dynamic roulette wheel of SYN types and packet sequence numbers. Using differing protocol sweeps, we could monitor different states without creating state ourselves! The ultimate goal was to provide inverse cascade across multiple routers and switches, allowing an attack to be sourced directly to a particular ethernet interface without the attacker's spoofing even mattering. By rotating state in real-time, using different queueing techniques, we could esentially traverse the entire network, sort of a big de-randomized traceroute, and virtually re-route all attack traffic back into the ethernet "netherworld", in a nutshell.

    Very advanced stuff! I applaud your work wholeheartedly!
  • huh? (Score:2, Insightful)

    i don't know a damn thing about what this story is talking about, but i've never been more scared in my life
  • by jakedata (585566) on Monday November 18, 2002 @07:30PM (#4702176)
    1. I have plenty of time to play with it.

    2. I don't have to worry about someone doing it to me.

    Is anyone working on SNORT signatures for this stuff?
  • by Sarin (112173) on Monday November 18, 2002 @07:34PM (#4702204) Homepage Journal
    The Paketto Keiretsu, Version 1.0, is a collection of five interwoven "proof of concepts" that explore, extract, and expose previously untapped capacities embedded deep within networks and their stacks, at Layers 2 through 4.

    Hmm let me guess you have to compile this as root, after that it will give "proof of concept" to the black hat 2002 people that indeed there are previously untapped capacities deep within my server, somewhere remotely hidden on the outer reaches of my port range? ;)
    • Re:So what is it? (Score:3, Informative)

      by LostCluster (625375)
      No, this doesn't work on the horizontal edges of your port range. This works below your TCP and UDP ports. It sends messages that don't quite make it that far up there in order to just see what happens.

      If you don't know what the OSI Networking Model is yet I suggest you go look it up... [google.com]
      • I think your humor detector may need a little fine tuning. I think he was referring to the fact that this is an incredibly complex piece of software, written by people We Really Should Not Trust. Who knows what else might be lurking in there, particularly if it has to be compiled as root?

        Now since he's released the tools as source, I doubt that there's anything particularly nasty in there. Paranoia is still a virtue in the sysadmin business, however.

  • by Anonymous Coward on Monday November 18, 2002 @07:40PM (#4702267)
    Let's see...

    ping 160.1.255.255

    Duck and cover, here comes the smurf...
  • by Wanker (17907) on Monday November 18, 2002 @07:43PM (#4702285)
    I don't quite follow what scanrand does that a normal SYN-based scanner does not except that it is broken into two parts so that potentially a different system could be used to receive the packets sent by the first system. Why would this be useful?

    I guess he refers to embedding a code in each packet sent out to validate that only "real" packets are accepted by the receiver as "Inverse SYN Cookie". I don't understand why this is important, tho.

    The "paratrace" program is quite interesting-- from the README:

    paratrace

    Paratrace traces the path between a client and a server, much like "traceroute", but with a major twist: Rather than iterate the TTLs of UDP, ICMP, or even TCP SYN packets, paratrace attaches itself to an existing, stateful-firewall-approved TCP flow, statelessly releasing as many TCP Keepalive messages as the software estimates the remote host is hop-distant. The resultant ICMP Time Exceeded replies are analyzed, with their original hop count "tattooed" in the IPID field copied into the returned packets by so many helpful routers. Through this process, paratrace can trace a route without modulating a single byte of TCP/Layer 4, and thus delivers fully valid (if occasionally redundant) segments at Layer 4 -- segments generated by another processe ntirely.


    Nutshell summary: this uses an existing open TCP connection to run a traceroute through a firewall that would otherwise tell you to take off. I could certainly see this being useful.

    Some good background reading on O'Reilly's Safari online books site if your TCP/IP internals are a bit rusty:

    Internet Core Protocols: The Definitive Guide [oreilly.com]

    TCP/IP Illustrated, Volume 1: The Protocols [oreilly.com]
    • by ryanr (30917) <ryan@thievco.com> on Monday November 18, 2002 @08:34PM (#4702597) Homepage Journal
      I guess he refers to embedding a code in each packet sent out to validate that only "real" packets are accepted by the receiver as "Inverse SYN Cookie". I don't understand why this is important, tho.

      With a traditional scanner, the scanner either has to maintain state (i.e. don't accept a reply to my scan request if I haven't sent it yet, nor if it doesn't match my sequence number, etc..) or it will be subject to the scanee spoofing replies. For example, if you figure out that I'm scanning you, then you can just start generating SYN-ACK packets and lie to me.

      By using inverse SYN cookies, the scanee can't reply until/unless it gets the actual SYN packet, and the scanner doesn't have to maintain any state, and can just blast full-speed.
    • by Electrum (94638) <david@acz.org> on Monday November 18, 2002 @08:39PM (#4702635) Homepage
      I don't quite follow what scanrand does that a normal SYN-based scanner does not except that it is broken into two parts so that potentially a different system could be used to receive the packets sent by the first system. Why would this be useful?

      I guess he refers to embedding a code in each packet sent out to validate that only "real" packets are accepted by the receiver as "Inverse SYN Cookie". I don't understand why this is important, tho.


      Because it allows much faster scanning than can be done with a traditional scanner. You need to understand SYN cookies:

      http://cr.yp.to/syncookies.html [cr.yp.to]

      Instead of sending a SYN and waiting for the response, as a normal scanner has to do, scanrand sends thousands of SYN packets at once, without tracking them. It determines the port based on the ``inverse SYN cookie'' that the response contains.
    • This sounds like the same thing that tcptraceroute does. It sends a tcp/ip packet to an open port and receives an icmp packet as reply. From that it builds the traceroute, even with the hosts behind a firewall.
  • Um, I'm so confused about the scissors and paste that I need to sit down. Note the links attributed to the open and close parens around 'linkcat'

    ( [wholesaled...supply.com]linkcat) [allartsupplies.com]

    Would someone please call me dumb and tell me the answer?
  • by kensai (139597) on Monday November 18, 2002 @07:56PM (#4702372) Homepage
    I can haxor the Gibson and become 3l33t
  • by meshko (413657) on Monday November 18, 2002 @07:58PM (#4702381) Homepage
    OK, this pretty much pushes me over. I've been considering becoming a slashdot troll for some time and I think this article finishes it. First interesting story in a week or two. It gets more moronic posts than anything I've ever seen on slashdot. The best posts here are of the type "this is way over my head". If this is over your head, but you think it's interesting stfu and don't post anything. I don't even want to talk about others.
    The compost bin story got a more meaningful discussion that this.
    90% of people here think that case mods are cool
    99% of people here look at a program which allows you to traceroute without icmp or udp (just to name one thing) and say "yeah, but what's the use"?
    WTF?

    I shall go and troll in the story about case with 6 neon lights attached to it now. See ya.
    • It's by far the best meta-slashdot comment I've ever read:

      http://apple.slashdot.org/comments.pl?sid=44091&ci d=4592270 [slashdot.org]
    • don't worry dude, slashdot hasn't been really technical for a _long_ _long_ time. it's more fun watching the downward spiral, there is no need to help it along. :)
    • No, he's got a real good point. Of course, by the time I read the article, two intelligent posts had managed to float their way up to the surface. The problem isn't with idiots on slashdot. They've always been there. The problem is moderation.

      I think a lot of people have noticed a stark decline in slashdot quality the last three or four weeks. This is about the time the editors changed the code to post notice about your mod points on the top of the front page when you log in. According to CmdrTaco, the number of mod points in use jumped from 4 per 10 comments to ~8 per 10 comments. To me this means two things:
      • there is twice as much uselessly moderated crap at +4 and +5.
      • half the moderators running loose on slashdot are people who until recently never bothered to read the discussions, as they would have figured out they had mod-points at that point, under the old system.


      This is dangerous. We're talking about a Byzantine failure model with half of our population being bent on our destruction. We can tolerate 20-25%, but once half the moderators are aligned against intelligent conversation, the system breaks down.

      Might want to read Taco's journal [slashdot.org]. He talks about the moderation system, and they're trying to figure out what to do about the sudden inflation of mod-points. They're not working very fast, granted, but they're working.

      It's also time for everyone to start thinking about what's broken, specifically, as opposed to the general "slashdot is totally populated by trolls" theory. The population of slashdot has not changed significantly in the last month! But the way we listen to them has. And so we're hearing more useless chatter. Slashdot isn't dead, it's just broken. I've come up with some ideas that I'll post to my journal - or a story about the slashdot malaise that may or may not get posted on the front page - to solicit public comments on what should be changed/fixed. Wish I had already, but been busy.

      Don't worry though. I'm sure that if slashdot does die, whatever succeeds it will first be posted about on slashdot. =)
  • by Anonymous Coward on Monday November 18, 2002 @07:59PM (#4702394)

    basically, this guy found a way to say "i will die alone" in over five hundred words, including the words "link layer" and "phentropy".
  • by Effugas (2378) on Monday November 18, 2002 @08:02PM (#4702410) Homepage
    SCANRAND
    ========
    Really, really fast port scanner, that can also trace network paths. Port scanning is simply the act of asking a machine if you can start up a conversation with a certain port of its, and marking down "yes" or "no" depending on the response. Normally, there's lots of overhead as you keep track of who you sent requests to and thus who you're expected responses from. Overhead, or "state", makes things slow. So scanrand is stateless -- right when you start up, it splits in two. One half asks everyone, "Heh! What are you hosting!" The other half picks up responses, "Hmmm, some guy just said he has a web server."

    Now, there's a problem: If someone knows I'm not keeping track of who I'm scanning, they can just throw fake responses back at me. But TCP lets me embed a little signature with every connection request -- the "Sequence Number". This number will be returned to me when I get a valid response from a host that I scanned. So I take the IP and the port of the machine I scan, encrypt it into the sequence, and send off the request. When I get the response back, I look at the ACKnowledgement, compare it to the IP and port of the machine that's talking to me, and immediately know whether I ever scanned this guy in the first place.

    So, that's why I get to scan really fast. Mind you, it's the least impressive part of Paketto in raw technical terms -- but it's definitely useful as hell.

    MINEWT
    ======
    What if you could just run a program, and a router showed up on your network? I don't mean physically, but I also don't mean "having anything visibly related to the computer hosting it". It'd be virtual, with its own separate IP addresses and it's own MAC addresses too. It'd be portable to any machine on the LAN, maybe it'd be fast, but it'd definitely be amazingly flexible -- no chips to make, no wires to crimp. Run this software, and there's something new on your net.

    That's what minewt is -- a new router that just shows up and works. Now, it happens to do some funky things -- Guerilla Multicast involves taking what your local network sees as a broadcast or multicast address and attaches it to what the outside world sees as just another IP of a single host. So the single host communication goes out, but once the packet returns, it's flooded to a host of happy listeners. (Such is the theory.) MAC Address Translation is also slightly cool -- NAT is all about using a Layer 4 TCP/UDP port to figure out which Layer 3 IP address (the 10.*'s an 192.168.*'s all us Linksys folk live behind) an incoming packet from the internet is really supposed to be going to.

    It ain't your gateway that downloaded all those MP3's, even if that's the IP address on that flow of music.

    Well, there's also this tech called ARP -- the Address Resolution Protocol. Your local network doesn't have a clue about IP addresses -- it just has these unique factory assigned bitstrings that uniquely identify everyone. ARP is used to translate the Layer 3 IP -- 10.* or whatever -- to the MAC address the factory assigned.

    NAT goes from L4(Port) to L3(IP). ARP goes from L3(IP) to L2(MAC).

    MAT -- MAC Address Translation -- just combines the two. L4(Port) leads to the combination L3(IP)/L2(MAC).

    End result? Multiple hosts can share the same IP address. Cool.

    LC [LINKCAT]
    ============
    I've got a wire. I want to talk on it -- but I can't, I've got all these sockets and programs and limitations in the way. Or at least, I had them.

    1) Execute lc -m00 and start typing hex. Whatever hex bytes I type show up on the ether.
    3) Profit.

    Or,

    1) Execute lc -l00 and start watching everything on the network go by in hex. ANything I like, I can copy, then run lc -m00 and paste back onto the wire once again.
    3) Profit.

    lc has a really interesting mode that's based on the fact that you can actually put data in a frame *after* IP is done with it -- it's called an ethernet trailer, and happens all the time when you try to send a packet smaller than the minimum legal length for ethernet. Well, as long as we can throw data after our packet, lets put crypto in it -- lets sign our frame! Basic support for SHA-1 HMAC's is provided.

    PARATRACE
    =========
    Alright, this is kinda neat. You've got a connection to some host, right? You want to know how your packets are getting there. But if you use normal traceroute, you're gonna start up a whole new connection. Paratrace gets around that -- you see, TCP lets you repeat packets; actually, by repeat, it's more like "The network can break and accidentally cause packets that were assumed to have been dropped to mysteriously come back to life; we handle this screwup just fine." So instead of spawning a whole new connection for our traces, we run our traceroute -- which is entirely a Layer 3 IP hack -- using a legitimate Layer 4 TCP packet. When the data eventually gets there, it's mostly ignored -- oh, the network screwed up again.

    If there's a stateful firewall in the way, well, it's looking at Layer 4 data, which is 100% valid.

    PHENTROPY
    =========
    See a cloud? Might be random. See a bunch of triangles? That ain't random. See the Borg Cube? Yeah, that's the FreeBSD kernel. This is an extension of Michel Zalewski's excellent Phase Space Analysis of TCP/IP Sequence Numbers, done with an incredibly interesting tool called OpenQVIS. Those images render *fast*, folks. 15-45fps fast.

    Terribly sorry I didn't do a writeup like this to begin with; hopefully the Keiretsu makes a bit more sense now.
  • Odd links (Score:2, Insightful)

    Am I missing the importance of safety scissors & Elmer's glue? Or are the links on the parentheses around linkcat just for kicks?
  • Fun with errors? (Score:5, Informative)

    by LostCluster (625375) on Monday November 18, 2002 @09:25PM (#4702889)
    Maybe it's too early for anybody to make sense of this thing... but here's what I've got so far: It seems that the great advance here is based on using the IP protocol all by itself in situations where conventionally we use TCP wrapping IP. (Remember class, we had a discussion on leaky abstractions [slashdot.org] recently where we remembered that TCP is what we use when we want to forget that IP exists.) By taking advantage of obscure parts of the IP protocol that we don't usually concern ourselves with, he's been able to use intentionally wayward packets to learn about the network. For example, sending an IP packet with a hopelessly short time to live to take advantage of the fact that whomever has the packet when it when it times out is supposed to send back a packet indicating that error. Turns out most routers do, so he collects that information and gets a traceroute that can go into places where a traditonal traceroute meets with a firewall. And that brings up the potentially dangerous side of things. This flies below our radars, it stays below our firewalls. His packets never go higher than the IP layer of our OSI model stack. (Remember that 7-layer thing that we all had to memorize in networking classes...) I'm not quite sure yet what poking around there gets them other than network topology info, but I kinda get the feeling that if there is something destructive that can be done, we're gonna get blindsided with it.
    • How about fun with lots of errors. If you can manipulate ip enough to do this, what's to say that you can't redirect that in a giant smurfing of the internet. 65k packets in 4 seconds could easily clog a semi-full link, if it was sustained.

      It's a layer 2 /. effect!
    • "I'm not quite sure yet what poking around there gets them other than network topology info, but I kinda get the feeling that if there is something destructive that can be done, we're gonna get blindsided with it."

      Ditto... You're not the only one worried about it!
    • Can someone hack a highly "secure" network with this? Well, they can certainly see and do things that normally cannot be seen or done, but I'm frankly not overly worried about intruder access with this. I think there's more of a threat from crackers thoroughly violating an unsecured SQL server setup, and there doesn't have to be a terrible lot of skill in that.

      This, however, puts a whole new angle on espionage, insider corruption, coordinated intruder-assisted theft and cracking, and possibly underground peer-to-peer networks. Just to get the tip of the iceberg.

      One would argue that some of this stuff may not be new, but it's certainly the first I'm hearing of any such tools or concepts being used.

      I like the LC program a lot. Someone could build a whole new network on that concept. It probably doesn't make much sense outright, but I can see all kinds of nasty tricks being played with that. That traceroute-like tool is also impressive... it could be downright dangerous for certain people with a level of network knowledge and intent of evil far beyond mine.

    • by DarkZero (516460) on Tuesday November 19, 2002 @01:21AM (#4703866)
      I'm not quite sure yet what poking around there gets them other than network topology info, but I kinda get the feeling that if there is something destructive that can be done, we're gonna get blindsided with it.

      The guy that came up with this released it so that we can all see it, use it, understand it, and adapt to the problems that come with it. That's not "getting blindsided". Getting blindsided is the guy that came up with it realizing that incredible destructive power may be in his hands and that he could just use it right then and there when no one even understands what he's doing on a very basic level.

      Since this is just a rearranging of what was already in TCP/IP, it was already there, sitting in some deep corner of the internet and the logic of how it works. Rather than being afraid of what it could do, I'm just thankful that the guy that found it decided to let everyone know about it so that we can take advantage of its good parts and protect ourselves against its bad parts.
    • TCP traceroute (Score:3, Informative)

      by Animats (122034)
      Yes, with this you can do traceroutes through firewalls that block ICMP, but pass TCP. That could actually be useful.

      TCP Traceroute is useful enough that it's already been implemented by somebody else. [toren.net] GPL, and for Linux, with an RPM available, even.

  • by cranos (592602) on Monday November 18, 2002 @09:35PM (#4702939) Homepage Journal
    Okay first off let me say I am not a TCP/IP expert by any means however this does present some interesting points.

    Firstly as a poster has noted before, by going under the radar by directly using the IP layer, this is going to open up a whole new rash of attack methods which we would be much better investigating and defending against.

    Secondly, I think its cool, it renews my faith in the basic tenet of geekdom - play with it until you break it, then learn to fix it again.

  • ...yup, there's still some genius around. Gotta read that stuff closer, I hope to catch a whip of it.
  • Anyone try this using RedHat 8? I can't seem to get any results back from paratrace.

    Scanrand works excellent under RH8... I can't believe how fast it is... WOW! Going to have to play with this one a little more. Definately blows the doors of nmap. The good news is that none of these scans seems to crash anything. The "ping of death" comparison in the article description made me a bit tense, since it's my job to defend the empire.
  • LOOK OUT! (Score:3, Interesting)

    by mcrbids (148650) on Monday November 18, 2002 @10:25PM (#4703161) Journal
    I got to reading this, and thought how cool it was. Then a cold chill ran through me...

    Can you imagine the damage that might occur if this hyperspeed scanner were combined with a Code-Red style worm? We've already talked about infection rates of few days, and with some optimization [slashdot.org], much less.

    But couldn't scanning tools like these cut the time for 100% Internet saturation down to something like 5 minutes?

    -Ben
    • by CoolVibe (11466) on Monday November 18, 2002 @10:54PM (#4703273) Journal
      I compiled the paketto keiretsu and toyed with it. (I'm still trying to get Qvis to compile so I can generate some cool graphs). Anyway, all the tools there can be rate-limited. Try the -b option.

      As for your worries about hyperspeed scanning, well, it's quite bandwith intensive. I guess network operators would notice if someone was scanning the entire internet this way. 2^16 hosts scanned in 4 seconds at full throttle means that 2^32 hosts takes 2^16 times longer. If the network was being satrurated for that amount of time, network operators _WILL_ notice.

      • With multiple worms dividing lists of hosts to scan, every division halves the time to scan the entire internet. I'm quite confident the so called 'Warhol Worm' is coming soon. And I also think it'll beat the security communitys grapevine by a large amount.
      • As for your worries about hyperspeed scanning, well, it's quite bandwith intensive. I guess network operators would notice if someone was scanning the entire internet this way.

        Err... it's the reverse SYN that makes the Keiretsu port scanner interesting. Still it's not one bit stealthier than an nmap doing the ordinary SYN scanning.

        For example banks record every incoming TCP SYN packet that leaver a socket half-open (i.e. for which the responded SYN ACK is never acked in return) and their alarms sound when they start receiving TCP SYN packets for "suspicious" port numbers, for a bank webserver that is pretty much anything outside 80. Well, not alarms, but they do usually take action if there are more of such packets (indicating a pattern, e.g. a scan).

        Then again, port scanning in an environment where it may get logged indicates that some basic things have been forgotten. Attacking a bank on an IP level and looking for open ports is like trying to score J.Lopez, theoretically possible but pointless in practice.
      • Anyway, all the tools there can be rate-limited. Try the -b option.

        Yeah, and worms will certainly rate-limit themselves and be nice to your network, won't they? ;-)

        2^16 hosts scanned in 4 seconds at full throttle means that 2^32 hosts takes 2^16 times longer.

        No. That would mean that scanning a single host would only take 4/2^16 seconds, or 0.06 msec. This seems too short to me, actually it probably is below your network's latency, even in a local network, so you cannot scan a single host that fast. The scanner works that fast by not scanning the hosts sequentially, but by sending requests out in parallel, and then collecting the responses as they come in. So I suppose the time it takes to scan a network doesn't linearly depend on the number of hosts.

        If the network was being satrurated for that amount of time, network operators _WILL_ notice.

        Well, when we're talking about worms, we're also talking about admins who leave their servers unpatched for months, so I'm not sure if they would notice. But the worm doesn't have to scan the whole internet anyway, because every infected machine will infect any other vulnerable host that it finds.

        The real question is whether what slows worms down is the time it takes to portscan, or the time it takes to actually try to infect other hosts that you've found. I have no data to back up my claim, but I suppose that the actual infection takes much longer in comparison, so speeding up the port scanning will not significantly improve the speed of the whole "infection process."

        • Isn't the equivilent to this rather like sending a syn to port 80 of the broadcast? You wouldn't have to care which hosts were up or not, because the network would take care of it. The only time delay would be propagation. Or maybe I don't understand something.
    • The warhol worm/curious yellow ideas are really at their best with a seed of insecure hosts. The big innovation is that if you tell each new host to start at a different part of the seed file, you can infect all the known insecure hosts in a matter of minutes.

      This isn't improved with faster port scanning. Port scanning might help you while you're making your seed file, but once you've found all those webservers, you still have to check each one to see if it's vulnerable.

      Iduno. I think.
  • by blair1q (305137)
    I remember my first checksum.
  • by Animats (122034) on Tuesday November 19, 2002 @01:53AM (#4703984) Homepage
    Yes, you can do this stuff, but it's not that profound.

    His "router" seems pointless, unless it's attached to someone else's LAN. Yes, you can write a single-port NAT router that allows multiple machines on the same LAN to have the same IP address. But then they can't talk to each other. (They can talk to the "router" and perhaps, via it, the outside world.) Apparently he did this to get around some restriction on his dorm LAN in college.

    • College was entertaining. Damn near got kicked out translating Windows print requests to the local Novell printers, so people could avoid installing Client32.

      Anyway, I used Proxy ARP to get around college LAN restrictions. I couldn't have done Minewt way back when. Minewt is an extension of Doxroute, which was written to allow routing rules based on anything I damn well felt like.

      --Dan
  • There is no Class B. It's called a /16.
  • Warning: Serious TCP/IP territory here!
    Of limits for ye olde slashdotters.

    Let me fist get the Crab-Book (http://www.oreilly.com/catalog/tcp3/) and read it. And then post this thing again a half a year later, so I can add my smartass remark.

    Here's for the ones who like pictures (Hehehe...):
    http://www.aw.com/catalog/academic/p roduct/1,4096, 0201776316,00.html

    Geez, I really have to get my TCP/IP sorted out. This stuff sounds to cool to miss out.

Reference the NULL within NULL, it is the gateway to all wizardry.

Working...