1819897 Members
2650 Online
109607 Solutions
New Discussion юеВ

securing Redhat 7.1

 
SOLVED
Go to solution
Leovino A. Trinidad, Jr
Frequent Advisor

securing Redhat 7.1

Hi!

Just want to know how will you secure redhat 7.1. How do you close the ports listed in nmap? How do you trace hackers? what logs do i need to look for?

Hope you could help me on these.

Regards,


LAT
14 REPLIES 14
Leovino A. Trinidad, Jr
Frequent Advisor

Re: securing Redhat 7.1

Hi!

Guys if the questions are too much just answer "how to close open ports on linux 7.1?". Thank you.

Regards,

LAT
Mark Grant
Honored Contributor

Re: securing Redhat 7.1

You don't specifically "close" ports, you just don't "open" them. If have an application listening on a port, it will be considered open. "xinetd" will listen on lots of ports but you can stop it doing that by commenting out the services you don't need in "/etc/services". Other applications such as sendmail get started up during boot so you need to look at disabling those services you don't need to.

Finally, if you absolutely want to make sure, then look at iptables to set up firewall rules on your machine.

There is a whole world of related information at the following link.

http://www.linuxsecurity.com/
Never preceed any demonstration with anything more predictive than "watch this"
Jerome Henry
Honored Contributor

Re: securing Redhat 7.1

To trace hackers means to monitor your system. A good tool for that specific filtering is pure secure to monitor servers, and snort to detect intrusions :
http://www.snort.org/
http://www.demarc.com/products/puresecure/

hth

J
You can lean only on what resists you...
Leovino A. Trinidad, Jr
Frequent Advisor

Re: securing Redhat 7.1

Hi Mark!

Thank you for your response, I tried your advice but seems it doesn't work. I commented out ports i think do need to be opened in the /etc/services. Here is the result.

[root]# nmap localhost

Starting nmap V. 2.54BETA7 ( www.insecure.org/nmap/ )
Interesting ports on gatekeeper (127.0.0.1):
(The 1495 ports scanned but not shown below are in state: closed)
Port State Service
1/tcp open tcpmux
7/tcp open echo
9/tcp open discard
11/tcp open systat
15/tcp open netstat
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
70/tcp open gopher
79/tcp open finger
80/tcp open http
109/tcp open pop-2
110/tcp open pop-3
111/tcp open sunrpc
119/tcp open nntp
138/tcp open netbios-dgm
139/tcp open netbios-ssn
143/tcp open imap2
512/tcp open exec
513/tcp open login
514/tcp open shell
515/tcp open printer
540/tcp open uucp
635/tcp open unknown
1080/tcp open socks
1524/tcp open ingreslock
2000/tcp open callbook
2001/tcp open dc
6000/tcp open X11
6001/tcp open X11:1
6667/tcp open irc
12345/tcp open NetBus
12346/tcp open NetBus
31337/tcp open Elite
32771/tcp open sometimes-rpc5
32772/tcp open sometimes-rpc7
32773/tcp open sometimes-rpc9
32774/tcp open sometimes-rpc11
54320/tcp open bo2k
Jerome Henry
Honored Contributor

Re: securing Redhat 7.1

Hi,

How astonishing it is to see:
12345/tcp open NetBus
12346/tcp open NetBus
31337/tcp open Elite
54320/tcp open bo2k

Is this a linux box ? Running those clients ?
If you want a port that an application uses to be closed, the idea is to stop this application in order to close the port.
For each, you can run service application_name stop.
But you can't stop everything if you want your box to work... Looking at iptables to protect your Linux would be a good idea...

hth

J
You can lean only on what resists you...
Mark Grant
Honored Contributor

Re: securing Redhat 7.1

LAT,

Sorry, after commenting out the services in /etc/services, you need to restart xinetd or find it's PID and "kill -1" it.

Never preceed any demonstration with anything more predictive than "watch this"
Sergejs Svitnevs
Honored Contributor

Re: securing Redhat 7.1

>how to close open ports listed in nmap
1. Run iptables firewall do disallow access to open ports
2. Stop the programm that is leaving the ports open.

Regards,
Sergejs
Huc_1
Honored Contributor

Re: securing Redhat 7.1

As you are running 7.1 you can set up firewall after installation time by running the following from a root shel

#setup

this will allow you to choice from a list ... in this case firewall

from there you can choice High, Medium, No Firewall, and allow some of the port you want !

The above will create default rule for in your case probably ipchains (iptables is I think default as of 7.2)

To check on this type the following

#ipchains -L

if it retuns rules and no error this is wat it is using

else try for iptables

#iptables -L

You can also do a

#service ipchains status

to know if this is running

to check for open port

#nmap "your_IP_name or OR your_IP_address"

the rules for ipchains are keep in /etc/sysconfig/ipchains

have a look at those and use man ipchains to futher explain/analyze


J-P
Smile I will feel the difference
Stuart Browne
Honored Contributor
Solution

Re: securing Redhat 7.1

This is quite a list.

What are you *ACTUALLY* running on the box?

Judging by the list, you're running a pop server, an smtp server (sendmail), an IRC server, a web server, a news server, leaving all r* commands open (rexec, rsh, rlogin), not to mention uucp, a socks server, and running a GUI X Session on the console.

you also appear to have been *HACKED* and are being used to hack other people (31337, 12345-6, 54320).

Use 'netstat -ntulp' to find out what these processes are, and stop them.

For the xinetd launched ones, turn them off using 'chkconfig off'. Do this for other higher level services (httpd, nntp, etc.) of which you are not using.

Once you've closed off the obvious holes, then get to work on the not-so-obvious ones.

Find out which root-kits have been used on your machine. The path to the processes which are running these daemons are you friends here, and will probably point to some half-hidden directories. At this point, /proc// is your friend (in particular, the 'cwd' symbolic link).

Once you've found and removed the root-kits (google is helpful), you need to verify that no trojans still exist. Use 'rpm -Va' to help find these.

If it's any of the root kits I'm aware of, you will also need to use 'lsattr' a fair bit to be able to fix these issues.

Once you've cleaned yourself up, and rebooted a few times to make sure they don't come back, you need to set up your firewall properly as discussed by the others in this thread.

You then need to update all affected packages with the latest eratta from RedHat.

These are just starting points. Each individual step will most probably take hours to complete.

Usually, the best thing for you to do is to back up your own personal data and settings, wax the box with a newer, more up-to-date distribution, and start again.
One long-haired git at your service...
Leovino A. Trinidad, Jr
Frequent Advisor

Re: securing Redhat 7.1

Hi Guys!

thank you for all your responses especially to Stuart Browne. actually, this incident is the first time i've experienced with redhat. I already turned-off some of the services but the ports are still open. Also, ran 'netstat -ntulp' and saw portsentry, named and sendmail running. The box is running ipchains. What else do I have to do?
Stuart Browne
Honored Contributor

Re: securing Redhat 7.1

Start by verifying that 'netstat' (part of the 'net-tolls' RPM) hasn't been replaced by a rootkit:

rpm -V net-tools

If '/bin/netstat' comes up, it's bad. Download a clean package (or pull off your install CD's), and re-install it.

Once you've confirmed it's clean, issue the command:

netstat -nutlp

This will list processes listening (either UDP or TCP), and what their process-id's are (PID). An example of the output from one of my machines:

tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 26363/sendmail
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 26376/ishttpd
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 795/httpd
tcp 0 0 192.231.136.2:53 0.0.0.0:* LISTEN 27128/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 27128/named

This is just 5 of the listening ports.

They state the protocol, the send/receive queues, the listening IP and port (the next two aren't a concern in this command), and the last field is the PID/process name.

lets look at the process listening on 8080 as an example.

It's called 'ishttpd', and is at PID 26376.

If we look in /proc/26376/, an 'ls -l' shows the following:

total 0
-r--r--r-- 1 root root 0 Dec 16 13:45 cmdline
lrwxrwxrwx 1 root root 0 Dec 16 13:45 cwd -> /etc/iscan
-r-------- 1 root root 0 Dec 16 13:45 environ
lrwxrwxrwx 1 root root 0 Dec 16 13:45 exe -> /opt/trend/ISHTTP/IScan.HTTP/ishttpd
dr-x------ 2 root root 0 Dec 16 13:45 fd
-r--r--r-- 1 root root 0 Dec 16 13:45 maps
-rw------- 1 root root 0 Dec 16 13:45 mem
-r--r--r-- 1 root root 0 Dec 16 13:45 mounts
lrwxrwxrwx 1 root root 0 Dec 16 13:45 root -> /
-r--r--r-- 1 root root 0 Dec 16 13:45 stat
-r--r--r-- 1 root root 0 Dec 16 13:45 statm
-r--r--r-- 1 root root 0 Dec 16 13:45 status

This shows us various pieces of good information. For starters, it shows the exact path to the executed binary (exe: /opt/trend/ISHTTP/IScan.HTTP/ishttpd), and the directory it was launched from (cwd: /etc/iscan). The contents of 'cmdline' is the command line that launched it.

With these details, you can start tracking down where a paper-trail might be. Rootkits usually leave a log of their progress in the directory they are launched from.

With the PID, you can try using the 'kill' command to be rid of it. You may want to verify that it is also not been replaced by using 'rpm -V util-linux'.

Once you've got the path name, and the binary name, you can do 2 things. One: find out where it was launched from (cd /etc;grep -r "" *), two: remove the offending binary (using 'lsattr' to make sure it isn't immutable (+i) and 'rm' to make sure you can get rid of it).

As for logs to trace them, well, try using the 'last' command. I highly doubt it will show anything as the files it relies upon (/var/run/utmp) will have most probably been destroyed after you were exploited.
One long-haired git at your service...
Stuart Browne
Honored Contributor

Re: securing Redhat 7.1

Oops, I was going to attach a file with those command outputs in a neater format..
One long-haired git at your service...
Leovino A. Trinidad, Jr
Frequent Advisor

Re: securing Redhat 7.1

Hi!

Thank you Stuart for that very helpful information. I just figured out the problem why there are ports opened on my linux box. It's because I let portsentry monitor other hackable ports (portsentry.conf).

Again, thank you for all your help especially to Stuart.

Regards,


LAT
Stuart Browne
Honored Contributor

Re: securing Redhat 7.1

No problems.. It's what we're here for.. ;)
One long-haired git at your service...