VCE - port 11111?
 

Hi..All,
I am often using nmap to scan servers to ensure that any unwanted ports are opened. Today I found VCE tcp 11111 opened port from nmap output. But before this I had never found this port as opened. Do we really need this? why this port got opened? I commented out in /etc/services for both tcp/udp 11111. But still it is listening. Could anybody please guide me, what is this port, and how to kill this process if we really don't need?

What process is listening on this port? As root run: You may also want to see this thread: which is a current topic dealing with unknown processes. In it unSpawn lists a command to capture a lot of log information regarding open ports and files that will help you trace down the process.

VCE - port 11111?
 

Hi..Thanks for your quick reply. Please see the below output.
netstat -pane | grep 11111
tcp 0 0 0.0.0.0:11111 0.0.0.0:* LISTEN 0 13320 4419/ricci

Here is the output from nmap for open ports

"Host is up (0.0017s latency).
Not shown: 991 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
443/tcp open https
3306/tcp open mysql
5989/tcp open wbem-https
8443/tcp open https-alt
11111/tcp open vce

ps -ef | grep vce
root 16811 16680 0 10:27 pts/1 00:00:00 grep vce

kill 16811
-bash: kill: (16811) - No such process

kill 16680
echo $?
0

netstat -pane | grep 11111
tcp 0 0 0.0.0.0:11111 0.0.0.0:* LISTEN 0 13320 4419/ricci

Again I scanned through nmap but still it is listening and I could not kill vce process. Please tell me, is this any virus related program for the attackers. And should I kill this process? If yes could you please show the commands that how can I kill this process. and how can I allow inbound and outbound for only ssh, http and mysql.

The program name is ricci, operating with pid 4419. Here is some information on this application:
See this link, which says that ricci listens on port 11111: http://kmaiti.blogspot.com/2010/12/h...ricci-for.html
For extra confirmation, see this link: http://www.linuxtopia.org/online_boo...-conga-CA.html which also confirms that this program listens on port 11111.

Part of the confusion is that this port was also used my a particular piece of malware called VCE. Your looking for a process called VCE failed because there isn't one and the PID you saw was the PID of your GREP query, which had already terminated when you tried to kill it, hence no such process.

The next step would be to confirm that you actually have this program installed, though in my estimation it is looking like this is a false alarm. Once you have determined that this program is benign, you can easily put a firewall in place to block external access to this program, however, if you are using the service it may no longer work. You may also want to look at configuring the application, if possible, to listen on an appropriate interface instead of all interfaces.

To block unwanted ports is fairly easy to do with iptables. The prefered method is to block all input connections and then only allow the ones you want. You could do this a simple script. Here is an example that I have also tweaked to show some variation options:

As you can see, you add the connections you want to your input chain. You can qualify the connections specifying things like the interface, protocol, port, and then tell it to ACCEPT the traffic. At the bottom, you place a DROP rule to drop all other traffic. These rules are like regular expressions and when a match is made, they stop comparing. This means it is important to put your rules in the proper order.

Outbound traffic is more difficult and fortunately less important. The problem is that while the input port numbers are defined, the output ports are not and instead often times use high order, random port numbers. Thankfully iptables is a state-aware system and you could use the state functions to allow established and related connections. Any of the many tutorials on IPtables should cover examples. Again, the important part is to stop the inbound connections. Outbound comes into play when you wish to stop programs from "phoning home" or stop malware, which is not as common on Linux.

Once you create your script and get iptables working as you wish, you can use iptables-save (iptables-save > filename) to capture the filter set. You can then configure your network scripts to call iptables-restore to automatically restore these rules on start up.

Lastly, I recommend using a drop rule at the end instead of setting the policy to drop. The difference is in how things will behave if you flush the rules. With the policy set to drop, all traffic will be closed and you can lock yourself out.

VCE - port 11111?
 

Thank you very much master. You guided me a lot. I killed pid 4419 and scanned through NMAP, now it is not listening. Could you please show me the iptables commands to block or accept the rules as you mentioned for below rules.
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT --dport 3306 -j ACCEPT
-A INPUT -j DROP

OP, why do you keep using nmap? you have root access to the system in question, validate your changes there.

i think i will, on behalf of everyone here, challenge you to do a little research to figure out how iptables rules work and how you get them to be enforced. the topic has been discussed peta-times on this site. this site, as well as your favorite search engine should reveal the gold bucket at the end of the rainbow. man iptables is also a good start.

"a little knowledge is a dangerous thing.", learned that early on in my nuke-e classes ;)

cheers.

Here is a link to an IPtables tutorial that I think is pretty good.

A simple rule set to allow SSH, Apache, and MySQL would be as follows:
This is a pretty basic configuration, but would meet this need. The idea is to allow only the desired traffic and reject all others. The firewall is best thought of as a protective wrapper around your applications, with the primary line of defense being to only run services you need. You could also improve these rules by specifying source IP addresses, if for example you know that you are only going to connect from a particular host.

With all of these applications you should consider ways to apply your security in layers. For example, in MySQL you will also need to consider how you handle the user authentication. A couple of options include allowing user@hostname, or requiring your users to create an SSH tunnel and then allowing user@localhost.

VCE - port 11111?
 

Hi.., Thank you
I used nmap from remote machine to confirm once again whether any unwanted ports are opened.

VCE - port 11111?
 

Hi..Thank you,
You gave me an useful link to know about iptables. Thanks.:)

you can do the same directly while on the box. why rely on "nmap" from some other system. i will typically use other tools from other machines when i dont have access to the system in question, and someone else is doing the config of that system, which is many times the case when the server guys wont let we security guys touch the box, its always make a request, wait for a reply, validate their change, yada yada yada. in some cases i have seen the admin block a the port in a firewall and then my scan tool said "nope, port closed" but in fact the server wasnt even touched, etc.

i have strong belief that the owners of systems need to KNOW the system, and in about 99.99% of the thousands of systems i have come across the owner of such systems knew very little about the box (they couldnt show me a build doc, didnt know the current patch level, had no idea what type of connectivity was allowed to reach the box, couldnt say which kernel version it was, couldnt say if it boots init 3 or 5, etc etc).

so i challenge you to get to KNOW your system. then when you think you fully understand it you can validate your claims by using tools against the box, etc.

i'm not saying what you are doing is bad, just prompting you to use a different approach, etc.