* DROP Fin Scan
[not found] <20021124093933.24186.71076.Mailman@kashyyyk>
@ 2002-12-12 14:27 ` Dade
2002-12-12 15:25 ` Blizzards
0 siblings, 1 reply; 3+ messages in thread
From: Dade @ 2002-12-12 14:27 UTC (permalink / raw)
To: netfilter
:
Hi,
I'd like to block all FIN SCAN type. In Internet I find the following method:
iptables -A INPUT -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
but for me is better to write:
iptables -A FORWARD -m state -state NEW -p tcp --tcp-flags FIN FIN -j DROP
that means blocking all packets with flag FIN active regarding only packets
belonging to new TCP connections.
Are you agree?
Thanks in advance,
Davide
Scrive netfilter-request@lists.netfilter.org:
> Send netfilter mailing list submissions to
> netfilter@lists.netfilter.org
>
> 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
> netfilter-request@lists.netfilter.org
>
> You can reach the person managing the list at
> netfilter-admin@lists.netfilter.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of netfilter digest..."
>
>
> Today's Topics:
>
> 1. Re: Am I making a bone-headed mistake with patch-o-matic ? (Brandon
> Broyles)
> 2. Packet filtering on the application layer (James Stickland)
> 3. Re: SNAT & Squence Numbers (Dax Kelson)
> 4. =?iso-8859-1?Q?Iptables_with_IP_Alias?=
> (=?iso-8859-1?Q?Juliano_Dapper?=)
> 5. cannot open shared object file: no such file or directory (James
> Stickland)
> 6. Re: [squid-users] How to allow traffic other than http (Colin
> Campbell)
> 7. DNAT to localhost (Nix N. Nix)
> 8. Re: Time based rules ... (Chris Poupart)
> 9. Netfilter 1.2.7a (debian), rule (DNAT) problems (040)
> 10. Re: Trojaned tcpdump and libpcap (Michael H. Warfield)
> 11. New to IP Tables (David Reta)
>
> --__--__--
>
> Message: 1
> From: "Brandon Broyles" <netfilter@drbroyles.com>
> To: <fabrice@netfilter.org>,
> <netfilter@lists.netfilter.org>
> Subject: Re: Am I making a bone-headed mistake with patch-o-matic ?
> Date: Sun, 24 Nov 2002 00:53:26 -0500
>
>
> ----- Original Message -----
> From: "Fabrice MARIE" <fabrice@netfilter.org>
> To: <netfilter@drbroyles.com>; <netfilter@lists.netfilter.org>
> Sent: Saturday, November 23, 2002 11:43 PM
> Subject: Re: Am I making a bone-headed mistake with patch-o-matic ?
>
> > There is a problem though (fixed in the CVS, but not yet updated on the
> HTML page..)
> > you shouldn't run # make patch-o-matic, but instead from the
> patch-o-matic
> directory,
> > you should run the ./runme script with the patch suite you want to apply
> as a parameter.
> > The corrected SGML source of the document is there :
> >
> http://cvs.netfilter.org/cgi-bin/cvsweb/~checkout~/netfilter/documentation/H
> OWTO/netfilter-extensions-HOWTO.sgml
>
>
> From what I read in the above link, I think something may be wrong with my
> patch-o-matic I got via CVS. I ran a (./runme base) and I got the
> following
> output. In this output the only thing that is "Already applied:" is the
> first line. Nothing else seems to be applied after that. Plus, that link
> above references switches ( Do you want to apply this patch [N/y/t/f/q/?]
> )
> that I am not getting.
>
> *********************************************************************
> Each patch is a new feature: many have minimal impact, some do not.
> Almost every one has bugs, so I don't recommend applying them all!
> -------------------------------------------------------
> Already applied: submitted/2.4.18
> submitted/ahesp-static
> submitted/arptables
> submitted/config-cleanup
> submitted/conntrack?helper-unregister
> submitted/conntrack
> submitted/dscp
> submitted/DSCP
> submitted/ecn
> submitted/ECN
> submitted/helper
> submitted/ip6tables-export-symbols
> submitted/ip6tables-exthdr-bug-ipv6
> submitted/ip_conntrack_protocol_destroy
> submitted/ip_conntrack_protocol_unregister
> submitted/ip_nat_irc-srcaddr-fix
> submitted/ipt_MIRROR-ttl
> submitted/ipt_REJECT-checkentry
> submitted/ipt_unclean-ecn
> submitted/ipv6-agr-ipv6
> submitted/irc-dcc-mask
> submitted/length-ipv6
> submitted/local-nat
> submitted/log-tunnel-fix-ipv6
> submitted/macro-trailing-semicolon-fix
> submitted/mangle5hooks
> submitted/nat-export_symbols
> submitted/nat-memoryleak-fix
> submitted/netfilter-arp
> submitted/ownercmd
> submitted/pkttype
> submitted/REJECT-dont_fragment
> submitted/REJECT_mark
> submitted/remove_no_version
> submitted/skb_clone_copy
> submitted/TOS-oops-fix
> submitted/ulog-module-unload
> submitted/ulog-nlgroup-shift-fix
> submitted/ulog-sparc-bitops-fix
> submitted/unclean-udpchecksum
> submitted/z-newnat16
> submitted/z-newnat_assertfix
> submitted/z-newnat_changeexpect-lockfix
> pending/newnat-udp-helper
> base/ahesp6-ipv6
> base/frag6-ipv6
> base/fuzzy
> base/iplimit
> base/ipt_unclean-ubit
> base/ipv4options
> base/IPV4OPTSSTRIP
> base/ipv6header-ipv6
> base/mport
> base/NETLINK
> base/NETMAP
> base/nth
> base/opts6-ipv6
> base/pool
> base/psd
> base/quota
> base/random
> base/realm
> base/REJECT-ipv6
> base/route6-ipv6
> base/SAME
> base/time
> base/TTL
>
> -----------------------------------------------------------------
> No more patches to apply! Q to Quit or ? for options [Q/a/r/b/?]
> Excellent! Kernel is now ready for compilation.
> *********************************************************************
>
> I never get a chance to choose which patches I wish to install. Before I
> wrote that first message to this mail list, I had already tried recompiling
> the kernel and iptables after I ran (./runme base). Does it look like my
> patch-o-matic is working incorrectly?
>
> Thanks,
> Brandon Broyles
>
>
>
>
> --__--__--
>
> Message: 2
> Date: Mon, 11 Nov 2002 23:25:35 -0500 (EST)
> From: James Stickland <jimmy@sympatico.ca>
> To: <netfilter@lists.netfilter.org>
> Subject: Packet filtering on the application layer
>
> Is there any way with linux (or just netfilter) to filter out packets
> based upon whats analyzed in the application layer of a packet?
>
>
>
>
> --__--__--
>
> Message: 3
> Subject: Re: SNAT & Squence Numbers
> From: Dax Kelson <Dax.Kelson@gurulabs.com>
> To: mike bramm <mike.bramm@bomberjacketproductions.com>
> Cc: netfilter@lists.netfilter.org
> Organization: Guru Labs
> Date: 12 Nov 2002 01:22:42 -0700
>
> On Mon, 2002-11-11 at 10:23, mike bramm wrote:
> > Hi,
> > I'm a Router/PIX guy that is just getting into the Linux/IPTables
> > scene. I've read the man pages and searched the web for information on
> > IPTables. And I'm not able to find answers to some of my questions.
> > Maybe you can help?
> > * If SNAT is configured for many to one (PAT), then I would
> > presume that the connections are tracked by sequence numbers.
> > Are the sequence numbers picked randomly, like the PIX? And is
> > there a range in with they are picked from? What mod does
> > this?
>
> AFAIK, the sequence numbers are left intact. I could be wrong though. A
> quick check with a packet sniffer should answer this.
>
> > * A syntax question. I've looked at alot of syntax examples and
> > I've noticed one character that I can't seem to match up with
> > any of the tutorials or man
> > pages.
> $IPTABLES -A INPUT $WAN_IFACE \ -j
> DROP What the heck is "\"? It looks like it would be used to separate the
> match and the target, but is not really necessary. Is this just a personal
> preference or is it needed?
>
> This isn't iptables syntax at all.
>
> The "\" at the end of a line is known as the continuation character.
> This is bourne shell syntax. It means that the next line should be
> treated as a continuation of the current line. The "\" character NOT at
> the end of the line, is the escape character and removes any special
> treatment of the following character and causes it to be treated
> literally.
>
> Dax
>
>
>
> --__--__--
>
> Message: 4
> Date: Wed, 13 Nov 2002 01:12:17 +0000
> Subject: =?iso-8859-1?Q?Iptables_with_IP_Alias?=
> From: "=?iso-8859-1?Q?Juliano_Dapper?=" <fjdapper@terra.com.br>
> To: "=?iso-8859-1?Q?netfilter?=" <netfilter@lists.netfilter.org>
>
> What's iptables not accept rules in ip alias, eth0:0, eth0:1?=0D=0AI have=
> a linux box with 2 ips and i have create ruls to redirect traffic to int=
> ernal machine,ex:=0D=0Aiptables -t nat -A PREROUTING -p tcp -i eth0 --dpo=
> rt 25 -j DNAT --to 192.168.0.1=0D=0Aiptables -t nat -A PREROUTING -p tcp =
> -i etho:0 --dport 80 -j DNAT --to=0D=0A192.168.0.2=0D=0Aeth0 - 200.200.20=
> 0.1=0D=0Aeth0:0 - 200.200.200.2=0D=0A=0D=0ATkz...=0D=0A=0D=0A=0D=0A=0D=0A=
>
>
>
>
> --__--__--
>
> Message: 5
> Date: Tue, 12 Nov 2002 21:27:38 -0500 (EST)
> From: James Stickland <jimmy@sympatico.ca>
> To: <netfilter@lists.netfilter.org>
> Subject: cannot open shared object file: no such file or directory
>
> Hi, i recently ran patch-o-matic to patch my kernel for the string match
> from the extra patches.
>
> I ran patch-o-matic, and it copied the string files to
> /usr/src/linux/net/ipv4/netfilter. Ok, so far so good.
>
> I went to compile my kernel, and have ipt_string as a module. I did so by
> adding the line CONFIG_IP_NF_MATCH_STRING=m in my /usr/src/linux/.config.
>
> I proceeded to do the standard make dep ; make modules ; make
> modules_install ; make bzImage. THe kernel compiled, i rebooted, and was
> successfully able to modprobe ipt_string.
> (/lib/modules/2.4.19/kernel/net/ipv4/netfilter/ipt_string.o)
>
> However, when i went to make use of the ipt_string match in an iptables
> rule, i was given the following error:
>
> iptables v1.2.7a: Couldn't load match
> `string':/usr/local/lib/iptables/libipt_st
> ring.so: cannot open shared object file: No such file or directory
>
> Upon inspection, the libipt_string.so did not exist in
> /usr/local/lib/iptables. How do i get this netfilter library to exist?
>
> I had this problem the last time i patched my kernel to support ipt_psd,
> but i cannot recall how i was able to get the psd library to exist.
>
> Did i miss a step while patching this time? Anyone with help please
> respond to the list and my email directly - jamesstickland@sympatico.ca
>
> Thank you.
>
>
>
>
>
>
> --__--__--
>
> Message: 6
> Date: Wed, 13 Nov 2002 16:34:21 +1000 (EST)
> From: Colin Campbell <sgcccdc@citec.qld.gov.au>
> To: Glen Spidal <glens@cybercorpinc.com>
> Cc: Net Filter <netfilter@lists.netfilter.org>,
> Squid Users <squid-users@squid-cache.org>
> Subject: Re: [squid-users] How to allow traffic other than http
>
> On Tue, 12 Nov 2002, Glen Spidal wrote:
>
> > I have servers set up as diagramed below. Proxied web traffic work fine.
> > Email fails.
> > I can send mail from the Linux box via Pine. Email server is at external
> > ISP.
>
> Squid is an HTTP proxy. Either run an MTA (sendmail, postfix, exim, qmail,
> ....) on the squid server or let the wintel clients talk to the ISP's mail
> server by routing (and natting?) through the squid server.
>
> Colin
> --
> Colin Campbell
> Unix Support/Postmaster/Hostmaster
> CITEC
> +61 7 3227 6334
>
>
>
> --__--__--
>
> Message: 7
> Subject: DNAT to localhost
> From: "Nix N. Nix" <nix@go-nix.ca>
> To: netfilter@lists.samba.org
> Organization:
> Date: 13 Nov 2002 03:45:54 -0500
>
> Why doesn't this work ?
>
> /sbin/iptables -t nat -A PREROUTING -p udp --destination 192.168.1.1/32
> --dport 80 -j DNAT --to-destination 127.0.0.1:8080
>
> The idea is: The Web server listens solely on 127.0.0.1:8080 . This
> allows me to run a Web server as a non-root user. But then, I want
> ${OUTSIDE_IP}:80 and 192.168.1.1:80 (my interface) to be forwarded to
> 127.0.0.1:8080 . I'm sure you've guessed by now that I'm running the
> Web server on my firewall ;o)
>
> Anyway, I tried setting /proc/sys/net/ipv4/conf/lo/rp_filter to 0, but
> that didn't help either.
>
> IMHO, the reason this doesn't work is that the above rule is added at
> the PREROUTING stage of the game. So, when the packet is routed, the
> routing decision is based on
> +----------------------+
> | Packet |
> +----------------------+
> |source:<192.168.1.xxx>|
> |dest: <127.0.0.1> |
> +----------------------+
> and, of course, somewhere, this packet gets dropped, because nothing
> should be able to reach 127.0.0.0/8 but 127.0.0.0/8, right ? But hell,
> I'm no expert.
>
> So, is there any way to forward TCP ports from local interfaces to the
> loopback interface ?
>
>
>
> Thanks for your advice.
>
>
>
> --__--__--
>
> Message: 8
> Date: Wed, 13 Nov 2002 11:00:37 -0500
> From: Chris Poupart <chris.poupart@mcgill.ca>
> To: Raymond Leach <raymondl@knowledgefactory.co.za>
> CC: Netfilter Mailing List <netfilter@lists.netfilter.org>
> Subject: Re: Time based rules ...
>
>
> This is a cryptographically signed message in MIME format.
>
> --------------ms030200050104000308010508
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
>
> Couldn't you just use a CRON job to add and remove that rule at the
> required times?
>
> -- Chris
>
> Raymond Leach wrote:
> > Hi
> >
> > Is there a way to put time restrictions on rules?
> > For eaxmple, something like:
> >
> > iptables -A FORWARD -i eth0 -p tcp -sport 1024: -dport 1024: -time
> > 0700:1700 -j DROP
> >
> > It would be nice ...
> >
> > Ray
> > --
>
>
> --------------ms030200050104000308010508
> Content-Type: application/x-pkcs7-signature; name="smime.p7s"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="smime.p7s"
> Content-Description: S/MIME Cryptographic Signature
>
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXDCC
> AwwwggJ1oAMCAQICAwhdizANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV
> BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx
> HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl
> bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDkyNzE3MTczNloXDTAzMDkyNzE3MTczNlowSTEf
> MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEmMCQGCSqGSIb3DQEJARYXY2hyaXMu
> cG91cGFydEBtY2dpbGwuY2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eF7z
> tl0IE3iJFRn+QxzBIYj9kv5bkCa3oB0ZcsGxoYoVoTKXPKmiI/CvhpNUKG3EgffmNsO1bsiW
> yoyX29ex3bjSUvXUp7rUdl4z/LlgTsPXOpfuXnt1d719kpn5yAPI3yzCBjjtwrEb1X7XUIcP
> iLW8kAwMn12a6m7ym7UUGuFALwIB3LkOiO0OnT46s5ePDLWwSLgRNamTT+DSgi5thUktZAhk
> jPcOwzrfvYH8+/BPbGpgjtUQjWE/prOI/MwAG+CUnFXFc72OjJsdBpUj0mRKiDpsVH6u0LWe
> lnxtnRWc40zdhl4zYvM3+t110RFmEsf9fl8qig2sc9noV4YBAgMBAAGjNDAyMCIGA1UdEQQb
> MBmBF2NocmlzLnBvdXBhcnRAbWNnaWxsLmNhMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEE
> BQADgYEA2R04OiFqWwqdpxeCGJQflyooYzpl7T+vXXizBMOLAcn6ecXf+na9O2AOFTOVLZ83
> kR0jg5vX7GJpvVDM+qBkQqyqCgsDElXxzizOEFwMZwbNcEl3lA1wxLwwcvICZlfAZsn1dNGo
> NZrZ2castGJgIf64I1YmlnxwX82nJDQJ1dQwggMMMIICdaADAgECAgMIXYswDQYJKoZIhvcN
> AQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
> CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2
> aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMjA5
> MjcxNzE3MzZaFw0wMzA5MjcxNzE3MzZaMEkxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBN
> ZW1iZXIxJjAkBgkqhkiG9w0BCQEWF2NocmlzLnBvdXBhcnRAbWNnaWxsLmNhMIIBIjANBgkq
> hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuHhe87ZdCBN4iRUZ/kMcwSGI/ZL+W5Amt6AdGXLB
> saGKFaEylzypoiPwr4aTVChtxIH35jbDtW7IlsqMl9vXsd240lL11Ke61HZeM/y5YE7D1zqX
> 7l57dXe9fZKZ+cgDyN8swgY47cKxG9V+11CHD4i1vJAMDJ9dmupu8pu1FBrhQC8CAdy5Dojt
> Dp0+OrOXjwy1sEi4ETWpk0/g0oIubYVJLWQIZIz3DsM6372B/PvwT2xqYI7VEI1hP6aziPzM
> ABvglJxVxXO9joybHQaVI9JkSog6bFR+rtC1npZ8bZ0VnONM3YZeM2LzN/rdddERZhLH/X5f
> KooNrHPZ6FeGAQIDAQABozQwMjAiBgNVHREEGzAZgRdjaHJpcy5wb3VwYXJ0QG1jZ2lsbC5j
> YTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBANkdODohalsKnacXghiUH5cqKGM6
> Ze0/r114swTDiwHJ+nnF3/p2vTtgDhUzlS2fN5EdI4Ob1+xiab1QzPqgZEKsqgoLAxJV8c4s
> zhBcDGcGzXBJd5QNcMS8MHLyAmZXwGbJ9XTRqDWa2dnGrLRiYCH+uCNWJpZ8cF/NpyQ0CdXU
> MIIDODCCAqGgAwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkG
> A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRow
> GAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2
> aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw
> KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAw
> MDAwMFoXDTA0MDgyNzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
> IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD
> ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw
> MDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXa
> iBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1
> Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp
> oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3
> MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGx
> S0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcN
> rUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTq
> JmmHf0iezqWf54TYyWJirQXGMYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD
> VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl
> MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJl
> ZW1haWwgUlNBIDIwMDAuOC4zMAIDCF2LMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzEL
> BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTExMzE2MDAzN1owIwYJKoZIhvcNAQkE
> MRYEFPPTeVlaU6CriiJOR4LZx+r6wQHOMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcw
> DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
> MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl
> cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
> FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg
> MjAwMC44LjMwAgMIXYswDQYJKoZIhvcNAQEBBQAEggEAoB1OfLfTqsK2qcx8rvWr2BjmUAf2
> lZptBBFjTllqjMOSSBf1uQW3pkKEgtRInTtpgO8n6GMaOufBeP6qqYL3F/D0lOwcn3R/E7my
> 0o8+dAN59mmI7X/CfKJFqPdob7VqPxTfp6fXr+gVxDcbG3WKfYkdpF2oDU9Z0TFaMKpZ76Zg
> OaF6May1hkzxVsuQgG3YZmzQleelN9X4kDCu4gfMfLSm2uWRjGuPV+EA+0CzIrHMt7kilkfo
> LBnN7NGRqMRZ6aydF6CQ8KS7ptV5KF5xTgMOr4m4IlDwl5PP6QJNZ2I4qFWe2eIHTWNqhiZa
> b7vNjCLgvG42EDyKPdHZfpZw6wAAAAAAAA==
> --------------ms030200050104000308010508--
>
>
>
> --__--__--
>
> Message: 9
> Date: Wed, 13 Nov 2002 17:41:57 +0100
> To: netfilter@lists.netfilter.org
> From: 040 <madmac@swipnet.se>
> Subject: Netfilter 1.2.7a (debian), rule (DNAT) problems
>
> Hello.
>
> First of all my configuration is:
> Debian Linux 3.0r0 w/ kernel 2.4.18-K7 on a x86 AMD Duron on a via KT133A
> chipset.
> The system is configured with two NIC's, namely two 3Com 3C905C 10/100-TX
> PCI networking cards and is acting part as
> a server and part as a router. I use it for serving things like web to the
> outside and a router to enable internet access via it
> from my lan because my ISP only hands me one IP address. if it's of any
> importance I hand out IP addresses to my lan
> via dhcpd, oh yea, it's a switched 10/100 mbit ethernet network.
> eth1 (dynamic, 217.208.248.*) is connected to the net and eth0 (static,
> 192.168.0.1) is connected to the lan.
>
> I've read the NAT HOWTO on netfilter.org and setted up masquadering like
> (from my ruleset):
> -A POSTROUTING -o eth1 -j MASQUERADE
> and I've also done the following:
> echo 1 > /proc/sys/net/ipv4/ip_forward
> and edited /etc/network/options to correspond with the variable
> ip_forward=yes
> Which works fine, I'm able to access the net via all the clients on my LAN
> when using the server as my gateway.
>
> Now I want to add a rule to forward all incoming data on port 4662 (TCP)
> from the internet (eth1) to
> a server on my LAN, namely host 192.168.0.7 (via eth0), so I add the
> following rule (under *nat):
> -A PREROUTING -p tcp -m tcp -i eth1 --dport 4662 -j DNAT --to-destination
> 192.168.0.7:4662
>
> After reloading iptables and trying to connect or scan the port 4662 on my
> external IP, nothing happends, i.e. the port is closed (yes, the
> client is listening on 4662 but does not recive any connections from the
> server's eth0 (192.168.0.1)).
>
> Anyone have any ideas for me?
>
> I'm providing a copy of my ruleset made with iptables-save to provide
> additional techincal information:
>
> # Generated by iptables-save v1.2.7a on Sun Nov 10 17:58:44 2002
> *nat
> :OUTPUT ACCEPT [0:0]
> :PREROUTING ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> -A PREROUTING -p tcp -m tcp -i eth1 --dport 4662 -j DNAT --to-destination
> 192.168.0.7:4662
> -A POSTROUTING -o eth1 -j MASQUERADE
> COMMIT
>
>
> Please note, I've tried to fiddle-around with the rules _alot_ so the above
>
> is not a specific case of not-working rather than just one out of 100
> examples.
>
> Thanks in advance.
> Henric Blomgren / Sweden.
>
>
>
> --__--__--
>
> Message: 10
> Date: Wed, 13 Nov 2002 12:10:26 -0500
> From: "Michael H. Warfield" <mhw@wittsend.com>
> To: James Miller <jimm@simutronics.com>
> Cc: netfilter@lists.netfilter.org
> Subject: Re: Trojaned tcpdump and libpcap
>
>
> --TA4f0niHM6tHt3xR
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Wed, Nov 13, 2002 at 10:25:30AM -0600, James Miller wrote:
> > Hello all
>
> > I have been a long time reader of this list. An associate passed this
> al=
> ong
> > to me this morning and I wanted to share it with everyone.
>
> > http://hlug.fscker.com/
> > Latest libpcap & tcpdump sources from tcpdump.org contain a trojan.
>
> > Affected version are:
> > libpcap-0.7.1.tar.gz
> > tcpdump-3.6.2.tar.gz
> > tcpdump-3.7.1.tar.gz
>
> Downloads from October 30 have been confirmed good. Downloads
> after November 12 confirmed bad. Anything in-between is anyone's guess.
> If anyone downloaded those sources between those two dates, please contact
> me with the package md5sums. I want to narrow down the time frame.
> CVS repository does NOT appear to have been compromised.
>
> Good:
>
> 03e5eac68c65b7e6ce8da03b0b0b225e tcpdump-3.7.1.tar.gz
> 0597c23e3496a5c108097b2a0f1bd0c7 libpcap-0.7.1.tar.gz
>
> Bad:
>
> 3c410d8434e63fb3931fe77328e4dd88 tcpdump-3.7.1.bad.tar.gz
> 73ba7af963aff7c9e23fa1308a793dca libpcap-0.7.1.bad.tar.gz
>
> > Regards,
> > Jim
>
> Mike
> --=20
> Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
> /\/\|=3Dmhw=3D|\/\/ | (678) 463-0932 |
> http://www.wittsend.com/=
> mhw/
> NIC whois: MHW9 | An optimist believes we live in the best of all
> PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
>
> --TA4f0niHM6tHt3xR
> Content-Type: application/pgp-signature
> Content-Disposition: inline
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
>
> iQCVAwUBPdKHguHJS0bfHdRxAQGAnAQAwNm/9IzDza90dxhposTZoeVtgzjjeipY
> BJlgyhbeyLKvC5DoBMxn7eW29tl7+4e4FFQOsMKkaCyw+sCbc12hb3hWlNLzQeGO
> DrVpeLCaZsFuEZndl9Y7c7dLQvl4jUZVoLgIR8TDUXv9oz0TvjTA+1MUWZ/bEDPP
> xpkiaOEc1yg=
> =gt4S
> -----END PGP SIGNATURE-----
>
> --TA4f0niHM6tHt3xR--
>
>
> --__--__--
>
> Message: 11
> From: David Reta <DavidR@Narus.com>
> To: "'netfilter@lists.netfilter.org'" <netfilter@lists.netfilter.org>
> Subject: New to IP Tables
> Date: Wed, 13 Nov 2002 16:14:33 -0800
>
> I just started using IP Tables and have a question. I was not able
> to find the answer in any of the docs I've read so far.
> I have a machine that I am using as a router and running Ip Tables on it.
> Here is a list of my tables.
>
> [root@qa-gate root]# iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
> ACCEPT tcp -- anywhere anywhere tcp dpt:http
> ACCEPT tcp -- anywhere anywhere tcp
> dpt:ftp-data
>
> ACCEPT tcp -- anywhere anywhere tcp dpt:ftp
> ACCEPT tcp -- anywhere anywhere tcp dpt:domain
> ACCEPT tcp -- anywhere anywhere tcp dpt:26
> DROP tcp -- anywhere anywhere
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
>
> Chain test (0 references)
> target prot opt source destination
>
> I am not able to pass any data through the router. Here is the scenario, I
> want to access a Web Site which is on the other side of the router. The way
> that I interpret this is that the packet will get passed to the first chain
> which is
> ACCEPT tcp -- anywhere anywhere tcp dpt:http
> and be let through, yet this is not happening. All tcp traffic is being
> blocked which is defined by my 6th rule. I guess I am not understanding
> this, but I would think that the packet would match the first rule and be
> passed through and the following chains would be ignored. My logic is
> probably wrong.
>
> Thanks,
> David
>
>
>
>
>
> --__--__--
>
> _______________________________________________
> netfilter mailing list
> netfilter@lists.netfilter.org
> https://lists.netfilter.org/mailman/listinfo/netfilter
>
>
> End of netfilter Digest
>
^ permalink raw reply [flat|nested] 3+ messages in thread