gmane.comp.security.firewalls.netfilter.devel

[ULOGD2 PATCH 0/18] Code cleaning, SCTP support, NFLOG logic fix

Eric Leblond — 2008-12-01T21:35:58

Hi, This patchset is made of four parts. First part is Pablo's work that I have completed. It cleans up the current key assignation by introducing a new set of functions: * add ukey_* function for key assignation Second part fixes a logic problem in NFLOG input plugin. System logging (for instance invalid conntrack message) are done on group 0 queue for all protocols. Thus a protocol dependant NFLOG plugin is stupid. Furthermore, the nfnetlink message contains the protocol information. This set of patch suppresses the addressfamily variable and modify NFLOG to only bind as system logging if group is 0: * Modify usage of nflog_bind_pf function. * Get rid of addressfamily variable in NFLOG input plugin * Document group 0 usage and suppress address_family Third part adds support for SCTP in ulogd2. It contains a basic packet parser and a support in all OUTPUT plugin: * Add SCTP support to BASE plugin. * SCTP support for PRINTPKT. * Add SCTP support to MySQL and PGSQL output. Last part is code cleaning. It fixes some memory leak fixes and cleaning of ulogd exit code.F or example, fini function were defined for each module but were never called: * Treat nice function return. * Fix stop function of NFCT plugin. * Don't free pluginstance when leaving * Fix minor memory leak in NFLOG plugin. * Call pluginstance stop function when exiting * Add SIGINT to list of terminal signal. * Unload plugins when quitting. * Introduce config_stop() function * Free stacks when exiting. * Fix memory leak in destructor_nfct(). * Add valgrind compilation option. This patch is build upon Pierre's last patchset. Patchset statistics: doc/mysql-ulogd2.sql | 43 ++++- doc/pgsql-ulogd2.sql | 41 ++++- filter/raw2packet/ulogd_raw2packet_BASE.c | 270 +++++++++++++-------------- filter/raw2packet/ulogd_raw2packet_LOCAL.c | 7 +- filter/ulogd_filter_HWHDR.c | 76 ++++---- filter/ulogd_filter_IFINDEX.c | 30 ++-- filter/ulogd_filter_IP2BIN.c | 9 +- filter/ulogd_filter_IP2STR.c | 15 +- filter/ulogd_filter_MARK.c | 4 +- filter/ulogd_filter_PRINTFLOW.c | 3 +- filter/ulogd_filter_PRINTPKT.c | 3 +- filter/ulogd_filter_PWSNIFF.c | 27 ++-- include/ulogd/conffile.h | 3 + include/ulogd/printpkt.h | 2 + include/ulogd/ulogd.h | 68 +++++++- input/flow/ulogd_inpflow_NFCT.c | 171 +++++++----------- input/packet/ulogd_inppkt_NFLOG.c | 186 +++++++++----------- input/packet/ulogd_inppkt_ULOG.c | 46 ++---- output/pcap/ulogd_output_PCAP.c | 11 +- output/ulogd_output_NACCT.c | 34 ++-- src/conffile.c | 4 + src/hash.c | 6 +- src/ulogd.c | 76 ++++++++- ulogd.conf.in | 37 ++-- util/printflow.c | 52 +++--- util/printpkt.c | 163 +++++++++-------- 26 files changed, 768 insertions(+), 619 deletions(-) BR, -- Eric Leblond inl.fr> -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

multicast forwarding

Kaplowitz, David — 2008-12-01T19:44:19

Greetings, I have an interesting difficulty. I want to be able to grab a multicast stream from a machine (192.168.12.13) and forward/rebroadcast/rewrite it, such that the packets seem to come from my DMZ host (192.168.12.12). I have been trying an iptables solution, but that doesn't seem to be working at the moment, and it was recommended to me by j_engelh on the #iptables channel to ask at this address for further assistance. Thank you for your time and effort on my behalf. -dkap Below is three representative packets: U 192.168.12.13:6970 -> 224.0.1.20:6990 ...< at >.7..........U`c.|?...^v/9.....?.....E......{.......^../..W....o.Q..;... ....:'.S.~.....fv.......1xe................y...|Q.....3.< at >.u..........=..... .^0.........0.B.`.^............{../.....B..UY....Z.....Te....H........^.... .'...._..<.!..^b/7.....b..3.s.."....X......B.NL&...*.V..C.../|^o.T< at >......O. =.7..Nc...R....Vku...X8.`8A$.....]..Qy8......[...)3x./.?.n.......qy. # U 192.168.12.13:6970 -> 224.0.1.20:6990 ...A.7..........U.S.}..../;......b..........fN.........O.^0.cA..t...b._W... ./.:/......D..X^5.1....^.y'./.$.Z....-*..r.`.<^I...x...+.......-SVa.....N.. ...;.]...=.......lJ..mO......{ ..5....Y._.8......... .h._.............f..R..^.yIP......L.d+.8.......8....?.xV.>....J.CfZ..1..p*. 88Z.f.....< at > ./'........:.c..0..:E.aO...B.h.....P.....r........T....%..K.... < at >J~...{...`q.q.g9J..PK....4-..kM.b..|..{....._.. GT..|........1y4^......... ./.... # U 192.168.12.13:6970 -> 224.0.1.20:6990 .`.B.7.u....... ....$. ...h.H...X ........`.....4Z.z....v..Gw...~..|....... T...hc...Q..knj7Y.`....|6%..LpS...wt.....s.|{i.}.....y.P5....(..q.e;.Z.H... 8O..nH.iw...t..I.....<.....&......y6..,b...Tk..k^.Z._.S./.Ny..C}.9cu..0...q O.........R.z:.u..-L..}.rPV.6.x.P....O.....?.....?..NO..?'..\...V.:....lp.! ..W..iar...B.aD.....^.....B.!..KXK...f....u....^:VEa|g.O...apq........~..%. ...%....d......y....P.Tz.....-..|.3...U< at >u........x....*gA.Fv.c`......2%'...[Z.FWJ.I...2.FV...VS.. G....69....W)]...W.E...O*......R......S..F...Ug...Y.}..p...U.......Z.5..... r.i...FT%C....n.%.Uu&!.j.).7.3.....V'j.....?..D.pl..h->< at >Z...Z...7...y...... ..$.$\......e.< at >.$*.h.{'......EE|.2z.+z.5....x....ul..< at >.4.$G.....r..N..q.uD 1..W...I....,^....5.`......z.o.......3.V...r...QEf...v...!..x.x..<4.?.e.1.] S..IJ...0 ......P.......x..i-....* .a8.A7........R..l2U.......e4t.g.......p ..aw....e......H.c.....h*...d.}....aK..........P...(...De..V...c.....PF...8 ......< at >y..2'....\..G..~x.F^/fl.0...TY...g.<..)L9.MR...d.S8.QF.%...z.....0.^ ...........5...............GlYT.^#c.L.._Ur..\\..;r%^.*.M< at >..5H.T.o.s...2..T. .g...?..b......?FwR.M....s...NN..h..&~.....".<.F.&.uN..=..........pb4U..... p..5......&.4.L.p-.C.oB..C...%^].e.`..#......6..z.2......2...<.h0a....E").. .v.< at >.< at >M..t......0DS.L0.=O.}M6$Mf..."....1j..-.#Yi....a.3#...i.>.....}^.W... .)C.JL...... .q...F....ss..S...1.)L!.C.fh\...V.

[ULOG PATCH 0/4] misc fixes, and new DBI output plugin

Pierre Chifflier — 2008-12-01T12:41:52

The first two patches fixes the following problems: - impossibility to run ulogd in gdb, due to a missing link to libpthread - possible use of uninitialized memory in a calloc(0), spotted by valgrind It also adds a new output mode, libdbi libdbi implements a database-independent abstraction layer in C, similar to the DBI/DBD layer in Perl. It allows to use all database types supported by libdbi, including MySQL, PostgreSQL, sqlite, Firebird, MSSQL, Sybase, Oracle, ingres .. It does not, however, replace other database modules, because as a common abstraction layer, it is unable to use any specific function, for ex. the asynchronous API for PostgreSQL. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[libnetfilter_log patch] Fix minor memory leak.

Eric Leblond — 2008-11-30T14:34:03

The nflog_handle is allocated in nflog_open(). This patch adds the missing free in nlog_close(). Signed-off-by: Eric Leblond inl.fr> --- src/libnetfilter_log.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/libnetfilter_log.c b/src/libnetfilter_log.c index 6c0936e..216cdb8 100644 --- a/src/libnetfilter_log.c +++ b/src/libnetfilter_log.c < at >< at > -237,7 +237,9 < at >< at > int nflog_handle_packet(struct nflog_handle *h, char *buf, int len) int nflog_close(struct nflog_handle *h) { -return nfnl_close(h->nfnlh); +int ret = nfnl_close(h->nfnlh); +free(h); +return ret; } /* bind nf_queue from a specific protocol family */

netfilter 00/29: Netfilter Update

Patrick McHardy — 2008-11-27T16:15:03

Hi Dave, the following patches contain part 1 of the netfilter updates for 2.6.29. The highlights are: - netns support for ebtables, ipt_addrtype and some related cleanups from Alexey Dobriyan - ctnetlink updates from Pablo: automatic helper module loading, proper event generation for actions performed through ctnetlink, minor cleanups - switching of xt_NFLOG to directly use nfnetlink_log as backend instead of the first loaded logging module, which was a constant source of confusion for users. From Eric Leblond. Also from Eric are two patches to support rerouting based on packet marks in nfnetlink_queue. - Misc cleanups and minor fixes from myself, Andy Whitcroft, Simon Arlot and Ingo Molnar. There's a trivial merge conflict in net/netfilter/nf_conntrack_netlink.c, so the patches won't apply directly. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git Thanks! include/linux/netfilter_bridge/ebtables.h | 3 +- include/linux/netfilter_ipv4/ipt_policy.h | 2 + include/linux/netfilter_ipv6/ip6t_policy.h | 2 + include/net/netfilter/nf_conntrack.h | 5 +- include/net/netfilter/nf_conntrack_ecache.h | 57 +++++++- include/net/netfilter/nf_conntrack_expect.h | 2 + include/net/netfilter/nf_conntrack_helper.h | 5 +- include/net/netfilter/nf_conntrack_l4proto.h | 2 +- include/net/netfilter/nfnetlink_log.h | 14 ++ include/net/netns/x_tables.h | 5 + net/bridge/br_netfilter.c | 2 +- net/bridge/netfilter/ebtable_broute.c | 26 +++- net/bridge/netfilter/ebtable_filter.c | 41 +++++- net/bridge/netfilter/ebtable_nat.c | 38 ++++-- net/bridge/netfilter/ebtables.c | 52 +++++--- net/ipv4/netfilter.c | 3 + net/ipv4/netfilter/arptable_filter.c | 12 +-- net/ipv4/netfilter/ipt_addrtype.c | 16 ++- net/ipv4/netfilter/nf_nat_rule.c | 23 --- net/ipv6/netfilter.c | 5 +- net/ipv6/netfilter/ip6table_filter.c | 17 +-- net/netfilter/nf_conntrack_amanda.c | 1 + net/netfilter/nf_conntrack_core.c | 61 ++++----- net/netfilter/nf_conntrack_ecache.c | 14 ++- net/netfilter/nf_conntrack_expect.c | 43 +++++- net/netfilter/nf_conntrack_ftp.c | 9 +- net/netfilter/nf_conntrack_h323_main.c | 1 + net/netfilter/nf_conntrack_helper.c | 32 ++++- net/netfilter/nf_conntrack_irc.c | 1 + net/netfilter/nf_conntrack_netbios_ns.c | 1 + net/netfilter/nf_conntrack_netlink.c | 200 ++++++++++++++++++++------ net/netfilter/nf_conntrack_pptp.c | 1 + net/netfilter/nf_conntrack_proto_gre.c | 2 +- net/netfilter/nf_conntrack_proto_sctp.c | 2 +- net/netfilter/nf_conntrack_sane.c | 1 + net/netfilter/nf_conntrack_sip.c | 1 + net/netfilter/nf_conntrack_tftp.c | 1 + net/netfilter/nfnetlink_log.c | 4 +- net/netfilter/xt_NFLOG.c | 5 +- net/netfilter/xt_recent.c | 22 ++-- 40 files changed, 514 insertions(+), 220 deletions(-) create mode 100644 include/net/netfilter/nfnetlink_log.h Alexey Dobriyan (12): netfilter: netns-aware ipt_addrtype netfilter: arptable_filter: merge forward hook netfilter: netns ebtables: part 1 netfilter: netns ebtables: part 2 netfilter: netns ebtables: more cleanup during ebt_unregister_table() netfilter: netns ebtables: ebtable_broute in netns netfilter: netns ebtables: ebtable_filter in netns netfilter: netns ebtables: ebtable_nat in netns netfilter: netns ebtables: br_nf_pre_routing_finish() fixup netfilter: xt_recent: don't save proc dirs netfilter: ip6table_filter: merge LOCAL_IN and FORWARD hooks netfilter: nf_conntrack_proto_gre: spread __exit Andy Whitcroft (1): netfilter: ip{,6}t_policy.h should include xp_policy.h Eric Leblond (3): netfilter: xt_NFLOG: don't call nf_log_packet in NFLOG module. netfilter: nfmark routing in OUTPUT, mangle, NFQUEUE netfilter: nfmark IPV6 routing in OUTPUT, mangle, NFQUEUE Ingo Molnar (2): netfilter: fix warning in net/netfilter/nf_conntrack_proto_tcp.c netfilter: fix warning in net/netfilter/nf_conntrack_ftp.c Pablo Neira Ayuso (6): netfilter: ctnetlink: use nf_conntrack_get instead of atomic_inc netfilter: ctnetlink: use EOPNOTSUPP instead of EINVAL if the conntrackhas no helper netfilter: ctnetlink: get rid of module refcounting in ctnetlink netfilter: nf_conntrack: connection tracking helper name persistent aliases netfilter: ctnetlink: helper modules load-on-demand support netfilter: ctnetlink: deliver events for conntracks changed from userspace Patrick McHardy (4): netfilter: nfnetlink_log: fix warning and prototype mismatch netfilter: nf_conntrack: fix warning and prototype mismatch netfilter: nf_conntrack_proto_sctp: avoid bogus warning netfilter: nf_conntrack_ftp: change "partial ..." message to pr_debug() Simon Arlott (1): netfilter: nf_nat: remove warn_if_extra_mangle -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] More secure SYSRQ for xtables-addons

John Haxby — 2008-11-27T12:28:29

Hello All, This is a patch to the SYSRQ xtables-addon that is, I believe, secure enough to use in moderately untrustworthy environments. I'm relatively new to posting patches so please forgive me if I've messed this up. Rationale: I want to be able to use SYSRQ to reboot, crash or partially diagnose machines that become unresponsive for one reason or another. These machines, typically, are blades or rack mounted machines that do not have a PS/2 connection for a keyboard and the old method of wheeling round a "crash trolley" that has a monitor and a keyboard on it no longer works: USB keyboards rarely, if ever, work because by the time the machine is responding only to a ping, udev is incapable of setting up a new keyboard. This patch extends the xt_SYSRQ module to avoid both disclosing the sysrq password and preventing replay. This is done by changing the request packet from the simple "" to a slightly more complex ",,,". The hash is the sha1 checksum of ",,,". A request can be constructed in a small shell script, for example: key="s" password="cookie" seqno=$(date +%s) salt="$(dd bs=12 count=1 if=/dev/urandom 2>/dev/null | openssl enc -base64)" req="$key,$seqno,$salt" req="$req,$(echo -n "$req,$password" | sha1sum | cut -c 1-40)" As before this can be sent to the victim machine using socat or netcat. Verification of the hash in xt_SYSRQ follows much the same process. The sequence number, seqno, is initialised to the current time (in seconds) when the xt_SYSRQ module is loaded and is updated each time a valid request is received. A request with a sequence number less than the current sequence number or a wrong hash is silently ignored. (Using the time for the sequence number assumes (requires) that time doesn't go backwards on a reboot and that the requester and victim have reasonably synchronized clocks.) The random salt is there to prevent pre-computed dictionary attacks difficult: dictionary attacks are still feasible if you capture a packet because the hash is computed quickly -- taking perhaps several milliseconds to compute a more complex hash in xt_SYSRQ when the machine is unresponsive is probably not the best thing you could do. However, cracking, say, a random 32 character password would take some time and is probably beyond what the people in the target untrustworthy environment are prepared to do or have the resources for. It almost goes without saying that no two victim machines should use the same password. Ideally the iptables rules for SYSRQ would include a minimum time between requests to avoid the worst effects of sysrq-request bombing, although I haven't mentioned that in the updated man page (mostly because I'm not sure how to do it). Finally, the module allocates all the resources it need at module initialisation time on the assumption that if things are going badly resource allocation is going to be troublesome. jch diff -up xtables-addons-1.6/extensions/libxt_SYSRQ.man.sysrq xtables-addons-1.6/extensions/libxt_SYSRQ.man --- xtables-addons-1.6/extensions/libxt_SYSRQ.man.sysrq2008-11-18 17:16:34.000000000 +0000 +++ xtables-addons-1.6/extensions/libxt_SYSRQ.man2008-11-27 11:02:12.000000000 +0000 < at >< at > -5,13 +5,15 < at >< at > stuck as a result -- if still possible, processes are stuck, interrupts are likely to be still processed, and as such, sysrq can be triggered through incoming network packets. .PP -This xt_SYSRQ implementation does not use any encryption, so you should change -the SYSRQ password after use unless you have made sure it was transmitted -securely and no one sniffed the network, e.g. by use of an IPsec tunnel whose -endpoint is at the machine where you want to trigger the sysrq. Also, you -should limit as to who can issue commands using \fB-s\fP and/or \fB-m mac\fP, -and also that the destination is correct using \fB-d\fP (to protect against -potential broadcast packets), noting that it is still short of MAC/IP spoofing: +The xt_SYSRQ implementation uses a salted SHA1 hash and a sequence number to +prevent network sniffers from either guessing the password or replaying earlier +requests. The initial sequence number comes from the time of day so you will +have a small window of vulnerability should time go backwards at a reboot. +However, the file /sys/module/xt_SYSREQ/seqno can be used to both query and +update the current sequence number. Also, you should limit as to who can issue +commands using \fB-s\fP and/or \fB-m mac\fP, and also that the destination is +correct using \fB-d\fP (to protect against potential broadcast packets), noting +that it is still short of MAC/IP spoofing: .IP -A INPUT -s 10.10.25.1 -m mac --mac-source aa:bb:cc:dd:ee:ff -d 10.10.25.7 -p udp --dport 9 -j SYSRQ < at >< at > -24,10 +26,9 < at >< at > This extension does not take any options required. .PP The SYSRQ password can be changed through -/sys/module/xt_SYSRQ/parameters/password; note you need to use `echo -n` to -not add a newline to the password, i.e. +/sys/module/xt_SYSRQ/parameters/password, for example: .IP -echo -n "password" >/sys/.../password +echo "password" >/sys/module/xt_SYSRQ/parameters/password .PP Alternatively, the password may be specified at modprobe time, but this is insecure as people can possible see it through ps(1). You can use an option < at >< at > -36,12 +37,36 < at >< at > by root. .IP options xt_SYSRQ password=cookies .PP -To trigger SYSRQ from a remote host, just use netcat or socat, specifying the -action (only one) as first character, followed by the password: -.IP -echo -n "scookies" | socat stdin udp-sendto:10.10.25.7:9 -.IP -echo -n "scookies" | netcat -u 10.10.25.7 9 -.PP -See the Linux docs for possible sysrq keys. Important ones are: -re(b)oot, power(o)ff, (s)ync filesystems, (u)mount and remount readonly. +The xt_SYSRQ module is normally silent unless a successful request is received, +but the \fIdebug\fP module parameter can be used to find exactly why a +seemingly correct request is not being processed. +.PP +To trigger SYSRQ from a remote host, just use netcat or socat: +.RS +.nf + +sysrq_key="s" # the SysRq key +password="password" +seqno="$(date +%s)" +salt="$(dd bs=12 count=1 if=/dev/urandom 2>/dev/null | + openssl enc -base64)" +req="$sysrq_key,$seqno,$salt" +req="$req,$(echo -n "$req,$password" | sha1sum | cut -c1-40)" + +echo "$req" | socat stdin udp-sendto:10.10.25.7:9 +# or +echo "$req" | netcat -uw1 10.10.25.7 9 + +.fi +.RE +.PP +See the Linux docs for possible sysrq keys. Important ones are: re(b)oot, +power(o)ff, (s)ync filesystems, (u)mount and remount readonly. More than one +sysrq key can be used at once, but bear in mind that, for example, a sync may +not complete before a subsequent reboot or poweroff. +.PP +The hashing scheme should be enough to prevent mis-use of SYSRQ in many +environments, but it is not perfect: take reasonable precautions to protect +your machines. Most importantly ensure that each machine has a different +password: there is scant protection for a SYSRQ packet being applied to a +machine that happens to have the same password. diff -up xtables-addons-1.6/extensions/xt_SYSRQ.c.sysrq xtables-addons-1.6/extensions/xt_SYSRQ.c --- xtables-addons-1.6/extensions/xt_SYSRQ.c.sysrq2008-11-18 17:16:34.000000000 +0000 +++ xtables-addons-1.6/extensions/xt_SYSRQ.c2008-11-27 11:15:34.000000000 +0000 < at >< at > -3,7 +3,6 < at >< at > *Copyright © Jan Engelhardt , 2008 * *Based upon the ipt_SYSRQ idea by Marek Zalem - *xt_SYSRQ does not use hashing or timestamps. * *This program is free software; you can redistribute it and/or *modify it under the terms of the GNU General Public License < at >< at > -19,43 +18,137 < at >< at > #include #include #include +#include +#include #include #include "compat_xtables.h" static bool sysrq_once; static char sysrq_password[64]; +static long seqno; +static int debug; module_param_string(password, sysrq_password, sizeof(sysrq_password), -S_IRUSR | S_IWUSR); +S_IRUSR | S_IWUSR); +module_param(seqno, long, S_IRUSR | S_IWUSR); +module_param(debug, int, S_IRUSR | S_IWUSR); MODULE_PARM_DESC(password, "password for remote sysrq"); +MODULE_PARM_DESC(seqno, "sequence number for remote sysrq"); +MODULE_PARM_DESC(debug, "debugging: 0=off, 1=on"); + +static struct crypto_hash *tfm; +static int digestsize; +static unsigned char *digest_password; +static unsigned char *sha1_digest; +static char *sha1_hexdigest; + +/* + * The data is of the form ",,," where + * is a series of sysrq requests; is a sequence number + * which must be greater than the last sequence number; is some + * random bytes; and is the sha1 hash of everything up to and + * including the preceding "/" together with the password. + * + * For example + * + * salt=$RANDOM + * req="s,$(date +%s),$salt" + * echo "$req,$(echo -n $req,secret | sha1sum | cut -c1-40)" + * + * You probably want a better salt and password than that though :-) + */ static unsigned int sysrq_tg(const void *pdata, uint16_t len) { const char *data = pdata; -char c; +int i, n; +struct scatterlist sg[2]; +struct hash_desc desc; +int ret; +long new_seqno = 0; if (*sysrq_password == '\0') { if (!sysrq_once) -printk(KERN_INFO KBUILD_MODNAME "No password set\n"); +printk(KERN_INFO KBUILD_MODNAME ": No password set\n"); sysrq_once = true; return NF_DROP; } - if (len == 0) return NF_DROP; -c = *data; -if (strncmp(&data[1], sysrq_password, len - 1) != 0) { -printk(KERN_INFO KBUILD_MODNAME "Failed attempt - " - "password mismatch\n"); +for (i = 0; sysrq_password[i]; i++) +if (sysrq_password[i] == '\n') +break; +sysrq_password[i] = '\0'; + +i = 0; +for (n = 0; n < len - 1; n++) { +if (i == 1 && '0' <= data[n] && data[n] <= '9') +new_seqno = 10L * new_seqno + data[n] - '0'; +if (data[n] == ',' && ++i == 3) +break; +} +n++; +if (i != 3) { +if (debug) +printk(KERN_WARNING KBUILD_MODNAME +": badly formatted request\n"); +return NF_DROP; +} +if (seqno >= new_seqno) { +if (debug) +printk(KERN_WARNING KBUILD_MODNAME +": old sequence number ignored\n"); +return NF_DROP; +} + +desc.tfm = tfm; +desc.flags = 0; +ret = crypto_hash_init(&desc); +if (ret) +goto hash_fail; +sg_init_table(sg, 2); +sg_set_buf(&sg[0], data, n); +strcpy(digest_password, sysrq_password); +i = strlen(digest_password); +sg_set_buf(&sg[1], digest_password, i); +ret = crypto_hash_digest(&desc, sg, n + i, sha1_digest); +if (ret) +goto hash_fail; + +for (i = 0; i < digestsize; i++) { +sha1_hexdigest[2 * i] = +"0123456789abcdef"[(sha1_digest[i] >> 4) & 0xf]; +sha1_hexdigest[2 * i + 1] = +"0123456789abcdef"[sha1_digest[i] & 0xf]; +} +sha1_hexdigest[2 * digestsize] = '\0'; +if (len - n < digestsize) { +if (debug) +printk(KERN_INFO KBUILD_MODNAME ": Short digest," +" expected %s\n", sha1_hexdigest); +return NF_DROP; +} +if (strncmp(data + n, sha1_hexdigest, digestsize) != 0) { +if (debug) +printk(KERN_INFO KBUILD_MODNAME ": Bad digest," +" expected %s\n", sha1_hexdigest); return NF_DROP; } +/* Now we trust the requester */ +seqno = new_seqno; +for (i = 0; i < len && data[i] != ','; i++) { +printk(KERN_INFO KBUILD_MODNAME ": SysRq %c\n", data[i]); #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 19) -handle_sysrq(c, NULL); +handle_sysrq(data[i], NULL); #else -handle_sysrq(c, NULL, NULL); +handle_sysrq(data[i], NULL, NULL); #endif +} return NF_ACCEPT; +hash_fail: +printk(KERN_WARNING KBUILD_MODNAME ": digest failure\n"); +return NF_DROP; } static unsigned int < at >< at > -73,9 +166,11 < at >< at > sysrq_tg4(struct sk_buff **pskb, const s udph = (void *)iph + ip_hdrlen(skb); len = ntohs(udph->len) - sizeof(struct udphdr); -printk(KERN_INFO KBUILD_MODNAME ": " NIPQUAD_FMT ":%u -> :%u len=%u\n", - NIPQUAD(iph->saddr), htons(udph->source), htons(udph->dest), - len); +if (debug) +printk(KERN_INFO KBUILD_MODNAME +": " NIPQUAD_FMT ":%u -> :%u len=%u\n", +NIPQUAD(iph->saddr), htons(udph->source), +htons(udph->dest), len); return sysrq_tg((void *)udph + sizeof(struct udphdr), len); } < at >< at > -94,9 +189,11 < at >< at > sysrq_tg6(struct sk_buff **pskb, const s udph = udp_hdr(skb); len = ntohs(udph->len) - sizeof(struct udphdr); -printk(KERN_INFO KBUILD_MODNAME ": " NIP6_FMT ":%hu -> :%hu len=%u\n", - NIP6(iph->saddr), ntohs(udph->source), - ntohs(udph->dest), len); +if (debug) +printk(KERN_INFO KBUILD_MODNAME +": " NIP6_FMT ":%hu -> :%hu len=%u\n", +NIP6(iph->saddr), ntohs(udph->source), +ntohs(udph->dest), len); return sysrq_tg(udph + sizeof(struct udphdr), len); } < at >< at > -146,11 +243,54 < at >< at > static struct xt_target sysrq_tg_reg[] _ static int __init sysrq_tg_init(void) { +struct timeval now; +tfm = crypto_alloc_hash("sha1", 0, CRYPTO_ALG_ASYNC); +if (IS_ERR(tfm)) { +printk(KERN_WARNING KBUILD_MODNAME +": Error: Could not find or load sha1 hash\n"); +tfm = NULL; +goto fail; +} +digestsize = crypto_hash_digestsize(tfm); +sha1_digest = kmalloc(digestsize, GFP_KERNEL); +if (!sha1_digest) { +printk(KERN_WARNING KBUILD_MODNAME +": Cannot allocate sha1_digest\n"); +goto fail; +} +sha1_hexdigest = kmalloc(2 * digestsize + 1, GFP_KERNEL); +if (!sha1_hexdigest) { +printk(KERN_WARNING KBUILD_MODNAME +": Cannot allocate sha1_hexdigest\n"); +goto fail; +} +digest_password = kmalloc(sizeof(sysrq_password), GFP_KERNEL); +if (!digest_password) { +printk(KERN_WARNING KBUILD_MODNAME +": Cannot allocate password digest space\n"); +goto fail; +} +do_gettimeofday(&now); +seqno = now.tv_sec; return xt_register_targets(sysrq_tg_reg, ARRAY_SIZE(sysrq_tg_reg)); +fail: +if (tfm) +crypto_free_hash(tfm); +if (sha1_digest) +kfree(sha1_digest); +if (sha1_hexdigest) +kfree(sha1_hexdigest); +if (digest_password) +kfree(digest_password); +return -EINVAL; } static void __exit sysrq_tg_exit(void) { +crypto_free_hash(tfm); +kfree(sha1_digest); +kfree(sha1_hexdigest); +kfree(digest_password); return xt_unregister_targets(sysrq_tg_reg, ARRAY_SIZE(sysrq_tg_reg)); } -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

iptables cut specific connections when lots of files are commited via subversion

IKA SysAdmin — 2008-11-27T08:53:24

Hi there, I had a problematic experience with iptables and thought, you might be interested. regards, Claudia Server FSC RX300, 8GB Memory Red Hat Enterprise Linux Server release 5.2 (Tikanga) Kernel 2.6.18-92.1.13.el5 #1 SMP Thu Sep 4 03:51:21 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux Diskspace 175GB free out of 185GB (mirrored) 2 network cards - one for "internal" use that provides samba shares - one for "external" use that provieds access to the subversion system the server is in a university campus in a virtual networkzone, but the filters there are open to my servers. apache httpd 2.2.3-11 subversion 1.4.2-2 iptables 1.3.5-4 iptables-ipv6 1.3.5-4 iptables added (created with firewall builder 3), only certain networks have access on the port 443, some on the samba shares on the server and some on the ssh port, everything else is closed down. cronjob, that refreshed the firewall builder iptables all 15min. (*/15 * * * * /bin/sh /etc/firewall/IkaFw.fw > /dev/null) svn clients mostly with tortoise over https port Problem with subversion: - commits and updates worked, but only with few files. As soon as somebody commited lots of files, the connection got lost. - to make it more problematic, the https port was not available anymore from at last two subnets (one of them outside the virtual network of the campus), but it was still available from within the same subnet as the server is and from another subnet outside the virtual network of the campus - on the server everything looked fine, httpd running, no errors in logfiles - but it wasn't accessible from all networks anymore - after a reboot of the server, everything worked again - until somebody committed lots of files again - after trying some things, I stopped iptables and we were able to commit lots of files - also the flushing of the iptables helped - for one big commit, afterwards the server wasn't accessible anymore from most of the outside networks - The use of the sambashare didn't produce any errors, we were able to load lots of heavy files on that share. So I disabled the iptables and setup an external firewall box - some developpers now commited large sums of files and the error didn't occur anymore. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Building the conntrack rule from scratch

Bryan Duff — 2008-11-26T21:45:07

If I build a conntrack rule (before any traffic actually traverses), and then send traffic through, the conntrack rule gets used, but no SNAT takes place. It sends the packet outbound with a source IP on the LAN instead of using the reply-dst and SNAT'ing to the WAN side. How do I get it to SNAT the packet? In this way I'm circumventing iptables (why use it when you already have all the information anyway) - so nat POSTROUTING is never actually touched by the first outbound packet - it's picked up by the conntrack rule. Tell me if I'm missing something, or if more information is needed. -Bryan -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

netfilter: ctnetlink: fix GFP_KERNEL allocation under spinlock

Patrick McHardy — 2008-11-26T11:23:08

This patch for 2.6.28 fixes a GFP_KERNEL allocation under spinlock in ctnetlink that was missed in the conntrack creation race fix. Please apply, thanks.

getting kernel compilation error after applying patches using p-o-m

2008-11-25T01:49:21

Hi, I am trying to build IPTable-1.4.2 with Red Hat Linux v4 U3 - kernel-2.6.9-34.EL. I have taken the following steps- I downloaded source code of iptables-1.4.2. I compiled and installed the IPTables-1.4.2 using the following command. # make # make install # and then I rebooted linux Then, I used the patch-o-matic to apply the set of patches( I downloaded the patch-o-match-ng using git clone, git://git.netfilter.org/patch-o-matic-ng) I am having kernel-2.6.9.34EL source code at /usr/src/kernel-2.6.9/linux-2.6.9 and IPTable-1.4.2 source code at /usr/src/iptables-1.4.2 I used the following steps to apply the patches- [root< at >RHEL4U3 patch-o-matic-ng]# export KERNEL_DIR=/usr/src/kernel-2.6.9/linux-2.6.9/ [root< at >RHEL4U3 patch-o-matic-ng]# export IPTABLES_DIR=/usr/src/iptables-1.4.2/ [root< at >RHEL4U3 patch-o-matic-ng]# ./runme base I applied all patches (which applies cleanly) and then used the following steps to build the kernel- [root< at >RHEL4U3]# make oldconfig [root< at >RHEL4U3]# make menuconfig [root< at >RHEL4U3]# make While making the Kernel, I encountered the following compilation errors- "net/ipv4/netfilter/ipt_ipv4options.c:160: error: unknown field `matchsize' specified in initializer net/ipv4/netfilter/ipt_ipv4options.c:160: warning: initialization makes pointer from integer without a cast net/ipv4/netfilter/ipt_ipv4options.c:161: warning: initialization from incompatible pointer type make[3]: *** [net/ipv4/netfilter/ipt_ipv4options.o] Error 1 make[2]: *** [net/ipv4/netfilter] Error 2 make[1]: *** [net/ipv4] Error 2 make: *** [net] Error 2" Can this error occur because of compatibility issue between Kernel-2.6.9.34EL and IPTable-1.4.2? If yes then which is the best compatible version of IPTable for Kernel-2.6.9.34EL? If there is no compatibility issue, can you please suggest me how to solve the above error? Thanks, Kamal -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] routing via nfmark in OUTPUT NFQUEUE

Eric Leblond — 2008-11-24T20:46:45

Hi, This small patchset is a resend of a work by Laurent Licour. It adds a rerouting possibility if the mark has been changed in OUTPUT via NFQUEUE. First patch is IPv4 version from Laurent Licour, second patch is a port to IPv6 I've done. BR, -- Eric Leblond inl.fr> NuFW, Now User Filtering Works : http://www.nufw.org -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

netfilter 00/03: netfilter fixes

Patrick McHardy — 2008-11-24T13:44:35

Hi Dave, the following three patches for 2.6.28 fix a couple of netfilter issues: - a conntrack creation race in ctnetlink that can cause NULL pointer dereferences in ctnetlink and duplicate conntrack entries. - a missing const qualifier that got lost during the encapsulation of iptables target parameters - a crash with bridge netfilter and GRE caused by a missing update_pmtu() function for the fake dst_entry. Please apply, thanks. include/linux/netfilter/x_tables.h | 2 +- net/bridge/br_netfilter.c | 13 +++++++++++++ net/netfilter/nf_conntrack_core.c | 2 -- net/netfilter/nf_conntrack_netlink.c | 5 +++-- 4 files changed, 17 insertions(+), 5 deletions(-) Herbert Xu (1): bridge: netfilter: fix update_pmtu crash with GRE Jan Engelhardt (1): netfilter: xtables: add missing const qualifier to xt_tgchk_param Patrick McHardy (1): netfilter: ctnetlink: fix conntrack creation race -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

I need help with libnetfilter_queue

ilninno — 2008-11-23T14:03:49

Hi again! I need help with libnetfilter_queue, I searched examples, but I only found one simple test. My problem is that i need source ip and source port, but i don't know how can i get from struct nfq_data *pkt in the callback function. Sorry for my english and thanks for your time :) -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

reinject packets

赵磊 — 2008-11-23T08:51:42

Hi, I register an NF_IP_PRE_ROUTING hook that check all the incoming packets and return NF_STOLEN on particular TCP packets. I’m trying to reinject them into the TCP/IP stack later. Any advice about how this can be achieved in a module? Does netfilter provide such a functionality? Thanks a lot.

iptables (1.4.2 release) failed to run on embedded system with "can't initialize iptables table `filter'"

David Wu — 2008-11-21T14:51:38

I am trying to run iptables (1.4.2 release)on a MCF53281(m68knommu, 2.6.26 kernel) embedded board. It failed with " iptables v1.4.2: can't initialize iptables table `filter': No chain/target/match by that name Perhaps iptables or your kernel needs to be upgraded. I traced the calls and found out that it failed at iptcc_chain_index_alloc(): h->chain_index = malloc(array_mem); in the first call to iptcc_chain_index_alloc() array_mem is 0 which means malloc(0) is called in the above statement. depends on the implementation malloc(0) may return NULL which is the case for m68k-uclinux-gcc(gcc version 4.2.3 and uClibc-0.9.29-20081003) I have changed the code to: if(array_mem == 0) h->chain_index = malloc(1); else h->chain_index = malloc(array_mem); and it works(while I have to fix another error -- ip_tables: ERROR target: invalid size 30 != 32) My question: 1 why tries to allocate 0 size memory, it is useful? 2 is there any problem to the iptables program in my change? I may have to rebuild the toolchain so malloc will return a live pointer for 0 size allocation. 3 I have got the error ip_tables: ERROR target: invalid size 30 != 32 from 1.3.7 and 1.4.2 (didn't try other versions) and sent to this list a question before but haven't received any answer then I assume I have done something wrong. If this is not the correct mailing list for these questions then can someone let me know the right mailing list ? thanks, David Wu -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

problem with iptables....badly need help

varun uppal — 2008-11-21T11:40:31

Hi, I am using iptables to queue the packets and then read them from IP_queue. The downloads stop, I took tcpdump on Ethernet interface and loopback interface, the data seems to be getting corrupted By the time it hits INPUT chain or is read from ip_queue. I have red hat enterprise linux 4, with kernel 2.6.9-42 and iptables version 1.2.11 please please badly need help. thanks varun -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

NF_STOLEN

赵磊 — 2008-11-21T02:17:06

Hi, I register a NF_IP_PRE_ROUTING hook that check the incoming packets. I’m trying to return NF_STOLEN on particular TCP packets and later pass them to the TCP module of the kernel. Any advice about how this can be achieved? Thanks a lot. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

doc: fix a typo in libip6t_REJECT.man

Jan Engelhardt — 2008-11-20T16:40:50

commit 0b474f182c0735e3920a4ae8ade73e8a6aaedecf Author: Jan Engelhardt medozas.de> Date: Thu Nov 20 17:21:04 2008 +0100 doc: fix a typo in libip6t_REJECT.man Signed-off-by: Jan Engelhardt medozas.de> --- extensions/libip6t_REJECT.man | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/extensions/libip6t_REJECT.man b/extensions/libip6t_REJECT.man index 909d826..877a769 100644 --- a/extensions/libip6t_REJECT.man +++ b/extensions/libip6t_REJECT.man < at >< at > -32,5 +32,4 < at >< at > TCP RST packet to be sent back. This is mainly useful for blocking (113/tcp) probes which frequently occur when sending mail to broken mail hosts (which won't accept your mail otherwise). .B tcp-reset -can only be used with kernel versions 2.6.14 or latter. - +can only be used with kernel versions 2.6.14 or later. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] nf_conntrack_proto_gre: spread __exit

Alexey Dobriyan — 2008-11-20T09:01:20

Signed-off-by: Alexey Dobriyan gmail.com> --- net/netfilter/nf_conntrack_proto_gre.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/netfilter/nf_conntrack_proto_gre.c +++ b/net/netfilter/nf_conntrack_proto_gre.c < at >< at > -341,7 +341,7 < at >< at > static int __init nf_ct_proto_gre_init(void) return rv; } -static void nf_ct_proto_gre_fini(void) +static void __exit nf_ct_proto_gre_fini(void) { nf_conntrack_l4proto_unregister(&nf_conntrack_l4proto_gre4); unregister_pernet_gen_subsys(proto_gre_net_id, &proto_gre_net_ops); -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] ip6table_filter: merge LOCAL_IN and FORWARD hooks

Alexey Dobriyan — 2008-11-20T09:00:23

Signed-off-by: Alexey Dobriyan gmail.com> --- net/ipv6/netfilter/ip6table_filter.c | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-) --- a/net/ipv6/netfilter/ip6table_filter.c +++ b/net/ipv6/netfilter/ip6table_filter.c < at >< at > -61,7 +61,7 < at >< at > static struct xt_table packet_filter = { /* The work comes in here from netfilter.c. */ static unsigned int -ip6t_local_in_hook(unsigned int hook, +ip6t_in_hook(unsigned int hook, struct sk_buff *skb, const struct net_device *in, const struct net_device *out, < at >< at > -72,17 +72,6 < at >< at > ip6t_local_in_hook(unsigned int hook, } static unsigned int -ip6t_forward_hook(unsigned int hook, - struct sk_buff *skb, - const struct net_device *in, - const struct net_device *out, - int (*okfn)(struct sk_buff *)) -{ -return ip6t_do_table(skb, hook, in, out, - dev_net(in)->ipv6.ip6table_filter); -} - -static unsigned int ip6t_local_out_hook(unsigned int hook, struct sk_buff *skb, const struct net_device *in, < at >< at > -105,14 +94,14 < at >< at > ip6t_local_out_hook(unsigned int hook, static struct nf_hook_ops ip6t_ops[] __read_mostly = { { -.hook= ip6t_local_in_hook, +.hook= ip6t_in_hook, .owner= THIS_MODULE, .pf= PF_INET6, .hooknum= NF_INET_LOCAL_IN, .priority= NF_IP6_PRI_FILTER, }, { -.hook= ip6t_forward_hook, +.hook= ip6t_in_hook, .owner= THIS_MODULE, .pf= PF_INET6, .hooknum= NF_INET_FORWARD, -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html