- This topic is empty.
-
Posts
-
Our company has a ZeroShell box installed at a client’s location. We have it load balancing across a cable connection and a DSL connection that our company provides. Recently, we found that our client’s server has been hacked. We’re trying to determine where the source of the attack came from. Our DSL connection only allows return traffic for internet facing services the the client’s server needs (HTTP and email), and it provides NAT translations for client’s internet connections if the cable goes down. While troubleshooting this issue, we noticed that when you go into a run box (not on the client’s network) and type in \
we get a prompt for a certificate that was issued by “Impresys”. We then get prompted for a username and password. We don’t know what is prompting us. The only virtual server port we have forwarded for the cable connection is TCP/5900 so we can VNC into the server when the DSL connection goes down. Is this the ZeroShell box prompting us for the username/password?[/img] I don’t think the promt has to do with ZS. Usually the “\ipaddress” is used for Samba shares. Do you have such a thing on the ZS?
The server can be hacked in many ways, that overcome the existance of a firewall. Since you allowed the http on the firewall then they might have attacked you with a malicious http packet, which could only be caught with an IDS.Thanks for the reply. What do you mean by allowing in HTTP and how do we check for samba connections?
You said it
Our DSL connection only allows return traffic for internet facing services the the client’s server needs (HTTP and email)
So you were allowing HTTP traffic in.
Ask your administrator to check for samba running on the server.
I was just telling you how we have our ZeroShell boxes set up. In the balance rules we have all port 80 and 443 traffic from the client’s LAN go out the cable connection then we have all of the server’s traffic going out my company’s WAN connection (either T1 or DSL) because we provide Static One-to-One NAT translations for the client’s servers. This is set up for all clients. This particular client is not hosting a website so we don’t have port 80 traffic directed towards it from our WAN connection. We suspect a hacker came in through the Cable connection but while troubleshooting we noticed that when we put in \ we get prompted to accept a certificate then we get prompted for a username and password. The Virtual Server portion of the ZeroShell only forwards TCP/5900 to the client’s server over the cable connection to allow my company to access the client’s server through VNC only in the event that one of our WAN lines (T1 or DSL) go down. if the T1 or DSL connection is up, we are not able to access the server through VNC over the cable connection. I hope that clears up any confusion and thanks for your time.
I think it would be easier to draw a picture of the server, the ZS, the internet lines and the client PC doing all the troubleshooting. Also a screenshot of the firewall and Virtual Server rules.
Here is a diagram of our topology:
Here is a screenshot of the Virtual Server config:
Here is a screenshot of our Balance Rules:
All traffic with port 80 or 443 goes out the Cable connection. Then we have all traffic for the server going out our WAN connection. Then we have all other traffic from the workstations go out the Cable connection.ETH00 is the LAN Adapter. IP address 10.49.1.1.
ETH01 is the Cable Adapter. IP Address id Dynamic.
ETH02 is the WAN Adapter to our Network. IP Address is 10.104.117.2.We currently have no Firewall rules in place. It is just set to the default which is enabled but no rules specified. Would you like to me to configure the firewall rules and make a screenshot of that also?
The \public-ip would be the dynamic public IP that the ZeroShell box gets from the cable connection.
root@zeroshell root> netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:389 0.0.0.0:* LISTEN 1637/slapd
tcp 0 0 0.0.0.0:749 0.0.0.0:* LISTEN 5689/kadmind
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 5699/httpd
tcp 0 0 24.105.134.125:53 0.0.0.0:* LISTEN 1710/named
tcp 0 0 192.168.142.142:53 0.0.0.0:* LISTEN 1710/named
tcp 0 0 192.168.250.254:53 0.0.0.0:* LISTEN 1710/named
tcp 0 0 10.104.49.2:53 0.0.0.0:* LISTEN 1710/named
tcp 0 0 10.49.1.1:53 0.0.0.0:* LISTEN 1710/named
tcp 0 0 192.168.141.142:53 0.0.0.0:* LISTEN 1710/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 1710/named
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 5714/sshd
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 1710/named
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 5699/httpd
tcp 0 0 127.0.0.1:33187 127.0.0.1:389 ESTABLISHED 1710/named
tcp 0 52 10.49.1.1:22 10.102.1.58:53293 ESTABLISHED 28757/0
tcp 0 0 127.0.0.1:389 127.0.0.1:33187 ESTABLISHED 1637/slapd
udp 0 0 24.105.134.125:53 0.0.0.0:* 1710/named
udp 0 0 192.168.142.142:53 0.0.0.0:* 1710/named
udp 0 0 192.168.250.254:53 0.0.0.0:* 1710/named
udp 0 0 10.104.49.2:53 0.0.0.0:* 1710/named
udp 0 0 10.49.1.1:53 0.0.0.0:* 1710/named
udp 0 0 192.168.141.142:53 0.0.0.0:* 1710/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 1710/named
udp 0 0 0.0.0.0:68 0.0.0.0:* 17213/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 16338/dhclient
udp 0 0 0.0.0.0:464 0.0.0.0:* 5689/kadmind
udp 0 0 192.168.142.142:88 0.0.0.0:* 5683/krb5kdc
udp 0 0 192.168.250.254:88 0.0.0.0:* 5683/krb5kdc
udp 0 0 10.104.49.2:88 0.0.0.0:* 5683/krb5kdc
udp 0 0 10.49.1.1:88 0.0.0.0:* 5683/krb5kdc
udp 0 0 192.168.142.142:750 0.0.0.0:* 5683/krb5kdc
udp 0 0 192.168.250.254:750 0.0.0.0:* 5683/krb5kdc
udp 0 0 10.104.49.2:750 0.0.0.0:* 5683/krb5kdc
udp 0 0 10.49.1.1:750 0.0.0.0:* 5683/krb5kdc
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ] DGRAM 191 935/udevd @/org/kernel/udev/udevd
unix 9 [ ] DGRAM 1822 1735/syslogd /dev/log
unix 2 [ ] DGRAM 6837019 17213/dhclient
unix 2 [ ] DGRAM 17645 16338/dhclient
unix 2 [ ] DGRAM 6260 5785/cron
unix 2 [ ] DGRAM 5944 5689/kadmind
unix 2 [ ] DGRAM 5914 5683/krb5kdc
unix 2 [ ] DGRAM 4385 1710/named
unix 2 [ ] DGRAM 1859 1743/klogd
root@zeroshell root>Does the cable modem have an IP of its own? Or is it working in bridge mode, thus only the ZS interface has an IP from your provider?
What is the firewall blocking? Could you show us a screenshot?
Also, where is the PC that you are doing the troubleshooting? Inside your LAN or outside?The cable modem does not have a public IP address of it’s own. They have 10.x.x.x addresses on the Cable ISP’s private network. Only the ZS interface has an IP from the Cable ISP. The firewall is enabled with no rules specified by default. I can show you a screenshot but it looks exactly how every other ZS box looks after being booted up for the first time.
The PC that we type \public IP of Cable connection is outside of our network completely. It is on a computer at someones house using a completely different internet connection.
- You must be logged in to reply to this topic.