LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   fail2ban (ssh): localhost shows up in iptables (https://www.linuxquestions.org/questions/linux-networking-3/fail2ban-ssh-localhost-shows-up-in-iptables-4175553629/)

atelszewski.versades 09-16-2015 02:08 AM
fail2ban (ssh): localhost shows up in iptables
 
Hi,

I found a strange thing, that is localhost shows up in iptables as banned, what could be the cause of that?

Code:
Chain f2b-sshd (1 references)
target    prot opt source              destination       
REJECT    all  --  62-210-254-20.rev.poneytelecom.eu  anywhere            reject-with icmp-port-unreachable
REJECT    all  --  119.81.234.37-static.reverse.softlayer.com  anywhere            reject-with icmp-port-unreachable
REJECT    all  --  localhost            anywhere            reject-with icmp-port-unreachable
RETURN    all  --  anywhere            anywhere
Some details:
Code:
$ grep 127 /etc/fail2ban/jail.local
ignoreip = 127.0.0.1/8
Code:
$ grep 127 /var/log/fail2ban.log*
/var/log/fail2ban.log.1:2015-09-10 13:57:25,664 fail2ban.filter        [4181]: WARNING Determined IP using DNS Lookup: localhost = ['127.0.0.1']
/var/log/fail2ban.log.1:2015-09-10 13:57:25,666 fail2ban.filter        [4181]: WARNING Determined IP using DNS Lookup: localhost = ['127.0.0.1']
/var/log/fail2ban.log.1:2015-09-10 14:00:02,952 fail2ban.filter        [22355]: WARNING Determined IP using DNS Lookup: localhost = ['127.0.0.1']
/var/log/fail2ban.log.1:2015-09-10 14:00:02,954 fail2ban.filter        [22355]: WARNING Determined IP using DNS Lookup: localhost = ['127.0.0.1']
/var/log/fail2ban.log.1:2015-09-10 15:51:00,634 fail2ban.filter        [22355]: INFO    [sshd] Ignore 127.0.0.1 by ip
BTW, I can ssh to the localhost without any problems.

Thanks for the help!

--
Best regards,
Andrzej Telszewski

zhjim 09-16-2015 02:30 AM
Actually it blocks ssh connection from localhost. Thus no need to worry. But as the destination beeing anywhere you should not be able to ssh localhost on the machine itself. Only if you have some kind of iptables -d localhost -j ACCEPT rule somewhere.

But why localhost gets into the ban list i have no clue. Also the fail2ban log ist not really telling why it looks for localhost. Do you have any cronjobs doing some ssh connections to your host?
Maybe you could try 127.0.0.1/24 inside you jail.local config.

atelszewski.versades 09-16-2015 02:58 AM
Hi,

Quote:
But as the destination beeing anywhere you should not be able to ssh localhost on the machine itself.
I'm perfectly able to ssh to localhost from lohalhost. Maybe the SRC port is different?

Quote:
Only if you have some kind of iptables -d localhost -j ACCEPT rule somewhere.
Well, I have, but if I'm correct, it's after f2b rules, but I might be wrong.

That's my iptables:
Code:
Chain INPUT (policy DROP)
target    prot opt source              destination       
f2b-sshd  tcp  --  anywhere            anywhere            multiport dports ssh
ACCEPT    all  --  loopback/8          loopback/8         
ACCEPT    all  --  10.20.30.0/24        10.20.30.0/24     
ACCEPT    icmp --  anywhere            anywhere            icmp echo-request limit: avg 1/sec burst 2
ACCEPT    tcp  --  anywhere            anywhere            tcp dpt:ssh
ACCEPT    udp  --  192.168.1.0/24      anywhere            state NEW udp spt:netbios-ns
ACCEPT    all  --  10.7.4.0/24          10.7.4.0/24       
ACCEPT    tcp  --  anywhere            anywhere            tcp dpts:10000:10002
ACCEPT    all  --  anywhere            anywhere            state RELATED,ESTABLISHED

Chain FORWARD (policy DROP)
target    prot opt source              destination       
ACCEPT    all  --  10.20.30.0/24        anywhere            ctstate NEW
ACCEPT    all  --  10.7.4.0/24          192.168.1.0/24      ctstate NEW
ACCEPT    all  --  anywhere            anywhere            ctstate RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target    prot opt source              destination       

Chain f2b-sshd (1 references)
target    prot opt source              destination       
REJECT    all  --  62-210-254-20.rev.poneytelecom.eu  anywhere            reject-with icmp-port-unreachable
REJECT    all  --  119.81.234.37-static.reverse.softlayer.com  anywhere            reject-with icmp-port-unreachable
REJECT    all  --  localhost            anywhere            reject-with icmp-port-unreachable
RETURN    all  --  anywhere            anywhere
Quote:
Do you have any cronjobs doing some ssh connections to your host?
Nope.

Quote:
Maybe you could try 127.0.0.1/24 inside you jail.local config.
Why would it help?

I have:
Code:
ifconfig lo
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Local Loopback)
        RX packets 12629  bytes 10030398 (9.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 12629  bytes 10030398 (9.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
so the mask is 8 bits.

--
Best regards,
Andrzej Telszewski

zhjim 09-16-2015 03:35 AM
As the fail2ban chain is first the localhost iptables rules should not matter. Also the rules says something about multiport dports ssh what ever that means. But no source port mentioned.

My bad with the 127.0.0.1/24 i ment 127.0.0.1/32 to directly address the host and not a network. Also this is just a stab in the dark. Just aims to get the localhost out of fail2ban.

Next on the list would be to find out from where your ssh localhost connection origin from. If you have a listen configuration of sshd its propably on a routable ip address and thus the connection should not origin from 127.0.0.1 but something like 192.168.0.1. Maybe do a ssh -v localhost and see if it prints any ip's. Maybe add some more -v to get more verbose output. Also check netstat -tulpn | grep ssh to see the ports and ip's sshd listens on.
Do you have ipv6 in action? Maybe the ssh connection walks this way. Any iptables on ipv6? Can fail2ban work with ipv6? Is it configured?


If I may give you a hint:
Just some minor improvement to your overall iptables setup would be to get the -m state --state ESTABLISHED,RELATED part as highest as possible. Less rules have to be checked this way.

atelszewski.versades 09-18-2015 04:56 AM
Hi,

Some more background information, but I believe it doesn't matter:
1. I'm running Slackware 14.0 and the package was meant for Slackware 14.1 (from http://slackbuilds.org/).
2. I have added file paths-overrides.local with:
Code:
[DEFAULT]
sshd_log = /var/log/messages
because for whatever reason the authentication messages from sshd shows up in /var/log/messages.
3. I have set net.ipv4.conf.all.arp_ignore=1, because there are users on the LAN that sometimes were directed to my host, because my internal network has the same subnet that LAN users sometimes configure on their LAN interfaces (e.g. they have two subnets on single LAN interface and I also have these two subnets but on different interfaces). I hope I'm clear enough;)

Quote:
As the fail2ban chain is first the localhost iptables rules should not matter.
What do you mean? Which "iptables rules" "should not matter"?

Quote:
Also the rules says something about multiport dports ssh what ever that means. But no source port mentioned.
multiport dports ssh: if I'm not mistaken, you can consider this to be destination port 22; multiport allows you to specify multiple ports and in this case port 22 (ssh) is specified.

Quote:
My bad with the 127.0.0.1/24 i ment 127.0.0.1/32 to directly address the host and not a network. Also this is just a stab in the dark. Just aims to get the localhost out of fail2ban.
I don't think it could help, unless there is error in f2b. 127.0.0.1/24 excludes much bigger range than 127.0.0.1/32;)

Quote:
Next on the list would be to find out from where your ssh localhost connection origin from. If you have a listen configuration of sshd its propably on a routable ip address and thus the connection should not origin from 127.0.0.1 but something like 192.168.0.1. Maybe do a ssh -v localhost and see if it prints any ip's. Maybe add some more -v to get more verbose output. Also check netstat -tulpn | grep ssh to see the ports and ip's sshd listens on.
Code:
$ netstat -tulpn | grep ssh
tcp        0      0 0.0.0.0:22              0.0.0.0:*              LISTEN      1171/sshd
Then I checked with Wireshark:
1. When I initiate the ssh to localhost, src port is 54901 and dst port is 22, so no rule in iptables should block it.
2. Then I have reply from src port 22 to dst port 54901 and again no rule should block it, because f2b-sshd rules triggers on dst port 22 and the dst port now is 54901.
3. And then the ssh conversion goes on without problems.

Quote:
Do you have ipv6 in action? Maybe the ssh connection walks this way. Any iptables on ipv6? Can fail2ban work with ipv6? Is it configured?
No IPv6 at all, disabled at boot time with ipv6.disable=1 kernel parameter.

Quote:
If I may give you a hint:
Just some minor improvement to your overall iptables setup would be to get the -m state --state ESTABLISHED,RELATED part as highest as possible. Less rules have to be checked this way.
I read somewhere that placing ESTABLISHED,RELATED at the end helps preventing DoS attacks, but I have no idea if it's true or not.

I'm pasting my complete iptables configuration here. If you see something strange, then please let me know:
Code:
  $IPT -F
  $IPT -X
  $IPT -t nat -F
  $IPT -t nat -X
  $IPT -t mangle -F
  $IPT -t mangle -X

  $IPT -P INPUT  DROP
  $IPT -P FORWARD DROP
  $IPT -P OUTPUT  ACCEPT

  ## Loopback.
  $IPT -A INPUT -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT

  ## Embedded device cross development. The device is connected to
  ## separate NIC and should have Internet access.
  $IPT -A INPUT -i eth1 -s 10.20.30.0/24 -d 10.20.30.0/24 -j ACCEPT
  $IPT -A FORWARD -i eth1 -s 10.20.30.0/24 -m conntrack --ctstate NEW -j ACCEPT
  $IPT -A POSTROUTING -s 10.20.30.0/24 -t nat -j MASQUERADE

  ## Accept PING on all NICs.
  $IPT -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/second --limit-burst 2 -j ACCEPT

  ## Accept SSH on all NICs.
  $IPT -A INPUT -p tcp --dport ssh -j ACCEPT

  ## Windows shares.
  #$IPT -A INPUT -p udp -s 192.168.1.0/24 -m state --state NEW -m udp --dport netbios-ns  -j ACCEPT
  #$IPT -A INPUT -p udp -s 192.168.1.0/24 -m state --state NEW -m udp --dport netbios-dgm  -j ACCEPT
  #$IPT -A INPUT -p tcp -s 192.168.1.0/24 -m state --state NEW -m tcp --dport netbios-ssn  -j ACCEPT
  #$IPT -A INPUT -p tcp -s 192.168.1.0/24 -m state --state NEW -m tcp --dport microsoft-ds -j ACCEPT
  ## Allow NetBIOS Name Service response to arrive.
  $IPT -A INPUT -p udp -s 192.168.1.0/24 -m state --state NEW -m udp --sport netbios-ns  -j ACCEPT

  ## BitTorrent.
  #$IPT -A INPUT -p udp --dport 6881:6999 -j ACCEPT
  #$IPT -A INPUT -p tcp --dport 6881:6999 -j ACCEPT
  #$IPT -A INPUT -p udp --dport 7881      -j ACCEPT

  ## Virtual machine networking. The machines are connected to separate
  ## NIC and should not have Internet access.
  $IPT -A INPUT -i vmnet0 -s 10.7.4.0/24 -d 10.7.4.0/24 -j ACCEPT
  $IPT -A FORWARD -i vmnet0 -s 10.7.4.0/24 -d 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT
  $IPT -A POSTROUTING -s 10.7.4.0/24 -d 192.168.1.0/24 -t nat -j MASQUERADE

  # mbnodemanager test ports (proprietary application).
  $IPT -A INPUT -p tcp --dport 10000:10002 -j ACCEPT

  ## Forwarding: established and related.
  $IPT -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
  ## Incoming connections: established and related (this rule at the end to prevent DoS).
  $IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Another interesting thing. Last time I checked, localhost was unbanned and at the moment it is banned again. And the log:
Code:
$ grep "127\|local" /var/log/fail2ban.log*
/var/log/fail2ban.log:2015-09-16 08:47:21,270 fail2ban.transmitter    [15698]: WARNING Command ['set', 'sshd', 'unbanip', 'localhost'] has failed. Received ValueError('IP localhost is not banned',)
/var/log/fail2ban.log:2015-09-16 08:47:31,750 fail2ban.transmitter    [15698]: WARNING Command ['set', 'sshd', 'unbanip', '127.0.0.1'] has failed. Received ValueError('IP 127.0.0.1 is not banned',)
/var/log/fail2ban.log.1:2015-09-10 13:57:25,664 fail2ban.filter        [4181]: WARNING Determined IP using DNS Lookup: localhost = ['127.0.0.1']
/var/log/fail2ban.log.1:2015-09-10 13:57:25,666 fail2ban.filter        [4181]: WARNING Determined IP using DNS Lookup: localhost = ['127.0.0.1']
/var/log/fail2ban.log.1:2015-09-10 14:00:02,952 fail2ban.filter        [22355]: WARNING Determined IP using DNS Lookup: localhost = ['127.0.0.1']
/var/log/fail2ban.log.1:2015-09-10 14:00:02,954 fail2ban.filter        [22355]: WARNING Determined IP using DNS Lookup: localhost = ['127.0.0.1']
/var/log/fail2ban.log.1:2015-09-10 15:51:00,634 fail2ban.filter        [22355]: INFO    [sshd] Ignore 127.0.0.1 by ip
seems to not give any reason for that at all.

Any ideas?

--
Best regards,
Andrzej Telszewski

zhjim 09-18-2015 05:51 AM
Points 1, 2, and 3 should not really matter here. Actually I don't know what option 3 does :)


Quote:
Originally Posted by atelszewski.versades (Post 5422169)
What do you mean? Which "iptables rules" "should not matter"?
Judging by the rule the sshd connection from localhost should be blocked. First rule in INPUT jumps to the fail2ban chain which has the block localhost rule. As the second rule in INPUT comes the allow all from and to localhost. But as fail2ban comes first and blocks localhost the traversal of the iptables rules should stop. Thus rule 2 has no effect.


Quote:
Originally Posted by atelszewski.versades (Post 5422169)
multiport dports ssh: if I'm not mistaken, you can consider this to be destination port 22; multiport allows you to specify multiple ports and in this case port 22 (ssh) is specified.
Seems just to be the way fail2ban works. All good thus far.

Quote:
Originally Posted by atelszewski.versades (Post 5422169)
I don't think it could help, unless there is error in f2b. 127.0.0.1/24 excludes much bigger range than 127.0.0.1/32;)
Depends on how fail2ban works. Like I said. Just a stab in the dark


Quote:
Originally Posted by atelszewski.versades (Post 5422169)
Then I checked with Wireshark:
1. When I initiate the ssh to localhost, src port is 54901 and dst port is 22, so no rule in iptables should block it.
2. Then I have reply from src port 22 to dst port 54901 and again no rule should block it, because f2b-sshd rules triggers on dst port 22 and the dst port now is 54901.
3. And then the ssh conversion goes on without problems.
Whats important here is the ip the connection origins from and not the port.

Quote:
Originally Posted by atelszewski.versades (Post 5422169)
I read somewhere that placing ESTABLISHED,RELATED at the end helps preventing DoS attacks, but I have no idea if it's true or not.
Okay no clue here either. But I say its more related to NEW connections though heavily depends on the type of DoS.

Best way to find out why localhost is blocked might be to check /var/log/messages with the regex that are within fail2ban configuration files.

atelszewski.versades 09-18-2015 06:41 AM
Hi,

Quote:
Quote:
3. I have set net.ipv4.conf.all.arp_ignore=1, because there are users on the LAN that sometimes were directed to my host, because my internal network has the same subnet that LAN users sometimes configure on their LAN interfaces (e.g. they have two subnets on single LAN interface and I also have these two subnets but on different interfaces).
Actually I don't know what option 3 does
I'm sorry for the confusion. net.ipv4.conf.all.arp_ignore=1 is not setting of fail2ban, it's sysctl one.
Have a look here: Preventing ARP flux on Linux
Basically, I have two NICs, eth0 and eth1, eth0 is 192.168.1.0/24 and eth1 is 10.20.30.0/24. eth0 is on LAN, eth1 is for my private use. If net.ipv4.conf.all.arp_ignore is set to 0 (default) and ARPs (that is "who has X.X.X.X") made on LAN 192.168.1.0/24, querying about who has something in 10.20.30.0/24, will resolve to my private eth1. And I need to prevent this behavior. Setting net.ipv4.conf.all.arp_ignore to 1 will make my box not to respond to queries about 10.20.30.0/24 (eth1), if they come from 192.168.1.0/24 (eth0).

Quote:
First rule in INPUT jumps to the fail2ban chain which has the block localhost rule.
Quote:
Whats important here is the ip the connection origins from and not the port.
Yep, it seems that you're right. If I see it correctly, the flow should be:
1. I try to connect to localhost:ssh.
2. f2b-sshd target should be run, because dst port in 1) is ssh.
3. REJECT target of f2b-sshd should be run, because source addr is localhost and localhost is banned.

Well, I don't why it does not work.

Quote:
Best way to find out why localhost is blocked might be to check /var/log/messages with the regex that are within fail2ban configuration files.
Without the regex at the moment, but should this one look suspicious?:
Code:
$ grep localhost /var/log/messages*
/var/log/messages:Sep 16 02:10:28 pc-andtel sshd[9865]: Address 113.175.178.110 maps to localhost, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
/var/log/messages:Sep 16 02:10:32 pc-andtel sshd[9876]: Address 113.175.178.110 maps to localhost, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
/var/log/messages:Sep 16 02:10:36 pc-andtel sshd[9884]: Address 113.175.178.110 maps to localhost, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
/var/log/messages:Sep 16 02:10:42 pc-andtel sshd[9895]: Address 113.175.178.110 maps to localhost, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
/var/log/messages:Sep 16 02:10:45 pc-andtel sshd[9903]: Address 113.175.178.110 maps to localhost, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
/var/log/messages:Sep 18 00:44:35 pc-andtel sshd[13180]: Address 113.175.178.110 maps to localhost, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
/var/log/messages:Sep 18 00:44:39 pc-andtel sshd[13188]: Address 113.175.178.110 maps to localhost, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
/var/log/messages:Sep 18 00:44:42 pc-andtel sshd[13197]: Address 113.175.178.110 maps to localhost, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
/var/log/messages:Sep 18 00:44:46 pc-andtel sshd[13204]: Address 113.175.178.110 maps to localhost, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
/var/log/messages:Sep 18 00:44:49 pc-andtel sshd[13212]: Address 113.175.178.110 maps to localhost, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
/var/log/messages:Sep 18 00:44:53 pc-andtel sshd[13219]: Address 113.175.178.110 maps to localhost, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
/var/log/messages:Sep 18 00:44:55 pc-andtel sshd[13226]: Address 113.175.178.110 maps to localhost, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
For a moment I though it could be me logging from the other place, but looking at the IP (113.175.178.110) it's not possible.

Oh lord, look at this:
Code:
$ iptables -nL --line-numbers
Chain INPUT (policy DROP)
num  target    prot opt source              destination       
1    f2b-sshd  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22
2    ACCEPT    all  --  127.0.0.0/8          127.0.0.0/8       
3    ACCEPT    all  --  10.20.30.0/24        10.20.30.0/24     
4    ACCEPT    icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 8 limit: avg 1/sec burst 2
5    ACCEPT    tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22
6    ACCEPT    udp  --  192.168.1.0/24      0.0.0.0/0            state NEW udp spt:137
7    ACCEPT    all  --  10.7.4.0/24          10.7.4.0/24       
8    ACCEPT    tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpts:10000:10002
9    ACCEPT    all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Chain FORWARD (policy DROP)
num  target    prot opt source              destination       
1    ACCEPT    all  --  10.20.30.0/24        0.0.0.0/0            ctstate NEW
2    ACCEPT    all  --  10.7.4.0/24          192.168.1.0/24      ctstate NEW
3    ACCEPT    all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
num  target    prot opt source              destination       

Chain f2b-sshd (1 references)
num  target    prot opt source              destination       
1    REJECT    all  --  222.186.21.208      0.0.0.0/0            reject-with icmp-port-unreachable
2    REJECT    all  --  113.175.178.110      0.0.0.0/0            reject-with icmp-port-unreachable
3    RETURN    all  --  0.0.0.0/0            0.0.0.0/0
And now at this:
Code:
$ iptables -L
Chain INPUT (policy DROP)
target    prot opt source              destination       
f2b-sshd  tcp  --  anywhere            anywhere            multiport dports ssh
ACCEPT    all  --  loopback/8          loopback/8         
ACCEPT    all  --  10.20.30.0/24        10.20.30.0/24     
ACCEPT    icmp --  anywhere            anywhere            icmp echo-request limit: avg 1/sec burst 2
ACCEPT    tcp  --  anywhere            anywhere            tcp dpt:ssh
ACCEPT    udp  --  192.168.1.0/24      anywhere            state NEW udp spt:netbios-ns
ACCEPT    all  --  10.7.4.0/24          10.7.4.0/24       
ACCEPT    tcp  --  anywhere            anywhere            tcp dpts:10000:10002
ACCEPT    all  --  anywhere            anywhere            state RELATED,ESTABLISHED

Chain FORWARD (policy DROP)
target    prot opt source              destination       
ACCEPT    all  --  10.20.30.0/24        anywhere            ctstate NEW
ACCEPT    all  --  10.7.4.0/24          192.168.1.0/24      ctstate NEW
ACCEPT    all  --  anywhere            anywhere            ctstate RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target    prot opt source              destination       

Chain f2b-sshd (1 references)
target    prot opt source              destination       
REJECT    all  --  222.186.21.208      anywhere            reject-with icmp-port-unreachable
REJECT    all  --  localhost            anywhere            reject-with icmp-port-unreachable
RETURN    all  --  anywhere            anywhere
Why the hell 113.175.178.110 is displayed as localhost in the second command?

--
Best regards,
Andrzej Telszewski

zhjim 09-18-2015 07:53 AM
Check /etc/hosts why 113.175.*.* is treated as localhost.

Quote:
/var/log/messages:Sep 16 02:10:28 pc-andtel sshd[9865]: Address 113.175.178.110 maps to localhost, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
If I recall correctly sshd has the option to do a reverse lookup of ip. And this is definitely the culprint of this fail2ban hick up. As well it explains why you can ssh into your local machine. Taken that 127.0.0.1 is the source address.

I'm a bit sleepy from lunch I check back later if i spot something more.

atelszewski.versades 09-18-2015 08:33 AM
Hi,

Quote:
Check /etc/hosts why 113.175.*.* is treated as localhost.
Code:
127.0.0.1                localhost
127.0.0.1                pc-andtel
So no problem here.

I did a bit of Wireshark and then:
Code:
$ nslookup 113.175.178.110
Server:                8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
110.178.175.113.in-addr.arpa        name = localhost.

Authoritative answers can be found from:
Well, 8.8.8.8 is Google's DNS. What the hell?


This reminds of a situation I had some time ago. If I entered non-existent address (I don't remember exactly if it was domain or IP) in the webbrowser I was always redirected to my own localhost server. I wonder if the current situation has anything to do with the old one.

Is it possible to protect against this situation?

--
Best regards,
Andrzej Telszewski

zhjim 09-22-2015 08:46 AM
On me machine it shows the same. Also using internal dns servers and not google ones. Also only with nslookup. With dig I get an emtpy ptr record. strange, strange. Also this would mean that the internal dns stack uses the logic of nslookup. What ever that means (:.

Maybe try to add 113.175... localhost to /etc/hosts. Or better
113.175.. pc-andtel to /etc/hosts.

atelszewski.versades 09-23-2015 02:37 AM
Hi,

Quote:
Maybe try to add 113.175... localhost to /etc/hosts. Or better
113.175.. pc-andtel to /etc/hosts.
Why would I do that? I actually don't want 113.175.178.110 to be returned as localhost ;)

I've been thinking if it would be possible to have some filter rules, looking into the DNS packets and changing them to something like "no such domain".
It would happen in 2 cases:
1) you want to check some domain and the reply from the DNS contains 127.0.0.0/8. This would prevent domains other than localhost resolving to 127.0.0.0/8.
2) you want to check some IP and the reply is localhost (like in our discussion). This would prevent IPs other than 127.0.0.0/8 resolving to localhost.

--
Best regards,
Andrzej Telszewski

atelszewski.versades 09-29-2015 02:16 AM
Hi,

Here we go again:
Code:
$ nslookup 188.225.76.121
Server:                8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
121.76.225.188.in-addr.arpa        name = .

Authoritative answers can be found from:
--
Best regards,
Andrzej Telszewski

zhjim 09-29-2015 03:13 AM
If you add your ip with a proper name to /etc/hosts sshd can pick that up and dont need to do an external lookup. Though dont put it in as localhost but the hostname you are using (pc-andtel it is?).

To get rid of the localhost from fail2ban you could add your outward ip to fail2ban ignore file. Just like 127.0.0.1.

Or put "UseDNs no" to your sshd_config
Quote:
UseDNS Specifies whether sshd(8) should look up the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address. The default is “yes”.
This will also get rid of the log line and have fail2ban not ban "localhost".

The approach with the filter rules would be huge. Might be easier to install a local dns server like dnsmasq or go big with bind.
If you only want to block those dns packages look into the string module of iptables.

Quote:
string
This modules matches a given string by using some pattern matching strategy. It requires a linux kernel >= 2.6.14.

--algo {bm|kmp}
Select the pattern matching strategy. (bm = Boyer-Moore, kmp = Knuth-Pratt-Morris)

--from offset
Set the offset from which it starts looking for any matching. If not passed, default is 0.

--to offset
Set the offset up to which should be scanned. That is, byte offset-1 (counting from 0) is the last one that is scanned. If not passed, default is the packet size.

[!] --string pattern
Matches the given pattern.

[!] --hex-string pattern
Matches the given pattern in hex notation.
iptables -A OUTPUT -p udp --dport 53 -m string --string 127.0.0.1 -j REJECT

The same for tcp or just leave out -p. To be faster on the search get a dump of an dns lookup and use --from and --to to narrow it down.

atelszewski.versades 11-05-2015 08:05 AM
Hi,

Quote:
If you add your ip with a proper name to /etc/hosts sshd can pick that up and dont need to do an external lookup. Though dont put it in as localhost but the hostname you are using (pc-andtel it is?).
I don't actually understand what you mean. Why would sshd need to do lookup on localhost? The only situation would be if I ssh locally, which is not the case 99.9% of the time. Anyway, localhost and pc-andtel were already in /etc/hosts.

Quote:
To get rid of the localhost from fail2ban you could add your outward ip to fail2ban ignore file. Just like 127.0.0.1.
Well, that's the thing now. I think that everything is correct here and I actually don't have to change anything. The problem is and was that, when listing blocked IP-s using iptables, iptables would resolve the IP-s names, and crucially, some of the IP-s resolve to, you guess it, localhost. But I don't think fail2ban or anything else gets confused and operates incorrectly - it is only us that are mislead by crappy DNS names being returned.

Quote:
Or put "UseDNs no" to your sshd_config
Did just that.

Quote:
The approach with the filter rules would be huge.
OK, I'm gonna give up on that. Using:
Code:
$ iptables -nL
gives the IP-s without resolving the names, which is fair enough for me.

Thanks for the help!

--
Best regards,
Andrzej Telszewski

HugoMeyer 01-09-2017 06:34 AM
Looking sideways
 
Hi,

In my case iptables -L shows localhost, however when iptables is run with -nL it shows an IP:

REJECT all -- localhost anywhere reject-with icmp-port-unreachable
REJECT all -- localhost anywhere reject-with icmp-port-unreachable

REJECT all -- 123.31.34.140 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 123.31.32.9 0.0.0.0/0 reject-with icmp-port-unreachable

# nslookup
> 123.31.34.140
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
140.34.31.123.in-addr.arpa name = localhost.

Perhaps they want one to do something silly resulting in ban2fail being stopped ...

my 2c.


All times are GMT -5. The time now is 09:09 PM.