Re: Hacked computer
> If you've been rooted, then the logs are probably no good. But check you wtmp > for logons, and messages, and well if you don't see anything unusual there then > the've prabaly been wiped. Have regained root yet? personally I would pull the > box off net and backup theimportant config stuff, then blast itbut hey I > tend to be a bit of an extremist in these cases... A very helpful trick I did on a Linux box once that was rooted where Mr. Friendly did a "rm -fr /" to try to make my life as difficult as possible was: (after installing the erased drive on a new machine) strings /dev/hdc1 > keepme_hdc1 Due to the fact that "rm" really doesn't erase anything, the contents were still there - doing a "strings" on the raw partition will retrieve a lot. With a bit of patience, it's amazing what will show up -- usually, the former contents of /var/log/* will show up as large chunks that are easily read... Turns out I found this guy's IP address and the time the system was blasted - a call to MCI resulted in a small amount of satisfaction... --mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
PC with two network cards
HI!! I have two network cards in my PC with freeBSD 4.0., a 3COM Ethernet card and a WaveLAN card. Both are attached at the same subnetwork, I mean , both has the same subnetwork address, but different host address. They are configured in rc.conf file and in /etc/hosts but when i try ifconfig -a the Ethernet card is running and ping works perfectly but the WaveLAN has inet 0.0.0.0 and ping doesnt work (but the card is running). Ana To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: PC with two network cards
It seems Ana Romero wrote: > HI!! > I have two network cards in my PC with freeBSD 4.0., a > 3COM Ethernet card and a WaveLAN card. Both are attached at the same subnetwork, > I mean , both has the same subnetwork address, but different host address. > They are configured in rc.conf file and in > /etc/hosts but when i try ifconfig -a the Ethernet card > is running and ping works perfectly but > the WaveLAN has inet 0.0.0.0 and ping doesnt work (but > the card is running). You need to setup the wavelan via the pccard_ether script or hardcode the ifconfig in pccard.conf... An ifconfig via rc.conf wont work on the wavelan as it is found after the network setups -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h
On Dec 18, 6:26pm, Jesper Skriver wrote:
} Subject: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_
} Hi,
}
} I'm trying to find out what to to now regarding this.
}
} To summarize.
}
} PHK committed my original patch, this patch have the following
} functionality
} - When a ICMP administrative prohibited is recieved, it zap's
} all TCP sessions in SYN-SENT state matching the source and destination
} IP addresses and TCP port numbers in the IP header + 8 bytes from the
} ICMP packet.
} - It does not match against TCP sequence number
} - disabled by default
}
} Yesterday I summitted a new diff, with the following changes to the
} above.
}
} - Matches against the TCP sequence number in the IP header + 8 bytes
} from the ICMP packet, against the last unacknowledged packet in the
} TCP session matching the source and destination IP addresses and
} TCP port numbers, these must be equal, thus it only matches if the
} ICMP unreachable is for the last sent packet.
} This is very secure, but in reality only has effect when setting up
} the session, as it doesn't work with multiple outstanding packets,
} it does work when setting up sessions, as the window will be zero
} here.
} this could be fixed by something like (*)
} - Check for SYN-SENT state removed
} - enabled by default
}
} What I will suggest at this point, is to do one of 2 things:
}
} 1) Extend the original diff PHK committed to check for sequence number,
}and enable it by default, trivial as it's part of the second diff.
} 2) Fix the second diff with the below code.
}
} For both I'll also add a extra check if the IP header in the ICMP packet
} has options set, and if it has, don't act on it, this applies to both,
} the reason for this is, if it has options set, we'll miss some (or all)
} of the 8 bytes from the TCP header, and thus, we'll not know port and
} sequence numbers.
}
} What do you prefer ? When I know this, I'll post a new diff for review.
}
} (*) replace
}
} if (tp->snd_una != tcp_sequence) {
}
} with
}
} /*
}* First check: if sequence numbers have wrapped, don't act on this.
}* Second -"- : if the sequence number from the ICMP packet is for a
}* "old" packet, it's probably spoofed, dont't act on this.
}* Third -"- : if the sequence number from the ICMP packet is for a
}* packet from the future, it's spoofed, don't act on this.
}*/
} if ((tp->snd_max < tp->snd_una) || (tcp_sequence < tp->snd_una) || \
} (tp->snd_max < tcp_sequence)) {
The sequence number comparisons should use the SEQ_xx() macros, which
handle sequence number wrapping. The sanity checks should probably be
the same as incoming RST validation, see the code in tcp_input() for
the code and matching comments. In the SYN-SENT state, this would
translate to:
if (SEQ_LEQ(tcp_sequence, tp->iss) ||
SEQ_GT(tcp_sequence, tp->snd_max)) {
/* ignore the icmp */
In the other states, RFC 793 says that the RST sanity checking is done by
comparing the sequence number of the of the incoming RST packet against
the transmit window (our outgoing acknowledgement numbers). The host
sending the RST is supposed to copy the acknowledgement number from
an incoming packet to the sequence number of the outgoing RST packet.
This presents a bit of a problem if we try to do the same thing with ICMP,
since it appears that the acknowledgement number is trimmed off the the
data that is returned in the ICMP packet.
It's been too long a day for me to figure out the security implications
of nuking non-SYN-SENT connections based on the sequence number (which
would still be better than nuking these connections without any additional
checking). If we want to do this, the test should probably be:
if (SEQ_LEQ(tcp_sequence, tp->snd_una) ||
SEQ_GT(tcp_sequence, tp->snd_max)) {
though someone needs to check this for fencepost errors.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Hacked computer
On Tue, Dec 19, 2000 at 03:24:15AM -0500, Mike Nowlin thus spoke: > > If you've been rooted, then the logs are probably no good. But > > check you wtmp for logons, and messages, and well if you don't > > see anything unusual there then the've prabaly been wiped. Have > > regained root yet? ... ... > Due to the fact that "rm" really doesn't erase anything, the > contents were still there - doing a "strings" on the raw partition > will retrieve a lot. > With a bit of patience, it's amazing what will show up -- usually, > the former contents of /var/log/* will show up as large chunks > that are easily read... Turns out I found this guy's IP address > and the time the system was blasted - a call to MCI resulted in a > small amount of satisfaction... It's amazing what TCT - The Coroners Toolkit - will display. 'lazurus' causes files to rise from the dead. Used ahead of time you can run MD5 on the entire system so you can check everything if you beleive you've been broken into. Dan Farmer and Wietse Venema wrote it. Bill -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Hacked computer
On Tue, Dec 19, 2000 at 10:07:45AM -0500, Bill Vermillion thus spoke: > On Tue, Dec 19, 2000 at 03:24:15AM -0500, Mike Nowlin thus spoke: Damn - been one of those days. I looked at the sources to get Wietse's name spelled right, and copied out the source address but negelected to include that. Bad form to follow up your own message - the relevant part is below for reference. Here are the addresses for the source: http://www.fish.com/forensics/ http://www.porcupine.org/forensics/ > > With a bit of patience, it's amazing what will show up -- usually, > > the former contents of /var/log/* will show up as large chunks > > that are easily read... Turns out I found this guy's IP address > > and the time the system was blasted - a call to MCI resulted in a > > small amount of satisfaction... > > It's amazing what TCT - The Coroners Toolkit - will display. > 'lazurus' causes files to rise from the dead. Used ahead of > time you can run MD5 on the entire system so you can check > everything if you beleive you've been broken into. > > Dan Farmer and Wietse Venema wrote it. > > Bill > -- > Bill Vermillion - bv @ wjv . com > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: PC with two network cards
In message <[EMAIL PROTECTED]> Soren Schmidt writes: : You need to setup the wavelan via the pccard_ether script or hardcode : the ifconfig in pccard.conf... An ifconfig via rc.conf wont work on : the wavelan as it is found after the network setups Or you need to add -z to the pccard flags: pccardd_flags="-z" in /etc/rc.conf. This will force pccardd to wait until it has succeeded or failed to attach a device in each slot before going into the background. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h
On Tue, Dec 19, 2000 at 06:25:46AM -0800, Don Lewis wrote:
> In the other states, RFC 793 says that the RST sanity checking is done by
> comparing the sequence number of the of the incoming RST packet against
> the transmit window (our outgoing acknowledgement numbers). The host
> sending the RST is supposed to copy the acknowledgement number from
> an incoming packet to the sequence number of the outgoing RST packet.
> This presents a bit of a problem if we try to do the same thing with ICMP,
> since it appears that the acknowledgement number is trimmed off the the
> data that is returned in the ICMP packet.
>
> It's been too long a day for me to figure out the security implications
> of nuking non-SYN-SENT connections based on the sequence number (which
> would still be better than nuking these connections without any additional
> checking). If we want to do this, the test should probably be:
>
> if (SEQ_LEQ(tcp_sequence, tp->snd_una) ||
> SEQ_GT(tcp_sequence, tp->snd_max)) {
>
> though someone needs to check this for fencepost errors.
It should be
if (SEQ_LT(tcp_sequence, tp->snd_una) ||
SEQ_GT(tcp_sequence, tp->snd_max)) {
As the sequence number will be == tp->snd_una when the window is zero.
I'll submit a new later tonight, as I havn't heard anything, I'll make a
sysctl control if it should have effect on all sessions, or only those
in SYN-SENT state, defaulting to those in SYN-SENT state only.
/Jesper
--
Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456
Work:Network manager @ AS3292 (Tele Danmark DataNetworks)
Private: Geek@ AS2109 (A much smaller network ;-)
One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
No Subject
Is there a way that I can temporarely supress Kernel arp errors from poping up on the console until i'm done with my config? I'm reconfiguring a network into separate internal and external segments separated by a firewall. However it's going to take me a little while to do it, and in order to keep things functioning until it's done, I'm gong to have to keep both the inside and outside nic's plugged into the same switch (which gives a lot of errors like this). /kernel: arp: 10.10.1.70 is on rl0 but got reply from (mac) on fpx0 TIA Peter Brezny SysAdmin Services Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: PC with two network cards (one of them a Wavelan!)
Also read this, a complete HOWTO about wireless networking and FreeBSD: http://www.live.com/wireless/unix-base-station.html It should answer your question fully. - Original Message - From: "Warner Losh" <[EMAIL PROTECTED]> To: "Soren Schmidt" <[EMAIL PROTECTED]> Cc: "Ana Romero" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, December 19, 2000 9:47 AM Subject: Re: PC with two network cards > In message <[EMAIL PROTECTED]> Soren Schmidt writes: > : You need to setup the wavelan via the pccard_ether script or hardcode > : the ifconfig in pccard.conf... An ifconfig via rc.conf wont work on > : the wavelan as it is found after the network setups > > Or you need to add -z to the pccard flags: > pccardd_flags="-z" > in /etc/rc.conf. This will force pccardd to wait until it has > succeeded or failed to attach a device in each slot before going into > the background. > > Warner > > > 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
Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h
On Mon, Dec 18, 2000 at 06:26:00PM +0100, Jesper Skriver wrote:
> Hi,
>
> I'm trying to find out what to to now regarding this.
>
> To summarize.
>
> PHK committed my original patch, this patch have the following
> functionality
> - When a ICMP administrative prohibited is recieved, it zap's
> all TCP sessions in SYN-SENT state matching the source and destination
> IP addresses and TCP port numbers in the IP header + 8 bytes from the
> ICMP packet.
> - It does not match against TCP sequence number
> - disabled by default
>
> Yesterday I summitted a new diff, with the following changes to the
> above.
>
> - Matches against the TCP sequence number in the IP header + 8 bytes
> from the ICMP packet, against the last unacknowledged packet in the
> TCP session matching the source and destination IP addresses and
> TCP port numbers, these must be equal, thus it only matches if the
> ICMP unreachable is for the last sent packet.
> This is very secure, but in reality only has effect when setting up
> the session, as it doesn't work with multiple outstanding packets,
> it does work when setting up sessions, as the window will be zero
> here.
> this could be fixed by something like (*)
> - Check for SYN-SENT state removed
> - enabled by default
I've got little response to my previous mail, so here is a new diff
(relative to -current), which I suggest to commit, I think this solves
all the issues people has brought up.
It has the following functionality.
- If the sysctl net.inet.tcp.icmp_admin_prohib_like_rst == 1 (default)
it enables the below.
- When a ICMP administrative prohibited is recieved, it check is the
IP header attached to the ICMP packet has any options set, if it has
it ignores it. The reason for this is, if any options is set the extra
8 bytes is no longer the first 8 bytes from the TCP header, source/
destination ports and sequence number, which we need to find the
right TCP session.
- Then it goes through the list of active TCP sessions, if it finds one
with the same source/destination IP addresses and TCP port numbers, it
checks if the sequence number it got from the ICMP packet is one of
a unacknowledged packet from this sessions, if it's not, it ignores it.
- If the sysctl net.inet.tcp.icmp_like_rst_syn_sent_only == 1 (default)
it will only zap connections in SYN-SENT state, if it's == 0 it will
zap the connection regardless of current state.
In a addition to this, I've done some cleanup compared to the diff I
posted on sunday.
This is also submitted as PR kern/23655
Someome please review this.
/Jesper
--
Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456
Work:Network manager @ AS3292 (Tele Danmark DataNetworks)
Private: Geek@ AS2109 (A much smaller network ;-)
One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
diff -ru sys/netinet.old/in_pcb.c sys/netinet/in_pcb.c
--- sys/netinet.old/in_pcb.cSun Dec 17 18:57:24 2000
+++ sys/netinet/in_pcb.cTue Dec 19 21:18:58 2000
@@ -667,13 +667,14 @@
* any errors for each matching socket.
*/
void
-in_pcbnotify(head, dst, fport_arg, laddr, lport_arg, cmd, notify)
+in_pcbnotify(head, dst, fport_arg, laddr, lport_arg, cmd, notify, tcp_sequence)
struct inpcbhead *head;
struct sockaddr *dst;
u_int fport_arg, lport_arg;
struct in_addr laddr;
int cmd;
void (*notify) __P((struct inpcb *, int));
+ u_int32_t tcp_sequence;
{
register struct inpcb *inp, *oinp;
struct in_addr faddr;
@@ -714,6 +715,15 @@
(lport && inp->inp_lport != lport) ||
(laddr.s_addr && inp->inp_laddr.s_addr != laddr.s_addr) ||
(fport && inp->inp_fport != fport)) {
+ inp = inp->inp_list.le_next;
+ continue;
+ }
+ /*
+* If tcp_sequence is set, then skip sessions where
+* the sequence number is not one of a unacknowledged
+* packet.
+*/
+ if ((tcp_sequence) && (tcp_seq_vs_sess(inp, tcp_sequence) == 0)) {
inp = inp->inp_list.le_next;
continue;
}
diff -ru sys/netinet.old/in_pcb.h sys/netinet/in_pcb.h
--- sys/netinet.old/in_pcb.hSun Dec 17 18:57:24 2000
+++ sys/netinet/in_pcb.hSun Dec 17 22:47:39 2000
@@ -290,7 +290,7 @@
struct in_addr, u_int, struct in_addr, u_int,
int, struct ifnet *));
void in_pcbnotify __P((struct inpcbhead *, struct sockaddr *,
- u_int, struct in_addr, u_int, int, void (*)(struct inpcb *, int)));
+ u_int, struct in_addr, u_int, int, void (*)(struct inpcb *, int),
+u_int32_t));
void in_pcbrehash __P((struct inpcb *));
intin_setpeeraddr __P((struct socket *so, struct sockaddr **nam))
Re: your mail
At Tue, 19 Dec 2000, [EMAIL PROTECTED] wrote: >Is there a way that I can temporarely supress Kernel arp errors from poping >up on the console until i'm done with my config? >I'm reconfiguring a network into separate internal and external segments >separated by a firewall. However it's going to take me a little while to do >it, and in order to keep things functioning until it's done, I'm gong to >have to keep both the inside and outside nic's plugged into the same switch >(which gives a lot of errors like this). >/kernel: arp: 10.10.1.70 is on rl0 but got reply from (mac) on fpx0 killall syslogd? (or tweak /etc/syslog.conf a little) Mark Lastdrager -- Pine Internet BV :: tel. +31-70-3111010 :: fax. +31-70-3111011 PGP 92BB81D1 fingerprint 0059 7D7B C02B 38D2 A853 2785 8C87 3AF1 Today's excuse: Bogon emissions To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: your mail
On Tue, 19 Dec 2000, Peter Brezny wrote:
> Is there a way that I can temporarely supress Kernel arp errors from poping
> up on the console until i'm done with my config?
> I'm reconfiguring a network into separate internal and external segments
> separated by a firewall. However it's going to take me a little while to do
> it, and in order to keep things functioning until it's done, I'm gong to
> have to keep both the inside and outside nic's plugged into the same switch
> (which gives a lot of errors like this).
> /kernel: arp: 10.10.1.70 is on rl0 but got reply from (mac) on fpx0
> TIA
> Peter Brezny
> SysAdmin Services Inc.
I patch if_ether.c so that it doesn't complain; I'm thinking about adding
a sysctl variable to allow this behavior to be changed at runtime.
*** sys/netinet/if_ether.c.ORIG Tue Oct 24 14:39:04 2000
--- sys/netinet/if_ether.c Tue Nov 21 05:32:04 2000
***
*** 557,567
--- 557,569
if (la && (rt = la->la_rt) && (sdl = SDL(rt->rt_gateway))) {
#ifndef BRIDGE /* the following is not an error when doing bridging */
if (rt->rt_ifp != &ac->ac_if) {
+ #ifdef NAGNAGNAG
log(LOG_ERR, "arp: %s is on %s%d but got reply from %6D on
%s%d\n",
inet_ntoa(isaddr),
rt->rt_ifp->if_name, rt->rt_ifp->if_unit,
ea->arp_sha, ":",
ac->ac_if.if_name, ac->ac_if.if_unit);
+ #endif
goto reply;
}
#endif
--
Guy Helmer, Ph.D.
Sr. Software Engineer, Palisade Systems --- [EMAIL PROTECTED]
http://www.palisadesys.com/~ghelmer
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Hosname lookup failure
Hi! I have a tiny laptop, Libretto100CT, I downloaded freeBsd (4.2)on it and from my home it was working fine. I brought it to school and now it is not able to connect to network. I changed the nameserver IP. If I do ping with IP address then I get error "host route not found". In case I use the name then I get "Host name lookup failure". Ping to localhost is working fine. Please give me some suggestions. -Harkirat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Hosname lookup failure
Do you have to set a default route to a gateway server? Ask your network administrator (or check the configuration of a buddy's machine). On Tue, 19 Dec 2000, Harkitrat Singh wrote: > > Hi! > > I have a tiny laptop, Libretto100CT, I downloaded freeBsd (4.2)on it and > from my home it was working fine. I brought it to school and now it is not > able to connect to network. I changed the nameserver IP. If I do ping with > IP address then I get error "host route not found". In case I use the name > then I get "Host name lookup failure". Ping to localhost is working fine. > > Please give me some suggestions. > > -Harkirat > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > === IF YOU WANT REFORM VOTE REFORM --- Orville R. Weyrich, Jr. Weyrich Computer Consulting mailto:[EMAIL PROTECTED] KD7HJVhttp://www.weyrich.com --- Visit our online collection of book reviews: http://www.weyrich.com/book_reviews/ Ask about our world wide web services! --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h
On Dec 19, 7:19pm, Jesper Skriver wrote: } Subject: Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c } } I'll submit a new later tonight, as I havn't heard anything, I'll make a } sysctl control if it should have effect on all sessions, or only those } in SYN-SENT state, defaulting to those in SYN-SENT state only. Do all ICMP unreachables kill off sessions in in the SYN-SENT state or only the administratively prohibited flavor? If all of them do, then only administratively prohibited ICMP unreachables should kill off established connections so that established sessions aren't killed off by routing flaps and other transient events. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
eepro100 dual port cards with failover ?
We need to use the dual Intel PRO/100+ dual port server adapter, and I wanted to know if FreeBSD supports them ? I guess that the card is a dual port (2 x RJ45) card and it uses only 1 IP for both ports and if one switch goes down it will automatically failure to the other port ? Is this at the driver level or at the hardware level ? (if anyone knows ) and if FreeBSD does not support them then can anyone recommend something similar ? thank you nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
