eth0 died on two FC4 boxes

Had two FC4 boxes on the same subnet. One was a working httpd server.
then I discovered that my WinXP could not ping either box and the FC4
boxes could not ping each other.

Tried to delete and reconfig the the eth0 interface using static and
DHCP. Both failed to activate, or would activate until another
application was launched and then the eth0 would inactivate

The script for these interfaces looked just how I expected them to
look.

Have I been hacked with some script that keeps "ifdown" my eth0?

Both these boxes could ping a few hours ago.

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com

> Tried to delete and reconfig the the eth0 interface using static and
> DHCP. Both failed to activate, or would activate until another
> application was launched and then the eth0 would inactivate
>
> The script for these interfaces looked just how I expected them to
> look.

How should "we" imagine your scripts if you don't post them?

The problem is not the scripts. These were once working machines as I
stated in my post.

I was hoping someone might know what or how working eth0 interfaces
might suddenly die on two different boxes with FC4.

ANSWER: The problem is that I am ignorant of how to harden a server and
some script kiddie with pimples and too much unsupervised play time
kicked the shit out of my respective boxes.

SOLUTION:
http://www.cert.org/tech_tips/win-UN...ompromise.html
http://unixhacks.blogspot.com/

So now I must back up my httpd.conf files, reload the OS, and do my
homework to toughen it up this time. Lessons learned. Thanks.

(E-Mail Removed) wrote:

>
> So now I must back up my httpd.conf files, reload the OS, and do my
> homework to toughen it up this time. Lessons learned. Thanks.
>

the #1 way to thwart script kiddies and brute force attacks (adjust
ports, # of connections and timeout to suit)

/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW
-m recent --set
/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW
-m recent --update --seconds 60 --hitcount 4 -j DROP

Although this won't stop a distributed attack, it will at least slow it
down.... at least in my fortunately limited experience even distributed
attacks use a single host to launch more than 4 probes quickly....

(E-Mail Removed) writes:

>The problem is not the scripts. These were once working machines as I
>stated in my post.

>I was hoping someone might know what or how working eth0 interfaces
>might suddenly die on two different boxes with FC4.

>ANSWER: The problem is that I am ignorant of how to harden a server and
>some script kiddie with pimples and too much unsupervised play time
>kicked the shit out of my respective boxes.

>SOLUTION:
>http://www.cert.org/tech_tips/win-UN...ompromise.html
>http://unixhacks.blogspot.com/

>So now I must back up my httpd.conf files, reload the OS, and do my
>homework to toughen it up this time. Lessons learned. Thanks.


Exactly how do you think they broke in?

I set up a second box and feeling a little brave, I added a few mail
services to my standard setup. I may not have had the ports locked all
the way down on this one (hey this will only take a few minutes - what
could happen in a few minutes?) They exploited mail services to destroy
ipconfig and take over eth0. From there is was typical bogus ARP crap.
Acctually my XP laptop was the compromised box and worked out from
there. That's my best guess. I put the OS firewalls up and tightend
down the ports. I am going to go back and do the thing recommended
above.

Very nice - Thank you.

Q. Why port 22?

(E-Mail Removed) wrote:
> Very nice - Thank you.
>
> Q. Why port 22?
>

A lot of brute-force attacks come in on ssh....

I get them all the time, and this stops them....

I've always been tempted to do something combining that and labrea
<http://labrea.sourceforge.net/> but never took the time.

Basically issue a redirect on the nth attempt to a labrea tarpit IP
address.....

:-)

--Yan