Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] firewall on an nfs/ssh server
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 3996
Location: Bavaria

PostPosted: Tue Mar 21, 2023 11:06 pm    Post subject: Reply with quote

jyoung wrote:
[...] since any connections they would accept are already accepted by
Code:
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

No.

An example:
Code:
:INPUT DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

With this your firewall is completely closed. You can do nothing ... because ... ONLY established communication (I dont say "session" because this is true also for session-less protocols (like UDP)) are allowed ... but HOW do you want to establish a communication ... yes ... you must allow the first packet ... THIS you must do with some "special" rules ...

... Of course it WOULD be possible to allow: "...--ctstate NEW,RELATED,ESTABLISHED" ... THEN you would allow ALL ... you dont want

OK. Now you allow outgoing SSH with this rule:
Code:
-A OUTPUT -p tcp -m tcp --dport 22 -j ACCEPT

What happens ? Please work with "iptables -L -v -n"
You will see the counter of this rule swithces to 1. The first packet. And ALL other packets - IN AND OUT - are allowed automatically by both rules above and you see the counter rises up for these both.

OK Now you allow incoming SSH to your ssh-daemon with:
Code:
-A INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 22 -j ACCEPT

What happens if you connect from your LAN to this machine?
You will see the counter of this rule switches to 1. The first packet. And ALL other packets - IN AND OUT - are allowed automatically by both rules above and you see the counter rises up for these both.

OK. Next you have this rule:
Code:
-A INPUT -m geoip ! --source-country US  -j DROP

What happens if someone - not from USA - tries to connect to your sshd ? Kernel drops this packet ... and rises the counter of this rule to 1. Nothing more. There is no establisched communication and therefore nothing happens.

OK. Next you have this rule:
Code:
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

Everybody (from USA ... OR ... other country WHICH WAS NOT dropped one rule before) is allowed to try to connect to your sshd. If there is forbidden conect THEN the counter of this rule will raise up to 1 AND both other rules will raise up with SOME numbers (all packets which are necessary to deny a connect to your sshd).

All other is already said from @Hu: Checking if your outgoing traffic is coming from 192.168.0.0 is senseless ... Your outgoing traffic has ALWAYS the IP of your machine (e.g.192.168.0.7) and therefore is ALWAYS in your local network. What you want is: You want allow only ssh TO == destination your local machines.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 3996
Location: Bavaria

PostPosted: Tue Mar 21, 2023 11:47 pm    Post subject: Reply with quote

P.S.

Usually ... usually it is better to work with as less as possible rules. You do something which is not neceassary:

1. Allow all incoming SSH from your LAN
2. Deny incoming SSH from NOT US ( ! --source-country )
3. Allowing all other incoming SSH

Better is:

1. Allow all incoming SSH from your LAN
2. Alow all incoming SSH FROM US
3. ... nothing more ... because all other packets will be dropped by your default

This is best handled with a "personal" chain:

Do a new chain for incoming SSH (this is just a name; you can name it like you want):
Code:
iptables -N SSH_IN


ALLOW in this chain SSH IN from your local LAN ... AND ... ALLOW FROM US
Code:
iptables -A SSH_IN -s 192.168.0.0/24 -j ACCEPT
iptables -A SSH_IN -m geoip --src-country US -j ACCEPT


In your "main" table (=INPUT) you just ask if an incoming packet want to connect to port 22 ... and if yes ... you JUMP to your personal chain:
Code:
iptables -A INPUT -p tcp --dport 22 -j SSH_IN


There is no need to drop other packets ... because THIS is DONE by your default rule ... =DROP


BTW: It is not necessary to write "... -m tcp ..." because kernel knows that "iptables -A INPUT -p tcp --dport 22 ..." is sufficient.


Last edited by pietinger on Wed Mar 22, 2023 12:36 am; edited 1 time in total
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 3996
Location: Bavaria

PostPosted: Wed Mar 22, 2023 12:14 am    Post subject: Reply with quote

P.P.S.

I highly recommend to work with logging ... you also said you want to see from which countries someone is trying to connect to your sshd ... please let me add this to you ... EXAMPLE:



Code:
#!/bin/sh
set -eu

### Defines ###

# define logging
logit="-j LOG --log-prefix"

### Basic Settings ###

iptables -F
iptables -X
iptables -P INPUT       DROP
iptables -P OUTPUT      DROP
iptables -P FORWARD     DROP
iptables -A INPUT       -i lo -j ACCEPT
iptables -A OUTPUT      -o lo -j ACCEPT
iptables -A INPUT       -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT      -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT


### Chain SSH_IN

iptables -N SSH_IN
iptables -A SSH_IN -s 192.168.0.0/24 ${logit} "ACCEPT SSH IN from LAN "
iptables -A SSH_IN -s 192.168.0.0/24 -j ACCEPT
iptables -A SSH_IN -m geoip --src-cc US ${logit} "ACCEPT SSH IN from US "
iptables -A SSH_IN -m geoip --src-cc US -j ACCEPT

iptables -A SSH_IN -m geoip --src-cc CA ${logit} "DROP SSH IN from CA "
iptables -A SSH_IN -m geoip --src-cc DE ${logit} "DROP SSH IN from DE "
iptables -A SSH_IN -m geoip --src-cc JP ${logit} "DROP SSH IN from JP "
iptables -A SSH_IN -m geoip --src-cc FR ${logit} "DROP SSH IN from FR "
iptables -A SSH_IN -m geoip ! --src-cc CA,DE,JP,FR ${logit} "DROP SSH IN from OTHER "
iptables -A SSH_IN -j DROP


### Firewall In ###

iptables -A INPUT -p tcp --dport 22 -j SSH_IN

# Log all other before it will be dropped by DEFAULT
iptables -A INPUT ${logit} "DROP IN "


### Firewall Out ###

# ALLOW SSH out to EVERYwhere
iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT
# Allow NFS out to EVERYwhere
iptables -A OUTPUT -p tcp --dport 2049 -j ACCEPT

# Log all other before it will be dropped by DEFAULT
iptables -A OUTPUT ${logit} "DROP OUT "



(I think you will be able now to add incoming NFS ... ;-)
Back to top
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 436

PostPosted: Thu Mar 23, 2023 2:51 am    Post subject: Reply with quote

Interesting. pietinger, I've tried a variation on your example, where I've added a chain NFS_IN. This seems to work okay, and I'm seeing dropped connection messages now in /var/log/messages.


Code:
iptables -L -v -n
Chain INPUT (policy DROP 75 packets, 21714 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
 1201 92446 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    2   120 SSH_IN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
    0     0 NFS_IN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2049
   75 21714 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "DROP IN "

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy DROP 2 packets, 152 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
 1044  787K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2049
    2   152 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "DROP OUT "

Chain NFS_IN (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        all  --  *      *       192.168.0.0/24       0.0.0.0/0            LOG flags 0 level 4 prefix "ACCEPT NFS IN from LAN "
    0     0 ACCEPT     all  --  *      *       192.168.0.0/24       0.0.0.0/0           
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip --source-country US  LOG flags 0 level 4 prefix "ACCEPT NFS IN from US "
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip --source-country US
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip --source-country CA  LOG flags 0 level 4 prefix "DROP NFS IN from CA "
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip --source-country DE  LOG flags 0 level 4 prefix "DROP NFS IN from DE "
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip --source-country JP  LOG flags 0 level 4 prefix "DROP NFS IN from JP "
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip --source-country FR  LOG flags 0 level 4 prefix "DROP NFS IN from FR "
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip ! --source-country CA,DE,JP,FR  LOG flags 0 level 4 prefix "DROP NFS IN from OTHER "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain SSH_IN (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    1    60 LOG        all  --  *      *       192.168.0.0/24       0.0.0.0/0            LOG flags 0 level 4 prefix "ACCEPT SSH IN from LAN "
    1    60 ACCEPT     all  --  *      *       192.168.0.0/24       0.0.0.0/0           
    1    60 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip --source-country US  LOG flags 0 level 4 prefix "ACCEPT SSH IN from US "
    1    60 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip --source-country US
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip --source-country CA  LOG flags 0 level 4 prefix "DROP SSH IN from CA "
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip --source-country DE  LOG flags 0 level 4 prefix "DROP SSH IN from DE "
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip --source-country JP  LOG flags 0 level 4 prefix "DROP SSH IN from JP "
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip --source-country FR  LOG flags 0 level 4 prefix "DROP SSH IN from FR "
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip ! --source-country CA,DE,JP,FR  LOG flags 0 level 4 prefix "DROP SSH IN from OTHER "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           


However, the dropped connection messages look very strange. Here are three examples (I've removed the MAC addresses).


Code:
Mar 22 22:43:23 kernel: DROP IN IN=eth0 OUT= MAC= SRC=192.168.0.14 DST=255.255.255.255 LEN=436 TOS=0x00 PREC=0x00 TTL=64 ID=58505 PROTO=UDP SPT=17500 DPT=17500 LEN=416
Mar 22 22:43:37 kernel: DROP IN IN=eth0 OUT= MAC= SRC=192.168.0.11 DST=255.255.255.255 LEN=221 TOS=0x00 PREC=0x00 TTL=64 ID=23993 DF PROTO=UDP SPT=17500 DPT=17500 LEN=201
Mar 22 22:43:42 kernel: DROP IN IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=255.255.255.255 LEN=206 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=2190 DPT=2190 LEN=186


The strange thing is, it's dropping incoming connections for local machines. Maybe they should be dropped, since I'm guessing from "PROTO=UDP" that these are not ssh or nfs connections. But then why are these machines trying to connect? 192.168.0.11 is the local address of my workstation, and I am using ssh and nfs to connect to it now, so maybe we can explain that. But 192.168.0.14 is my partner's laptop, and 92.168.0.10 does not actually correspond to any machine currently on the network. What could this mean?
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 3996
Location: Bavaria

PostPosted: Thu Mar 23, 2023 2:32 pm    Post subject: Reply with quote

jyoung wrote:
However, the dropped connection messages look very strange. Here are three examples (I've removed the MAC addresses).

Code:
Mar 22 22:43:23 kernel: DROP IN IN=eth0 OUT= MAC= SRC=192.168.0.14 DST=255.255.255.255 LEN=436 TOS=0x00 PREC=0x00 TTL=64 ID=58505 PROTO=UDP SPT=17500 DPT=17500 LEN=416
Mar 22 22:43:37 kernel: DROP IN IN=eth0 OUT= MAC= SRC=192.168.0.11 DST=255.255.255.255 LEN=221 TOS=0x00 PREC=0x00 TTL=64 ID=23993 DF PROTO=UDP SPT=17500 DPT=17500 LEN=201
Mar 22 22:43:42 kernel: DROP IN IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=255.255.255.255 LEN=206 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=2190 DPT=2190 LEN=186


The strange thing is, it's dropping incoming connections for local machines. Maybe they should be dropped, since I'm guessing from "PROTO=UDP" that these are not ssh or nfs connections. But then why are these machines trying to connect? 192.168.0.11 is the local address of my workstation, and I am using ssh and nfs to connect to it now, so maybe we can explain that. But 192.168.0.14 is my partner's laptop, and 92.168.0.10 does not actually correspond to any machine currently on the network. What could this mean?

If you have a question about ports, take a look into:
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
here you will see you have dropbox in your network (you surely already know that 255.255.255.255 is a broadcast address == destination is every station in you netwrok)

You see working with logging is important if using a firewall ... not only to see real bad request, but also to see if you have forgot to allow something used ... 8)

Be sure you have a machine with IP address 192.168.0.10 in your network ... maybe a TV ... ?


BTW: For the future you surely will need to allow outgoing DNS (to your used DNS-server(-s)) and HTTP/HTTPS/RSYNC for your Gentoo portage to be able to update ... Maybe also NTP ... ;-)
Back to top
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 436

PostPosted: Sat Mar 25, 2023 5:16 pm    Post subject: Reply with quote

Hi All,

Thanks for helping me figure out iptables. I think at this point I have some really good working examples of the kind of things I want to do. I'm going to mark this thread as SOLVED.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 3996
Location: Bavaria

PostPosted: Sat Mar 25, 2023 11:01 pm    Post subject: Reply with quote

jyoung wrote:
Thanks for helping me figure out iptables.

You are very welcome !

Have fun with Gentoo ! :D
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum