Menu
▾
▴
[Devil-Linux-discuss] Troubles with Telnet clients
|
From: <ne...@co...> - 2007-04-24 18:15:50
|
OK I'd like to thank all those who have offered help.
I got a few suggestions about dropping the NAT--I'm way too new at all of this to take that hint and be able to just run with it. There are two different options I am looking at.
----------------------------------------------------------------------------------------------------------------------------------------
Option #1
How would I modify the firewall.rules to allow for traffic to reach the telnet server without using NAT. It is possible that the NAT is what is causing the telnet sessions to swap, get stolen by another user (please see thread if you need clarification on that one).
######################################################################
#accept DHCP
${IPTABLES} -A INPUT -p UDP -i eth1 --dport 67:68 -j ACCEPT
${IPTABLES} -A OUTPUT -p UDP -o eth1 --dport 67:68 -j ACCEPT
#allow access to the server
${IPTABLES} -A FORWARD -i eth1 -p TCP -o eth0 -d $TELNETIP --dport 23 -j ACCEPT
${IPTABLES} -A FORWARD -i eth0 -p TCP -o eth1 -s $TELNETIP -m state --state ESTABLISHED,RELATED --sport 23 -j ACCEPT
#drop UDP packets
${IPTABLES} -A FORWARD -p UDP --dport 1: -j DROP
${IPTABLES} -A INPUT -p TCP -i eth1 --dport :21 -j DROP
#${IPTABLES} -A INPUT -p TCP -i eth1 --dport 24:66 -j DROP
#${IPTABLES} -A INPUT -p TCP -i eth1 --dport 69: -j DROP
${IPTABLES} -A INPUT -p TCP -i eth1 --dport 24: -j DROP
#allow ping from WAN side only
${IPTABLES} -A INPUT -s $OUR_NW -p icmp -j ACCEPT
${IPTABLES} -A OUTPUT -s $OUR_NW -p icmp -j ACCEPT
${IPTABLES} -A FORWARD -p icmp -j DROP
${IPTABLES} -A OUTPUT -p icmp -j DROP
######################################################################
# Masquerading (aka NAT, PAT, ...)
######################################################################
${IPTABLES} -t nat -A POSTROUTING -o ${OUT_DEV} -j MASQUERADE
######################################################################
----------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------------
2nd possibility (although I would prefer to get the first option working)
Another option I've been looking into is offering dhcp off of the red side. I've managed to get a test system up and running. DHCP is working on the red side; however I can't seem to get the telnet to forward through the firewall. Started out with the default firewall.rules.2nic
green IP 10.3.10.9/255.255.0.0 gw 10.3.1.1
red IP 192.168.1.200/255.255.255.0 (DHCP server)
Telnet server IP 131.107.1.18/255.255.0.0
if I SSH into the DL box from either side, I can telnet to the server. I can't seem to get the forwarding to work properly.
Block-A works--as long as Block-D is commented out (not ideal, since it prevents the red side from dropping some malicious/bad packets).
Block-C works perfectly.
Block-B does not work at all
Here's the changes:
#BLOCK-A############################################################################
#Accept DHCP
${IPTABLES} -A INPUT -i ${OUT_DEV} -p UDP --dport 67:68 -j ACCEPT
${IPTABLES} -A OUTPUT -o ${OUT_DEV} -p UDP --dport 67:68 -j ACCEPT
####################################################################################
# We accept anything from the inside.
${IPTABLES} -A INPUT -i ${INT_DEV} -j ACCEPT
${IPTABLES} -A OUTPUT -o ${INT_DEV} -j ACCEPT
# Allow our firewall to connect.
${IPTABLES} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
${IPTABLES} -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# Allow Ping and friends.
${IPTABLES} -A INPUT -p icmp -j ACCEPT
${IPTABLES} -A OUTPUT -p icmp -j ACCEPT
# Fast reject for Ident to eliminate email delays.
${IPTABLES} -A INPUT -p TCP --dport 113 -i ${OUT_DEV} -j REJECT --reject-with tcp-reset
# Masquerading (aka NAT, PAT, ...)
${IPTABLES} -t nat -A POSTROUTING -o ${OUT_DEV} -j MASQUERADE
#BLOCK-B############################################################################
# Uncomment/modify the next 4 lines to forward a service to an internal IP.
SERVER_IP=131.107.1.18 # Internal IP of server.
PORT=23 # 22 = SSH. Change to 80 for web server, etc.
${IPTABLES} -A PREROUTING -i ${OUT_DEV} -t nat -p TCP --dport $PORT -j DNAT --to ${SERVER_IP}:${PORT}
${IPTABLES} -A FORWARD -p TCP -d ${SERVER_IP} --dport $PORT -i ${OUT_DEV} -o ${INT_DEV} -j ACCEPT
####################################################################################
#BLOCK-C###########################################################################
# Uncomment/modify the next 2 lines to open a port on the internet to Devil Linux.
PORT=22 # 25 = SMTP. Change to the port you wish to open.
${IPTABLES} -A INPUT -p tcp --dport $PORT -i ${OUT_DEV} -j ACCEPT
####################################################################################
#BLOCK-D############################################################################
# Block invalid connections from the internet.
#[ -n "$LOGGING" ] && \
# ${IPTABLES} -A FORWARD -m state --state NEW,INVALID -i ${OUT_DEV} -j LOG --log-prefix "FORWARD INVALID:"
#${IPTABLES} -A FORWARD -m state --state NEW,INVALID -i ${OUT_DEV} -j DROP
####################################################################################
Here's the contents of the iptables -L on the test system.
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp dpts:bootps:bootpc
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
REJECT tcp -- anywhere anywhere tcp dpt:ident reject-with tcp-reset
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT tcp -- anywhere 131.107.1.18 tcp dpt:telnet
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state NEW
Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp dpts:bootps:bootpc
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state NEW,RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
----------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------------
I'd prefer to go with option 1 if it is possible to get it working. We have a wireless network that can't be secured (due to the handheld barcode scanners and their limitations).
thanks,
>
> Message: 3
> Date: Thu, 19 Apr 2007 18:22:30 +0000
> From: ne...@co...
> Subject: Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11,
> Issue 2
> To: dev...@li...
> Message-ID:
>
> <041...@co...>
>
>
> There really is no reason to NAT.
>
> The way this box was intended to operate is as follows:
> 1)DHCP the clients (192.168.0.x)
> 2)Don't allow anything but telnet to a specific server (no dns etc...)
> 3)Do not trust the clients.
>
> In a lot of ways the firewall is backwards. Since we have embedded telnet
> clients (that can't be any smarter than they already are) we needed a way to
> lock down our wireless without interfering with the normal operation of the
> business.
>
> I trust the network on the red side, but can't trust the wireless clients. I'm
> not sure if it would help, but I have the freedom to have up to 255 IP's set
> aside on the network (red side). Don't know if it would help to have the red
> interface have multiple IP's etc...
>
> Aside from not being an expert on this, I have no reason to stick with NAT. I'd
> be fine with modifying the config, but wouldn't know how to adjust it on my own.
> Here's the relevant parts of the rules file. Would it be as simple as dropping
> the DNAT and nat portions from the rules?
>
> ######################################################################
> #accept DHCP
> ${IPTABLES} -A INPUT -p UDP -i eth1 --dport 67:68 -j ACCEPT
> ${IPTABLES} -A OUTPUT -p UDP -o eth1 --dport 67:68 -j ACCEPT
>
> #translate to our network
> ${IPTABLES} -A PREROUTING -i eth1 -t nat -p TCP -d 10.10.10.18 -j DNAT --to
> $TELNETIP_NM
>
> #allow access to the server
> ${IPTABLES} -A FORWARD -i eth1 -p TCP -o eth0 -d $TELNETIP --dport 23 -j ACCEPT
> ${IPTABLES} -A FORWARD -i eth0 -p TCP -o eth1 -s $TELNETIP -m state --state
> ESTABLISHED,RELATED --sport 23 -j ACCEPT
>
> #drop UDP packets
> ${IPTABLES} -A FORWARD -p UDP --dport 1: -j DROP
> ${IPTABLES} -A INPUT -p TCP -i eth1 --dport :21 -j DROP
> #${IPTABLES} -A INPUT -p TCP -i eth1 --dport 24:66 -j DROP
> #${IPTABLES} -A INPUT -p TCP -i eth1 --dport 69: -j DROP
> ${IPTABLES} -A INPUT -p TCP -i eth1 --dport 24: -j DROP
>
> #allow ping from WAN side only
> ${IPTABLES} -A INPUT -s $OUR_NW -p icmp -j ACCEPT
> ${IPTABLES} -A OUTPUT -s $OUR_NW -p icmp -j ACCEPT
> ${IPTABLES} -A FORWARD -p icmp -j DROP
> ${IPTABLES} -A OUTPUT -p icmp -j DROP
>
> ######################################################################
>
> # Masquerading (aka NAT, PAT, ...)
> ######################################################################
> #${IPTABLES} -t nat -A POSTROUTING -o ${OUT_DEV} -j MASQUERADE
> ######################################################################
>
> -joseph
> -------------- Original message ----------------------
> From: dev...@li...
> > Send Devil-linux-discuss mailing list submissions to
> > dev...@li...
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
> > or, via email, send a message with subject or body 'help' to
> > dev...@li...
> >
> > You can reach the person managing the list at
> > dev...@li...
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Devil-linux-discuss digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: Devil-linux-discuss Digest, Vol 11, Issue 1
> > (ne...@co...)
> > 2. Re: Devil-linux-discuss Digest, Vol 11, Issue 1 (Heiko Zuerker)
> > 3. Re: Devil-linux-discuss Digest, Vol 11, Issue 1 (Fred Frigerio)
> > 4. Re: ADSL not connecting - more details (David Nicol?s Abdala)
> > 5. Re: ADSL not connecting - more details (Heiko Zuerker)
> > 6. need of tcptraceroute on devil (Philippe Weill)
> > 7. Fwd: openvpn tun problem (Jozsef Valkai)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Thu, 05 Apr 2007 19:19:33 +0000
> > From: ne...@co...
> > Subject: Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11,
> > Issue 1
> > To: dev...@li...
> > Message-ID:
> >
> >
> <040...@co...>
> >
> >
> > Heiko, thank you for your quick reply.
> >
> > > What do you mean exactly with swapping sessions?
> > >I'm currently failing to understand where the DL box comes into play
> > >(except for the firewalling).
> >
> > Swapping sessions:
> > Each user logs into the telnet-based app.
> > When they log in, they get specific menu options based on their logon.
> > When one handheld "steals" a session, someone can power up a scanner and be
> > logged in as someone else--or be logged in as someone else who might have been
> > in the middle of an inventory transaction. A good example of this might be
> > where one person was adding to an outbound shipment at the same time someone
> > else was receiving product. Without warning the receiver's scanner was using
> > the shipper's session. That really messes up the transactions and can take a
> > while to solve.
> >
> >
> > The DL box:
> > This is how we are controlling the access to the network. When we put the DL
> > box in, the dozen or so clients connecting to the telnet server all seem to be
> > coming from the same IP (the DL box). Before the DL box, each of the scanners
> > had their own IP that could be seen by the telnet server. This means that it
> > could restore a session if there was a disruption in our T1.
> >
> > Basically I'm looking for suggestions on how to keep the DL box in use without
> > (or at least minimizing) the problems with the telnet clients. The DL box has
> > prevented a number of people from hopping onto our wireless network and I'd
> like
> > to keep it.
> >
> > -joseph
> >
> >
> > >
> > > Message: 9
> > > Date: Thu, 05 Apr 2007 18:49:45 +0000
> > > From: ne...@co...
> > > Subject: [Devil-Linux-discuss] Telnet clients swapping sessions
> > > To: dev...@li...
> > > Message-ID:
> > >
> > >
> <040...@co...>
> > >
> > >
> > > Good Day everyone,
> > >
> > > I've set up a DL (1.2) server that controls wireless access to our LAN. It
> > runs
> > > on a via c3 system.
> > >
> > > The only purpose for the wireless is to allow handheld barcode scanners
> (less
> > > than a dozen embedded DOS telnet clients) to connect to one of our servers.
> We
> > > set the firewall rules to only allow for specific telnet traffic and dhcp
> > > requests.
> > >
> > > All went fairly well for a couple of weeks. Then we noticed that the
> embedded
> > > clients were swapping/stealing sessions. Sometimes it would happen when
> > there
> > > was a glitch in our T1 etc...
> > >
> > > Lately, things have gotten worse. The handheld scanners are doing this
> > several
> > > times a day. When one is powered on, for example, it sometimes steals the
> > > session from another handheld. This is a problem as users have different
> > > permissions in the inventory software.
> > >
> > > If at all possible, the clients need to DHCP, and we need to keep the access
> > as
> > > tight as is possible. Just going through the logs, I can see a dozen or two
> > > foiled attempts to hop onto our network.
> > >
> > >
> > > I'll gladly provide more info since I don't know what info would help.
> > >
> > >
> > >
> > >
> > > ------------------------------
> > >
> > > Message: 10
> > > Date: Thu, 5 Apr 2007 14:01:25 -0500 (CDT)
> > > From: "Heiko Zuerker" <he...@zu...>
> > > Subject: Re: [Devil-Linux-discuss] Telnet clients swapping sessions
> > > To: dev...@li...
> > > Message-ID:
> > > <295...@ga...>
> > > Content-Type: text/plain;charset=iso-8859-1
> > >
> > >
> > > On Thu, April 5, 2007 13:49, ne...@co... wrote:
> > > > Good Day everyone,
> > > >
> > > >
> > > > I've set up a DL (1.2) server that controls wireless access to our LAN.
> > > > It runs on a via c3 system.
> > > >
> > > >
> > > > The only purpose for the wireless is to allow handheld barcode scanners
> > > > (less than a dozen embedded DOS telnet clients) to connect to one of our
> > > > servers. We set the firewall rules to only allow for specific telnet
> > > > traffic and dhcp requests.
> > > >
> > > > All went fairly well for a couple of weeks. Then we noticed that the
> > > > embedded clients were swapping/stealing sessions. Sometimes it would
> > > > happen when there was a glitch in our T1 etc...
> > > >
> > > > Lately, things have gotten worse. The handheld scanners are doing this
> > > > several times a day. When one is powered on, for example, it sometimes
> > > > steals the session from another handheld. This is a problem as users
> > > > have different permissions in the inventory software.
> > > >
> > > > If at all possible, the clients need to DHCP, and we need to keep the
> > > > access as tight as is possible. Just going through the logs, I can see a
> > > > dozen or two foiled attempts to hop onto our network.
> > > >
> > > >
> > > > I'll gladly provide more info since I don't know what info would help.
> > >
> > > What do you mean exactly with swapping sessions?
> > > I'm currently failing to understand where the DL box comes into play
> > > (except for the firewalling).
> > >
> > > --
> > >
> > > Regards
> > > Heiko Zuerker
> > > http://www.devil-linux.org
> > ------------------------------
> >
> > Message: 2
> > Date: Thu, 5 Apr 2007 14:24:43 -0500 (CDT)
> > From: "Heiko Zuerker" <he...@zu...>
> > Subject: Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11,
> > Issue 1
> > To: dev...@li...
> > Message-ID:
> > <272...@ga...>
> > Content-Type: text/plain;charset=iso-8859-1
> >
> >
> > On Thu, April 5, 2007 14:19, ne...@co... wrote:
> > > Heiko, thank you for your quick reply.
> > >
> > >
> > >> What do you mean exactly with swapping sessions?
> > >> I'm currently failing to understand where the DL box comes into play
> > >> (except for the firewalling).
> > >>
> > >
> > > Swapping sessions:
> > > Each user logs into the telnet-based app.
> > > When they log in, they get specific menu options based on their logon.
> > > When one handheld "steals" a session, someone can power up a scanner and
> > > be logged in as someone else--or be logged in as someone else who might
> > > have been in the middle of an inventory transaction. A good example of
> > > this might be where one person was adding to an outbound shipment at the
> > > same time someone else was receiving product. Without warning the
> > > receiver's scanner was using the shipper's session. That really messes
> > > up the transactions and can take a while to solve.
> > >
> > >
> > > The DL box:
> > > This is how we are controlling the access to the network. When we put the
> > > DL box in, the dozen or so clients connecting to the telnet server all
> > > seem to be coming from the same IP (the DL box). Before the DL box, each
> > > of the scanners had their own IP that could be seen by the telnet server.
> > > This means that it could restore a session if there was a disruption in
> > > our T1.
> > >
> > > Basically I'm looking for suggestions on how to keep the DL box in use
> > > without (or at least minimizing) the problems with the telnet clients.
> > > The DL box has prevented a number of people from hopping onto our
> > > wireless network and I'd like to keep it.
> >
> > OK so you're currently hiding all the scanners behind a NAT right now.
> > Would it be possible for you to 'officially' route the IPs from the
> > scanners, without the NAT?
> >
> > --
> >
> > Regards
> > Heiko Zuerker
> > http://www.devil-linux.org
> >
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Thu, 5 Apr 2007 15:30:25 -0400
> > From: "Fred Frigerio" <ffr...@lo...>
> > Subject: Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11,
> > Issue 1
> > To: <dev...@li...>
> > Message-ID:
> > <CB8...@wi...>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > It may sound obvious but you can DHCP and route one of the non-internet
> > routable networks. Either 192.168.x.x/24 or even partition 10.x.x.x./8
> > into many /24 You can even superpose that IP network on another but then
> > you would have to assign the IP's to a given MAC address on the DHCP
> > server so you don't disturb your normal network. Another option is go
> > the vlan way which is probably cleaner but may need an upgrade of the
> > switches.
> >
> > What is the reason to do NAT?
> >
> >
> > Fred Frigerio
> > Locust USA
> >
> > This electronic message transmission contains information from Locust
> > USA which may be confidential or privileged. The information is
> > intended to be for the use of the individual or entity named above. If
> > you are not the intended recipient, be aware that any disclosure,
> > copying, distribution or use of the contents of this information is
> > prohibited. If you have received this electronic transmission in error,
> > please notify us by telephone (305-889-5410) or by reply via electronic
> > mail immediately.
> >
> > -----Original Message-----
> > From: dev...@li...
> > [mailto:dev...@li...] On Behalf Of
> > Heiko Zuerker
> > Sent: Thursday, April 05, 2007 3:25 PM
> > To: dev...@li...
> > Subject: Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11,
> > Issue 1
> >
> >
> > On Thu, April 5, 2007 14:19, ne...@co... wrote:
> > > Heiko, thank you for your quick reply.
> > >
> > >
> > >> What do you mean exactly with swapping sessions?
> > >> I'm currently failing to understand where the DL box comes into play
> > >> (except for the firewalling).
> > >>
> > >
> > > Swapping sessions:
> > > Each user logs into the telnet-based app.
> > > When they log in, they get specific menu options based on their logon.
> > > When one handheld "steals" a session, someone can power up a scanner
> > > and be logged in as someone else--or be logged in as someone else who
> > > might have been in the middle of an inventory transaction. A good
> > > example of this might be where one person was adding to an outbound
> > > shipment at the same time someone else was receiving product. Without
> >
> > > warning the receiver's scanner was using the shipper's session. That
> > > really messes up the transactions and can take a while to solve.
> > >
> > >
> > > The DL box:
> > > This is how we are controlling the access to the network. When we put
> >
> > > the DL box in, the dozen or so clients connecting to the telnet server
> >
> > > all seem to be coming from the same IP (the DL box). Before the DL
> > > box, each of the scanners had their own IP that could be seen by the
> > telnet server.
> > > This means that it could restore a session if there was a disruption
> > > in our T1.
> > >
> > > Basically I'm looking for suggestions on how to keep the DL box in use
> >
> > > without (or at least minimizing) the problems with the telnet clients.
> > > The DL box has prevented a number of people from hopping onto our
> > > wireless network and I'd like to keep it.
> >
> > OK so you're currently hiding all the scanners behind a NAT right now.
> > Would it be possible for you to 'officially' route the IPs from the
> > scanners, without the NAT?
> >
> > --
> >
> > Regards
> > Heiko Zuerker
> > http://www.devil-linux.org
|
