[SOLVED] firewall on an nfs/ssh server

[jyoung]

I'm setting up an iptables firewall on an nfs/ssh sever, but I'm seeing entries in /var/log/messages which suggest that it's not working properly. Here is the
script I'm using to generate rules for iptables:

[jyoung]

I even just put the hacker's IP address in /etc/hosts.deny, but I'm still seeing failed password messages.

[Hu]

Rule 2 allows ssh from anywhere if rule 1 has not dropped it. Have you verified that the Chinese IP address is in fact considered ! --src-cc US? If rule 1 is confused and not dropping that traffic, then rule 2 would allow it.

How did you disallow root in sshd_config? How did your ssh client try to authenticate as root?

[pingtoo]

jyoung,

The "/etc/hosts.deny" is only used by sys-apps/tcp-wrappers, not firewall. Do you have sys-apps/tcp-wrappers? Is your sshd build with tcp-wrappers support? or your sshd will only start by tcpd? I think gentoo net-misc/openssh dropped support for tcp-wrappers

For firewall to work with geoip, You need kernel support. Do you have package net-firewall/xtables-addons installed? is your xtables-addons have USE flag for "geoip", Did you install geoip database? have a look at Gentoo wiki iptables for installation procedure

I found a example on how to configure iptables to manage geoip may be you can review it to see if it can help you.

I am sorry I hit you with so many questions. But we need to establish a base line in order for further discussion.

[jyoung]

Hu, is there a way I could trace the IP through the rules, and if it's considered by ! --src-cc US?

In sshd_config I have

[jyoung]

One more item: I also can't ssh from the server to another local machine. I'm new to iptables, so I suspect I've setup the rules incorrectly.

[Hu]

[pingtoo]

jyoung,

I think you asked two questions, One is iptables rule to log access from unknown origin and second sshd configuration for not allow root password login.

First I will suggest sshd_config setup then review iptables rule

sshd_config, I suggest you just turn off password authentication method altogether by default, only allow use publickey by default. Only allow Matched specific host(IP address(es)) use other authentication methods

[jyoung]

I've added the geoip logging to the script

[jyoung]

Hu, correct me if I'm wrong, but accepting an established connection would let me ssh back into the machine that I ssh'd from, right? Or would it really allow all connections on the LAN?

[Hu]

[pingtoo]

[jyoung]

Hmm, when I run

[pingtoo]

jyoung,

iptables, is not a user space process. It just a tool to manipulate in kernel netfilter module.

everytime you issue a iptables command it does something to the netfilter's rule, it is active right away.

The procedure you described is a way to persist the netfilter rules you defined.

if you ran your iptables script than reboot without some sort of persistent strategy you will lost you rules that store in the iptable script until you ran it again.

[Hu]

iptables-save "saves" the rules by printing them to stdout. You do not need to run it unless you want to see the rules or intend to redirect the output somewhere. As I interpret that output, your start overwrote whatever your custom script did, so the rules loaded now are not the ones you posted.

[jyoung]

Interesting, that would track with the seeming lack of dropped connections. So, iptables-save is basically the same as iptables -L. Here's what iptables -L prints for me after restarting the iptables service

[Hu]

I would say iptables-save is an inferior alternative to iptables -L, because iptables -L by design omits quite a bit of detail in the interest of brevity. Brevity is bad for troubleshooting posts. iptables-save shows almost all details by default. Only hit counters are omitted, and those can be shown with -c. As a matter of practice, I ask people to provide their iptables-save output when they want me to review their rules, because too many important details are hidden by iptables -L.

Starting the Gentoo iptables service replaces the rules with the ones saved from a prior run, which may be very permissive if nothing better was saved.

According to the limited output provided, you now have a rule which accepts all ssh traffic before considering its country of origin, which is consistent with your original complaint. It then accepts all that traffic 2 more times (uselessly, since a decision was already made), checks the country of origin, and accepts it again if the country check does not drop it (again, uselessly). It's possible that these rules are not what they seem, since you did not show the interface restriction, if any.

[pingtoo]

[pietinger]

jyoung,

have a look into "man iptables" ... You can delete all rules with "iptables -F" (from kernel; not from a saved file; you must do a save to have empty rules also in your file).

If you want your rules being activ again after your next reboot you (really) should add rc-script "iptables" to your runlevel "default" (if OpenRC; do the same if using systemd). This rc-script SAVES all rules into a file at shutdown and read this file again when booting (if you are using OpenRC you can do this save manually with "/etc/init.d/iptables save").

I recommend to view your rules with "iptables -L -v -n" (look into manpage) and then do sometimes a "iptables -Z" which set the packet count to zero, so you will see in which rule your counter rises up again.


Do you know what "stateful inspection" mean ? If no, let me explain shortly:

Your kernel inspects EVERY data packet. There was a time where you had only ONE chance to do firewalling; this one was (and still is):

1) If you want allow SSH traffic FROM your machine to another you must allow all packets FROM your machine with DESTINATION port 22 AND you must also allow all packets TO your machine with SOURCE port 22 ... BOTH WAYS ... THIS you have to do for every communication you want allow.

If you want allow that someone can connect to your sshd, you must allow packets TO your machine with DESTINATION port 22 AND also ...


TODAY we have a 2nd method: Statefull inspection:

2) You allow only the FIRST packet of your desired communication and your kernel knows which answer BELONGS to this packet. Now you can allow ALL ANSWERS with ONE rule: "iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT" for incoming packets and a 2nd rule for outgoing packets (if you do forwarding you need a 3rd one). These both rules will handle the COMPLETE session

You surely can imagine that this is easier than the old stateless inspection. Maybe you might look my firewall rules in (the 1st post):
https://forums.gentoo.org/viewtopic-t-1112806.html (its german; just look to my bash script for the INITIAL configuration)

[jyoung]

Okay, I think I see part of my issue. I was mixing up "rc-service iptables save" with "iptables-save". I'm now able to make edits to the firewall. That one hacker in China seems to have given up. However, I'm still having some trouble. Hackers with non-US IPs are still showing up in with "Failed password for invalid user", and also I can't ssh from the server to another machine on the LAN.

Here are the current firewall settings.

[Hu]

[pietinger]

jyoung,

you surely know that targets like ACCEPT or DROP (and REJECT) are "end-station" targets ... as soon as one rule fits kernel immediately allow (or forbid) this packet and stops checking rules after this rule. The LOG target is NOT an "end-station" rule: Kernel just logs something and proceed with checking next rules ... and IF NO rule fits kernel does what is DEFAULT for this chain ... You have as default for your OUTPUT accepting all ... so, every rule which accepts special outgoing traffic is ... senseless ... because it would be allowed by your default. For INPUT you have default DROP (=good) ... so, HERE you must allow something or you will have no communication.

In my firewall I forbid ALL (also OUTPUT) as default ... so, I must allow not only incoming traffic; I must allow also outgoing traffic.

[jyoung]

Okay, Hu, I think pietinger's comment echos a comment you made earlier, but I think I understand now. I'm on on the server and try to ssh into another machine, that's the "established" connection, whereas earlier I assumed that the established connection would be the ssh link that I used to get into the server.

As of now I can ssh into machines in the LAN. Fantastic! And, I am actually not seeing any new hackers in /var/log/messages since this morning.

Here are the current rules. Does this look reasonable?

[Hu]

You are getting closer. Allowing NFS over the Internet is unusual, so I wonder if you really meant to do that. As I noted before, your output rules are weird. You don't need source-specific rules if you reiterate them without a source qualifier. As I also wrote above, checking the source IP in the output rules is rarely useful. Did you mean to check the destination IP? Also, I should note that you presently do not allow outbound http/https, which may break the system package manager's ability to download updates.

[jyoung]