[lug] DHCP?? was new to BLUG, Hello, @Home setup

Thu Feb 15 22:46:27 MST 2001

Well-written (um, did I really say that?) trojans could contact some
upstream server and let them know where they live... or they maybe just 
don't care what IP they're on... depends on the trojan.

An evil "example" of this would be an idea an aquaintence of mine had --
write a trojan that installs itself and then uses HTTP outbound to
"read" a web page.  The page could be at Geocities or just about
anywhere where someone could post the page semi-anonymously.  The more
confusion about where the page gets posted from, the better...

Then let's say this particular trojan is a DDOS trojan....

The web page can have whatever content someone wants to create... a fake
family picture site, whatever...

Include code in the trojan to read only the HTML *comment* tags on the
web page.  Have it watch for something like:

<!-- GETEM: 192.168.1.1 -->

When it sees that content hidden in the HTML page, it starts attacking
that machine with whatever form of attack it's programmed to.

So now let's apply this to your machine on DHCP.

It changes IP addresses... no big deal.  It just still goes out with an
innocuous-looking HTTP request at timed intervals looking for the
"catchphrase"... once it sees it, it starts generating traffic.

So in this case DHCP does nothing.

Now, in the case of someone rootkitting your machine or something like
that, DHCP IP changes may help keep them from returning to your machine
at a later time, but once a machine has been hit by script kiddies,
there are usually scanners available to scan a range of IP's and find
the machine again that has been broken into.

In other words, changing your IP address regularly doesn't give much
security to anything... it might help in certain circumstances, but it
won't do the proper job of securing the machine.

In the case of something like the first story, hopefully your firewall
has EGRESS filters on it and you only allow certain traffic OUT.  Of
course, if the DDOS is a ping flood or something you allow outbound at
your firewall anyway, it's still going to work -- but how did they get
the trojan on the machine in the first place through the firewall?

(GRIN -- It gets worse...)

Now if your ISP or preferrably, you if you have a router, haven't
blocked the use of IP's that you don't own outbound also (should be
common practice, but in many cases it is not still to this day) your
machine could also use spoofed IP addresses for an outbound attack.

(Getting nervous yet?  heh heh... proper security's a pain!)

So even though your IP changes regularly, if your ISP isn't blocking
other IP's in your range, a "smart" trojan could take advantage of that
and make the attack look like it's coming from your neighbor's machine
(in the case of home broadband) or somewhere else.

I guess the best way to put it is that proper security is a HIGHLY
detailed process.  And you have to be willing to give up some
functionality of a wide-open connection to the Internet to do a good job
at keeping your machines from doing bad things to others.  It's a cat
and mouse game... that's for certain.

The thing that is most worrisome about security is found by taking a
look at job postings.  Only the very largest corporations have started
taking security seriously enough to start having on-staff Security
Engineers.  Most companies think a once-a-year port-scan of their DMZ's
is sufficient, and they usually pay big bucks to a consulting company
for the privelege.

How does this relate to Linux?

Linux (and other *nix variants) have all the tools ready and waiting for
a sysadmin to properly secure his machines and network.  From proper
routing, to firewall code, to network and host-based
intrusion-detection, to monitoring software -- and others -- there's
just a GREAT toolkit for security sitting right in front of anyone using
a *nix system.

Meanwhile, Windows users are paying THROUGH THE NOSE for software that
when tested heavily leaves a lot to be desired on all of these issues.

Even just basic packet sniffers that can't keep up with a true 100Mb/s
connection on Ethernet run into the thousands of dollars on Windows
platforms.  Fire up tcpdump and Ethereal on a *nix system and you're
going to be able to push an awful lot of traffic through your sniffer
before it dumps on a *nix box.  Linux has issues with libpcap that limit
its effectiveness here -- but OpenBSD and others will do a little better
with the BSD network stack.  This from experience -- no empirical
evidence here that I know of.

I guess I went off on a rant here (Dennis Miller?) but I've always been
impressed with where the open-source community is on security compared
to the commercial vendors.  Many commercial vendors are obviously afraid
of this, making those who would like to do comparisons and evaluations
of their software jump through hoops and sign NDA's, only to find out
that their product doesn't actually catch much of what it claims to
catch.  Then when pressed for a reason why, they usually sputter that
"the guy down the street at XYZ company uses it!".  So what?

Of course, NDA's mean that they can't legally tell anyone that the
product stinks, and not everyone has the time to do huge amounts of
analysis on the products... so people buy them and they think they're
"secure".

Security's not something that doesn't take proper time and resources
applied to it.  It should be a high-ranking clueful engineers job at
every organization to know and enforce a properly published security
policy for that organization -- not something a company ONLY relies on
an outside contractor for.  The outside contractor should DEFINITELY be
used for a sanity check regularly, but it shouldn't be the ONLY line of
defense.

Man I got going here tonight ... sorry!  Drinking too much coffee at the
internet cafe!  Whew!

On Thu, Feb 15, 2001 at 10:04:02PM -0700, John Starkey wrote:
> > DHCP doesn't do anything for security.
> >
> > Especially when they hand you out the same IP every time (what I've
> > heard about @Home's DHCP setup is that they do that?).
> 
> That's what i was referring to. The hopping around. But I'm sure a good trojan will
> detect a new IP and retunr that to the person that planted it right?
> 
> John
> 
> >
> > NAT may or may not be useful, but not DHCP.
> >
> > On Thu, Feb 15, 2001 at 03:50:14PM -0700, John Starkey wrote:
> > > Ok. So what's the advantage of DHCP? The only one I've heard from a general user
> > > standpoint is Security.
> > >
> > > I know from the admin's perspective it'll free any unused addys.
> > >
> > > To me it's just a pain since I need my files remotely.
> > >
> > >
> > > Thanks,
> > >
> > > John
> > >
> > >
> > >
> > > John Hernandez wrote:
> > >
> > > > I think your reasons are valid for wanting to use DHCP.
> > > >
> > > > If using dhcpcd:
> > > >
> > > > /sbin/dhcpcd -h C1234567-A ...
> > > >
> > > > If using pump:
> > > >
> > > > /sbin/pump -h C1234567-A ...
> > > >
> > > > where C1234567-A is that silly ID given to you by the cable company.
> > > >
> > > > That should do it.  No need to actually use their hostname.domain.
> > > >
> > > > John Starkey wrote:
> > > > >
> > > > > Yeah I wasn't gonna bring that up. But why are you worrying about DHCP?
> > > > >
> > > > > Shannon Johnston wrote:
> > > > >
> > > > > > I don't know if this is a big help but on my @Home service even if you're
> > > > > > pulling an address from the DHCP server, it comes up the same every time.
> > > > > > I've just set that static IP address in the ifcfg-eth0 file and I'm good
> > > > > > to go.
> > > > > > Do you know if it's pushing through a different IP everythime you power
> > > > > > up?
> > > > > >
> > > > > > Shannon Johnston
> > > > > >
> > > > > > On Thu, 15 Feb 2001, John Starkey wrote:
> > > > > >
> > > > > > > Welcome David.
> > > > > > >
> > > > > > > There is a HOWTO at www.linuxdoc.org . I can't help you with @Home and
> > > > > > > DHCP, some other member's can, I'm sure. But I thought I'd atleast let
> > > > > > > you know about this doc. I think it's appropriately called "Cable-modem"
> > > > > > > or something similar.
> > > > > > >
> > > > > > > Also Richard from the Linux Newbie list at rutgers created a HOWTO for
> > > > > > > his ISP in Europe. I could probably look it up for you if the General
> > > > > > > HOWTO doesn't help. It's been a year though. A quick search thru the
> > > > > > > geocrawler archives for that list should turn up a hit.
> > > > > > >
> > > > > > > Good luck,
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > "Holshouser, David" wrote:
> > > > > > >
> > > > > > > > I'm new to the area and to BLUG.
> > > > > > > > Thanks for being here. My last LUG was always very helpful
> > > > > > > > and I look forward to working, volunteering, and learning
> > > > > > > > with you in the future.
> > > > > > > >
> > > > > > > > For now, I'm trying to get a box up on @Home that I've had on cable
> > > > > > > > in NC for a year or so with RoadRunner.
> > > > > > > >
> > > > > > > > I've searched the archives and can't find a simple explanation or
> > > > > > > > how-to, so I'm guessing that means there is nothing special to do
> > > > > > > > for @Home. Unfortunately I haven't received any response from their
> > > > > > > > dhcp server and can't get any connectivity.
> > > > > > > >
> > > > > > > > I've heard that you must set the name to whatever they assign you.
> > > > > > > > Is there any other setup 'stuff' that I need to know?
> > > > > > > > A simple list of things to do on an external web page would
> > > > > > > > serve me fine.
> > > > > > > > Must I empty my resolv.conf for dhcp to work? What about netmask?
> > > > > > > > Shouldn't dhcp reset all of that for me?
> > > > > > > >
> > > > > > > > Windoze works everytime, reboot to linux and nothing.
> > > > > > > > Again, it's been up with RR for a while.
> > > > > > > >
> > > > > > > > Thanks in advance.
> > > > > > > > David
> > > > > > > >
> > > > > > > > --
> > > > > > > > David Holshouser
> > > > > > > > Engineer I
> > > > > > > > Ball Aerospace & Technologies Corp.
> > > > > > > > (303)939-5085  dholshou at ball.com
> > > > > > > > _______________________________________________
> > > > > > > > Web Page:  http://lug.boulder.co.us
> > > > > > > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Web Page:  http://lug.boulder.co.us
> > > > > > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Web Page:  http://lug.boulder.co.us
> > > > > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > > > >
> > > > > _______________________________________________
> > > > > Web Page:  http://lug.boulder.co.us
> > > > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > > > _______________________________________________
> > > > Web Page:  http://lug.boulder.co.us
> > > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > >
> > > _______________________________________________
> > > Web Page:  http://lug.boulder.co.us
> > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >
> > --
> > Nate Duehr <nate at natetech.com>
> >
> > GPG Key fingerprint = DCAF 2B9D CC9B 96FA 7A6D AAF4 2D61 77C5 7ECE C1D2
> > Public Key available upon request, or at wwwkeys.pgp.net and others.
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug

-- 
Nate Duehr <nate at natetech.com>

GPG Key fingerprint = DCAF 2B9D CC9B 96FA 7A6D AAF4 2D61 77C5 7ECE C1D2
Public Key available upon request, or at wwwkeys.pgp.net and others.