ultra newbie:disable ftpd/telnet rhat7

[justatest]

Hello...
I've just setup a redhat 7 on adsl and think I'm being hacked (already?). I've a zyxel modem/router that does filtering but I'm not sure yet of how that works.

Anyway, a port-scan from the internet(I tried vulnerabilities.org) tells me I have ftpd and telnet running amongst other services.

How do I disable these?

thanks (I think it's urgent..)

/j-p.

[LordStanley]

get pmfirewall (http://www.pmfirewall.com) to start with.

[bdg1983]

I believe you need to comment out the lines in /etc/services

[justatest]

just to say thanks - I've done what you both suggest.. I'll try a new port scan in the morning as I'm dropping off from lack of sleep.

It's time to begin educating myself on the niceties of Linux...

regards
/j-p.

[justatest]

Hello...

I received the following suggestion after the latest scan. Can anyone tell me how to configure the web server to return a bogus version?

(thanks again!)


Information found on port http (80/tcp)

The remote web server type is :
Apache/1.3.12 (Unix) (Red Hat/Linux) mod_ssl/2.6.6 OpenSSL/0.9.5a mod_perl/1.24


We recommend that you configure your web server to return
bogus versions, so that it makes the cracker job more difficult

[Golden_Eternity]

Originally posted by mdwatts:
I believe you need to comment out the lines in /etc/services

/etc/services only handles mapping of port numbers to service names. It does not control which services are actually being started.

You probably meant to say /etc/inetd.conf

After you save the changes to inetd.conf, you'll need to restart inetd:

kill -HUP `cat /var/run/inetd.pid`
or
killall -HUP inetd

should do the trick.

[Golden_Eternity]

Originally posted by justatest:
The remote web server type is :
Apache/1.3.12 (Unix) (Red Hat/Linux) mod_ssl/2.6.6 OpenSSL/0.9.5a mod_perl/1.24


We recommend that you configure your web server to return
bogus versions, so that it makes the cracker job more difficult

Actually, what you need to be doing is installing the latest version of apache. There has been a recent advisory for versions prior to 1.3.19. Its a directory traversal issue that can disclose the contents of a directory in place of an error message... Not too dangerous on its own, but if you're running CGIs with calls to databases (for example), this could lead to more serious issues.

Giving false version numbers is of questionable value. In most cases, you'll find that an attack will be launched without the attacker even bothering to scan you first. Attackers who bother with a scanner might be fooled, but sometimes there is more than one way to determine the version number of a program (here I am speaking generally, not specifically addressing apache).

If you do decide to change your version reply, its actually a very simple change in httpd.conf. I'm not adminning a web server right now, or I'd dig out the tag for you. It should be fairly apparent if you scan through the sample config file.

[ 06 April 2001: Message edited by: Golden_Eternity ]

[justatest]

..but it seems on redhat 7.0 the file inetd.conf doesn't exist?

There's only an xinetd.conf that contains just a defaults section with four lines and an includedir line.

thanks for any updates..
/j-p.

[Golden_Eternity]

Originally posted by justatest:
..but it seems on redhat 7.0 the file inetd.conf doesn't exist?

There's only an xinetd.conf that contains just a defaults section with four lines and an includedir line.

That's right, RH 7 introduced xinetd... (I zoned and didn't pay attention to the version number, my bad)

For xinetd, the last line of xinetd.conf will point you to the right directory (likely /etc/xinetd.d), the includedir directive you mentioned.

In that directory, you'll find the config files for the services. To disable these services, I believe you add the line "disable = yes" to the service's config file.

[ 06 April 2001: Message edited by: Golden_Eternity ]

[bdg1983]

You probably meant to say /etc/inetd.conf

Yes, you are most certainly correct. Can I use the excuse of old age for my lapse of memory?

[justatest]

I installed pmfirewall as suggested but not understanding what ipchains etc. etc. are in my linux-fledgling state, I ended up creating a wonderfully secure server - nothing was responding!

Therfore I uninstalled (decided to do some in-depth study before installing a second time) but in the meantime, I disabled the well-known services Telnet, Ftpd et al, as was kindly (and patiently) explained to me.

Now when I request a port-scan, I receive a reply listing a series of (to me) not-so-well-known ports such as Sambar on 443/tcp or auth 113/tcp which should be disabled.

Yes, you've guessed my next question:

As I had disabled the well-known services by editing a file (each filename being the same name as the service) within the xinetd.d directory and adding the line disable = yes, I now want to disable these other 'lesser-known' services that do not have a file dedicated to them....

...but how can I do that if there's no filename for 'Sambar' or 'auth'?

Once again, RH7.0 is the linux version in question.

Long-winded this time - apologies and grateful thanks for any suggestions offered.

/j-p.

[justatest]

I installed pmfirewall as suggested but not understanding what ipchains etc. etc. are in my linux-fledgling state, I ended up creating a wonderfully secure server - nothing was responding!

Therfore I uninstalled (decided to do some in-depth study before installing a second time) but in the meantime, I disabled the well-known services Telnet, Ftpd et al, as was kindly (and patiently) explained to me.

Now when I request a port-scan, I receive a reply listing a series of (to me) not-so-well-known ports such as Sambar on 443/tcp or auth 113/tcp which should be disabled.

Yes, you've guessed my next question:

As I had disabled the well-known services by editing a file (each filename being the same name as the service) within the xinetd.d directory and adding the line disable = yes, I now want to disable these other 'lesser-known' services that do not have a file dedicated to them....

...but how can I do that if there's no filename for 'Sambar' or 'auth'?

Once again, RH7.0 is the linux version in question.

Long-winded this time - apologies and grateful thanks for any suggestions offered.

/j-p.

[bdg1983]

Sorry as I don't know the answer to your question.

Have you read the Security NHF's on this site. Probably would be very helpful for you.

[justatest]

In fact, I've been doing this in such haste as the server is now on the internet, and vulnerable (I wanted to concentrate on putting up a website - a classic case of the cart before the horse, you might say.)

As you suggest, it's time to stop and do some study myself instead of relying on the expertise and goodwill of others.

thanks
/j-p.

[Golden_Eternity]

I found what appears to be a much better explanation of xinetd than the one I was going from:
http://www.macsecurity.org/resources/xinetd/tutorial.shtml

[Jason Deraleau]

I have your solution.

Go into /etc/xinetd.d/

remove any files for services you don't want to support :)

JD

[justatest]

..However, there aren't any files which mention tcp ports 113, 443 etc. in the xinetd.d directory (finger, ntalk, rlogin, talk, tftp, linuxconf-web, rexec, rsh, telnet, wu-ftpd - all disable=yes)

I then commented out the relevant lines in the /etc/services file, but even that didn't seem to have any effect on closing down these lesser well-known ports.

/j-p.

[Golden_Eternity]

What sort of scanner are you using to show that these ports are open, and what exactly does the scanner say?

I've seen some scanners that show a port is filtered, but the terms used can be misinterpreted to say that they're open... Just a thought.

[Golden_Eternity]

Originally posted by mdwatts:
<STRONG>Yes, you are most certainly correct. Can I use the excuse of old age for my lapse of memory?</STRONG>

Works for me, I use it all the time... In this industry anyone over 23 is over the hill, right?

I figure commenting out lines in /etc/services would probably work anyway. If inetd can't map the inbound connection to a service, then it won't know to open the connection. Not the best way, but it might still work.

[ndelo]

Sorry I haven't read everything in this post so I may be saying something already suggested. But if you want to stop anything in RH7 not handled by xinetd, you need to make changes to your runlevel directory, /etc/rc.d/rc.X, where X is the runlevel you are running in. You can find out what runlevel you are operating in by reading your /etc/inittab file. Not to far down in that file you will find an entry in it that says something like id:3:initdefault (if 3 is your default runlevel). Now that you know your runlevel, look in your /etc/rc.d/rc3.d (again if 3 is your runlevel, if not just change into rcX.d, where X is your runlevel) and you will see a bunch of symbolic links like S80sendmail, S90xfs. These links boot up those services--sendmail for instance--at startup. Delete any link for any service you do not want to run on your box. You can safely do this without removing the actual service. Just reboot the machine, or better yet, stop the service by issuing a /etc/rc.d/init.d/sendmail stop (I'm using sendmail as an example) and the service will be shut off. Now if the service isn't running, it can't be exploited. Just make sure you know what the service is and what it does before you shut it off. Hope this helps. :)

If you are running RH7, make sure you stop or update bind, lpr, vixie-cron and wu-ftp, if you are in fact running any of these services. Check out the updates and errata section at Redhat's site for other security risks, as there are about 1 million of them.

[ 12 April 2001: Message edited by: ndelo ]

[justatest]

Thanks 'ndelo' for such valuable information... can you recommend any online source for more of the (i.e. get to the point) same?

regards
/j-p.

[ndelo]

Um, online resources, I'm not sure. Just do a search for "linux run levels". I did just one on Google and came up with a lot of stuff, though I'm not sure what was good and what was not as I didn't have time to wade through it all Runlevels are fairly easy to understand once you do a little bit of reading and poking around. All of this info can be found in any good linux sys admin book. I recommend these two, as they continue to be resources for me:
http://www.bookpool.com/.x/kd76j2xjc6/sm/1565924002
http://www.bookpool.com/.x/kd76j2myii/sm/0672319853

[ 13 April 2001: Message edited by: ndelo ]