Re: [leaf-user] bering bridge setup
Le Samedi 11 Mai 2002 01:02, Manfred Schuler a écrit : Hi Jacques, I have tried rc2, same result. I have checked your user manual and your installation manual. I want to setup a router that grants access for wireless clients to the internal net and the whole wide world. All interfaces are working. I can setup a bridge using brctl and ip. but when I use ifup, I get the message of missing variables. If you need more information, please ask for it. Hi Manfred What says ifup -v ifacename ? (You might need to ifdown ifacename first) The -v flag will give a verbose execution of ifup Bridging is rather undocumented in Bering at this stage. That is why I am very much interested in knowing more abou what you have done. Would you be ready to document that a bit ? Cheers Jacques ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Restricting SMTP, IMAP and POP traffic
OK. What you are asking for here is considerably simpler than what I understood from your earlier message, and it is quite straightforward to do at the ipchains level. I'm too out of date with Eigerstein to translate the ipchains stuff to Charles' scripts, though, but perhaps someone else will be able to step in with that part. I suspect, though, that you will have to add them to the file that handles non-standard rules explicitly, since the requirements are a bit specialized. At 05:48 AM 5/11/02 -0400, Enchufa2.com wrote: [...] What I would like to do is prevent users from changing the browser proxy configuration at their workstations and then bypass the proxy/cache and also to prevent unauthorized users to change their e-mail app configuration and become able to send/receive external e-mail using external e-mail servers. Ideally, unathorized users would only be able to use the local mail servers and authorized users would be able to use both internal and external servers. To prevent ALL users from bypassing the Squid proxy server, create ipchains rules that block all traffic destined for port 80 (and maybe 443, 20, and 21, depending on what services you have Squid handling) from any internal IP address other than the one for the host running the Squid proxy. To prevent ALL users from bypassing the internal mail server, create ipchains rules that block all traffic destined for port 25 from any IP address other than the one for the host running SMTP server. Also block all traffic destined for ports 110 and the IMAP port (unless there is a reason why the SMTP server needs to connect to offsite servers on these ports; then do the same as port 25.) Preventing only unauthorized users from doing these things depends on how you identify them. You seem to have in mind authorizing *hosts* rather than users, since you write: I was thinking of using DHCP to associate authorized machines with an specific IP addresses or range via IP leases based on MAC addresses. Doing this is a natural extension of the process of authorizing the servers to use these ports. You'd do it (at the ipchains level) by inserting, at an appropriate location, input-chain rules that ... FIRST, explicitly ACCEPT traffic to (for example) port 25 from the authorized machines SECOND, explicitly DENY (or REJECT) traffic to those same ports from all other LAN addresses BTW, your original message seemed to want to do more than block ... you seemed to be looking for a way to redirect at least some of this traffic back to the LAN hosts. This, or at least some of this, may be doable by way of a custom chain in ipchains; I haven't tried it so am not sure. I'm more confident that the iptables system in kernel 2.4.x could manage this by way of its PREROUTING table (though once again I haven't actually done it), albeit at some price in extra LAN traffic. -- Never tell me the odds!--- Ray Olszewski-- Han Solo Palo Alto, CA[EMAIL PROTECTED] ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Restricting SMTP, IMAP and POP traffic
Enchufa2.com [EMAIL PROTECTED] wrote: Let me step out on a limb. I am just looking into the idea of using a private DMZ for a backup server. One LEAF box's protected server would send files to another LEAF box's port forwarded server via SSH. From my reading, I get the feeling that some of the ipchain rules Ray described are covered in the extended scripts available for Eigerstein Beta 2. I am too new in the learning curve to fully describe the configuration yet. The extended scripts are the default scripts in Dachstein. The scripts are available to EB2 as an add on package. Moreover, there are some hook files that may be useful in adding the specialized rules Ray talked about, if the extended scripts do not provide support by default. What I am thinking is that the extended scripts would help with adding a private network DMZ. See your modified diagram below. If your company can spring for the cost of one more network card in your LEAF box, then you would put all your servers on the DMZ. This would also offer your network more protection if one of your servers is compromised. A reverse masquerade rule is set for the servers in the extended scripts. You could block all the services Ray talked about and restrict them to 172.16.8.2. This would restrict the services to your internal servers on the DMZ because of the built in rules. Please see the ADVANCED FIREWALL CONFIGURATION section of the network.txt documentation file. Hopefully, I helped and not hindered here. Greg Morgan This is a commented diagram of the current setup: Internet Gateway 216.72.129.xxx | | LMMDS Wireless link to ISP network | | ISP router at building 172.16.8.1 subnet mask: 255.255.255.0 | LRP: Eigerstein Beta 2 ***|** * | * Router offers: * eth0: 172.16.8.2 * NAT for the LAN, portfw to internal ** servers, SSH access from the outside * eth1: 192.168.0.1 * * | * * eth2: 192.168.0.2 *3 interal servers network/DMZ moved here. * | * ***|** | | Internal network 192.168.0.0/24 | | hub/switch | | | | | | | |3 internal servers and several workstations: | | | | | | | |Services offered by the servers: | | | | | | | |- To the inside:proxy/cache (Squid),Socks5 proxy= , | | | |authentication,DHCP,SMTP,IMAP,DNS | | | | | | | |- To the outside: www | | | | | | | |All servers and workstations | | | |use 192.168.0.1 as defualt gateway | | | | | | | |Servers IP config is manual | | | | | | | |Workstations get IP config via DHCP | | | | | | | +--- 192.168.0.2 | | | | | +- 192.168.0.3 | | . | | . | | . | + 192.168.0.252 | +-- 192.168.0.253 ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] Bering using lrpkg.cfg
Hi list, I am trying to create a bering disk that uses the lrpkg.cfg file to specify the packages without much luck. What I am trying to do for now is creating an lrpkg.cfg file on a working hdd module (diskonchip thats completely ide compatible). As soon as I remove the LRP variable from syslinux.cfg My system refuses to boot telling me I attempted to kill init. It pretty much looks like it that he is not reading lrpkg.cfg at all. I have read the bering user guide and did everything in section 8 without success Any clues anyone??? ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Identify processes launched by inetd?
At 09:05 PM 5/11/02 +0200, Kim Oppalfens wrote: Hi all, just wondered if there was a way to see which processes are actually running from inetd. Since ps aux won't show them. It will if they are actually running at the moment (for example, open telnet connections will have associated telnetd processes). If they aren't actually running, they aren't really *processes*. If you want to know what *services* inetd is mediating, the easiest way to find out is to check /etc/inetd.conf to see what services are listed in it. As a double check, you can run netstat -l, but it doesn't distinguish inetd-mediated services from services that are running directly. -- Never tell me the odds!--- Ray Olszewski-- Han Solo Palo Alto, CA[EMAIL PROTECTED] ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Restricting SMTP, IMAP and POP traffic
On 11/5/02 11:23 AM, Ray Olszewski from [EMAIL PROTECTED] wrote: OK. What you are asking for here is considerably simpler than what I understood from your earlier message, and it is quite straightforward to do at the ipchains level. I'm too out of date with Eigerstein to translate the ipchains stuff to Charles' scripts, though, but perhaps someone else will be able to step in with that part. I suspect, though, that you will have to add them to the file that handles non-standard rules explicitly, since the requirements are a bit specialized. I am glad my revision to my original post made things clearer. Reading the troubleshooting guide helped. At 05:48 AM 5/11/02 -0400, Enchufa2.com wrote: [...] What I would like to do is prevent users from changing the browser proxy configuration at their workstations and then bypass the proxy/cache and also to prevent unauthorized users to change their e-mail app configuration and become able to send/receive external e-mail using external e-mail servers. Ideally, unathorized users would only be able to use the local mail servers and authorized users would be able to use both internal and external servers. To prevent ALL users from bypassing the Squid proxy server, create ipchains rules that block all traffic destined for port 80 (and maybe 443, 20, and 21, depending on what services you have Squid handling) from any internal IP address other than the one for the host running the Squid proxy. To prevent ALL users from bypassing the internal mail server, create ipchains rules that block all traffic destined for port 25 from any IP address other than the one for the host running SMTP server. Also block all traffic destined for ports 110 and the IMAP port (unless there is a reason why the SMTP server needs to connect to offsite servers on these ports; then do the same as port 25.) Preventing only unauthorized users from doing these things depends on how you identify them. You seem to have in mind authorizing *hosts* rather than users, since you write: I was thinking of using DHCP to associate authorized machines with an specific IP addresses or range via IP leases based on MAC addresses. For Proxy and SMTP usage, the users are already required to authenticate themselves, but I would like to have another layer of security by restricting access to HTTP and SMTP/IMAP/POP traffic based on IP addresses. Doing this is a natural extension of the process of authorizing the servers to use these ports. You'd do it (at the ipchains level) by inserting, at an appropriate location, input-chain rules that ... FIRST, explicitly ACCEPT traffic to (for example) port 25 from the authorized machines SECOND, explicitly DENY (or REJECT) traffic to those same ports from all other LAN addresses BTW, your original message seemed to want to do more than block ... you seemed to be looking for a way to redirect at least some of this traffic back to the LAN hosts. This, or at least some of this, may be doable by way of a custom chain in ipchains; I haven't tried it so am not sure. I'm more confident that the iptables system in kernel 2.4.x could manage this by way of its PREROUTING table (though once again I haven't actually done it), albeit at some price in extra LAN traffic. I haven´t looked at more recent versions or distros of LRP/LEAF heritage (Oxygen, Dachstein) but it may be that I upgrade to a LRP/LEAF derivative based on a 2.4 kernel and iptables filtering. Thanks again, Omar ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
