I have 2 linux machines, both of them have rsyslog. I need to send logs from client machine to server machine. I have done these steps but still I am not able to send the message. What am I doing wrong? I am using UDP port 514
SERVER MACHINE : (192.16.72.239)
updated /etc/rsyslog.conf, uncommented 2 lines after comment
# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
`restarted rsyslog`
executed below commands as well:
[root#mysystem/]# iptables -A INPUT -p udp --dport 514 -j ACCEPT
[root#mysystem/]#nc -l -p 514 -4
Ncat: bind to 0.0.0.0:514: Address already in use. QUITTING.
CLIENT MACHINE :
added this rule(third line) at the end of the file:
# remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
#*.* ##remote-host:514
*.* ##192.16.72.239:514
# ### end of the forwarding rule ###
now I am using command on client machine logger "sending message from client to server". But I can see above message is present in client's /var/log/messages but it is not present in server's /var/log/messages.
Am I doing anything wrong?
Related
Hello guys i need to resolve this problem (all server have installed centos 7): i'm trying to create a gre tunnel through vps (in Italy - OpenVZ) and a dedicated server (in Germany), but they do not communicate internally (ping and ssh command tests). Next i create a gre tunnel trought vps (in Italy - OpenVZ) and vps (in France - KVM OpenStack) and their communicate, i next i had create a tunnel trought vps (in France - KVM OpenStack) and a dedicated server (in Germany) their communicate. I can not understand why the vps (in Italy - OpenVZ) and the dedicated server (in Germany) do not communicate, ideas on how I can fix (
I also tried with iptables disabled, firewalld is not enable)? Thanks
In other words:
In other attempts (by this i mean that i managed to successfully create the GRE Tunnel between these machines):
The VPS (in France) and VPS (in Italy) communicate internally (ping and ssh command tests)
The VPS (in France) and Dedicated Server (in Germany) communicate internally (ping and ssh command tests)
Problem (by this i mean that i could not successfully create the GRE Tunnel between these machines):
The VPS (in Italy) and Dedicated Server (in Germany) do not communicate internally (ping and ssh command tests). I also asked hosting services if they had any restrinzione but nothing.
My configuration:
VPS command for tunnel:
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
iptunnel add gre1 mode gre local VPS_IP remote DEDICATED_SERVER_IP ttl 255
ip addr add 192.168.168.1/30 dev gre1 ip link set gre1 up
Dedicated server command for tunnel:
iptunnel add gre1 mode gre local DEDICATED_SERVER_IP remote VPS_IP ttl 255
ip addr add 192.168.168.2/30 dev gre1
ip link set gre1 up
[root#VPS ~]# ping 192.168.168.2
PING 192.168.168.2 (192.168.168.2) 56(84) bytes of data.
^C
--- 192.168.168.2 ping statistics ---
89 packets transmitted, 0 received, 100% packet loss, time 87999ms
[root#DE ~]# ping 192.168.168.1
PING 192.168.168.1 (192.168.168.1) 56(84) bytes of data.
^C
--- 192.168.168.1 ping statistics ---
92 packets transmitted, 0 received, 100% packet loss, time 91001ms
[root#VPS ~]# tcpdump -i venet0 "proto gre" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes ^C 0 packets captured 1 packet received by filter 0 packets dropped by kernel
[root#DE ~]# tcpdump -i enp2s0 "proto gre" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel
[root#VPS ~]# lsmod | grep gre
ip_gre 4242 -2
ip_tunnel 4242 -2 sit,ip_gre
gre 4242 -2 ip_gre
[root#DE ~]# lsmod | grep gre
ip_gre 22707 0
ip_tunnel 25163 1 ip_gre
gre 13144 1 ip_gre
Console image with full command output
If ip_forwarding is required for the tunnel to work, you need to do /sbin/sysctl -p
And what does the output of ip tunnel show and ip route show on both the ends
I'm using the net-snmp for gather system information in linux.
but I found there is problem.
when I check port usage of Net-SNMP by netstat, I found net-snmp using 3 UDP port.
Here is the result.
[root# snmp]# netstat -anp | grep snmp
tcp 0 0 127.0.0.1:199 0.0.0.0:* LISTEN 6392/snmpd
udp 0 0 0.0.0.0:49005 0.0.0.0:* 6392/snmpd
udp 0 0 0.0.0.0:161 0.0.0.0:* 6392/snmpd
udp 0 0 0.0.0.0:44837 0.0.0.0:* 6392/snmpd
as you can see, the snmpd using 2 more udp port without 161.
also I found why the 2 udp ports are randomly occupied by snmp.
those ports are using for sending snmp trap.
when I remove the tran2sink and informsink option, the 2 UDP ports are no more appear.
this is my part of configuration of snmpd.conf
###########################################################################
# SECTION: Trap Destinations
#
# Here we define who the agent will send traps to.
# trap2sink: A SNMPv2c trap receiver
# arguments: host [community] [portnum]
trap2sink 192.168.1.4
# informsink: A SNMPv2c inform (acknowledged trap) receiver
# arguments: host [community] [portnum]
informsink 192.168.1.4 NMS_COM
# trapcommunity: Default trap sink community to use
# arguments: community-string
trapcommunity NMS_COM
# authtrapenable: Should we send traps when authentication failures occur
# arguments: 1 | 2 (1 = yes, 2 = no)
authtrapenable 1
my program have to use 40000~50000 udp port.
so I want to use those trap options and change the ports.
how can I fix the ports?
You can try to set port for the directives as below:
trap2sink 1.1.1.1:port_num e.g. trap2sink 1.1.1.1:162
I hope I understood your question and this would help.
These are SNMP Ephemeral ports. Here is a quote from a Microsoft support page on them:
While SNMP service is running it may be noticed via the netstat
Command Line utility that in addition to the well known ports for
sending and receiving SNMP traps (161/162) that a random ephemeral
port has been created by the service as well.
The random port usage is intended behavior and is opened for the
purpose of sending "management" traps
...
This port will remain in
the system while the SNMP service is running, but is not actively used
unless a management trap is to be sent outbound. Since SNMP does not
listen for inbound packets on this random port, this does not present
a security vulnerability.
I have an apache web server where most of my content is hosted, and then I have a node.js server I'm using for various tasks as well. I want users to be able to get information from my node.js server only through reverse proxy from my apache server. I understand how to set up a reverse proxy using mod_proxy on the apache side, but how can I restrict access to the node server except through an apache virtual host? One option I'm sure would work is to host my node server on a separate box and block any ip address except the apache server. Is there a way though that I could have them both running on the same machine and configure node to reject requests except from the apache server?
You could have the running on the same box. In the Node server have something like the following:
if(req.socket.remoteAddress !== '127.0.0.1'){
res.writeHead(403, {"Content-Type": "text/plain"});
res.write('403 Access Denied');
res.end();
} else {
// allow access
doSomething();
}
Of course, that allows other processes on the same box to connect to the Node server.
I've done this using iptables, allowing incoming connections to port 80 for the webserver. Access to port 3000 from the webserver is allowed because it's coming from the same host.
Here's an example rule file:
*filter
# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT
# Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allows all outbound traffic
# You could modify this to only allow certain traffic
-A OUTPUT -j ACCEPT
# Allows connections for HTTP
-A INPUT -p tcp --dport 80 -j ACCEPT
# Allows SSH connections
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
# Now you should read up on iptables rules and consider whether ssh access
# for everyone is really desired. Most likely you will only allow access from certain IPs.
# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
# log iptables denied calls (access via 'dmesg' command)
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
# Reject all other inbound - default deny unless explicitly allowed policy:
-A INPUT -j REJECT
-A FORWARD -j REJECT
COMMIT
Put this file on your server (e.g. /etc/iptables.up.rules), and run the iptables command to update your iptables rules.
iptables-restore < /etc/iptables.up.rules
I have been using wire-shark to analyse the packets of socket programs, Now i want to see the traffic of other hosts traffic, as i found that i need to use monitor mode that is only supported in Linux platform, so i tried but i couldn't capture any packets that is transferred in my network, listing as 0 packets captured.
Scenario:
I'm having a network consisting of 50+ hosts (all are powered by windows Except mine), my IP address is 192.168.1.10, when i initiate a communication between any 192.168.1.xx it showing the captured traffic.
But my requirement is to monitor the traffic of 192.168.1.21 b/w 192.168.1.22 from my host i,e. from 192.168.1.10.
1: is it possible to capture the traffic as i mentioned?
2: If it is possible then is wire-shark is right tool for it (or should i have to use differnt one)?
3: if it is not possible, then why?
Just adapt this a bit with your own filters and ips : (on local host)
ssh -l root <REMOTE HOST> tshark -w - not tcp port 22 | wireshark -k -i -
or using bash :
wireshark -k -i <(ssh -l root <REMOTE HOST> tshark -w - not tcp port 22)
You can use tcpdump instead of tshark if needed :
ssh -l root <REMOTE HOST> tcpdump -U -s0 -w - -i eth0 'port 22' |
wireshark -k -i -
You are connected to a switch which is "switching" traffic. It bases the traffic you see on your mac address. It will NOT send you traffic that is not destined to your mac address. If you want to monitor all the traffic you need to configure your switch to use a "port mirror" and plug your sniffer into that port. There is no software that you can install on your machine that will circumvent the way network switching works.
http://en.wikipedia.org/wiki/Port_mirroring
I have installed snmpd on my Ubuntu server via apt-get install snmpd snmp. Then I changed the line in /etc/default/snmpd
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid 0.0.0.0'
After that, I restarted the snmpd server(/etc/init.d/snmpd restart). However, when I ran netstat -an | grep "LISTEN ", I don't see snmpd is listening on port 161.
I don't have any firewall which blocks that port.
$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
User "nos" is correct; UDP bindings do not show up as "LISTEN" under "netstat". Instead, you will see a line or two like the following, showing that "snmpd" is indeed ready to receive data on UDP port 161:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:161 0.0.0.0:* 1785/snmpd
udp6 0 0 ::1:161 :::* 1785/snmpd
The "netstat" manpage has this to say about the "State" column:
The state of the socket. Since there are no states in raw mode and usually no states used in UDP, this column may be left blank.
Thus, you would not expect to see the word "LISTEN" here.
From a practical perspective, however, there is one more thing that I'd like to note. Often, the default Net-SNMP "snmpd.conf" configuration file limits incoming connections to only local processes.
Default /etc/snmp/snmpd.conf
# Listen for connections from the local system only
agentAddress udp:127.0.0.1:161
# Listen for connections on all interfaces (both IPv4 *and* IPv6)
#agentAddress udp:161,udp6:[::1]:161,tcp:161,tcp6:[::1]:161
Usually, the point of setting up "snmpd" is so that another machine can monitor it. To accomplish this, make sure that the first line is commented out and that the second line is enabled.
Looks like it is listening on 161/UDP. From the man page:
By default, snmpd listens for incoming SNMP requests on UDP port 161 on all IPv4 interfaces. However, it is possible to modify this behaviour by specifying one or more listening addresses as arguments to snmpd. A listening address takes the form: [<transport-specifier>:]<transport-address>
Read the man page for more details