Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Basic IP knowledge

By tayknight in Internet
Mon Aug 13, 2001 at 04:36:22 PM EST
Tags: Help! (Ask Kuro5hin) (all tags)
Help! (Ask Kuro5hin)

Hi all. I turned on the loggin on my router last week to see what Code Red looked like. Wow. Now I need some help.

I initially just wanted to see if I was getting probed. I don't run IIS, but I do run Win2k Pro. I was suprised the number of times I'm probed, a bunch on port 80, a bunch on lots of other ports as well.
I have Apache on my windows box, so I set the router to forward HTTP request to my box so Apache could log the acutal requests. It is kind of cool, if scary, to see what is happening, in real time, when computers are trying to compromise my box. So far I'm safe.
My questions comes because of some of the other probes being made on my computer. For instance, I've been probed a few hundred times in the last few hours on port 5632 which my logging program says is for PCAnywhere, which I don't run on my computer. I tried to do a reverse DNS lookup to see if I could resolve the offending IP to a domain name. No Luck. I also tried to trace route to the IP address. It only resolved up to Verio, three hops below the destination IP address.
So, is there a way for a newbie to learn about how IP is structured. I dont' want to do anything to the guy, it isn't enough traffic to be concerned about, but it is traffic. I figure some good knowledge now might help if the traffic ever does get extreme. Where should I start?


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o Also by tayknight

Display: Sort:
Basic IP knowledge | 33 comments (32 topical, 1 editorial, 0 hidden)
read this book. (3.66 / 9) (#1)
by cicero on Sun Aug 12, 2001 at 09:17:56 PM EST

tcp/ip illustrated vol 1 is the book you want to check out.

I am sorry Cisco, for Microsoft has found a new RPC flaw - tonight your e0 shall be stretched wide like goatse.
re: read this book (4.50 / 2) (#9)
by Salamander on Mon Aug 13, 2001 at 09:56:21 AM EST

Agreed. Another good book for your particular purpose would be Northcutt's Network Intrusion Detection, which will describe some of the ways that quirks of how TCP/IP are designed and implemented can be abused by hackers.

[ Parent ]
It's nothing specifically directed at you (4.00 / 4) (#2)
by xriso on Sun Aug 12, 2001 at 09:37:39 PM EST

Looking through my logs, I see plenty of worm-like attacks. One that seems to happen somewhat often is a triplet of connection attempts to port 137, presumably to break in through Windows File Sharing. Another is attempts to connect to 27374, which I hear is a backdoor installed by SubSeven or the Ramen worm. And then there's the endless stream of connections to bootpc, which I think is an @home probe for dhcp or something.

There will always be attempts for some exploit pouring in. If you want to keep safe, minimize the number of open services you have running, and get security updates as soon as possible.
*** Quits: xriso:#kuro5hin (Forever)

bootp, dhcp (4.27 / 11) (#3)
by fluffy grue on Sun Aug 12, 2001 at 09:51:37 PM EST

DHCP is the successor to bootp. bootp assigns IP addresses based on ethernet MAC addresses and does some minor configuration (routers, mostly). DHCP takes it a step further by adding leases (which allow dynamic allocation) and adds more configuration. Neither exists within the TCP/IP domain (they're Ethernet protocols), and since they're nonroutable, there's no such thing as a remote DHCP or bootp probe.

Unless it means something else in the Windows domain, bootpc is a client for bootp, just as dhcpc and pump are clients for DHCP. Since those are (again) non-routable Ethernet protocols, there is no way that it could be a remote exploit. In fact, most likely you're just seeing other people connecting and disconnecting on @Home's network. I don't know how @Home is set up, but when I had Road Runner when I was living in Virginia a few years ago, all of the ARP, DHCP, etc. traffic was broadcast across the entire cable segment. It was all legitimate traffic though; it was just other modems configuring themselves and such. It was fun to occasionally see who was online and then use Samba to print porn to their printers.
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Ethernet Protocols? Give me a break. (4.00 / 1) (#22)
by abdera on Thu Aug 16, 2001 at 09:24:39 AM EST

Give me a break. From the overview of RFC 951:

This RFC describes an IP/UDP bootstrap protocol (BOOTP) . . .

Hmm. . . sure sounds like an ip protocol rather than Ethernet one. Never mind the fact that bootp and DHCP work just dandy over token ring FDDI, and PPP. Never tried it over PLIP or SLIP, but I would imagine that it works there, too.

Since bootp and DHCP use UDP, you could certainly forward traffic to UDP port 68. The reason that typical bootp traffic is not routed is because it is sent to the broadcast ip address. If, however you have a shoddily put together bootp client running, it is not unreasonable to convieve of exploiting the client by sending unicast traffic to it.

It was fun to occasionally see who was online and then use Samba to print porn to their printers.

I wonder how many marriages have had undue stress put upon them by such shenanigans. What at first appears to be a harmless prank can turn sour quickly. Would you would be as amused by putting a copy of Hustler in you nieghbor's mailbox?

#224 [deft-:deft@98A9C369.ipt.aol.com] at least i don't go on aol
[ Parent ]

Attacks from local segments, too (none / 0) (#23)
by abdera on Thu Aug 16, 2001 at 09:31:12 AM EST

I forgot to mention that a user on your local segment could even try to exploit a bootp client with broadcast traffic. Perhaps your neighbor is having a little trouble falling asleep on his couch and read a book about network security and found a little hole in the source code of your bootp client?

#224 [deft-:deft@98A9C369.ipt.aol.com] at least i don't go on aol
[ Parent ]

Ah, my bad (none / 0) (#25)
by fluffy grue on Thu Aug 16, 2001 at 10:45:13 PM EST

I thought bootp was Ethernet-level and unrouteable. At least, that was the impression I got from my networking class. Additionally, it's interesting to wonder how the configuration response would be routed to the client, since the client wouldn't have an IP address at the time.

The "print porn" thing was, in all honesty, a joke. I never actually printed any porn to other peoples' printers (just messages saying, for example, "You shouldn't leave your printer open to the world"). Sorry for trying to be humorous.

FWIW, it's a good idea to not be so hostile.
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

bootp replies (none / 0) (#26)
by abdera on Fri Aug 17, 2001 at 12:28:27 PM EST

Additionally, it's interesting to wonder how the configuration response would be routed to the client, since the client wouldn't have an IP address at the time.

From the RFC:

4. Chicken / Egg Issues

How can the server send an IP datagram to the client, if the client doesnt know its own IP address (yet)? Whenever a bootreply is being sent, the transmitting machine performs the following operations:

1. If the client knows its own IP address ('ciaddr' field is nonzero), then the IP can be sent 'as normal', since the client will respond to ARPs [5].

2. If the client does not yet know its IP address (ciaddr zero), then the client cannot respond to ARPs sent by the transmitter of the bootreply. There are two options:

a. If the transmitter has the necessary kernel or driver hooks to 'manually' construct an ARP address cache entry, then it can fill in an entry using the 'chaddr' and 'yiaddr' fields. Of course, this entry should have a timeout on it, just like any other entry made by the normal ARP code itself. The transmitter of the bootreply can then simply send the bootreply to the client's IP address. UNIX (4.2 BSD) has this capability.

b. If the transmitter lacks these kernel hooks, it can simply send the bootreply to the IP broadcast address on the appropriate interface. This is only one additional broadcast over the previous case.

Additionally, the boot traffic can be helped (not quite routed) by a router so that a single server can dish out ip addresses for multiple subnets. I suspect that this is the way most cable companies operate.

Sorry for trying to be humorous.

Sorry for taking you seriously.

FWIW, it's a good idea to not be so hostile.

Point taken. Apologies for misdirecting my work-related frustration at you.

#224 [deft-:deft@98A9C369.ipt.aol.com] at least i don't go on aol
[ Parent ]

Hm (none / 0) (#27)
by fluffy grue on Fri Aug 17, 2001 at 01:08:25 PM EST

That chicken/egg solution is pretty kludgy. Maybe it's in trying to avoid explaining that why my networking class' textbook just said that they were Ethernet protocols, so that it wouldn't have to explain the details. :) (The book was pretty bad about going in-depth about certain things.)
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Why not look it up? (none / 0) (#31)
by mindstrm on Sat Aug 18, 2001 at 04:26:45 PM EST

You'll find, if you dig, that there is a field in an etherent frame called 'type' that normally specifies the encapsulated protocol: Usually, IP. (0x0800 if I remember correctly). In Ethernet-II, it's a type field, in 802.11, it's a length field.

You'll notice there is no type for 'DHCP'. DHCP is most definately a subset of IP.

Check RFC-1340, under 'Ethernet - numbers of interest'. I'm sure if you have a copy of TCP/IP Illustrated, the list will be in the apendix somewhere as well.

Don't confuse thsi with the IP protocol-id field, which you might be tempted to think is the right one becuase it let's you specify a subtype of 'ip'....

[ Parent ]
You are both correct, sort of. (none / 0) (#30)
by mindstrm on Sat Aug 18, 2001 at 04:03:39 PM EST

THe guy who says that BOOTP/DHCP is IP based is technically correct; it is structured as a valid UDP broadcast datagram.

IT's commonly thought of as an ethernet-level protocol because it has to work without the presence of any other IP-related information.

A response is addressed to the source MAC address from the incoming frame (just like any other IP response; the only difference is that we don't need to use ARP to look it up, because we already know it (and ARP wouldn't work anyway, because it has no address).
Remember, IP addresses are just used to look up MAC addresses when it comes to the local segment.

Also, it's not 'routed' to the client; it's addressed. As you say, without IP addresses, it's not routable. If the DHCP server is on a different segment, then you are employign DHCP-relay, which is different.

[ Parent ]
27374... (3.33 / 3) (#6)
by mrgoat on Mon Aug 13, 2001 at 07:22:54 AM EST

...Is the default port for Sub7 version 2.0(?) and up. It can be configured to run over different ports as well. 1234 was teh default for earlier version. So whoever told you that was the port was right.

"I'm having sex right now?" - Joh3n
--Top Hat--
[ Parent ]

More reliable way to find owner of an IP (4.42 / 7) (#4)
by chrisbolt on Sun Aug 12, 2001 at 10:38:42 PM EST

I tried to do a reverse DNS lookup to see if I could resolve the offending IP to a domain name. No Luck. I also tried to trace route to the IP address. It only resolved up to Verio, three hops below the destination IP address.

A better way to find who owns an IP if it doesn't have valid reverse DNS is to type the IP address into this whois. It will give more specific results than just "hosted by verio".

<panner> When making backups, take a lesson from rusty: it doesn't matter if you make them, only that you _think_ you made them.
basic internet knowledge (3.40 / 5) (#5)
by sesquiped on Sun Aug 12, 2001 at 11:36:55 PM EST

I'm not exactly sure what you're asking with "is there a way for a newbie to learn about how IP is structured?", so this might not be what you're looking for, but it's a very useful introduction to how the internet works: http://www.freesoft.org/CIE/

y'all wanna understand TCP/IP (2.87 / 8) (#7)
by jann on Mon Aug 13, 2001 at 07:26:30 AM EST

well ... it is a long and hard road ... took me years and I still am amazed ad what occasionally crops up.

But here is how to start.

1. Learn how to data cable ... 10Baset is fine. Learn how a hub works, how to punchdown a krone block, how to make a crossover cable and learn why it works. How to cascade 2 hubs, how to install a Nic.
2. Learn how a switch and bridge works.
3. Connect 2 pc's up to a hub running IP and pinging each other. Insert network analyser onto another hub port and watch. Do other networky stuff. watch.

OK ... that was the introduction ... the basics ... if you don't know that TCP/IP is nothing to you anyways.

4. pick up the Cisco CCNA studyguide or do the course. Learn. get a job working with routers ... anything will do. play with them.
run up a couple of freebsd boxes with an internet connection and have them routing betwix themselves. Play, break, fix, learn, use an ethernet sniffer.
5. do the Cisco ACRC, then the BCMSN.
6. keep playing

And eventually, one day, you wake up and suddenly it all makes perfect sense. And it is like a light has shone upon you and you have been enlightened. And all future networking problems, questions and issues are simple ... really ... I am not kidding ... it is like enlightment.


now I am learning perl ... am still waiting for that light to shine ... TCP/IP I am good at ... perl I am working on ;-)

lol (1.50 / 4) (#8)
by mami on Mon Aug 13, 2001 at 08:23:52 AM EST


[ Parent ]
ACRC is no more (none / 0) (#21)
by el_guapo on Tue Aug 14, 2001 at 04:51:26 PM EST

it's now BSCN - Building Scalable Cisco Networks. A newbie may need to start with Interconnecting Cisco Network Devices, A friend of mine (complete network newbie) just took the Cisco Acadamy 1 and 2 classes, 1 was a little basic but 2 was great for him.
mas cerveza, por favor mirrors, manifestos, etc.
[ Parent ]
Firewall (4.66 / 3) (#10)
by finial on Mon Aug 13, 2001 at 10:34:15 AM EST

Rather than letting the stuff through and tracing it with Apache logs, try getting ZoneAlarm and using those logs instead. You say only that you forwarded HTTP requests (port 80) to your box, but you don't say how you determined the other ports. Did you turn on the DMZ function or did you specifically forward each port? Since you are getting varied port numbers, I can only assume you turned on the DMZ feature. If that's the case (and you don't have a firewall) you are wide open.

They have a free version and a pro (40USD) version. It's a great product.

On a similar note, you can use Gibson's site to find out just how much of your system is visible. I had trouble convincing my parents to install a firewall on their new cable modem until I told them to go to this site and see for themselves. They installed the zonealarm firewall within minutes. Good stuff.

Firewall (none / 0) (#14)
by tayknight on Mon Aug 13, 2001 at 01:40:02 PM EST

I use the Linksys Cable Router (BEFSR14 or something like that.) Its a hardware NAT router. It logs requests and forwards them to a specified IP behind the firewall. It has a DMZ feature, but I'm not using it.
Pair up in threes - Yogi Berra
[ Parent ]
Or even better... (none / 0) (#29)
by mindstrm on Sat Aug 18, 2001 at 03:55:44 PM EST

though I like Zone Alarm.. I found Tiny Personal Firewall (http://www.tinysoftware.com/pwall.php) a bit easier to use (and lackin the splash screens). The user interface is a bit more techy, and it's not crippled in any way.

[ Parent ]
Internet infrastructure (4.50 / 2) (#11)
by yosemite on Mon Aug 13, 2001 at 10:37:54 AM EST

Here's a couple more good links for more information:
  • IANA (Internet Assigned Numbers Authority) has a list of well-known ports at www.iana.org/assignments/port-numbers Use this to answer questions like "what are all these connections to port 111?" (answer: they're looking for rpc, a big Un*x security hole).

  • Many of the protocols used on the internet (including ftp, http, nntp, etc, etc) are specified in documents called "RFC"s. Go to www.faqs.org/rfcs/ for a good starting point on public internet standards, and links to standards authorities (including the IANA)
Also, don't feel bad if you feel overwhelmed by information overload. Why, with just 5 or 10 years of study, you'll begin to feel like there might be a day when you can understand some significant fraction of it ;-).

[Signature redacted]

Logging under Linux (4.00 / 1) (#13)
by Eimi on Mon Aug 13, 2001 at 01:21:33 PM EST

I've heard a lot of people speak highly of ZoneAlarm. My question is, is there anything like it under Linux, or a way to at least log what programs are connecting where from my box (not that I'm all that paranoid about that, but I'm curious) and what addresses are probing me, at what ports, etc. I try to keep things pretty well shut down, but I'm curious.

Snort (4.00 / 1) (#15)
by The Larch on Mon Aug 13, 2001 at 02:41:49 PM EST

Snort will detect and log intrusion attempts. It's somewhat CPU-intensive and tends to generate rather a lot of false positives with the default ruleset though, so you'll need to tweak it to your needs.

I used to run snort on a Linux Pentium 233MMX firewall with two 100Mbps interfaces, and while the CPU utilization was negligible when scanning packets coming in from the Internet at 512kbps, copying files across the firewall at the full 100Mbps would cause packets to be dropped, and I had to exclude that particular host/protocol pair from scanning altogether.

For a lighter weight traffic monitoring system, you can just run tcpdump in a spare xterm with an appropriate filter to trim out the uninteresting traffic ;)

[ Parent ]

Try lsof (none / 0) (#17)
by dxb on Mon Aug 13, 2001 at 04:00:34 PM EST

IIRC lsof displays process->port mappings, as well as process->file mappings.

snort is also excellent - many, many uses.

[ Parent ]
iptables (none / 0) (#20)
by jynx on Tue Aug 14, 2001 at 06:58:57 AM EST

You can set ask the Linux kernel to log verious things about traffic. See the firewalling HOWTO.


[ Parent ]

iptables & a gui firewall; ethereal (none / 0) (#24)
by juln on Thu Aug 16, 2001 at 07:58:02 PM EST

The standard firewalls for linux are based on kernel modules, netfileter/iptables for 2.4 and above and ipchains for 2.2. Both of these are usually set up to log denied packets in a system directory; you can get gui programs that display the intercepted packets and let you add dynamic rules. If you really want to see details about all packets, you can get a network sniffer like ethereal (which is also available for Windows). This program is at www.ethereal.com. A good firewall gui program can be found at firestarter.sourceforge.net.

[ Parent ]
another GUI (none / 0) (#32)
by krokodil on Tue Aug 21, 2001 at 07:55:24 AM EST


[ Parent ]
In short, and embarrasingly, no, there isn't. (5.00 / 1) (#28)
by mindstrm on Sat Aug 18, 2001 at 03:53:22 PM EST

No before all you jump down my throat about it... here's what I mean.

Linux is fantastic at firewalling and filtering, don't get me wrong. It's fairly trivial to set up some firewalling to protect yourslef.

But what ZoneAlarm (or my favorite, Tiny Personal Firewall) do, that linux doesn't (as far as I know) is firewal the interface between the applications and the network libraries themselves.

They actively control who can open network sockets and who can't (and what kind, and on what ports) as well as controlling incoming and outgoing packets... and that's partly what makes them cool. Not only can you restrict whether or not your computer is allowed to receive packets on TCP port 80, but you can specify which program is allowed to receive them.

So you can't just get some new application that tries to upload all your passwords back over port 80 via http thinking it'll work, because ZA or TPF will bitch about it and ask you if it's okay for this new app to do what it's doing.

[ Parent ]
Some options (4.50 / 2) (#16)
by jd on Mon Aug 13, 2001 at 03:57:53 PM EST

The best way to learn is NOT through dusty books, arcane RFCs, or strange burritos from Taco Bell. The best way to learn is to look at actual code, and see what it does. As any 3-5 year old can tell you, there is NOTHING to compare with just trying things out.

First, take a look at tcpdump/libpcap, the ancient and definitely definitive piece of code for monitoring IP packets. That'll give you a heads-up on how different packets are structured and what the different bits of structure mean.

Secondly, play around with the source for nmap. That shows you how portscans work, how fingerprints of OS' can be taken, and other good stuff.

Third, grab a copy of routed, a simple RIP router daemon. Why, you might ask? Security gurus might have an idea of what I'm up to. So, if you want to be an IP guru, you might want to make a few educated guesses. After all, the information is all contained above.

Fourth, grab hold of a few "less common" network tools. bing is kinda neat. There's some nice stuff in RAToolSet, too. I'm not just suggesting these for my health, they do actually have a value.

Lastly, go to SecurityFocus, or one of these other specialist on-line sites, and dig up everything you can find on honeypots.

Ok, now an explanation as to what is going on, here. Once you understand how to intercept packets, and/or inject them, you're in a strong position to protect yourself from any wanna-be intruders.

By learning how to massage the fingerprints of an OS, you can also learn how to send back misleading information to those who are interested in scanning your box. By this point, you can tell any would-be cracker whatever you wish.

The less-used tools can help identify the intruder, even if the intruder's computer is un-pingable. There still has to be router traffic, to tell the Internet where that machine is. There still has to be an AS number for that particular segment of the network. If you're -REALLY- lucky, someone may have set a nearby router to report its geographic location.

Finally, the bit the A-TEAM loved to do, on those cheesy TV shows. You set a trap. A honey-pot. In short, you set up something SO inviting, that when the skript-kiddies detect it, they'll plunge in. And then you've got them.

It doesn't have to be painful for them, it just needs to be (a) a way to keep them out of your hair, whilst you're doing real stuff, and/or (b) a learning-experience, on why not to be malicious to others.

Since no one mentioned this yet... (3.00 / 2) (#18)
by Elendale on Mon Aug 13, 2001 at 05:30:21 PM EST

IIRC, PCanywhere is a program commonly used by sKr1pt K1dd13s to get access to a machine. Something about a rather large (and unfixed) security flaw that allowed a foreign user to gain access to a machine running PCanywhere. Shouldn't cause you trouble though...


When free speech is outlawed, only criminals will complain.

ARIN (4.00 / 2) (#19)
by J'raxis on Mon Aug 13, 2001 at 05:37:46 PM EST

whois.arin.net (Both accessible via web and `whois`) will give you contact information for IP addresses. For example, when I query
MediaOne NorthEast (NET-M1-NE-4)
27 Industrial Ave.
Chelmsford, MA 01824

Netname: M1-NE-4
Netblock: -
Maintainer: MDON

MediaOne NorthEast (ZM117-ARIN)

Domain System inverse mapping provided by:


Record last updated on 10-Aug-2001.
Database last updated on 11-Aug-2001 23:03:50 EDT.
— The Raxis

[ J’raxis·Com | Liberty in your lifetime ]

For the curious but lazy... (none / 0) (#33)
by SIGFPE on Thu Aug 23, 2001 at 10:29:57 PM EST

...a good book is "Internet Core Protocols" by Eric Hall and published by O'Reilly. Right from the beginning it gets you started with a packet sniffer (on enclosed CDROM, works under W2K) and examining the traffic on your network. You don't have to read thousands of pages of this and that revision to this and that protocol. Excellent! The packet sniffer isn't bad either - it identifies many protocols and interprets the headers for you.
Basic IP knowledge | 33 comments (32 topical, 1 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!