Re: What is my next step as a script kiddie ? (DDoS)
On Sun, Jan 12, 2003 at 03:33:16AM +0300, [EMAIL PROTECTED] wrote: > > much less CPU and plenty of places to strike. Protecting your network > > infrastructure is certainly the next place to go after you protect your > > high-target hosts. > > > > For some examples, see http://www.e-gerbil.net/ras/projects/dos/dos.txt > remember disposition: > small net(s) connected via low band (less then 10M) > link to one upstream. Obviously if you have a low speed connection, your pipe will fill before the hosts or routers ever have a chance to fall over (unless you have a REALLY low end router :P). But if the point of this discussion is to protect the hosts from falling over, then the network must be able to deliver a sufficiently large attack. And nothing sucks quite like watching a GSR fall over under a 20Mbit SYN flood. :) -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Asus A7N8X Deluxe, nForce2 chipset, 3com MAC, Broadcom/Altima PHY
On Sun, Jan 12, 2003 at 01:04:30PM -0800, David O'Brien wrote: > On Sun, Jan 12, 2003 at 09:07:31PM +0200, Mikko S. Hyvarinen wrote: > > The on-board 3com MAC and Broadcom/Altima PHY are not being detected by the > > xl(4) driver in -current (cvsup done yesterday evening). > > In the Award BIOS there is only one setting for the 3com device, a supposed > > on/off switch with only values Disabled and Auto; I have used Auto. > ... > > FWIW, the diff for the files mentioned is attached, in case someone wants > > to continue from here. > > Thanks! I committed this patch so it didn't get lost and maybe someone > else with one of these boards can take it all the way. As usual, it had to be something simple. With the attached change on top of the previous set the Altima AC101L PHY is detected correctly. I'm not so sure whether that xl_choose_xcvr() modification is actually necessary, but one can never be too sure. Tested with 10baseT/UTP and it works normally. Regards, MSH -- All opinions expressed above are mine alone and do not express the views of my employer or any other organizations that I am affiliated with. Index: sys/pci/if_xl.c === RCS file: /data/cvs/freebsd/src/sys/pci/if_xl.c,v retrieving revision 1.121 diff -u -r1.121 if_xl.c --- sys/pci/if_xl.c 12 Jan 2003 21:03:38 - 1.121 +++ sys/pci/if_xl.c 13 Jan 2003 16:24:50 - @@ -1245,6 +1245,7 @@ case TC_DEVICEID_HURRICANE_656: /* 3c656 */ case TC_DEVICEID_HURRICANE_656B:/* 3c656B */ case TC_DEVICEID_TORNADO_656C: /* 3c656C */ + case TC_DEVICEID_TORNADO_10_100BT_NVIDIA: /* nVidia nForce2 integrated */ sc->xl_media = XL_MEDIAOPT_MII; sc->xl_xcvr = XL_XCVR_MII; if (verbose) @@ -1340,6 +1341,8 @@ pci_get_device(dev) == TC_DEVICEID_HURRICANE_656B) sc->xl_flags |= XL_FLAG_INVERT_MII_PWR | XL_FLAG_INVERT_LED_PWR; + if (pci_get_device(dev) == TC_DEVICEID_TORNADO_10_100BT_NVIDIA) + sc->xl_flags |= XL_FLAG_PHYOK; /* * If this is a 3c905B, we have to check one extra thing.
Re: PANIC in tcp_syncache.c sonewconn() line 562
On Mon, 2003/01/13 at 17:47:11 +0100, Martin Blapp wrote:
> #10 0xc03df350 in trap (frame=
> {tf_fs = 24, tf_es = -65520, tf_ds = 16, tf_edi = 2, tf_esi = -1031597312,
> tf_ebp = -854635944, tf_isp = -854635988, tf_ebx = -1031595264, tf_edx = 4,
> tf_ecx = 0, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1071076206, tf_cs
> = 8, tf_eflags = 66050, tf_esp = -1031595264, tf_ss =
> 0}) at /usr/src/sys/i386/i386/trap.c:445
> #11 0xc03cf9f8 in calltrap () at {standard input}:98
> #12 0xc02e1f3f in syncache_socket (sc=0xc2831300, lso=0xc2831300, m=0xc0ed9c00)
> at /usr/src/sys/netinet/tcp_syncache.c:562
> #13 0xc02e23e8 in syncache_expand (inc=0xcd0f4b4c, th=0xc0ed9c68,
> sop=0xcd0f4b18, m=0xc0ed9c00)
> at /usr/src/sys/netinet/tcp_syncache.c:781
> #14 0xc02db779 in tcp_input (m=0xc0ed9c68, off0=20) at
> /usr/src/sys/netinet/tcp_input.c:703
> #15 0xc02d409b in ip_input (m=0xc0ed9c00) at /usr/src/sys/netinet/ip_input.c:923
> #16 0xc02d4192 in ipintr () at /usr/src/sys/netinet/ip_input.c:941
> #17 0xc02c1713 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:97
> #18 0xc0238df1 in ithread_loop (arg=0xc0eba000) at
> /usr/src/sys/kern/kern_intr.c:535
> #19 0xc0237cf3 in fork_exit (callout=0xc0238c20 , arg=0x0,
> frame=0x0)
> at /usr/src/sys/kern/kern_fork.c:873
>
> 562 so = sonewconn(lso, SS_ISCONNECTED);
This seems to actually be a quite old bug: we allow listen() to be
called on connected sockets, which messes up the state of the socket
(it will get SO_ACCEPTCONN set). Before syncache, this would likely
only lead to the connection becoming catatonic, unless a matching SYN
packet came along (in a state where the initial SYN of the connection
was already received). With syncache however, a panic can be triggered
by normal ACK packets.
In your example, the listen is buried in the bowels of the RPC code.
The solution should be to reject the listen() with EINVAL (which seems
to be that standard-mandated error for connected sockets); patch
attached.
Any thoughts on this?
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
<[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Index: kern/uipc_socket.c
===
RCS file: /ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.140
diff -u -r1.140 uipc_socket.c
--- kern/uipc_socket.c 5 Jan 2003 11:14:04 - 1.140
+++ kern/uipc_socket.c 13 Jan 2003 21:43:52 -
@@ -266,6 +266,10 @@
int s, error;
s = splnet();
+ if (so->so_state & (SS_ISCONNECTED | SS_ISCONNECTING)) {
+ splx(s);
+ return (EINVAL);
+ }
error = (*so->so_proto->pr_usrreqs->pru_listen)(so, td);
if (error) {
splx(s);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: PANIC in tcp_syncache.c sonewconn() line 562
Hi Thomas, > The solution should be to reject the listen() with EINVAL (which seems > to be that standard-mandated error for connected sockets); patch > attached. Cool, thank you for the proposed solution. I suspected something like this; rpcgen does generate quite broken code sometimes, and nobody cared about fixing these old bugs. :-( Since rpcgen in STABLE is broken too, it's not my fault ;) I'll provide a rpcgen patch too which has the call to listen() removed (in the inetd case) after the socket is already connected. I guess a "rpcgen -I" generated server should knew about this issue and test properly if it is run standalone or from inetd. The solution I think would be to reuse the socket. I'll provide a fix for this ! Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
kld && inetsw.pr_protocol overriding + old reuse
I'm interested in whether the following could be acomplished: there's KLD module, installing some new syscalls in the kernel, as well as installing new ``struct ipprotosw'' for some protocol or another(let's assume IPPROTO_UDP). Could we just add some code in the begging of the new protocol handler (counting, statistics , etc...) and call the old one after doing that. If possible, what should be the preparation for that last call ? Any help appreciated! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
kld && inetsw.pr_protocol overriding + old reuse
I'm interested in whether the following could be acomplished: there's KLD module, installing some new syscalls in the kernel, as well as installing new ``struct ipprotosw'' for some protocol or another(let's assume IPPROTO_UDP). Could we just add some code in the begging of the new protocol handler (counting, statistics , etc...) and call the old one after doing that. If possible, what should be the preparation for that last call ? Any help appreciated! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: kld && inetsw.pr_protocol overriding + old reuse
Radoslav Vasilev wrote: > I'm interested in whether the following could be acomplished: > there's KLD module, installing some new syscalls in the kernel, as well as > installing new ``struct ipprotosw'' for some protocol or another(let's > assume IPPROTO_UDP). > Could we just add some code in the begging of the new protocol handler > (counting, statistics , etc...) and call the old one after doing that. If > possible, what should be the preparation for that last call ? > Any help appreciated! This can't really be done, without actually hacking over top of the location that contained the code associated with the previous symbol. The reason for this is that the input path sometimes ends up making direct calls, assuming that the protocol stack is stacked the way it's expected to be stacked (e.g. direct calls to routines that are in struct ipprotosw). If you need to hack over the function, you need a lot more knowledge of assembly language; it is occasionally useful for profiling an existing system. The usual reason for wanting to do this is to make TCP/IP connections that are invisible to the OS, in order to attempt to turn FreeBSD boxes into DDOS robots, without the knowledge of their owners. 8-|. If you have a specific reason for this, you can replace the entry points with explicit entry points for your own routines, that call the real (renamed) routines, indirectly, and then replace the pointers. This will work fine on systems which legitimately belong to you, and for which you are willing to recompile the kernel, in order to make your modules work. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: kld && inetsw.pr_protocol overriding + old reuse
It is not very simple. However Netgraph/ng_socket.c does something similar.
net_add_domain is called from ngs_mod_event().
However, it is not possible to remove this module because the feature to
remove a domain is missing.
switch (event) {
case MOD_LOAD:
/* Register protocol domain */
net_add_domain(&ngdomain);
break;
case MOD_UNLOAD:
/* Insure there are no open netgraph sockets */
if (!LIST_EMPTY(&ngsocklist)) {
error = EBUSY;
break;
}
#ifdef NOTYET
if ((LIST_EMPTY(&ngsocklist)) && (typestruct.refs == 0)) {
/* Unregister protocol domain XXX can't do this yet.. */
if ((error = net_rm_domain(&ngdomain)) != 0)
break;
} else
#endif
error = EBUSY;
break;
I would be interested in this feature too ;-)
However there is no reference counter within the protosw structure, neither
within the domain structure. It seems to be difficult to remove them.
Moreover, how can the domains, that require a "routing layer", be loaded ?
rn_init is called only during the boot process in order to find the
max_keylen = MAX(dom->dom_maxrtkey).
Vincent
Le Mardi 14 Janvier 2003 00:53, Radoslav Vasilev a écrit :
> I'm interested in whether the following could be acomplished:
> there's KLD module, installing some new syscalls in the kernel, as well as
> installing new ``struct ipprotosw'' for some protocol or another(let's
> assume IPPROTO_UDP).
> Could we just add some code in the begging of the new protocol handler
> (counting, statistics , etc...) and call the old one after doing that. If
> possible, what should be the preparation for that last call ?
> Any help appreciated!
>
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
