[Leaf-user] Trying to get Oxygen to boot from hda1
Hi. I hope I'm not doing something completely dense... I'm trying to get Oxygen to boot off a partition on my hard drive /dev/hda1. I just downloaded the Oxygen images yesterday with kernel 2.2.19. I ran "syslinux -s /dev/hda1", copied all the files from the boot floppy--except ldlinux.sys and linux--to hda1, copied in the kernel from the Oxygen+Openwall+IDE-2.2.19-tar.gz package, edited syslinux.cfg on hda1 to change the line under default linux to include boot=/dev/hda1 instead of /dev/fd0u1680, saved everything and reboot. But when it boots off the hard drive I just get: "SYSLINUX 1.62 2001-04-24 Copyright (C) 1994-2001 H. Peter Anvin" ...and then it hangs. I tried a couple different kernels, and retried the whole process a few times after reformatting, but get the same response each time. Am I missing something obvious? ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Cron script not working?
Hi all I put together a little script to e-mail me the day's bandwidth usage, which would simply run ipchains and show its accounting figures and e-mail them to me, then reset the counters.. # cat bandwidth.sh #!/bin/ash touch /tmp/runnow ipchains -n -v -L output | mail john@myaddress ipchains -Z This script has permissions level 777 and is owned by root:root. my /etc/crontab file includes: # m h dom mon dow user command 40 6* * * sh-httpd savelog -g adm -m 640 -u sh-httpd -c 4 /var/sh-log/sh-httpd.log 42 6* * * rootrun-parts --report /etc/cron.daily 47 6* * 7 rootrun-parts --report /etc/cron.weekly 52 61 * * rootrun-parts --report /etc/cron.monthly 0 8 * * * root/root/bandwidth.sh I am using Eigerstein-2B. Basically, it Doesn't Work. No script gets run. I tried restarting cron, tried putting the /root/bandwidth.sh script in /etc/cron.daily/, but that didn't make any difference. Run manually from a command line, it works ok, just never from cron. Nothing goes in the logs either. What am I doing wrong? Cheers John ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] just a comment
Hello All, Hope that you all are doing well. I have recently set up another Eigerstein Masquerading firewall, but this time we wanted to try and take advantage of the eth0_IP_EXTRA_ADDRS="x.x.x.x" The result, at least for us, was that it did not work. We wanted the firewall to answer to packets coming from this ip addr as well as from the one defined in the eht0_IP. It turns out that the LRP would not see this IP at all. Has anyone had any problems with this feature? Cheers, Lonnie ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Trying to get Oxygen to boot from hda1
This was the biggest problem I had with Oxygen --- it took me many hours of messing around to get it to work off the HD. For some reason, no recent versions of syslinux would work, so I ended up using an older one (1.48). There was a *lot* of booting from a floppy, changing syslinux stuff on the drive, trying to boot from the drive, watching it hang, and rebooting from the floppy. Very frustrating. But with that version, I *did* manage to get it to work. Wyatt > > Hi. I hope I'm not doing something completely dense... > > I'm trying to get Oxygen to boot off a partition on my hard drive > /dev/hda1. I just downloaded the Oxygen images yesterday with kernel > 2.2.19. > > I ran "syslinux -s /dev/hda1", copied all the files from the boot > floppy--except ldlinux.sys and linux--to hda1, copied in the kernel from > the Oxygen+Openwall+IDE-2.2.19-tar.gz package, edited syslinux.cfg on hda1 > to change the line under default linux to include boot=/dev/hda1 instead of > /dev/fd0u1680, saved everything and reboot. > > But when it boots off the hard drive I just get: > > "SYSLINUX 1.62 2001-04-24 Copyright (C) 1994-2001 H. Peter Anvin" > > ...and then it hangs. I tried a couple different kernels, and retried the > whole process a few times after reformatting, but get the same response > each time. Am I missing something obvious? > > > ___ > Leaf-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Re: Just a Comment
> I have recently set up another Eigerstein Masquerading firewall, but this time > we wanted to try and take advantage of the > > eth0_IP_EXTRA_ADDRS="x.x.x.x" > > The result, at least for us, was that it did not work. We wanted the firewall to > answer to packets coming from this ip addr as well as from the one defined in > the eht0_IP. > > It turns out that the LRP would not see this IP at all. > > Has anyone had any problems with this feature? > The following is copied from my network.conf and works fine for me. Note that you need the mask ;ength and you separate the addresses with spaces. >> # Secondary IP addresses/networks on same wire - add them here >> eth0_IP_EXTRA_ADDRS="66.92.66.50/24 66.92.66.49/24 66.92.66.48/24" Richard Minutillo [EMAIL PROTECTED] ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Oracle 8
Todd Pearsall wrote: > > You should be on the right path. port 1521 is the default Oracle listener > port. Once you connect to the listener it spawns processes on other ports > to continue the conversation. > > With Oracle inside the firewall you need to let 1521 in and then Oracle > starts communication on the other ports that LEAF should let out. > > Does the Oracle box have a routable IP or is it masquareded. If it's > masquareded be sure to open 1521 and then forward it to the Oracle box. I > would assume the dynamically assigned ports would be handled fine by the > normal masquarding logic. (maybe?) > > Sorry for the lack of specific suggestions. That was great. Just to reword it a bit, on the LEAF: The internal nic is generally set by the firewall rules to accept everything inbound and outbound. There's a masq rule for the private internal lan. The external nic is then opened to new TCP and/or UDP traffic on port 1521 both inbond and outbound. A portforwarding tunnel rule is then set in place that forwards TCP and/or UDP traffic from the firewall IP on port 1521 to the Oracle computer's IP on port 1521. Even though the rule is "from this comp to that comp," it really is "back and forth between comp and comp." It's a 2-way tunnel. Any traffic from the Oracle IP's port 1521 destined for the Internet will get tunneled, and it will then look like traffic from your firewall IP's port 1521 destined for the internet. And finally, all traffic from the internal lan is allowed out the external nic, with a few caveats for the paranoid :) Because a firewall generally logs everythings that's not specifically allowed, any strangeness should appear in the syslog, and you can make adjustments as necessary. Regards, Matt ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] LaBrea for LRP?
Is there anyway Labrea could be used if you are a simple cable user with one IP adres? Like by listening on some ports? Is this doable now or would it require a change to the sourcecode? Kim Oppalfens On Thu, 20 Sep 2001 14:42:52 -0500, Alec Miller wrote: >Someone sent me this link in the midst of the recent Nimda attacks. > >I don't have the tools to make this into an LRP package, but I >think this >could be a neat addon. > >(If it doesn't already exist for LRP) > > >Alec > > >= > >http://www.incidents.org/LaBrea/LaBrea.txt > > > > >- >--- > > > > Welcome to My Tarpit >The Tactical and Strategic Use of LaBrea > > >Introduction > > >LaBrea is a small Linux-based application that puts unused >IP >addresses on your network to use, creating a "tarpit" which can >stop >or slow down scans of your address space. This paper details >the >technical aspects of how LaBrea works as well as the >tactical >advantages of deploying LaBrea on your network. > >Background - Creating Virtual Machines >-- > >LaBrea works as a low-level network application that creates >"virtual >machines" on your network - machines that don't really exist yet >are >able to answer connection attempts in a special way that slows >and >even stops the connecting process. > >Local communication between machines on a LAN (local area network) >is >done using MAC (machine access code) addresses, not with IP >addresses. >These MAC addresses are 48 bits in length, as opposed to the 32 >bits >of an IP address. > >External attempts to access machines in the LAN are done using >IP >addresses and will go through the local router. The local >router's >job is to figure out which MAC corresponds to which IP. The >router >does this by broadcasting a special request asking "who owns" the >IP >in question. If any machine "owns" the IP it will respond with its >MAC >address to the router. This request and response is known as >the >Address Resolution Protocol or "ARP." > >The tenacious quality of the ARP protocol used in these >router >requests is what makes LaBrea possible: If at first the router >does >not find a machine with the IP in question, it will ask again - >and >again. > >LaBrea monitors these ARP requests and replies that are needed >to >connect external traffic with the local area network. If it >notes >several successive ARP requests without intervening ARP replies >LaBrea >will issue an ARP reply, effectively creating a virtual machine. > >Making Virtual Machines Real > >Once the virtual machine has been created, LaBrea will monitor >all >traffic destined for the MAC address it has given to the router, >and >will thereafter respond to inbound TCP/IP packets in a way that >can >tie up the connecting machines for long periods of time. Most >modern >TCP/IP implementations are very tenacious about holding >onto >established connections. LaBrea sends enough of a response to hold >the >connection open, but no more - the connecting machine is left >hanging, >waiting. > >Tarpitting >-- >The connecting machine's TCP/IP implementation will ordinarily >not >give up easily, but will continue to attempt to use what it regards >as >an established connection over and over until it finally times >out. >The timeout value will of course vary from implementation >to >implementation, but it will always be several orders of >magnitude >longer than for a failed connection attempt. This is the "tarpit" >that >LaBrea uses to catch worms and scanners. > >Connection Trapping >--- >LaBrea can also trap and hold connection attempts. By moving >a >connection from the established state to the persist state, LaBrea >can >literally hold connections open for an indefinite period of time, >so >that only a process reset at the other end will end it. >Communicating >in this manner is done economically despite the potentially >wide >bandwidth involved; also, the bandwidth usage itself is configurable. > >Impersonation >- >To effectively trick more advanced scanning tools into >believing >virtual machines are real, LaBrea offers standard responses to >a >number of typical network probes such as echo requests and >SYN/ACK >scans. > >No Collateral Damage > >All connection attempts aimed at LaBrea virtual machines can >be >considered suspect in nature as these machines do not really exist >nor >do they, for example, have any entries in the Domain Name System. > >Tactical Use > >Monitoring connection activities can give the network >operations >center a good view of the extent and nature of any >reconnaissance >taking place: Is a broad rang
Re: [Leaf-user] Re: Just a Comment
But have you tried eth0_IP_EXTRA_ADDRS="146.9.31.42/24 146.9.31.56/24" [EMAIL PROTECTED] wrote: > > That's very interesting in that when I added eth0_IP_EXTRA_ADDRS="146.9.31.42 > 146.9.31.56" > > the LRP would not catch either one of them and only traffic directed to the eth0 > ip was caught. > > Strange to me. > Lonnie > ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Trying to get Oxygen to boot from hda1 - success
Okay, I downloaded syslinux 1.63 which noted that it fixed some bios compatibility problems, ran that from linux and now my hard drive boots up fine. Cool. Thanks for your help. -Steve On 2001.10.07 11:00:53 -0500 [EMAIL PROTECTED] wrote: > This was the biggest problem I had with Oxygen --- it took me many hours > of messing around to get it to work off the HD. > > For some reason, no recent versions of syslinux would work, so I ended up > using an older one (1.48). There was a *lot* of booting from a floppy, > changing syslinux stuff on the drive, trying to boot from the drive, > watching it hang, and rebooting from the floppy. Very frustrating. > > But with that version, I *did* manage to get it to work. > > Wyatt > > > > > Hi. I hope I'm not doing something completely dense... > > > > I'm trying to get Oxygen to boot off a partition on my hard drive > > /dev/hda1. I just downloaded the Oxygen images yesterday with kernel > > 2.2.19. > > > > I ran "syslinux -s /dev/hda1", copied all the files from the boot > > floppy--except ldlinux.sys and linux--to hda1, copied in the kernel > from > > the Oxygen+Openwall+IDE-2.2.19-tar.gz package, edited syslinux.cfg on > hda1 > > to change the line under default linux to include boot=/dev/hda1 > instead of > > /dev/fd0u1680, saved everything and reboot. > > > > But when it boots off the hard drive I just get: > > > > "SYSLINUX 1.62 2001-04-24 Copyright (C) 1994-2001 H. Peter Anvin" > > > > ...and then it hangs. I tried a couple different kernels, and retried > the > > whole process a few times after reformatting, but get the same > response > > each time. Am I missing something obvious? > > > > > > ___ > > Leaf-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/leaf-user > > ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Re: Just a Comment
Thanks for the info and I will give it a try as well. Cheers Lonnie Quoting "Richard G. Minutillo" <[EMAIL PROTECTED]>: > But have you tried eth0_IP_EXTRA_ADDRS="146.9.31.42/24 146.9.31.56/24" > > [EMAIL PROTECTED] wrote: > > > > That's very interesting in that when I added > eth0_IP_EXTRA_ADDRS="146.9.31.42 > > 146.9.31.56" > > > > the LRP would not catch either one of them and only traffic directed > to the eth0 > > ip was caught. > > > > Strange to me. > > Lonnie > > > > ___ > Leaf-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/leaf-user > ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-user] routing question
hi pedro !!! thanks for your help. but this only solved my routing problems on the lrp2-side. actually the isdn-connection is always started by lrp2. can i add a second route to the lrp2 on the fw ? (ro add 192.168.1.0 via portmaster metric 2) how will fw know, if the ipsec-link on lrp1 is down ?? could this work ? thanks & bye stefan Am 03.10.2001 12:28:14, schrieb "Pedro Barreto" <[EMAIL PROTECTED]>: >hi Stefan, > >if you have some piece of software that will automatically connect the >isdn line when traffic is received on the isdn device, you could add >another default route with a higher metric, like: > >ip r add default dev $isdn_dev via $isdn_ip metric 2 >(assuming the first default route has a metric of 1) > >but that might bring the isdn line when the internet link is too >saturated. > >you can also try to create a script to ping LRP2 box trough LRP1 and >should that ping fail bring on the isdn interface, that script could go >to the cron.d (every 2 minutes "*/2 * * * *") > >the script might be like: > >#!/bin/bash >/bin/ping -w 2 -n -q -I $INTERNET_DEV -c 1 $LRP2_IP 2>&1 > /dev/null >if [ "$?" = "1" ]; then > ip r del default > bring_up_isdn() > ip r add default dev $ISDN_DEV >fi > >you could also add to this script functionality to bring down isdn when >internet is up again. > >that might help you, >pedro > > >> -Original Message- >> From: stefan [mailto:[EMAIL PROTECTED]] >> Sent: Wednesday, October 03, 2001 9:33 AM >> To: [EMAIL PROTECTED] >> Subject: [Leaf-user] routing question >> >> >> >> hi !! >> it's not really a LEAF-specific problem, but maybe a routing-pro >> reads this also - hopefully. >> i've connected two locations with ipseced-LRP-boxes, now i plan >> a backup with isdn, but i have some routing problems. >> >> >> the network looks like this: >> >> 192.168.1.0LRP2-.-.-.-Internet-.-.-.-.-LRP1 >> | ipsec | >> |FW10.1.1.0 >> || >> | portmaster >> |__isdn__| >> >> >> the FW is running on solaris. portmaster is a RAS-server from >> lucent. >> i want the network to work on, if the internet connection fails, >> but i don't know which routing-protocols i can/should use to >> solve this. i'd be glad if there's an easy solution. >> i think the main "problem" is the firewall, which schould know, >> which route to the 192.168.1 network to use. >> >> >> thanks. >> >> stefan >> >> >> >> ___ >> Leaf-user mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/leaf-user >> > > ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
