netfilter Digest, Vol 17, Issue 15

hgfhg

Send netfilter mailing list submissions to
[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.netfilter.org/mailman/listinfo/netfilter
or, via email, send a message with subject or body 'help' to
[email protected]

You can reach the person managing the list at
[email protected]

When replying, please edit your Subject line so it is more specific than "Re: Contents of netfilter digest..."

Today's Topics:

1. connection time (jonathan)
2. Re: connection time (Sp0oKeR)
3. RE: connection time (Rob Sterenborg)
4. Re: Very wierd problem (Svenne Krap)
5. RE: FORWARD Chain Question (Gene Dellinger)
6. Allowing Samba Access to certain IPs (Jason)
7. Re: Allowing Samba Access to certain IPs PLEASE DISREGARD THIS EMAIL (Jason)

----------------------------------------------------------------------

Message: 1
Date: Mon, 12 Dec 2005 18:24:27 +0100
From: jonathan <[email protected]>
Subject: connection time
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain

hi,
Is there a way to limit the ssh connection time through via an Iptables rule ?

------------------------------

Message: 2
Date: Mon, 12 Dec 2005 15:40:14 -0200
From: Sp0oKeR <[email protected]>
Subject: Re: connection time
To: jonathan <[email protected]>
Cc: [email protected]
Message-ID:

	<[email protected]>

Content-Type: text/plain; charset=UTF-8

I think uou can use time patch ( Patch O Matic) to do this.

http://www.netfilter.org/projects/patch-o-matic/pom-base.html#pom-base-time

Regards,

Sp0oKeR

Iptables

--
=====================
Rodrigo Ribeiro Montoro
Desenvolvedor BRMAlinux
[email protected]
RHCE/LPIC-I
=====================

------------------------------

Message: 3
Date: Mon, 12 Dec 2005 19:00:22 +0100
From: "Rob Sterenborg" <[email protected]>
Subject: RE: connection time
To: <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="US-ASCII"

- If you are referring to a start date/time and stop date/time, you can use the time patch.

- If you are referring to limiting a connection to eg 20 minutes from the time the connection was initiated, you can use the expire patch.

Gr,
Rob

------------------------------

Message: 4
Date: Mon, 12 Dec 2005 20:20:37 +0100
From: Svenne Krap <[email protected]>
Subject: Re: Very wierd problem
To: Derick Anderson <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

Hi again.

Well you intuition wasn't far off. After an uncanny amount of hours of testing different things, I found the solution. (I did learn that for the next time, tcpdump has the first try to find the problem ;)

It seems like the firewall in front of the customer (or perhaps his computer/application) sets the "dont fragment" bit on the packages (I believe that is fairly uncommon?). The package arrives fine at my firewall, but as there are VLANs behind the firewall, the MTU of 1500 is

four bytes too long to continue past the firewall. Normally, the package

would be fragmented by my firewall (as I understand it) and served. Unfortunately, the DF-flag prevents this, so my firewall bails out with an ICMP type 3 message subtype 4 (unreachable - need to frag). This message seems to get lost at the firewall in front of my customer (of which he has no control). So his application waits for an acceptance of the package which my firewall dropped due to being too big.

The problem has been verified by setting the MTU to 1496 on his computer, after which everything runs flawlessy.

I must admit, that I am not that strong within MTU discovery and ICMP messages (the above is based on what I have read to day and found out by

tcpdump).

Here is the relevant piece of tcpdump (81.7.170.138 is my firewall, 81.7.185.77 is a temp IP used for debugging his server (oh, the joy of DNAT ;) and 80.63.34.250 is my clients ip:

14:26:45.691261 IP 80.63.34.250.2831 > 81.7.185.77.22: . 5460:5672(212) ack 305 win 64671

14:26:45.691333 IP 80.63.34.250.2831 > 81.7.185.77.22: P 6588:7100(512) ack 305 win 64671

14:26:45.691386 IP 81.7.185.77.22 > 80.63.34.250.2831: . ack 6588 win 12040 <nop,nop,sack sack 1 {7432:11100} >

14:26:45.691480 IP 81.7.185.77.22 > 80.63.34.250.2831: . ack 7100 win 12800 <nop,nop,sack sack 1 {7432:11100} >

14:26:45.692357 IP 80.63.34.250.2831 > 81.7.185.77.22: P 11100:12560(1460) ack 305 win 64671

14:26:45.692368 IP 81.7.170.138 > 80.63.34.250: icmp 556: 81.7.185.77 unreachable - need to frag (mtu 1496)

14:26:45.692471 IP 80.63.34.250.2831 > 81.7.185.77.22: P 12560:13920(1360) ack 305 win 64671

14:26:45.692711 IP 81.7.185.77.22 > 80.63.34.250.2831: . ack 7100 win 12800 <nop,nop,sack sack 2 {12560:13920}{7432:11100} >

14:26:45.695955 IP 80.63.34.250.2831 > 81.7.185.77.22: P 13920:15380(1460) ack 305 win 64671

14:26:45.695965 IP 81.7.170.138 > 80.63.34.250: icmp 556: 81.7.185.77 unreachable - need to frag (mtu 1496)

14:26:46.047387 IP 80.63.34.250.2831 > 81.7.185.77.22: P 7100:8560(1460) ack 305 win 64671

14:26:46.047401 IP 81.7.170.138 > 80.63.34.250: icmp 556: 81.7.185.77 unreachable - need to frag (mtu 1496)

14:26:46.812538 IP 80.63.34.250.2831 > 81.7.185.77.22: P 7100:8560(1460) ack 305 win 64671

14:26:46.812552 IP 81.7.170.138 > 80.63.34.250: icmp 556: 81.7.185.77 unreachable - need to frag (mtu 1496)

14:26:48.125581 IP 80.63.34.250.2831 > 81.7.185.77.22: P 7100:8560(1460) ack 305 win 64671

14:26:48.125592 IP 81.7.170.138 > 80.63.34.250: icmp 556: 81.7.185.77 unreachable - need to frag (mtu 1496)

14:26:50.641188 IP 80.63.34.250.2831 > 81.7.185.77.22: P 7100:8560(1460) ack 305 win 64671

14:26:50.641201 IP 81.7.170.138 > 80.63.34.250: icmp 556: 81.7.185.77 unreachable - need to frag (mtu 1496)

14:26:55.563161 IP 80.63.34.250.2831 > 81.7.185.77.22: P 7100:8560(1460) ack 305 win 64671

14:26:55.563174 IP 81.7.170.138 > 80.63.34.250: icmp 556: 81.7.185.77 unreachable - need to frag (mtu 1496)

The customer offered his NOC my number so that I could tell what I found

out, but he declined as "my network is running fine!".

So I am very interested in knowing :
- whether or not you agree with me, that this is a problem of the firewall in front of the customer (as opposed to a flaw my setup)?
- this could be a potential problem for other people (my mtu of 1496 instead of 1500) ?
- if it is his firewall, can I stille use the TCPMSS extension to corretct this problem, and if so, how ?

Thanks in advance

Svenne

other

your

I

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3254 bytes
Desc: S/MIME Cryptographic Signature
Url : /pipermail/netfilter/attachments/20051212/4ba10ac3/smime-0001.bin

------------------------------

Message: 5
Date: Mon, 12 Dec 2005 11:46:09 -1000
From: "Gene Dellinger" <[email protected]>
Subject: RE: FORWARD Chain Question
To: <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

To All:
I got some helpful information, thanks to those who responded, I am still a
bit fuzzy though.
A packet coming in ETH0 destined for a system connected to ETH1, will that
packet begin in the PREROUTING
chain on ETH1(sample 1) and then out or go to the FORWARD chain(sample
2)
and then out.

ETH0:PREROUTING---->FORWARD---->POSTROUTING---->OUT

         |	           |            |
       INPUT  	     |         OUTPUT
         |	          \|/	      |
      Local Process    |         Local Process
		           |
	   ----<---<-----|
	   |
        \|/
ETH1:PREROUTING---->FORWARD---->POSTROUTING---->OUT
         |			            |
       INPUT  		          OUTPUT
         |			            |
      Local Process		   Local Process

sample 1
_________________________________________________________

ETH0:PREROUTING---->FORWARD---->POSTROUTING---->OUT

         |	           |            |
       INPUT  	     |  	   OUTPUT
         |	          \|/	      |
     Local Process     |         Local Process
		           |
		           |
		           |
		          \|/
ETH1:PREROUTING---->FORWARD---->POSTROUTING---->OUT
         |			            |
       INPUT  		          OUTPUT
         |			            |

Local Process Local Process

sample 2
_________________________________________________________

Thanks Again
Gene D.

-----Original Message-----
From: Gene Dellinger [mailto:[email protected]]
Sent: Friday, December 09, 2005 2:40 PM
To: [email protected]
Subject: FORWARD Chain Question

On a multi-homed machine being used as a firewall, if a packet is forward'd from one interface to another. Does the packet enter the in at PRE-ROUTING portion of iptables chain again for that interface? It may seem obvious but I just want to make sure I am clear on that aspect of the chain traversal.

Thanks
Gene D.

------------------------------

Message: 6
Date: Mon, 12 Dec 2005 14:01:30 -0800
From: "Jason" <[email protected]>
Subject: Allowing Samba Access to certain IPs
To: <[email protected]>
Message-ID: <009001c5ff67$9b95fe60$2e01a8c0@jasonspc>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original

I am running a Samba server on Fedora Core 4 that I would like to open up
access only to certain networks and block all others.

How Would I accomplish this using iptables? Here is my firewall script
so
you can see what it is I am doing wrong.

Thanks

Jason

# import this saved configuration into your iptables configuration with
the 
following command:
# iptables-restore < web_server.config

*nat
:PREROUTING ACCEPT [127173:7033011]
:POSTROUTING ACCEPT [31583:2332178]
:OUTPUT ACCEPT [32021:2375633]
COMMIT

*mangle
:PREROUTING ACCEPT [444:43563]
:INPUT ACCEPT [444:43563] :FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [402:144198]
:POSTROUTING ACCEPT [402:144198]
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP COMMIT

*filter
:INPUT DROP [1:242]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:icmp_packets - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 43 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 106 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 783 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 901 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3306 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10000 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 12000 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 15000 -j ACCEPT
-A INPUT -s 127.0.0.1 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth0 -p udp -m udp -d 192.168.1.41 --dport

137 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth0 -p udp -m udp -d 192.168.1.41 --dport

138 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth0 -p tcp -m tcp -d 192.168.1.41 --dport

139 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth0 -p tcp -m tcp -d 192.168.1.41 --dport

445 -j ACCEPT
-A INPUT -s 66.220.104.76 -i eth0 -p udp -m udp -d 71.111.151.20 --dport

137 -j ACCEPT
-A INPUT -s 66.220.104.76 -i eth0 -p udp -m udp -d 71.111.151.20 --dport

137 -j ACCEPT
-A INPUT -p icmp -j icmp_packets
-A INPUT -j LOG --log-prefix "IPTABLES-IN Default Drop: " --log-level 7

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 23 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 43 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 106 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 123 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 783 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 901 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 3306 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 10000 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 12000 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 15000 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 2210 -j ACCEPT
-A OUTPUT -d 127.0.0.1 -j ACCEPT
-A OUTPUT -p icmp -j icmp_packets
-A OUTPUT -j LOG --log-prefix "IPTABLES-OUT Default Drop: " --log-level 7

-A icmp_packets -p icmp -m icmp --icmp-type 0 -j ACCEPT -A icmp_packets -s 127.0.0.1 -p icmp -m icmp --icmp-type 8 -j ACCEPT -A icmp_packets -p icmp -m icmp --icmp-type 8 -j DROP
-A icmp_packets -p icmp -m icmp --icmp-type 3 -j ACCEPT -A icmp_packets -p icmp -m icmp --icmp-type 11 -j ACCEPT COMMIT

------------------------------

Message: 7
Date: Mon, 12 Dec 2005 14:08:14 -0800
From: "Jason" <[email protected]>
Subject: Re: Allowing Samba Access to certain IPs PLEASE DISREGARD
THIS EMAIL
To: "Jason" <[email protected]>, <[email protected]>
Message-ID: <009d01c5ff68$8c58f910$2e01a8c0@jasonspc>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=response

I'm Sorry. I accidentally sent this before I was finished composing. Please disregard this email message. I will resend when I am finished. My
apologies

Jason

----- Original Message -----
From: "Jason" <[email protected]>
To: <[email protected]>
Sent: Monday, December 12, 2005 2:01 PM
Subject: Allowing Samba Access to certain IPs

up

script

with

-j

--dport

--dport

--dport

--dport

--dport

------------------------------

_______________________________________________
netfilter mailing list
[email protected]
https://lists.netfilter.org/mailman/listinfo/netfilter

End of netfilter Digest, Vol 17, Issue 15
*****************************************

That's uncanny, Pete, I was just sitting here thinking the VERY same thing ... about hang gliders flinging hand grenades!

For future reference you might find that you will be better received when the whole digest isn't quoted ...

    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header