Unable to connect to imap via telnet remotely - linux

If I try:
telnet localhost 143
I can get access to imap
If I try
telnet server.name 143
I get
telnet: Unable to connect to remote host: Connection timed out
See output of my netstat.
netstat --numeric-ports -l | grep 143
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN
tcp6 0 0 :::143 :::* LISTEN
What does the above output mean?
Am at my wits end cannot get imap to work remotely, works perfectly with webmail on the server.
I'm accessing the server from laptop terminal remotely, and locally for localhost connection

The output you quote:
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN
tcp6 0 0 :::143 :::* LISTEN
means that you have a program (presumably your imap server) listening on port 143 via tcp (on both IPv4 and IPv6). And the "0.0.0.0" part means it should accept connections from any source. (If it said "127.0.0.1:143" for the local address, it would mean that only local connections would be accepted.)
So, since it looks like you have the serer listening correctly, I'd first check that server.name actually resolves to the correct IP address. Can you contact any other services on that server to make sure that part works?
Assuming that that works, then the next thing I'd check would be your firewall. You might look at http://www.cyberciti.biz/faq/howto-display-linux-iptables-loaded-rules/ but you could probably start by just running:
sudo iptables -L -v
On my machine which has no firewall rules I get this:
$ sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
If you get something much different, the I'd take a closer look to see if that's blocking your traffic.

Related

iptables TPROXY gets hit but doesn't redirect to port

I'm running Debian 8 with iptables.
I have the following rule:
iptables -t mangle -A PREROUTING -p tcp --dport 5000 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 4000
I simply want to redirect all traffic going with destination port 5000 to port 4000.
The standard iptables REDIRECT is not usable in my case, as it alters the packet and changes the original destination port.
Looking at iptables -t mangle -nvL I can see the rule being hit:
Chain PREROUTING (policy ACCEPT 5056 packets, 13M bytes)
pkts bytes target prot opt in out source destination
12 720 TPROXY tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5000 TPROXY redirect 0.0.0.0:4000 mark
0x1/0x1
But my service running on port 4000 doesn't intercept the packets.
I have a simple NodeJS application listening for all TCP on port 4000, which doesn't get any packets:
server.listen(4000, () => { console.log('listening on 4000'); });
Also, running wireshark on TCP port 4000 on all interfaces doesn't show anything.
You also need to set up the routing rule:
# 1 is --tproxy-mark parameter in iptables command
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

Blocking IP is not working

This question has been asked several times but none of the answers works for me. This is very simple, I want to block some IP access to a server
I tried this:
.htaccess
Order Deny,Allow
Deny from 151.101.52.84
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- 151.101.52.0/24 anywhere
REJECT tcp -- 151.101.52.84 anywhere tcp reject-with icmp-port-unreachable
DROP all -- 151.101.52.84 anywhere
DROP all -- 151.101.52.84 anywhere
DROP tcp -- 151.101.52.84 anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:http limit: avg 100/min burst 200
/etc/hosts.deny
ALL : 151.101.52.84
netstat -te | grep 151.101
tcp 0 1 ip-*-*-*-*.us-we:51181 151.101.52.84:http SYN_SENT apache 800352623
Already restarted httpd
Even I blocked the IP via Amazon EC2 VPC
Need to restart entire server? Need something else with iptables?
Have you tried Fail2Ban?
sudo apt-get install fail2ban

Can't access nginx accessible on private ip but not on public ip

I'm creating resources using terraform and I have a node in the subnet 172.1.0.0 with no security group or rules assigned to the node; the node has two endpoints 22 and 80.
I used nmap to confirm that the ports are open and they are:
nmap -Pn -sT -p T:11 some-ingress.cloudapp.net
Starting Nmap 6.47 ( http://nmap.org ) at 2016-07-08 19:02 EAT
Nmap scan report for some-ingress.cloudapp.net (1.2.3.4
Host is up (0.31s latency).
PORT STATE SERVICE
22/tcp open ssh
Nmap done: 1 IP address (1 host up) scanned in 1.34 seconds
nmap -Pn -sT -p T:80 some-ingress.cloudapp.net
Starting Nmap 6.47 ( http://nmap.org ) at 2016-07-08 19:02 EAT
Nmap scan report for some-ingress.cloudapp.net (1.2.3.4)
Host is up (0.036s latency).
PORT STATE SERVICE
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds
I've installed nginx on the node and running curl 172.1.0.4 and curl 127.0.0.1 and curl 0.0.0.0 gets me the default nginx page.
However running curl <public ip> or curl <dns name> hangs and I get a
curl: (56) Recv failure: Connection reset by peer
My iptables rules are:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:bootpc
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
ACCEPT udp -- anywhere anywhere udp dpt:bootps
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Why can't I possibly access nginx at the node's public ip?
The node is in a virtual network 172.1.0.0/16 and a subnet of 172.1.0.0/24 I can post the terraform configs if needed.

can not ftp localhost but can ftp from remote server

I have installed vsftp to the server , the status is running now , but when use the command ftp localhost , it pops the 421 Service not available. , would advise what is wrong ? thanks
bash-3.2# /etc/rc.d/init.d/vsftpd status
vsftpd (pid 580) is running...
bash-3.2# ps -ef |grep vsftpd
root 580 1 0 15:44 ? 00:00:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
root 607 467 0 15:45 pts/0 00:00:00 grep vsftpd
bash-3.2# ftp localhost
Connected to localhost (127.0.0.1).
421 Service not available.
the below is the output , would advise what can I do ? thanks
bash-3.2# netstat -tanp |grep ftp
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 3205/vsftpd
bash-3.2# ps -ef |grep ftp
root 3205 1 0 Feb02 ? 00:00:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
root 6075 5626 0 21:35 pts/0 00:00:00 grep ftp
bash-3.2# /sbin/iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
bash-3.2# /sbin/chkconfig --list |grep ip
all iptables are off
There is a parameter called tcp_wrappers=YES in vsftpd.conf. And it checks your hosts.deny file under /etc. You can change tcp_wrappers=NO or you can check your hosts.deny file under /etc
bash-3.2# ftp localhost
Connected to localhost (127.0.0.1).
421 Service not available.
It looks like you can connect, that is the server listens to this address (like you see with netstat too) and there are no iptables rules which block the connection.
Instead the server itself refuses to serve you. Therefore you need to look at the server logs and server configuration for help. Maybe you should look at the tcp_wrappers option and the related configuration in /etc/hosts.allow etc.

snmpd is not listening on port 161 on Ubuntu server

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

Resources