[Leaf-user] FTP server problem
##INTERN_ftp_SERVER = IP address##Default: STD=INTERN_SSH_SERVER=10.10.104.1## Others Undefined## EXT=All Undefined ##Scripts: STD EXT ##This group of variables controls port-forwarding services from the LRP box's##external interface to internal machines. Allowed xxx services are FTP, WWW,##SMTP, POP3, IMAP, and SSH. ##Services forwarded using these variables are always forwarded from the LRP##box's external IP address (see EXTERN_IP, above). ##If you expect people on the internet to be able to use your server, you must##also open the appropriate ports in your firewall rules (see EXTERN_UDP_PORTS,##EXTERN_UDP_PORTn, EXTERN_TCP_PORTS, AND EXTERN_TCP_PORTn, ##above).Is this above segment for FTP Servers with port 21 or is it all ftp servers all ports? Get your FREE download of MSN Explorer at http://explorer.msn.com. ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Squid redirect dachstein floppy
Kevin Kropf wrote: I am not that familiar with ipchains and was hoping for a little more detail. I put together the following command from the info on the squid FAQ: $IPCH -A input -p tcp -d 0/0 80 -j REDIRECT 3128 However I am not sure what else is needed and where to put it in ipfilter.conf Thanks for any help on this. Todd Pearsall replied: You can create a file in /etc named ipchains.input and add the command: ipchains -A input -p tcp -d 0/0 www -j REDIRECT 3128 If you are worried about users bypassing the proxy you can add following to block non-proxy web traffic ipchains -A input -i eth1 -d 0/0 www -j reject With those lines added type svi network ipfilter reload this will reload the rules including the ones in the /etc/ipchains.input file. Charles added the ipchains.input , ipchains.output and ipchains.forward cabability so you could extend the rules w/o editing the ipfilter.conf directly. As Todd mentioned, the place for this rule is /etc/ipchains.input. There are a few other things to be aware of, however. One big issue is the fact that inbound connections to high ports (=1024) are allowed by the default firewall rules. In addition to configuring squid so it only answered requests from internal network(s), I'd also want to block inbound connection attemts to squid from the internet. Port-scanners have taken to using proxies (as well as zombies) to do their port-scanning dirty work for them, and I'm sure you don't want that happening with your systems. Anyway, start with a deny of any squid requests from the internet: $IPCH -A input -p tcp -d 0/0 3128 -i $EXTERN_IF If you're running (or port-forwarding) a web server from your LRP box, you need rules to allow that traffic rather than redirecting it to squid. For internal access to weblet, you need something like: $IPCH -A input -j ACCEPT -p tcp -d $INTERN_IP www -i $INTERN_IF For a publicly visible webserver, you need something like the following, due to where the ipchains.input file rules get added to the overall rule-chain: $IPCH -A input -j ACCEPT -p tcp -d $EX_IP www -i $EXTERN_IF Finally, you can redirect all other web queries to your squid proxy: $IPCH -A input -j REDIRECT 3128 -p tcp -d 0/0 www Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] OPENSSHD
I'm using Dachstein CD 1.0.1 and its working great! I have a question about OpenSSHD. I can connect (using putty) from my internal network, but when I try from the external (say, at work) I get connection refused in the daemon log. I looked around for some help, and can't figure out why sshd would be blocking the connection, even before I get a password prompt. Thanks for your help, Sean ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] OPENSSHD
I did add a rule that should have opened port 22 in the firewall, and since the deamon log shows an sshd message refusing the connection, I am assuming it is getting through. I looked at the hosts.allow and hosts.deny, and didn't see anything obvious allowing the internal network... I'll look again when I get home! Have you tried the geocrawler search recently? Makes the whole concept of an archive useless. Someone has GOT to get that fixed! - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 12, 2001 2:23 PM Subject: [Leaf-user] OPENSSHD I'm using Dachstein CD 1.0.1 and its working great! I have a question about OpenSSHD. I can connect (using putty) from my internal network, but when I try from the external (say, at work) I get connection refused in the daemon log. I looked around for some help, and can't figure out why sshd would be blocking the connection, even before I get a password prompt. There's been some discussion of this recently I think. From what I remember, you need to do either or both of: - open a hole in your firewall for tcp port 22 (edit /etc/network.conf - follow the instructions in that file) - add an entry in hosts.allow for sshd (although I'm a bit hazy on that part) If you search the list archive, you'll probably find clearer explanations. tim ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] OPENSSHD
You are correct sir! I was also poking around the mail- archive site and found a few hits that might help. Thanks! After work I'll have to give it a shot. Sean P.S. When I first used ESB2, I was shocked to see someone had tried to login to my firewall using SSH. External access was on by default. Looks like Dachstein has it Off by default, and now I want to have external access! - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 12, 2001 2:46 PM Subject: Re: [Leaf-user] OPENSSHD I did add a rule that should have opened port 22 in the firewall, and since the deamon log shows an sshd message refusing the connection, I am assuming it is getting through. OK I looked at the hosts.allow and hosts.deny, and didn't see anything obvious allowing the internal network... I'll look again when I get home! Have you tried the geocrawler search recently? Makes the whole concept of an archive useless. Someone has GOT to get that fixed! I know, it's impossible to use. I have better luck with this one http://www.mail-archive.com/leaf-user@lists.sourceforge.net/ Just had a quick scout around, and searching for 'ssh hosts.allow' turned up a fair few results. tim - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 12, 2001 2:23 PM Subject: [Leaf-user] OPENSSHD I'm using Dachstein CD 1.0.1 and its working great! I have a question about OpenSSHD. I can connect (using putty) from my internal network, but when I try from the external (say, at work) I get connection refused in the daemon log. I looked around for some help, and can't figure out why sshd would be blocking the connection, even before I get a password prompt. There's been some discussion of this recently I think. From what I remember, you need to do either or both of: - open a hole in your firewall for tcp port 22 (edit /etc/network.conf - follow the instructions in that file) - add an entry in hosts.allow for sshd (although I'm a bit hazy on that part) If you search the list archive, you'll probably find clearer explanations. tim ___ 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] FTP Server - Change default ports
Hey All, I'm running an FTP server behind my Dachstein 1.01 router, and rather than have hundreds of scanners hitting my FTP server on port 21 and try and hack an account I'd like to move it to a different and much higher port number (above 1024 if possible). I've checked on google but not found anything that works. Most related articles refer to changing the ip_masq_ftp line to read: ip_masq_ftp ports=port#,port# this doesn't seem to work - and logging into port 21 still works. I am running Seawall 4.1.1 if that makes any difference. Any and all help is appreciated. S _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Why can't I ping from a Dachstein box?
Sending this on the leaf-user list after some hours of trying My present problem is that I can't ping from my dachstien box, loaded with the rc2 version booted from floppy. Is it possible there is some firewall filtering that prevents ping even outbound? In consonance with the troubleshooting support page, I have the following network diagram: A PC running Suse 7cat5 hub cat5 dachstein box (192.168.1.1/24 dev eth0) --- (SMC EZ Hub 10/100) -- (192.168.1.2/24 dev eth1) (dhcp dev eth0 ) Alcatel speed touch DSL modem. I have a known working ethernet nic in the Suse box, used it before to ping a different box, all works fine. I have two Netgear FA311 nics in the dachstein box, and the natsemi.o module seems to pick them up fine upon insmod natsemi.o The output of lsmod shows the natsemi loaded, and in use by pci-scan. The results of dmesg are no errors, only eth1: setting full-duplex based on negotiated link capability I would like to set an IP address on eth1, set a route, and ping my Suse machine just to verify it. I have done: ip addr add 192.168.1.2/24 broadcast 192.168.1.255 dev eth1 ip link set up ip route add 192.168.1.0/24 dev eth1 The output of ip addr show is: 1: lo: LOOPBACK,UP yadda yadd 2: eth0: BROADCAST,MULTICAST yadda link/ether (the correct hw addr) 3: eth1: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether (the correct hw addr) inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1 and the output of ip route show is: 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.2 But a ping command ping 192.168.1.1 shows 9 or 10 packets sent, none recieved, all packets lost. Also --- looking ahead to tyring to connect up eth0 to my dsl provider: I have read the LRP xDSL how-to, but it is only for static IP from a provider, apparently. Is there a how-to for getting PPPOE running over a DSL modem in Dachstein? Thanks again. ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Squid package??
Todd Pearsall wrote: I grabbed it from the Oxygen packages, but I don't know and can't currently check what version it is. It's the same one. I've compiled Squid 2.4 STABLE3 to run under glibc 2.0; it should work in any system. I also compiled it with SNMP enabled. It requires the libm library, and libcrypt. It does NOT need libnsl (I removed it...) It's a big package - the squid binary (stripped) is about 477k, and the compressed package is about 311k. The cache will be at /usr/cache. The package, if you want it, is at http://leaf.sourceforge.net/pub/oxygen/packages/squid.lrp. If you have any problems, let me know. ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-user] Squid package??
I poked around a bit and found that the Oxygen version does not include squidGuard. How hard would it be to put up the latest version that includes squidGuard? Kevin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Douthitt Sent: Wednesday, December 12, 2001 10:30 AM To: LEAF Users List Subject: Re: [Leaf-user] Squid package?? Todd Pearsall wrote: I grabbed it from the Oxygen packages, but I don't know and can't currently check what version it is. It's the same one. I've compiled Squid 2.4 STABLE3 to run under glibc 2.0; it should work in any system. I also compiled it with SNMP enabled. It requires the libm library, and libcrypt. It does NOT need libnsl (I removed it...) It's a big package - the squid binary (stripped) is about 477k, and the compressed package is about 311k. The cache will be at /usr/cache. The package, if you want it, is at http://leaf.sourceforge.net/pub/oxygen/packages/squid.lrp. If you have any problems, let me know. ___ 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] Squid redirect dachstein floppy
On a related note, I was having problems after I started using squid on a
dachstein CD (default RAM disk size) on a P75 with 32MB of RAM. After
installing squid it would work fine for a while and then I'd start
periodically seeing messages like:
VM Process Killing: {different service name}
VM Process Killing: {different service name}
VM Process Killing: {different service name}
as services stopped. The error message are from my memory so it may not be
exact, but should be close. I assume this is the kernel killing processes
since it is low on virtual memory to keep the kernel from running out of VM
and crashing. Anyone else running into this? BTW, this is running as
proxy-only, no caching.
I also wanted to log squid to a remote machine but the usual syslog.conf *.*
#re.mo.te.ip didn't seem to work, no squid logs that I could find appeared
on there remote server. Does squid not use the syslog daemon?
Thanks,
Todd
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Todd Pearsall
Sent: Wednesday, December 12, 2001 8:49 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Leaf-User (E-mail)
Subject: RE: [Leaf-user] Squid redirect dachstein floppy
You can create a file in /etc named ipchains.input and add the command:
ipchains -A input -p tcp -d 0/0 www -j REDIRECT 3128
If you are worried about users bypassing the proxy you can add
following to
block non-proxy web traffic
ipchains -A input -i eth1 -d 0/0 www -j reject
With those lines added type
svi network ipfilter reload
this will reload the rules including the ones in the /etc/ipchains.input
file.
Charles added the ipchains.input , ipchains.output and ipchains.forward
cabability so you could extend the rules w/o editing the ipfilter.conf
directly.
- Todd
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Kropf
Sent: Wednesday, December 12, 2001 1:18 AM
To: [EMAIL PROTECTED]; Leaf-User (E-mail)
Subject: RE: [Leaf-user] Squid redirect dachstein floppy
I am not that familiar with ipchains and was hoping for a little more
detail.
I put together the following command from the info on the squid FAQ:
$IPCH -A input -p tcp -d 0/0 80 -j REDIRECT 3128
However I am not sure what else is needed and where to put it in
ipfilter.conf
Thanks for any help on this.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Douthitt
Sent: Tuesday, December 11, 2001 5:32 PM
To: LEAF Users List
Subject: Re: [Leaf-user] Squid redirect dachstein floppy
Kevin Kropf wrote:
I have Squid running on dachstein-rc2-1680.exe and would like
to redirect
all internal port 80 requests to the default Squid port of 3128
on the LRP
box.
I have read through the archives and found very little of use.
What is the best way to do this?
This is in the Squid FAQ - in fact, it's an entire section (#17); go to
the Squid home page at http://www.squid-cache.org/ .
___
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 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] FTP Server - Change default ports
running a server behind a firewall on a different port requires a setup on the ftp server: following settings (for proftpd) are relevant: Port21 - change this to reflect your preferences MasqueradeAddress your firewall's ip address or domain name PassivePortsfromport toport the last two are needed to make passive mode work (people with firewalls will like you for doing this). check if your version supports these directives. you will have to port-forward your port of choice for the ftp server and the range of passive ports as well as the ftp-data port (20) to the masqueraded host. you will have to make sure your firewall accepts connections on these ports. how to do this is specific to your distribution / firewall. since i do not restart often, i just use a little script that does the port forwarding and have actually forgotten how to configure my router. ip_masq_ftp is not relevant to the question of running a masqueraded ftp-server. i am not sure however what to do with the ftp-data port if 2 or more ftp servers run on different ports. i did consult ftp.echogent.com/docs/FTP_and_Firewalls.pdf (very good reading, btw.) -Ursprüngliche Nachricht- Von: Simon Bolduc [EMAIL PROTECTED] An: [EMAIL PROTECTED] [EMAIL PROTECTED] Datum: Mittwoch, 12. Dezember 2001 19:31 Betreff: [Leaf-user] FTP Server - Change default ports Hey All, I'm running an FTP server behind my Dachstein 1.01 router, and rather than have hundreds of scanners hitting my FTP server on port 21 and try and hack an account I'd like to move it to a different and much higher port number (above 1024 if possible). I've checked on google but not found anything that works. Most related articles refer to changing the ip_masq_ftp line to read: ip_masq_ftp ports=port#,port# this doesn't seem to work - and logging into port 21 still works. I am running Seawall 4.1.1 if that makes any difference. Any and all help is appreciated. S _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ 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] Why can't I ping from a Dachstein box?
Good start on a trouble report. A few specific questions: 1. Can the DachStein router/firewall ping its *own* IP addresses? 192.168.1.2 in particular? If not, how does this fail (I suspect from your report that you have read the FAQ materials on pings, but just in case, I'll mention that pings fail in about 5 distinct ways)? 2. Can the SuSE host ping its *own* interface (192.168.1.1)? If not, how does this fail? 3. Is the routing table on the SuSE host correct? (Look at the output of netstat -nr on it.) 4. Since the LAN seems to consist of only the two hosts ... are you sure all the hardware is OK? Are both UTP cables good (regular cables, NOT crossover cables)? Are the ports on the hub good? Are both devices plugged into normal (NOT uplink) ports on the hub? Do appropriate lights come on, on the various NICs and hub ports, when cables are connected and pings are running (sorry I can't be more specific here; there are too many variations on LED arrangements)? I think there's a FAQ answer that asks a few more queations than these regarding hardware. As to your PPPoE question ... I haven't used PPPoE in some time, and not with DachStein, but Ken Hadley's instructions, part of the PPPoE package itself, should guide you (They certainly seemed adequate to me back when I used his EigerStein-based PPPoE image). At 01:29 PM 12/12/01 -0500, Dr. Richard W. Tibbs wrote: Sending this on the leaf-user list after some hours of trying My present problem is that I can't ping from my dachstien box, loaded with the rc2 version booted from floppy. Is it possible there is some firewall filtering that prevents ping even outbound? In consonance with the troubleshooting support page, I have the following network diagram: A PC running Suse 7cat5 hub cat5 dachstein box (192.168.1.1/24 dev eth0) --- (SMC EZ Hub 10/100) -- (192.168.1.2/24 dev eth1) (dhcp dev eth0 ) Alcatel speed touch DSL modem. I have a known working ethernet nic in the Suse box, used it before to ping a different box, all works fine. I have two Netgear FA311 nics in the dachstein box, and the natsemi.o module seems to pick them up fine upon insmod natsemi.o The output of lsmod shows the natsemi loaded, and in use by pci-scan. The results of dmesg are no errors, only eth1: setting full-duplex based on negotiated link capability I would like to set an IP address on eth1, set a route, and ping my Suse machine just to verify it. I have done: ip addr add 192.168.1.2/24 broadcast 192.168.1.255 dev eth1 ip link set up ip route add 192.168.1.0/24 dev eth1 The output of ip addr show is: 1: lo: LOOPBACK,UP yadda yadd 2: eth0: BROADCAST,MULTICAST yadda link/ether (the correct hw addr) 3: eth1: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether (the correct hw addr) inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1 and the output of ip route show is: 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.2 But a ping command ping 192.168.1.1 shows 9 or 10 packets sent, none recieved, all packets lost. Also --- looking ahead to tyring to connect up eth0 to my dsl provider: I have read the LRP xDSL how-to, but it is only for static IP from a provider, apparently. Is there a how-to for getting PPPOE running over a DSL modem in Dachstein? -- Never tell me the odds!--- Ray Olszewski-- Han Solo Palo Alto, CA[EMAIL PROTECTED] ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Static ARP table in 2.4 linux kernel.
Hello, Have a problem with static MAC-IP mappings. I need to create the static ARP table, load it into the kernel and work only with static mappings. I'm able to create the table (/etc/ethers), load it to the kernel (arp -f /etc/ethers) and everythingworks fine but linux continues to add dynamic entries to ARP table. If I switching off arp frp eth0 interface (ifconfig eth0 -arp), IP stops works even if static arp table still exists (arp -n -a prints out the table). Any advices how to do that? Kernel version is 2.4.9. Thanks in advance, Dmitri. ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-user] Squid package??
I do not know as I am new to squid etc... It (squidGuard) was included in the squid-2.lrp I used and had instructions on how to use it. http://users.bart.nl/~nelemans/squid/squid.html I assumed someone did the research and thought it best to do this. What is your experience and opinion? What is Squirm? Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Douthitt Sent: Wednesday, December 12, 2001 11:45 AM To: LEAF Users List Subject: Re: [Leaf-user] Squid package?? Kevin Kropf wrote: I poked around a bit and found that the Oxygen version does not include squidGuard. How hard would it be to put up the latest version that includes squidGuard? squidGuard is a separate product. It'll take some doing, since it requires libdb. Some questions though: why use squidGuard when you have the redirection capabilities in Squid? Why use squidGuard instead of Squirm? ___ 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] Why can't I ping from a Dachstein box?
At 02:37 PM 12/12/01 -0500, Dr. Richard W. Tibbs wrote: Answers in line below. Thx for this help, but still stymied. [old stuff and html deleted] OK. With the obvious stuff out of the way, how about this set of ideas? 1. Is the SuSE host running any firewalling of its own? On it, does ipchains -L -n report anything interesting? 2. Do the logs on the DachStein router report any DENY'd or REJECT'd icmp packets? Does ipchains -L -n -v report any rules that would seem to be blocking the icmp traffic? 3. After you attempt and fail to ping the SuSE device, does the DachStein router's arp table show an entry for the SuSE device? (more /proc/net/arp)? Does the SuSE host have an arp entry for the DachStein router? 4. This is a real long shot, but ... what is in /proc/sys/net/ipv4/icmp_echo_ignore_all on the SuSE host? It's probably 0 [=FALSE], as it should be. If it is a 1 [=TRUE], change it to 0 ( echo 0 /proc/sys/net/ipv4/icmp_echo_ignore_all, I think) and see if that changes your results. 5. Could the hub itself be bad? Do you have a crossover cable (or another hub) you can use to connect the two hosts directly? 6. You mentioned appropriate green led's lighting up. Do the NICs and hub ports have only connect LEDs, or do they have traffic LEDs as well? If they have both, do they all behave as expected? 7. Finally ... have you tried any connections other than pings? I don't know what services the SuSE host is running, so I cannot be more specific here. 8. And plu-finally ... have you tried and failed in the other direction too? Can the SuSE host ping, or or connect towhatever else is running in the way of services on, the DachStein router? -- Never tell me the odds!--- Ray Olszewski-- Han Solo Palo Alto, CA[EMAIL PROTECTED] ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Squid redirect dachstein floppy
Todd Pearsall wrote:
On a related note, I was having problems after I started using squid on a
dachstein CD (default RAM disk size) on a P75 with 32MB of RAM. After
installing squid it would work fine for a while and then I'd start
periodically seeing messages like:
VM Process Killing: {different service name}
VM Process Killing: {different service name}
VM Process Killing: {different service name}
as services stopped. The error message are from my memory so it may not be
exact, but should be close. I assume this is the kernel killing processes
since it is low on virtual memory to keep the kernel from running out of VM
and crashing. Anyone else running into this? BTW, this is running as
proxy-only, no caching.
Squid needs *LOTS* of memory and disk space. I'd recommend you run with
64M at least, maybe more. Remember, too, that unlike normal
distributions a major chunk of that 32M is used by the RAM disks, so
you're actually running on something like 16M or less for Squid to run
in. Get more memory
I also wanted to log squid to a remote machine but the usual syslog.conf *.*
#re.mo.te.ip didn't seem to work, no squid logs that I could find appeared
on there remote server. Does squid not use the syslog daemon?
Use squid -s to log startups and shutdowns (and such like) to syslog.
As for accesses, it's not currently possible.
___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Charles makes it into Linux Journal!
Among others here on this list ... I have created a single-diskette distribution that installs the base configuration of a VPN firewall based on the Linux Router Project (LRP, www.linuxrouter.org), a compact Linux distribution that can fit on a single, bootable floppy diskette. The distribution here is essentially Charles Steinkuehler's Eiger disk image with Steinkuehler's IPSec-enabled kernel and LRP IPSec package. Firewalling is carried out through Linux ipchains. This particular version is based on the 2.2.16 kernel of Linux. This distribution is called DUCLING (Diskette- based Ultra Compact Linux IPSec Network Gateway). Compact Linux distributions have a twisted history. LRP technically refers to Dave Cinege's compact distribution. There are many variants around, including Charles Steinkuehler's distribution (EigerStein) of Matthew Grant's defunct Eiger version (lrp1.steinkuehler.net). Another such distribution is David Douthitt's Oxygen (leaf.sourceforge.net/content.php?menu=900page_id=1). Also, there is LEAF (Linux Embedded Appliance Firewall), a developer's umbrella that tries to coordinate releases and documentation, sort of like a one-stop shop for compact Linux distributions (leaf.sourceforge.net). I use the term LRP to refer to the compact Linux distribution presented here, even though some may consider this terminology incorrect. http://www.linuxjournal.com/article.php?sid=4772 By Duncan Napier -- Goodbye youth, goodbye dreams, The good times and the friends I used to know. Goodbye freedom, hello fear, A brave new world has suddenly appeared. Salvation Road, The Kinks ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] FTP Server - Change default ports
Well that works just perfectly - thanx. Gotta love when you overlook trying something simple S From: Kiril [EMAIL PROTECTED] Reply-To: Kiril [EMAIL PROTECTED] To: Simon Bolduc [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Leaf-user] FTP Server - Change default ports Date: Wed, 12 Dec 2001 22:06:31 +0100 running a server behind a firewall on a different port requires a setup on the ftp server: following settings (for proftpd) are relevant: Port21 - change this to reflect your preferences MasqueradeAddress your firewall's ip address or domain name PassivePortsfromport toport the last two are needed to make passive mode work (people with firewalls will like you for doing this). check if your version supports these directives. you will have to port-forward your port of choice for the ftp server and the range of passive ports as well as the ftp-data port (20) to the masqueraded host. you will have to make sure your firewall accepts connections on these ports. how to do this is specific to your distribution / firewall. since i do not restart often, i just use a little script that does the port forwarding and have actually forgotten how to configure my router. ip_masq_ftp is not relevant to the question of running a masqueraded ftp-server. i am not sure however what to do with the ftp-data port if 2 or more ftp servers run on different ports. i did consult ftp.echogent.com/docs/FTP_and_Firewalls.pdf (very good reading, btw.) -Ursprüngliche Nachricht- Von: Simon Bolduc [EMAIL PROTECTED] An: [EMAIL PROTECTED] [EMAIL PROTECTED] Datum: Mittwoch, 12. Dezember 2001 19:31 Betreff: [Leaf-user] FTP Server - Change default ports Hey All, I'm running an FTP server behind my Dachstein 1.01 router, and rather than have hundreds of scanners hitting my FTP server on port 21 and try and hack an account I'd like to move it to a different and much higher port number (above 1024 if possible). I've checked on google but not found anything that works. Most related articles refer to changing the ip_masq_ftp line to read: ip_masq_ftp ports=port#,port# this doesn't seem to work - and logging into port 21 still works. I am running Seawall 4.1.1 if that makes any difference. Any and all help is appreciated. S _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Squirm and SquidGuard
I tried everything to compile SquidGuard. The stable version requires libdb 2.6.4+ and won't work with any libdb 3 less than 3.4+ something. It won't work with libdb 4 at all apparently. It also has bugs that keep it from compiling, and hasn't been updated in almost two years. The development version also requires libdb in the versions listed, but won't compile. The development version is dated July 2001. Squirm (1.23) was better - it compiled just fine, and doesn't need libdb, libcrypt, libm or anything aside from the ordinary. squirm.lrp is in the usual place: http://leaf.sourceforge.net/pub/oxygen/packages/squirm.lrp ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Squirm and SquidGuard
Kevin Kropf wrote: Thanks for your trouble. I will read up on it and perhaps give it a try. Probably best way to go is to do the following: 1. Use Red Hat 5.2 or Mandrake 5.2 or Debian 2.1 distributions - all glibc 2.0 based. 2. Get libdb v3 probably - v4 may not yet be supported, and v3 probably works. Install it if you want, otherwise use the --with-db option to configure below with the right directory... that might even be better... 3. Compile with the usual ./configure and make options... I use on a regular basis: ./configure --sysconfdir=/etc --prefix=/usr make This removes all sorts of strangeness, such as different locations of software, libraries, include libraries, etc. See how that goes. ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Why can't I ping from a Dachstein box?
More inline comments and full Dachstein ipchains output attached as a text file . Also, to state right up front: I haven't changed the dachstein rules at all. In fact I have not been able to find the full text of the ruleset anywhere yet. lrcfg, under Network IP Filter/Firewall Rules presents a huge script that seems to automagically generate the ACLs. I haven't messed with it. I seem to remember an email on the list about an ipchains input file somewhere, but I have not messed with that either. Thanks for all this trouble; if I thought that it was normal that the internal iface would disallow pings, I guess I could go on my way trying to get pppoe working over the external iface. But I am happier understanding how the firewall policies work, if y'all can stand the frustration !! Ray Olszewski wrote: Comments inline. I added the LEAF list back in.At 03:49 PM 12/12/01 -0500, Dr. Richard W. Tibbs wrote:... 1. Is the SuSE host running any firewalling of its own? On it, does"ipchains -L -n" report anything interesting?Keep in mind that without modification the Suse box has successfully pinged another doorstop box with TomsRootBoot running just to check it out. Worked through same cables, same hub. That additional doorstopis now turned off and disconnected from hub; new dachstein box plugged in and running. sigh I sure wish you had mentioned this earlier. I couldn't keep this "inmind" before now because you hadn't mentioned it in your earlier troublereports (or did you and I missed it?). This information changes my focus alot in thinking about the problem ... it makes a lot of my prior questionsirrelevant./sigh Very sorry, Ray... I thought I had mentioned it, but the thread of these emails is getting real long... Still, the ACLs on the Suse box allow a ping, so it is still usefull to look at them (for me, the unwashed, anyway ;-) Hope this isn't getting to aggravating. OK. Now, a very basic question ... are you sure you have eth0 and eth1 onthe DachStein router associated with the right NICs? That is, might you haveeth0 (the external, as yet unconfigured interface) connected to the hubinstead of eth1 (the internal interface assigned to 192.168.1.2)? Awfully sure they are connected right physically. I checked the Hw addrs on the cards before I put them in the Aptiva (= Dachstein doorstop) and noted the positions. A "ip link show" command verifies the hw addrs and associated dev ifaces. I also switched nics with the cable on the dachstein box just to make sure. no change in the outcome. Since you say below (not sure if this is with respect to the NICs, the hub,or both, but for this purpose it doesn't matter) -- They have traffic as well, but I have observed no "flickering" -- indication of traffic activity This is w.r.t the hub -- in the earlier network with the "other doorstop" I had a ping running between Suse and Tomsrtbt and the little green lites flicker to indicate traffic. They stay solid green to indicate a good link. -- this sort of misconiguration is the first thing that comes to mind.The second possibility is that some more general rule, or one of the defaultDENY policies, on the DachStein router (one where proto=ALL) is blocking thepings. This is improbable, if you stayed close to the default ruleset ...but your reporting of the "icmp-relevant lines" doesn't cover all the bases. As you summarize the input chain on the DachStein router, it DENYseverything (the default policy is DENY, and the only lines you list orsummarize below are DENYs and REJECTs). Actually, so do the forward andoutput chains, as you summarize them. But then your reply to question 2lists a couple of ACCEPT lines (uninterpretable in isolation; we call them"rulesets" because they only have meaning when viewed as a set).So ... I don't know if your edited report in question 1 left out some ACCEPTlines or if the router really is as misconfigured as your summary suggests.But your logs (probably /var/log/messages) should indicate if the router isDENYing a lot of traffic, it should be logging those DENYs.If it is a DachStein-specific misconfiguration, someone who is currentlyrunning DachStein can suggest the likely locations for the error. A responsethat is not specific to DachStein still requires an accorate listing of thefull rulesets. Suse box ipchains output hasChain input (policy ACCEPT)targetprotoptsource dest portsDENY udp l- 0.0.0.0/0 0.0.0.0/0 *- 0:1023(a couple of other udp and tcp flavors)DENY icmp l- 0.0.0.0/0 0.0.0.0/0 8- *Chain forward (policy ACCEPT)target protopt source dest portsMASQ all --0.0.0.0/0 0.0.0.0/0n/aChain output (policy ACCEPT) :no entriesThe ipchains -L -n output on the Dachstein box is voluminous but the icmp-relevant lines areChain input (policy
Re: [Leaf-user] Why can't I ping from a Dachstein box?
Well, I find I am reduced to grasping at straws. The firewall rulesets you appended to your message look fine; the pings should be dropping through to the final (in rough terms, ACCEPT anything that made it this far) rules on the input and output chains. I'm left wondering about the possibility of a hardware problem with the NICs, possibly an IRQ or I/O base problem. Do /proc/interrupts and /proc/ioports report sensible values for these devices? Since they are pci-bus NICs, I assume there is no old-style problem like a conflict with the IRQ of an unused serial port (this was a common problem with isa-bus NICs). If that isn't it ... and I think it a long shot, myself ... I'm out of ideas. Sorry. At 06:42 PM 12/12/01 -0500, Dr. Richard W. Tibbs wrote: More inline comments and full Dachstein ipchains output attached as a text file . -- Never tell me the odds!--- Ray Olszewski-- Han Solo Palo Alto, CA[EMAIL PROTECTED] ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] FTP Server - Change default ports
Simon Bolduc wrote: Hey All, I'm running an FTP server behind my Dachstein 1.01 router, and rather than have hundreds of scanners hitting my FTP server on port 21 and try and hack an account I'd like to move it to a different and much higher port number (above 1024 if possible). I've checked on google but not found anything that works. Most related articles refer to changing the ip_masq_ftp line to read: ip_masq_ftp ports=port#,port# this doesn't seem to work - and logging into port 21 still works. I am running Seawall 4.1.1 if that makes any difference. Any and all help is appreciated. S I can help you with a different firewall solution. I wrote a firewall for Oxygen and Dachstein that handles your simple request. I think that you may have had problems with your newish ip_masq_ftp command if the ip_masq_ftp.o modules is an older version that doesn't support it. The command you quoted is new to me, and I really shouldn't comment. If you want to try out my firewall, it's called pfw.lrp, Packet Firewall v.1.0, at ftp://ftp.schalit.net/pub/ In the /usr/local/etc/popts , the optional services file, I use the following lines to forward two different ports on my firewall to port 21 on my ftp server. YodaFtpC1=$IPX:21$YODA:21$WORLD:alltcplog \ YodaFtpC2=$IPX:710$YODA:21$WORLD:alltcplog \ That's an example of how I run what looks like an ftp server on port 710. If you try out pfw, I can walk you through it. You can fire it up without making any changes and it will work, but it won't accept any inbound services until you edit the popts file. Good Luck, Matthew ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Why can't I ping from a Dachstein box?
What you want to do at this point is either modify the firewall ruleset text file to specify loggin the traffic so you can see what is happening, or you can insert the rules to do so into the ruleset that's running. You would want to add the -l switch to the default rules for input and output. That's the rule that the traffic is matching, based on the byte counts in the ipchains -L -n you posted. Once you've added the -l switch and reloaded, make the traffic and look at your syslog. You should see quite a bit of the exact answer as to what is going on. When sitting at the LEAF and pinging an internal LAN computer, outgoing ping is ICMP type 8. The response are input on eth1 as ICMP type 0. Those are allowed according to your rules. If you have trouble making the correct rule modifications, post, and we'll give you the exact syntax. Regards, Matthew ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Can't save etc.lrp - modules don't load
Hi there, I'm booting Dachstein from a floppy which then reads packages from the latest Dachstein CD. The problem I'm experiencing is, I think, that the changes I am trying to make to /etc/modules are not being saved on to the floppy. I'm not entirely sure I've understood the config process for a Dachstein floppy and CD combination so I've set out my assumptions below in case I've got the concept wrong... If I understand it correctly, I need to modify /etc/modules to remove the comments from the modules that I need and then save the file - as one would with E2B. I then need to back up the /etc system on to the floppy so that the modified etc.lrp gets loaded on boot. So that is what I am doing. I am seeing a back up menu item for: 2) etc Full fd0 msdos and I am issuing b 2 to back this system up to the floppy. There's then a green write light on the floppy ad all looks well. When the system boots I see what I think is a sign that the floppy version of etc.lrp is being read, ie: Linuxrc: Installing etc: /dev/cdrom /dev/fd0 but I don't see any signs that the uncommented modules are being loaded. The only clues I see to what is happening are a series of SIOCGIFFLAGS: Operation not supported by device exiting errors. These come after the message that invites contributions to dhcp code development. When the system tries to start the two interfaces in this box, it says it can't find them. The problem is not restricted to NIC modules. If I uncomment kernel helper modules that are commented out by default in the /etc/module file - such as pptp support - and save and back up the file, I note that there is no sign this module loaded, although the modules that are uncommented on the CD do load. I've tried manually loading the etc.lrp package using lrpkg -i etc and can see that etc.lrp loads but when I go back into the lrcfg menu system and then into Package Settings - Modules - Modules, I see that the lines I had uncommented are still commented. I got on fine with E2B so I suspect the problem is that I have misunderstood part of the back up process for a floppy-booted Dachstein CD. Anyone know what I am dong wrong? Any help would be greatly appreciated! Thanks Lee ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Why can't I ping from a Dachstein box?
I added the list back in, again. At 08:33 PM 12/12/01 -0500, Dr. Richard W. Tibbs wrote: ... /proc/interrupts shows 0: 8398664 XT-PIC timer 1: 16910 XT-PIC keyboard 2 0 XT-PIC cascade 6 1654 XT-PIC floppy 8: 3 XT-PIC rtc 10: 128 XT-PICeth1 11: 1 XT-PICeth0 13 1 XT-PICfpu both nics are PCI The ioports file shows no entry for eth1 or eth0 explicitly (should there be?) Yes. Do you have your BIOS set to NOT running a PnP OS? There are items called pic1 and pic2 and dma1 and dma2. All the addresses seem rational. [old stuff deleted] [html duplicate deleted] -- Never tell me the odds!--- Ray Olszewski-- Han Solo Palo Alto, CA[EMAIL PROTECTED] ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
