Computer Scientist

Showing posts with label SNMP. Show all posts
Showing posts with label SNMP. Show all posts

Saturday, 15 January 2011

Linux Network Security Issues

Until now, as far as I know, there are at least three different levels of network security mechanism that affects the running of network processes, TCP Wrapper, Iptables firewall, SELinux.

TCP Wrapper and SELinux are host-based mechanism. According to a response to a network packet, TCP Wrapper and SELinux will decide if this packet can be processed by the specific running process. They will not block any network access from other hosts, however, they will limit the running process in the host from processing network messages.

Iptables, on the other hand, provides a network-based security mechanism. It inspects every network packet whenever a packet going into a host or leaving a host. A great amount of distinct functional rules can be set up in order to filter some specific packets. By this way, unwanted packet is forbidden outside of the host.

In my recent experiment, several problems are suffered in these two issues. I'd like to record them here for future reference:

  1. In school's Fedora 11 system, snmp messages can not going out even if the corresponding port is opened by iptables firewall. When I was using tcpdump to inspect every packet of snmp protocol, I found that snmp request messages were able to go in the system. but there were never any packets coming out. I supposed that two possibilities: snmp crashed, or some other than iptables was keeping block the outgoing messages. Finally, after I searched almost the whole internet (joking, can I? but it is true that it is quite difficult to spot a specific rear problem on the internet.), I realised that I got half correct. There is something called TCP Wrapper which is used by Linux system to prevent some specific daemon processes from accessing from unwanted network hosts. In this case, all of the process other than several processes denoted in the file /etc/hosts.allow is allowed to be accessed in localhost host which means that only local access is allowed. This is right the reason why I was able to query snmp using localhost. In coming snmp messages from other hosts is not allowed to be processed by snmpd (so harsh!!). The solution is simple, just add the snmpd into hosts.allow file. 
  2. The problem regarding to Iptables is a little foolish, but I learnt others when I modified the rules of Iptables. Actually, the reason of I can't transfer files to cspc020 is because I open the wrong port for tcp connection (don't believe the instructions on the webpage totally, this lessoned me). Just open tcp60000 is fine. During this process, i found that, always modify the iptables using iptables command line tools before modify the configuration file /etc/sysconfig/iptables, because the command line is temporary but effects at once. If there are some problems, I am able to resume it by restart computer and then the original configuration will be read. !!!! Good mechanism.


Thursday, 13 January 2011

Strange SNMP problem in Ubuntu or other platform

Description of the problem:
After I have installed SNMPd in Ubuntu 9.04, I was trying to snmpwalk system to test the correction of the installation and deployment. However, I got a Time out message even though I did not get any firewall installed in Ubuntu. At the beginning, I thought that it is the firewall problem like in Fedora. The truth of no firewall installed in Ubuntu by default makes me realise that this is not in that case.

Solution:
Ubuntu is different from Fedora, there is a file to keep the default snmpd's running options, which is:
/etc/default/snmpd. In it, the options denote that only local host is able to snmpwalk the SNMP agent. In this case, I will not only need to change the snmpd.conf configure file, but I will also need to change some lines in the snmpd configure file mentioned above to make it work. The changing is like this:


#SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1'
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid -c /etc/snmp/snmpd.conf

Thursday, 2 December 2010

Problems suffered when I was usign SNMP

1. Set user pass-phrases problem:
    It seems to be infeasible to change pass-phrases directly in configure file. Each time, after I changed pass-phrases in configure file, I can still not make it effect even I have already restart the snmpd.
    (1). When I used snmpusm command to change password, I got a error message. This is because I was failed to assign a correct view to my current account.
    (2). When I used the same command, I got a USM generic error in rpc242. I supposed that I used wrong syntax of snmpusm command. Here is this time's typing (running locally in rpc242):
  snmpusm -v3 -l authPriv -u chenfu -a MD5 -A -x DES -X localhost passwd [ -Ca | -Cx ]

2. Running External Program:
    Actually, I can use several different "things" to run external programs using snmp on remote host.
    (1). "sh" is used to run shell script specially.
    (2). "exec" can used to run almost all of programs. <>
    ========Both "sh" and "exec" should be used by occasions when only one line result is needed. They are under a specific OID. Before, it seems to be feasible to assign aa arbitrary OID to a specific program (It is your responsibility to make sure no conflicts happen.). But now, I have never completed it. Maybe new version of SNMP forbidden this unreliable feature.========
    (3). "extend" is emerge under the situation where the manually assigning of an OID to a program is unsupported by "sh" and "exec".
    (4). "pass" is used to deal with some manually assigned OID. I am not quite familiar with "pass". As far as I know, you are able to decide what operations to do when a specific OID is looked up.

    My problem at the beginning is that I accidentally used the "exec" to run a simple script. I want to use a manually assigned OID to mark this entry. But it failed. When I turned to use "extend", it works quite well.

3. Usage of extend without assigned OID:

  1. On the remote server configure date extension in /etc/snmp/snmpd.conf. Simply add this single line at the end of the config file and reload snmpd:
    extend datecheck /bin/date
    
  2. From any client that has allowed SNMP access to the server query the datecheck with:
    ~$ snmpwalk -v2c -c public remote.server NET-SNMP-EXTEND-MIB::nsExtendOutputFull
    NET-SNMP-EXTEND-MIB::nsExtendOutputFull."datecheck" = STRING: Wed Oct 18 00:01:44 NZDT 2006
    
    That's about it. Easy way to run programs and scripts remotely, isn't it?