Re: Hacked - FreeBSD 7.1-Release
# pfctl -sr | grep ssh_brutes block drop quick from to any pass quick on em1 inet proto tcp from any to xxx.xxx.xxx.0/23 port = ssh flags S/SA keep state (source-track rule, max-src-conn 20, max-src-conn-rate 3/12, overload flush global, src.track 12) pass quick on em0 inet proto tcp from any to xxx.xxx.xxx.0/23 port = ssh flags S/SA keep state (source-track rule, max-src-conn 20, max-src-conn-rate 3/12, overload flush global, src.track 12) # pfctl -t ssh_brutes -T show 24.69.83.139 24.106.149.2 59.108.230.130 59.124.109.227 60.6.237.54 60.212.42.11 61.47.34.67 78.40.82.74 79.136.123.7 79.188.234.58 85.12.25.157 85.38.97.122 85.114.135.208 94.198.49.185 110.12.64.141 114.255.100.163 116.28.64.181 121.254.228.61 123.15.41.98 123.124.236.195 158.49.245.201 173.10.126.225 189.108.172.26 190.9.128.231 193.203.70.180 195.219.57.189 202.103.25.246 203.76.99.62 203.94.231.11 208.87.3.42 210.119.104.170 211.92.149.147 211.144.32.185 212.18.195.102 216.36.150.58 218.97.254.206 218.206.233.43 221.202.118.39 222.221.2.210 # uname -a OpenBSD tereo.xxx.com 4.5 GENERIC#0 amd64 -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Disc lock up on 8.0-STABLE
> When you say "lock up" and "can't login" (in your original mail) - are > you sure this really is a lockup and not e.g. sshd dieing because of the > attacks? E.g. can you ping the machine, can you leave something like > "date >> /root/run.txt && vmstat 1 3 >> /root/run.txt" in crontab so you > track the moment it dies more closely? Yes, I can ping the machine, and connect to the SSH port and see the banner. On the console I can hit return and get a login prompt, and then get a password prompt. Trying to login doesnt work though - the symptoms are consistent with it not being able to read from the discs, but not panicing or dying either. I can, for example, connect to the mysql daemon, and see it trying to execute queries, but never completing thhem. I am currently running a kernel on that machine with DDB, KDB and WITNESS in it. It has annoyingly refused to hang since I did that though - I did have a hang with jst DDB and KDB, which I regret not investigating more. At tghe time I though "gah, forgot witness", and so recompiled the kernel expecting another lockup wthin a few hours. I do think that the original "3am" thing is a red herring now - I have been getting locks at other times of the daya. Also it is not a runaway fork, as when I wa sin the debugger I did a 'ps' and there wasnt anything unusual going on - i.e. a reasombale number of processes, but not excessive. What are the best traces to do when I get a debugger again ? 'show locks' and 'ps' I know, but I am never sure quite what else is useful. cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sheevaplug questions
On Sun, 27 Dec 2009 17:00:25 +0100, Zoran Kolic wrote: Howdy! I ordered sheevaplug box and read as much as I could, regarding controlling this little node from bsd box. Seems that cu works fine on linux, but module should be loaded to enable serial emulation from usb host port to mini usb port on sheevaplug. Does someone use this mini computer and how connects to serial console? Almost all of documetation mentions win and linux. I suppose would be pretty easy to go further with serial line available. Btw, there is freebsd port for this plug already. Would be fine to try it out. Best regards Zoran Hi, I have 2 of them and cu works fine. As root you can do this. The serial-over-usb provides you with 2 serial devices. The second one is the console. The first is the JTAG interface to flash the bios. # cu -l cuaU1 -s 115200 The device number in cuaU1 is depending on how many serial devices you have over usb. When you plug the serial-over-usb in you should see something like these lines in dmesg/messages. Dec 28 18:30:17 sjakie kernel: ugen2.4: at usbus2 Dec 28 18:30:17 sjakie kernel: uftdi0: on usbus2 Dec 28 18:30:17 sjakie kernel: uftdi1: on usbus2 Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Hacked - FreeBSD 7.1-Release
On Mon, Dec 28, 2009 at 05:50:23PM -0600, Adam Vande More wrote: > On Mon, Dec 28, 2009 at 4:59 PM, Chris H wrote: > > > > > My point here was that by increasing the verbosity, you will more easily be > > able > > to grep against login /failures/, and more easily discover dictionary/ > > brute-force > > attacks. It's certainly made my job easier, and hasn't required any > > modifications > > to our current policies. You /have/ considered PF(4), haven't you? It's > > /really/ > > an excellent strategy for securing your network. > > > > --Chris H > > > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > > > I use security/denyhosts for this, very simple to setup like 5 minutes if > you're a fast reader. There are other options as well that offer similar > functionality. I haven't used this software, but based on this page: http://denyhosts.sourceforge.net/features.html It implies that it blocks access to services using /etc/hosts.deny, which means the attackers are still able to obtain TCP connections to your box; e.g. you're still wasting sockets on these attackers, which ultimately means they're still wasting your resources. hosts.deny does not stop the establishment of the socket; only a firewall can do that. If the software can be tuned to add entries to a firewall (e.g. to a pf.conf-included file), rather than hosts.deny, then that would be advised. I've written my own script to do all of this. It parses periodic security mails (on a daily basis), and does WHOIS lookups + parses the results to tell me what netblocks/CIDRs I should consider blocking. For example, for a security mail that contains this: horus.sc1.parodius.com login failures: Dec 28 15:54:49 horus sshd[74684]: Failed password for root from 199.71.214.240 port 51197 ssh2 Dec 28 15:54:49 horus sshd[74686]: Invalid user test from 199.71.214.240 Dec 28 18:39:24 horus sshd[84742]: Failed password for root from 208.94.235.248 port 42979 ssh2 Dec 28 18:39:25 horus sshd[84744]: Failed password for root from 208.94.235.248 port 43056 ssh2 Dec 28 18:39:25 horus sshd[84746]: Failed password for root from 208.94.235.248 port 43156 ssh2 Dec 28 18:39:26 horus sshd[84749]: Failed password for root from 208.94.235.248 port 43265 ssh2 Dec 28 18:39:27 horus sshd[84751]: Failed password for root from 208.94.235.248 port 43356 ssh2 The script would output the following: 199.71.214.240 199.71.212.0/22Psychz Networks, Walnut, CA, US 208.94.235.248 208.94.232.0/22WZ Communications Inc., Madison, WI, US 208.94.235.0/24Soft-Com.biz, Inc., Panama, NA, PA Then manually (this is intentional) I go and add the entries I feel are relevant to a file called pf.conf.ssh-deny which our systems use to block SSH access. Relevant pf.conf entries: # SSH brute-force attacks, with overrides table persist file "/conf/ME/pf.conf.ssh-allow" table persist file "/conf/ME/pf.conf.ssh-deny" # Block traffic from SSH brute-force attackers, with overrides pass in quick on $ext_if proto tcp from to any port ssh block in quick on $ext_if proto tcp from to any port ssh Contents of the pf.conf.ssh-deny file resemble this: # # Network blocks which we don't want to allow SSH traffic # from. These are predominantly netblocks or IPs which have shown # signs of brute-force SSH attacks (usually dictionary-based). # # LACNIC (Latin America) # 132.247.0.0/16 132.248.0.0/16 ... # APNIC (Asia-Pacific) # ... # JNIC (Japan) # ... # RIPE (European) # ... # AFRINIC (Africa) # ... # Other (miscellaneous attackers) # ... Then I simply do /etc/rc.d/pf check && /etc/rc.d/pf reload. I also have a script that pushes out the pf.conf.ssh-deny machines to other hosts on our network and executes the above commands. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Hacked - FreeBSD 7.1-Release
On Mon, Dec 28, 2009 at 10:44:41AM -0500, Andresen, Jason R. wrote: > The point is, if your machine is on the internet, then bots are > going to try password attacks on any open port they can find. It's > just the sad fact of life on the current internet. Unfortunately, > this activity will also make it much more difficult to determine > when you are under attack from an actual person, which was my point > earlier. It's one that is not going to be easy to solve either, > unless you're willing to rewrite SSH to require every connection > attempt to pass a Turing test or something. On all systems which need to be accessible from the public Internet: Run sshd on port 22 and port 8022. Block incoming traffic on port 22 on your firewall. Everybody coming from the outside world needs to know it is running on port 8022. Everybody coming from the inside world has access as normal. Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ ed...@mavetju.org Weblog: http://www.mavetju.org/weblog/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Hacked - FreeBSD 7.1-Release
On Tue, 29 Dec 2009 12:45:36 +0100, Edwin Groothuis wrote: On Mon, Dec 28, 2009 at 10:44:41AM -0500, Andresen, Jason R. wrote: The point is, if your machine is on the internet, then bots are going to try password attacks on any open port they can find. It's just the sad fact of life on the current internet. Unfortunately, this activity will also make it much more difficult to determine when you are under attack from an actual person, which was my point earlier. It's one that is not going to be easy to solve either, unless you're willing to rewrite SSH to require every connection attempt to pass a Turing test or something. The turing test is a private/public key with a passphrase. And disable passwords. On all systems which need to be accessible from the public Internet: Run sshd on port 22 and port 8022. Block incoming traffic on port 22 on your firewall. Everybody coming from the outside world needs to know it is running on port 8022. Everybody coming from the inside world has access as normal. Edwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Hacked - FreeBSD 7.1-Release
Adam Vande More wrote: > I use security/denyhosts for this, very simple to setup like 5 minutes if > you're a fast reader. There are other options as well that offer similar > functionality. Like security/bruteblock -- Tuomo ... The way to a man's heart is through the left ventricle ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2 to 8.0 serial not working
On Mon, 28 Dec 2009, Mike Tancsa wrote: At 09:27 PM 12/28/2009, Wes Morgan wrote: I just upgraded from 7.2-stable to 8.0-stable, same kernel config (with uart), same everything else and now I can't receive more than a few bytes of data from my weather station before it just waits incessantly. Everything worked before, with the same serial port settings, uart device etc. Has anything else changed in the serial interface? I'm using the cuauX devices at 2400 baud. For some low speed apps (1200bps in our case) I found I needed to set hint.uart.0.flags="0x00100" ---Mike Thanks for the suggestion. 0x100 doesn't seem to work, no data is being seen at all. Using 0x800, I get a bit more data, and if I slow down how fast I'm reading from the port I get a bit more (?), but the final pass only reads two bytes before hanging indefinitely, not honoring the VMIN/VTIME parameters. It's almost like data is being thrown away, but the actual number of bytes is very small so I don't see how that could be happening. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cannot list a particular directory through NFS with UDP
Hi Rick,
Sorry for the delayed reply, but I have had little time available with
Christmas.
On Fri, Dec 18, 2009 at 03:23:44PM -0500, Rick Macklem wrote:
>
> > 00:00:01.953196 IP (tos 0x0, ttl 64, id 48966, offset 0, flags [none],
> > proto UDP (17), length 168) 192.168.1.1.3819288094 > 192.168.1.222.2049:
> > 140 readdir [|nfs]
> > 00:00:01.953665 IP (tos 0x0, ttl 64, id 27028, offset 0, flags [+], proto
> > UDP (17), length 1500) 192.168.1.222.2049 > 192.168.1.1.3819288094: reply
> > ok 1472 readdir POST: DIR 755 ids 0/0 [|nfs]
> > 00:00:01.953711 IP (tos 0x0, ttl 64, id 27028, offset 1480, flags [none],
> > proto UDP (17), length 632) 192.168.1.222 > 192.168.1.1: udp
> >
> This appears to be the reply to the nfs readdir request, which is what
> would be expected. It could be a problem with the content or the reply
> or a NetBSD client issue.
>
> If you were to email me the raw tcpdump capture for the above, I could
> take a look at it in wireshark (which knows how to interpret nfs) and
> see if there is anything bogus looking in the reply.
> ("tcpdump -s 0 -w host 192.168.1.1" and then email me as an
> attachment, should do it)
You will find the pcap file attached.
FYI, I've tried to use "rdirplus" option from NetBSD NFS client as a
workaround but the mount stalls in UDP (works in TCP). If you are also
interested in this problem, I can provide a trace quickly this time :).
Regards,
--
Jeremie Le Hen
Humans are born free and equal. But some are more equal than the others.
Coluche
pcap.nfs-udp
Description: Binary data
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 5.5-STABLE to 88.0-RELEASE
Randy Bush wrote: > can one go from 5.5 to 8.0 using the normal hammer, or is it > multi-stage, and i should just blow it away and go from install? This is a very late reply, but just for the archives ... You can do the update in two steps. Please see this entry in /usr/src/UPDATING: 20080123: To upgrade to -current after this date, you must be running FreeBSD not older than 6.0-RELEASE. Upgrading to -current from 5.x now requires a stop over at RELENG_6 or RELENG_7 systems. So, basically you can go from 5.5 to 7.2 (or 7-stable), and then to 8.0 (or 8-stable). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The ITU has offered the IETF formal alignment with its corresponding technology, Penguins, but that won't fly." -- RFC 2549 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sheevaplug questions
Howdy! > I have 2 of them and cu works fine. > As root you can do this. The serial-over-usb provides you with 2 serial > devices. The second one is the console. The first is the JTAG interface to > flash the bios. > # cu -l cuaU1 -s 115200 Perfect! I hardly wait to get the device! > When you plug the serial-over-usb in you should see something like these > lines in dmesg/messages. > Dec 28 18:30:17 sjakie kernel: ugen2.4: at usbus2 > Dec 28 18:30:17 sjakie kernel: uftdi0: on > usbus2 > Dec 28 18:30:17 sjakie kernel: uftdi1: on > usbus2 When I turn the plug on, in fact? I suspect Attos tried to connect to wrong device name, or it was on some older freebsd version? Also, there were more than one version of plug, with maybe different hardware parts. Not related to freebsd: forum posts point to error after changing root password on the plug. Someone experienced it? I see no reason to have any problem on default ubuntu 9.04 with simple "passwd". Almost all posters made "apt-get update first". Thank you all for reply. Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sheevaplug questions
On Tue, 29 Dec 2009 16:51:19 +0100, Zoran Kolic wrote: Howdy! I have 2 of them and cu works fine. As root you can do this. The serial-over-usb provides you with 2 serial devices. The second one is the console. The first is the JTAG interface to flash the bios. # cu -l cuaU1 -s 115200 Perfect! I hardly wait to get the device! When you plug the serial-over-usb in you should see something like these lines in dmesg/messages. Dec 28 18:30:17 sjakie kernel: ugen2.4: at usbus2 Dec 28 18:30:17 sjakie kernel: uftdi0: on usbus2 Dec 28 18:30:17 sjakie kernel: uftdi1: on usbus2 When I turn the plug on, in fact? I suspect Attos tried to connect to wrong device name, or it was on some older freebsd version? Also, there were more than one version of plug, with maybe different hardware parts. Not related to freebsd: forum posts point to error after changing root password on the plug. Someone experienced it? I see no reason to have any problem on default ubuntu 9.04 with simple "passwd". Almost all posters made "apt-get update first". Thank you all for reply. Best regards Zoran Please provide a link to the forum post. Otherwise I can only guess what you mean. There is no error because of changing the password. But there are some thing broken in the default install (missing dir, missing timezone, etc.). Follow the commands in this link and you're ready to go. http://www.plugcomputer.org/plugwiki/index.php/QuickStart Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Hacked - FreeBSD 7.1-Release
On 12/29/2009 3:45 AM, Edwin Groothuis wrote: mpt to pass a Turing test or something. On all systems which need to be accessible from the public Internet: Run sshd on port 22 and port 8022. Block incoming traffic on port 22 on your firewall. Everybody coming from the outside world needs to know it is running on port 8022. Everybody coming from the inside world has access as normal. Edwin I seem to recall on one of the openbsd lists someone speaking of risks of running sshd or other services on high numbered ports, presumably because a non root user cannot bind ports up to 1024. Brian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Hacked - FreeBSD 7.1-Release
On Dec 29, 2009, at 10:10 , Brian W. wrote: > On 12/29/2009 3:45 AM, Edwin Groothuis wrote: >> mpt to pass a Turing test or something. >> On all systems which need to be accessible from the public Internet: >> Run sshd on port 22 and port 8022. Block incoming traffic on port >> 22 on your firewall. >> >> Everybody coming from the outside world needs to know it is running >> on port 8022. Everybody coming from the inside world has access as >> normal. >> >> Edwin >> > I seem to recall on one of the openbsd lists someone speaking of risks of > running sshd or other services on high numbered ports, presumably because a > non root user cannot bind ports up to 1024. On a multi-user machine, where you want to keep students or others from spoofing on machines on which they have logins but which you manage (i.e., they don't have root or sudo), this makes sense--ON THE SERVER SIDE. The connecting client's port is going to be above 1024 anyway, and the client doesn't really care on which port the server is running. In this day and age, when anyone, black hat or white, can stand up their own *ix box and run whatever they want on whatever port, the notion of only connecting to "privileged ports" as a way of protecting yourself (e.g., from password sniffing or whatever) is rather quaint and ineffective. -- Chris BeHanna ch...@behanna.org___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sheevaplug questions
Hi, Ronald! > Please provide a link to the forum post. Otherwise I can only guess what > you mean. > There is no error because of changing the password. But there are some > thing broken in the default install (missing dir, missing timezone, etc.). > Follow the commands in this link and you're ready to go. > http://www.plugcomputer.org/plugwiki/index.php/QuickStart It was not easy to find the link again. plugcomputer.org/plugforum/index.php?topic=110.0 I found more complaints over lost root pass all over forums. Simply people mess something without trail what it was. Once more, I still have no device, so cannot try out anything. Thanks for help. Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Hacked - FreeBSD 7.1-Release
On Tue, Dec 29, 2009 at 03:20:37AM -0800, Jeremy Chadwick wrote: > ... > I've written my own script to do all of this. It parses periodic > security mails (on a daily basis), and does WHOIS lookups + parses the > results to tell me what netblocks/CIDRs I should consider blocking. For > example, for a security mail that contains this: > > horus.sc1.parodius.com login failures: > Dec 28 15:54:49 horus sshd[74684]: Failed password for root from > 199.71.214.240 port 51197 ssh2 > Dec 28 15:54:49 horus sshd[74686]: Invalid user test from 199.71.214.240 > Dec 28 18:39:24 horus sshd[84742]: Failed password for root from > 208.94.235.248 port 42979 ssh2 > Dec 28 18:39:25 horus sshd[84744]: Failed password for root from > 208.94.235.248 port 43056 ssh2 > Dec 28 18:39:25 horus sshd[84746]: Failed password for root from > 208.94.235.248 port 43156 ssh2 > Dec 28 18:39:26 horus sshd[84749]: Failed password for root from > 208.94.235.248 port 43265 ssh2 > Dec 28 18:39:27 horus sshd[84751]: Failed password for root from > 208.94.235.248 port 43356 ssh2 > > The script would output the following: > > 199.71.214.240 > 199.71.212.0/22Psychz Networks, Walnut, CA, US > 208.94.235.248 > 208.94.232.0/22WZ Communications Inc., Madison, WI, US > 208.94.235.0/24Soft-Com.biz, Inc., Panama, NA, PA > > Then manually (this is intentional) I go and add the entries I feel > are relevant to a file called pf.conf.ssh-deny which our systems use to > block SSH access. > ... I do something somewhat similar, though the implementation is rather different. Like Jeremy, I choose to make the actual actions intentionally manual. Among salient points: * Because I'm fairly familiar with it, I (still) use IPFW. * I received a bit of a "prod" (thanks, Julian!) to use IPFW tables; that's been quite helpful. * I use a moderately quaint (and probably embarrassing) mixture of Perl & Bourne shell scripts, as well as make, to extract the netblock information from WHOIS, and to construct a persistent store that's referenced at boot time. * As a general rule, I try to report activity such as the above (to the listed contact(s) from WHOIS). (When I do, I Bcc: myself and keep a opy of all salient correspondence. Or bounce-o-grams.) * For SSH (in particular), I do not rely only on the /var/log/security entries created by sshd. Rather, I also configure IPFW to log all SSH session-establishment requests. If I report the unwanted ativity, I provide both sets of log excerpts. (I often find probes logged by IPFW that sshd does not log. And yes, I check the "block" list before IPFW logs a "sucessful" SSH session-establishment request packet.) * I use one table to block access to SSH. I have another for extreme cases of abuse, where I block all traffic in either direction, and a third for access to my Web server. I suppose I could also do something similar for SMTP * I use this for machines that (may) connect directly to the Internet; thus, my "firewall" machine certainly qualifies -- but so does my laptop. * I have no mechanism in place to identify, let alone prune, stale entries. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgprLgGulJKyH.pgp Description: PGP signature
Re: Hacked - FreeBSD 7.1-Release
Tuesday, December 29, 2009, 6:20:37 AM, you wrote:
> On Mon, Dec 28, 2009 at 05:50:23PM -0600, Adam Vande More wrote:
>> On Mon, Dec 28, 2009 at 4:59 PM, Chris H wrote:
>>
>> >
>> > My point here was that by increasing the verbosity, you will more easily be
>> > able
>> > to grep against login /failures/, and more easily discover dictionary/
>> > brute-force
>> > attacks. It's certainly made my job easier, and hasn't required any
>> > modifications
>> > to our current policies. You /have/ considered PF(4), haven't you? It's
>> > /really/
>> > an excellent strategy for securing your network.
>> >
>> > --Chris H
>> >
>> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>> >
>>
>> I use security/denyhosts for this, very simple to setup like 5 minutes if
>> you're a fast reader. There are other options as well that offer similar
>> functionality.
> Then I simply do /etc/rc.d/pf check && /etc/rc.d/pf reload.
> I also have a script that pushes out the pf.conf.ssh-deny machines
> to other hosts on our network and executes the above commands.
Increase verbosity ? why not just create a pflog file just for port 22
or whatever you listen on for ssh or some kind of login and parse
that. See attached script for a start on parsing the explained pflog.
I have been toying around with the attached idea that makes use of
connection tracking in pf.
pass in log quick proto { tcp } from any port >1024 to any port \
{ $shports } label "SCT/Login:$dstport" keep state (max-src-conn 5, \
max-src-conn-rate 15/30 overload flush global)
This has worked out quite well so far but the script that is attached
has a few bugs and optimizations that could be made to it but it does
its job regardless without third-party utilities. I have added some
parsing of the pflogs through the use of tcpdump and sed to pull bad
IPs out as well but do not use that on a regular basis. I have the
script setup in a cron job to run once a hour and pull the IPs from
the active table and combine the contents with the blacklist file and
ultimately sort, uniq & reload the table with the contents of the
blacklist file making adding IPs to the blacklist just add to the
table on the next cron run..
Depending on where you put your blacklist deny rule you can be saving
the rest of your services from the attackers to.
Still lots of work to be done on this but I figured I would put it out
there for someone else to toy with and see what comes out of it.
Best regards.
--
Tuesday, December 29, 2009 12:09:10 PM
jhell
pflog_fil.sh
Description: Binary data
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Most files in subversion stable/8/sys touched by bms
Larry Baird wrote: > I use the following to get a feel of what is changing in FreeBSD 8 kernel. > http://svn.freebsd.org/viewvc/base/stable/8/sys/?sortby=date By the way, here is another little tool that can be used to watch changes in 8-stable conveniently: http://www.secnetix.de/olli/FreeBSD/svnews/?p=stable/8/sys It lists commits (optionally with diffs) to the path specified in reverse chronological order, i.e. newest at the top. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Life is short (You need Python)" -- Bruce Eckel, ANSI C++ Comitee member, author of "Thinking in C++" and "Thinking in Java" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Hacked - FreeBSD 7.1-Release
Edwin Groothuis writes: > On Mon, Dec 28, 2009 at 10:44:41AM -0500, Andresen, Jason R. wrote: >> The point is, if your machine is on the internet, then bots are >> going to try password attacks on any open port they can find. It's >> just the sad fact of life on the current internet. Unfortunately, >> this activity will also make it much more difficult to determine >> when you are under attack from an actual person, which was my point >> earlier. It's one that is not going to be easy to solve either, >> unless you're willing to rewrite SSH to require every connection >> attempt to pass a Turing test or something. > > On all systems which need to be accessible from the public Internet: > Run sshd on port 22 and port 8022. Block incoming traffic on port > 22 on your firewall. > > Everybody coming from the outside world needs to know it is running > on port 8022. Everybody coming from the inside world has access as > normal. This assumes that everybody coming in from the outside is doing so from a location that can reach port 8022 on your network. Restrictive corporate, campus, and hotspot firewalls will often break this assumption. If your network is personal, and you know the other ends of the connections won't be so draconian, this isn't a problem. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Hacked - FreeBSD 7.1-Release
Brian W. wrote: > On 12/29/2009 3:45 AM, Edwin Groothuis wrote: > > On all systems which need to be accessible from the public Internet: > > Run sshd on port 22 and port 8022. Block incoming traffic on port > > 22 on your firewall. > > > > Everybody coming from the outside world needs to know it is running > > on port 8022. Everybody coming from the inside world has access as > > normal. > > I seem to recall on one of the openbsd lists someone speaking of risks > of running sshd or other services on high numbered ports, presumably > because a non root user cannot bind ports up to 1024. That's probably because OpenBSD doesn't have mac_portacl(4). ;-) But basically it's right: You should never run any important services (including sshd) on ports that might be bound by unprivileged users. The basic problem is that, if the sshd daemon happens to die for some reason, an unprivileged user could run his own ssh daemon (presumably a hacked/modified one) on the same port. Of course he doesn't have the private host keys, and he can't really let users log in to the real system, so his fake ssh daemon will be discovered rather sooner than later, but it might be enough to steal some sensitive information from unsuspecting users. Historically, unprivileged users cannot bind services to port numbers below 1024, so those port numbers were considered "safe" regarding the above problem. However, that concept is somewhat diluted today, because you can change the range of privileged port numbers on many (most?) operating systems. On FreeBSD there are some sysctls that default to the historical range: net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.reservedlow: 0 So, theoretically you can set the "reservedhigh" value to 8022, and then you can safely run sshd on that port number. You can even set the sysctl to 65535, completely preventing users from running _any_ services. However, this also prevents them from using active FTP and other things. A better way is to use FreeBSD's mac_portacl(4) which is quite easy to use. It enables you to install rules that specify exactly to which ports user processes are allowed to bind. So you can specifically protect the single port number 8022, for example. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing." -- Mother Teresa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Hacked - FreeBSD 7.1-Release
On Tue, Dec 29, 2009 at 02:30:11PM -0500, Lowell Gilbert wrote: > > On Mon, Dec 28, 2009 at 10:44:41AM -0500, Andresen, Jason R. wrote: > >> The point is, if your machine is on the internet, then bots are > >> going to try password attacks on any open port they can find. It's > >> just the sad fact of life on the current internet. Unfortunately, > >> this activity will also make it much more difficult to determine > >> when you are under attack from an actual person, which was my point > >> earlier. It's one that is not going to be easy to solve either, > >> unless you're willing to rewrite SSH to require every connection > >> attempt to pass a Turing test or something. > > > > On all systems which need to be accessible from the public Internet: > > Run sshd on port 22 and port 8022. Block incoming traffic on port > > 22 on your firewall. > > > > Everybody coming from the outside world needs to know it is running > > on port 8022. Everybody coming from the inside world has access as > > normal. > > This assumes that everybody coming in from the outside is doing so from > a location that can reach port 8022 on your network. Restrictive > corporate, campus, and hotspot firewalls will often break this > assumption. If your network is personal, and you know the other ends > of the connections won't be so draconian, this isn't a problem. And let's not forget the fact that the people doing the brute-force attacks already have access to multiple compromised machines (sometimes in the tens or hundreds of thousands), which means they'll eventually change their methods to include portscanning of the remote system rather than just blindly assuming TCP port 22. When you have access to so many systems, completing a full scan (65535 ports) would take a lot less time than, say, if run from a single system. Given that OpenSSH happily spits back an identity string -- including version -- to anyone who establishes a TCP connection to it, detecting if SSH is associated with said port isn't that hard. I don't know if this method is officially part of the SSH protocol or not (I'm not familiar with the protocol). Example FreeBSD box: Connected to localhost. Escape character is '^]'. SSH-2.0-OpenSSH_5.2p1 FreeBSD-20090522 The "FreeBSD-" string is supposed to come from VersionAddendum in /etc/ssh/sshd_config, except it appears the base system's OpenSSH defines this as the VersionAddendum default. The rest of the string, AFAIK, isn't modifiable outside of editing the source. The justification for the FreeBSD- hard-coded default is in src/crypto/openssh/FREEBSD-upgrade. I don't agree with the logic (basic security starts with "give the remote attacker *as little* information about your system as possible"), but I'm not going to argue: 0) VersionAddendum The SSH protocol allows for a human-readable version string of up to 40 characters to be appended to the protocol version string. FreeBSD takes advantage of this to include a date indicating the "patch level", so people can easily determine whether their system is vulnerable when an OpenSSH advisory goes out. Some people, however, dislike advertising their patch level in the protocol handshake, so we've added a VersionAddendum configuration variable to allow them to change or disable it. So ultimately changing the port number from 22 to something else is just a temporary measure that does little other than annoy legitimate people connecting to your system. Don't have anyone else connecting to it? Then why not just use port 22 and deny 0.0.0.0/0 + allow netblocks you come in from? I guess some people travel a lot and use a multitude of ISPs, but surely it wouldn't take that long to build an appropriate allow/permit list. Ah well. Each to his/her own when it comes to solving this problem. Everyone likes something different/has a different method/etc. based on their needs/styles. :-) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Most files in subversion stable/8/sys touched by bms
On Tue, Dec 29, 2009 at 7:37 PM, Oliver Fromme wrote: > By the way, here is another little tool that can be used to > watch changes in 8-stable conveniently: > > http://www.secnetix.de/olli/FreeBSD/svnews/?p=stable/8/sys > Thank you for mentioning this, this is a great tool for everyone to have around (instantly bookmarked). I'd have one question to ask - would you consider adding one more piece of information to the output, namely "age" of the commit? So that 17:38:50 - r201208 by rwatson would look like: 17:38:50 - r201208 (17 hours, 30 minutes old) by rwatson or 17:38:50 - r201208 (3 days, 15 hours old) by rwatson etc. Little extra like this makes tracking down some specific changes easier, or makes some quick point of reference where you left the last time, etc. I guess you get the idea.. It's not exactly critical, just would be handy to see there, if possible :) m. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 8.0: can't PXE Boot using nvidia nForce4 network card
On Tue, Dec 29, 2009 at 1:37 AM, Pyun YongHyeon wrote: > > :-( > How about this one? Sorry, I'm just guessing(no hardware, no > documentation). > Thanks for this new patch but still same error: FreeBSD 8.0-STABLE #5: Tue Dec 29 08:50:27 CET 2009 r...@debugger.bsdrp.net:/usr/obj/usr/src/sys/GENERIC i386 (...) nfe0: irq 21 at device 10.0 on pc i0 nfe0: Lazy allocation of 0x100 bytes rid 0x10 type 3 at 0x8100 nfe0: Reserved 0x100 bytes for rid 0x10 type 3 at 0x8100 nfe0: MII without any phy! device_attach: nfe0 attach returned 6 (...) Regards, Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
install FreeBSD 8 on disk where windows7 made a gpt
hail, I have Windows7 alone in a disk, and now I'd like to install FreeBSD 8 on it. when I boot from USB disk, the partitioner says there is no partitions on it. then I read about: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot and got to the fixit part. then gpt show ad10 says also there is no gpt in there. is there any way to deal with this ? thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
something fails with svn
Hi list! Something fails, when updated the FreeBSD's svn repo to git. Since yesterday I get this warning: $ git svn rebase ... M sys/boot/pc98/kgzldr/crt.s Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/cddl/contrib/opensolaris Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/stable/8/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/kmacy/releng_7_2_fcs/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/dev/acpica Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/pf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/stable/8/sys/contrib/pf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys/contrib/pf r201153 = 2a0c8903699f2e4ff17312c753e335424eeac5e3 (refs/remotes/git-svn) M sys/powerpc/conf/DEFAULTS M sys/sparc64/conf/DEFAULTS M sys/ia64/conf/DEFAULTS M sys/sun4v/conf/DEFAULTS M sys/pc98/conf/DEFAULTS M sys/i386/conf/DEFAULTS M sys/amd64/conf/DEFAULTS Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/cddl/contrib/opensolaris Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/dev/acpica Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/pf r201164 = c4051399b1b56820b010acba9f5f0e2953f5be70 (refs/remotes/git-svn) M etc/rc.d/named M etc/mtree/BIND.chroot.dist M etc/namedb/named.conf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/etc r201173 = d70d011b0c38f8a35845a3a63e6ba60f2f04774b (refs/remotes/git-svn) M usr.sbin/zic/Theory M lib/libc/stdtime/tzfile.5 Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc/stdtime Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/lib/libc Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/usr.sbin/zic Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/zic r201184 = 47c9db23979a71f805ff5f11d0574ae1ed83a581 (refs/remotes/git-svn) ... the git config is: [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [svn-remote "svn"] url = svn://svn.freebsd.org/base/stable/7 fetch = :refs/remotes/git-svn Is this a user error (my), or it's an mismerge or repo fail git / or freebsd's svn? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: install FreeBSD 8 on disk where windows7 made a gpt
On Tue, 2009-12-29 at 20:05 -0200, Nenhum_de_Nos wrote: > hail, > > I have Windows7 alone in a disk, and now I'd like to install FreeBSD 8 on > it. when I boot from USB disk, the partitioner says there is no partitions > on it. > > then I read about: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot and got to > the fixit part. then gpt show ad10 says also there is no gpt in there. > > is there any way to deal with this ? There are some fixes in 8-STABLE that I don't think I got into 8.0. Those fixed reading of GPT headers written by opensolaris. I haven't seen the GPT headers written by Win7. If you want to "dd if=/dev/ad10 of=header-dump.bin bs=512 count=34" and send that to me, I can take a look at what is written. robert. > thanks, > > matheus -- Robert Noland FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Most files in subversion stable/8/sys touched by bms
On Tue, Dec 29, 2009 at 20:41, Michal Varga wrote: > On Tue, Dec 29, 2009 at 7:37 PM, Oliver Fromme wrote: >> By the way, here is another little tool that can be used to >> watch changes in 8-stable conveniently: >> >> http://www.secnetix.de/olli/FreeBSD/svnews/?p=stable/8/sys >> > Thank you for mentioning this, this is a great tool for everyone to > have around (instantly bookmarked). > > I'd have one question to ask - would you consider adding one more > piece of information to the output, namely "age" of the commit? So > that > > 17:38:50 - r201208 > by rwatson > > would look like: > > 17:38:50 - r201208 (17 hours, 30 minutes old) > by rwatson > > or > > 17:38:50 - r201208 (3 days, 15 hours old) > by rwatson > > etc. > > Little extra like this makes tracking down some specific changes > easier, or makes some quick point of reference where you left the last > time, etc. I guess you get the idea.. It's not exactly critical, just > would be handy to see there, if possible :) I would prefer the name of the timezone. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Jailed Service contact IMAPS
Being able to run those commands (telnet/openssl) via the jail implies there is nothing wrong with the jail itself, but instead the squirrelmail config. Aside from double checking the squirrelmail config which I would highly suggest, can you provide a packet capture of an active squirrelmail session in which the squirrelmail application fails to do what you intend it to do? All that's necessary really is to capture the initial SYN and the response to that SYN, provided the machine your connected to provides one. If you see the handshake occuring then the problem is most likely elsewhere which may be determined by increasing verbosity in the respective log files. ~Paul Peter Fraser wrote: Yes I can connect over telnet. If I even do openssl s_client -connect :993 I can also connect and list my mail. The machine is running FreeBSD 8 by the way. On Mon, Dec 28, 2009 at 9:53 AM, Paul Procacci wrote: Peter Fraser wrote: Hi All I have two servers, one running apache and squirrelmail in a jail. Squirrelmail on this server is trying to contact dovecot running imaps on port 993 on another server and failing. When I try from another physical machine it works but I would prefer to run this service from within a jail. Can anyone please let me know how to make this work? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" Have you tried to first do a simple (from within the jail): telnet host 993 Do you get connected? If not, do you have any firewall rules either on the host maintaining the jail or the host you are connecting to? If not, can you do a tcpdump to see what specificly is happening to those packets via (on the host again): tcpdump -i host and port 993 Do you see packets both leaving your machine and coming back? If not, can you repeat the process above on the host machine maintaining the jail, but not within the jail itself. Are the results the same? The above is a start and should provide enough information as to whether the problem is specific to the jail or the physical host. ~Paul This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/emaildisclaimer.aspx for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/emaildisclaimer.aspx for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: something fails with svn
On Tue, 29 Dec 2009 17:18, oliver.pntr@ wrote: Hi list! Something fails, when updated the FreeBSD's svn repo to git. Since yesterday I get this warning: $ git svn rebase ... M sys/boot/pc98/kgzldr/crt.s Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/cddl/contrib/opensolaris Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/stable/8/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/kmacy/releng_7_2_fcs/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/dev/acpica Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/pf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/stable/8/sys/contrib/pf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys/contrib/pf r201153 = 2a0c8903699f2e4ff17312c753e335424eeac5e3 (refs/remotes/git-svn) M sys/powerpc/conf/DEFAULTS M sys/sparc64/conf/DEFAULTS M sys/ia64/conf/DEFAULTS M sys/sun4v/conf/DEFAULTS M sys/pc98/conf/DEFAULTS M sys/i386/conf/DEFAULTS M sys/amd64/conf/DEFAULTS Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/cddl/contrib/opensolaris Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/dev/acpica Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/pf r201164 = c4051399b1b56820b010acba9f5f0e2953f5be70 (refs/remotes/git-svn) M etc/rc.d/named M etc/mtree/BIND.chroot.dist M etc/namedb/named.conf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/etc r201173 = d70d011b0c38f8a35845a3a63e6ba60f2f04774b (refs/remotes/git-svn) M usr.sbin/zic/Theory M lib/libc/stdtime/tzfile.5 Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc/stdtime Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/lib/libc Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/usr.sbin/zic Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/zic r201184 = 47c9db23979a71f805ff5f11d0574ae1ed83a581 (refs/remotes/git-svn) ... the git config is: [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [svn-remote "svn"] url = svn://svn.freebsd.org/base/stable/7 fetch = :refs/remotes/git-svn Is this a user error (my), or it's an mismerge or repo fail git / or freebsd's svn? SVN never has problems "It's powered by FreeBSD ;)" Take a look at your git config. The problem lies there and is very visible. After you are done fixing that re-read the whole email that you posted. -- Tue Dec 29 23:28:28 2009 jhell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
usb wlan hostap
hail, I've looked in google and not found many info on this subject. and all man pages on freebsd.org says on footnote 7.2R (although they mention wlan0 devices). I've found a topic on forum from last year and that's much about it. I have a small pc (itx based) and no pci slot usable so I'd like to have an ap based on freebsd and usb nic. its basically for internet on one or two notebooks, so if it works 11Mbps is fine if its stable on it. I've read about atheros based, but the man fro uath doesn't say hostap mode. I found it on ural but most adaptors listed there are somwhat old an discontinued from theirs manufacturers. so I ask here ... of course ther cheaper the better, but I would pay a little more if it is known to work really good. I have atheros based pci on another pc and it is really good for me. just for thre record, this will be used in pfSense 2.0 (FreeBSD 8 based), but may also run FreeBSD 8 itself, and with another usb lan nic. thanks, matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
