LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 04-28-2006, 07:49 AM   #1
LarryFrigginWachs
Member
 
Registered: Dec 2005
Posts: 31

Rep: Reputation: 15
SAMBA Hacked! and now I face a catch 22


Brothers and Sisters-

I am relatively new to Linux, so forgive the ignorance please:
My samba server has been pristine for about a year now- until I started using the same machine as a webserver (I had to keep smba running also- long story)- anyhow I have noticed now an epidemic of weird entries in my samba logs- machines with strange names that are not on our network. Also foreign IP addresses. chkrootkit shows no infection.
I'd like to know what my next step should be. Even if I rebuild and start over though, I can't firewall samba (it is a known issue that all firewalls have to be off [IPtables- F] in order for the windows machines to browse the samba share. It seems like a catch-22 to me.

Thank very kindly.
LFW
 
Old 04-28-2006, 08:27 AM   #2
uselpa
Senior Member
 
Registered: Oct 2004
Location: Luxemburg
Distribution: Slackware, OS X
Posts: 1,507

Rep: Reputation: 47
My Samba server has firewall rules and the Windows machines browse the shares just fine, so that should not be an obstacle at all. I have never heard about this "known issue" before.

What are these entries in the logs - what makes you think that they indicate a problem? Can you quote some?
 
Old 04-28-2006, 08:33 AM   #3
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,417
Blog Entries: 55

Rep: Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622
What you're looking for should amount to anything close to a post-compromise checlkist. Steps to take:
- Make sure control over the machine is yours. This means you must make sure there are no accounts added, no logins in progress and no processes running that are considered foreign, hostile or threathening to the box and your LAN. Examine your passwd and group files. Use "who" to see who's there now, "last" to see who is/was there at what time. List processes and use "ps -u username" to check per-user processes and lsof for a more detailed process view. Kill "unwanted" processes and make sure those users are denied access.
- Stabilise situation. Stop services until you know where the problem is and how to secure and restrict access. Restrict inbound network access to those locations you know are OK. Firewall everything else to log and deny.
- Assess damage: I have noticed now an epidemic of weird entries in my samba logs- machines with strange names that are not on our network. Also foreign IP addresses. Post some relevant some log lines please as well as any info from the steps above, as well as more detailed info on how your network is set up, network info (so anyone can help you properly firewall the place *and* have SMB working), service info (configs, for hardening purposes).
 
Old 04-28-2006, 08:37 AM   #4
ledow
Member
 
Registered: Apr 2005
Location: UK
Distribution: Slackware 13.0
Posts: 241

Rep: Reputation: 34
Oh dear God.

Quote:
Originally Posted by LarryFrigginWachs
I started using the same machine as a webserver (I had to keep smba running also- long story)"
There's nothing too wrong with this but you MUST (absolutely MUST) ensure that people from the internet side cannot access samba (or anything else for that matter).

Quote:
Originally Posted by LarryFrigginWachs
- anyhow I have noticed now an epidemic of weird entries in my samba logs- machines with strange names that are not on our network. Also foreign IP addresses.
Panic. Panic now. People on the internet side of your computer can see/access/read/write your samba shares with ease. TURN OFF SAMBA until you can firewall it properly. Most likely there are LOTS of other ports open on your machine also dangerously exposed to anyone who cares look.

Quote:
Originally Posted by LarryFrigginWachs
I'd like to know what my next step should be. Even if I rebuild and start over though, I can't firewall samba (it is a known issue that all firewalls have to be off [IPtables- F] in order for the windows machines to browse the samba share. It seems like a catch-22 to me.
You CAN firewall without having to turn everything off. I have Samba on an internet-facing machine and can browse it perfectly well from the local net. If it wasn't possible, half the computers in the world would be comprised.

A firewall has many parts, usually one setting for INTERNAL access (i.e. your local network) and one for EXTERNAL (i.e. anybody who happens to be on the Internet and sees your computer). You want your internal network to have "full" access, the external network to have NOTHING (except possibly your www server?).

Visit www.grc.com from this machine and access their ShieldsUp test - anything that website says it can see, anyone on the internet can see. If it says NetBIOS ports, anyone can browse your samba shares and (depending on your setup) write to them.

- IMMEDIATELY turn off Samba.
- Install a REAL firewall and set it up (depends on your distribution - I use ProjectFiles.com rc.firewall on Slackware, yours will vary depending on what you use).
- DO NOT put the machine back on the Internet until the grc.com test shows all closed/stealth for every port (except for those you want EVERYONE on the Internet to see).

This is a serious problem and you should not be on the Internet if you have Samba ports open. This is really not negotiable and I'm surprised your ISP hasn't already blocked your account (many of the ISP's I have seen in the past will warn you and block your account if you do not fix this exact problem).

You need to configure a proper firewall IMMEDIATELY and not turn samba back on until it's properly configured. If you do not know how to do this, get someone to do it for you. If you can't get someone to do it for you, do not use it online.

This is not just bashing - this is a serious problem. chkrootkit only shows you SOME entries that SOME people who are "hacking" your computer might use to get full access. Chances are, with this poor configuration, anyone automatically has full access to your machines/network anyway.

Last edited by ledow; 04-28-2006 at 08:39 AM.
 
Old 04-29-2006, 05:54 PM   #5
LarryFrigginWachs
Member
 
Registered: Dec 2005
Posts: 31

Original Poster
Rep: Reputation: 15
Ledow: You can bash me. I deserve it for being an idiot.
Thanks all for your very helpful replies. I have a related question: would this have anything to do with my 3 samba machines freezing up every few hours to days (requiring hard re-boot)? This is what originally got me poking in the logs. I posted a question about the freezing under the newbie forum (before I found out about the hack). I havent really gotten much feedback from that post, so I am only asking here if it is likely hack related (if not I will pursue it in the appropriate forum). These are log excerpts from the three (as you can see, ending with re-start).
I hope this is not considered cross-posting. I would never be discourteous to this great community.

There should have been no one on the network during the times these logs were recorded.
Apr 25 19:17:17 localhost smbd[5976]: write_socket: Error writing 4
bytes to socket 5: ERRNO = Connection reset by peer
Apr 25 19:17:25 localhost smbd[5874]: [2006/04/25 19:17:25, 0]
lib/util_sock.c:send_smb(647)
Apr 25 19:17:29 localhost smbd[5976]: [2006/04/25 19:17:29, 0]
lib/util_sock.c:send_smb(647)
Apr 25 19:17:33 localhost smbd[5874]: Error writing 4 bytes to client.
-1. (Connection reset by peer)
Apr 25 19:17:38 localhost smbd[5976]: Error writing 4 bytes to client.
-1. (Connection reset by peer)
Apr 25 19:26:35 localhost smbd[6286]: [2006/04/25 19:26:35, 0]
lib/util_sock.c:write_socket_data(430)
Apr 25 19:26:35 localhost smbd[6286]: write_socket_data: write
failure. Error = Connection reset by peer
Apr 25 19:26:35 localhost smbd[6286]: [2006/04/25 19:26:35, 0]
lib/util_sock.c:write_socket(455)
Apr 25 19:26:35 localhost smbd[6286]: write_socket: Error writing 4
bytes to socket 5: ERRNO = Connection reset by peer
Apr 25 19:26:35 localhost smbd[6286]: [2006/04/25 19:26:35, 0]
lib/util_sock.c:send_smb(647)
Apr 25 19:26:35 localhost smbd[6286]: Error writing 4 bytes to client.
-1. (Connection reset by peer)
Apr 25 19:41:16 localhost nmbd[2606]: [2006/04/25 19:41:16, 0]
nmbd/nmbd_namequery.c:query_name_response(101)
Apr 25 19:41:16 localhost nmbd[2606]: query_name_response: Multiple
(2) responses received for a query on subnet 192.168.1.116 for name
MYGROUP<1d>.
Apr 25 19:41:16 localhost nmbd[2606]: This response was from IP
192.168.1.118, reporting an IP address of 192.168.1.118.
Apr 25 19:55:59 localhost smbd[6458]: [2006/04/25 19:55:59, 0]
lib/util_sock.c:write_socket_data(430)
Apr 25 19:55:59 localhost smbd[6458]: write_socket_data: write
failure. Error = Connection reset by peer
Apr 25 19:55:59 localhost smbd[6458]: [2006/04/25 19:55:59, 0]
lib/util_sock.c:write_socket(455)
Apr 25 19:55:59 localhost smbd[6458]: write_socket: Error writing 4
bytes to socket 24: ERRNO = Connection reset by peer
Apr 25 19:55:59 localhost smbd[6458]: [2006/04/25 19:55:59, 0]
lib/util_sock.c:send_smb(647)
Apr 25 19:55:59 localhost smbd[6458]: Error writing 4 bytes to client.
-1. (Connection reset by peer)
Apr 25 20:01:19 localhost nmbd[2606]: [2006/04/25 20:01:19, 0]
nmbd/nmbd_namequery.c:query_name_response(101)
Apr 25 20:01:19 localhost nmbd[2606]: query_name_response: Multiple
(2) responses received for a query on subnet 192.168.1.116 for name
MYGROUP<1d>.
Apr 25 20:01:19 localhost nmbd[2606]: This response was from IP
192.168.1.118, reporting an IP address of 192.168.1.118.
Apr 26 08:33:46 localhost syslogd 1.4.1: restart


Apr 25 21:20:21 localhost smbd[5612]: process_local_message:
unsolicited oplock break reply from pid 5612, port 32796, dev = fd00,
inode = 1966087, file_id = 7
Apr 25 21:20:21 localhost smbd[5613]: [2006/04/25 21:20:21, 0]
lib/util_sock.c:send_smb(647)
Apr 25 21:20:34 localhost smbd[5613]: Error writing 107 bytes to
client. -1. (Broken pipe)
Apr 25 21:20:34 localhost smbd[5613]: [2006/04/25 21:20:34, 0]
smbd/oplock.crocess_local_message(420)
Apr 25 21:20:38 localhost smbd[5613]: process_local_message: Received
unsolicited break reply - dumping info.
Apr 25 21:20:38 localhost smbd[5613]: [2006/04/25 21:20:38, 0]
smbd/oplock.crocess_local_message(435)
Apr 25 21:20:38 localhost smbd[5613]: process_local_message:
unsolicited oplock break reply from pid 5613, port 32796, dev = fd00,
inode = 1966087, file_id = 7
Apr 25 21:36:58 localhost nmbd[2451]: [2006/04/25 21:36:58, 0]
nmbd/nmbd_namequery.c:query_name_response(101)
Apr 25 21:36:58 localhost nmbd[2451]: query_name_response: Multiple
(2) responses received for a query on subnet 192.168.1.200 for name
MYGROUP<1d>.
Apr 25 21:36:58 localhost nmbd[2451]: This response was from IP
192.168.1.118, reporting an IP address of 192.168.1.118.
Apr 26 08:37:48 localhost syslogd 1.4.1: restart




> Apr 25 22:08:17 www smbd[4980]: write_socket_data: write failure.
> Error = Connection reset by peer
> Apr 25 22:08:17 www smbd[4980]: [2006/04/25 22:08:17, 0]
> lib/util_sock.c:write_socket(455)
> Apr 25 22:08:17 www smbd[4980]: write_socket: Error writing 4 bytes to
> socket 5: ERRNO = Connection reset by peer
> Apr 25 22:08:17 www smbd[4980]: [2006/04/25 22:08:17, 0]
> lib/util_sock.c:send_smb(647)
> Apr 25 22:08:17 www smbd[4980]: Error writing 4 bytes to client. -1.
> (Connection reset by peer)
> Apr 25 22:40:31 www smbd[4987]: [2006/04/25 22:40:31, 0]
> lib/util_sock.c:get_peer_addr(1000)
> Apr 25 22:40:31 www smbd[4987]: getpeername failed. Error was
> Transport endpoint is not connected
> Apr 25 22:40:31 www smbd[4987]: [2006/04/25 22:40:31, 0]
> lib/util_sock.c:get_peer_addr(1000)
> Apr 25 22:40:31 www smbd[4987]: getpeername failed. Error was
> Transport endpoint is not connected
> Apr 25 22:40:31 www smbd[4987]: [2006/04/25 22:40:31, 0]
> lib/util_sock.c:write_socket_data(430)
> Apr 25 22:40:31 www smbd[4987]: write_socket_data: write failure.
> Error = Connection reset by peer
> Apr 25 22:40:31 www smbd[4987]: [2006/04/25 22:40:31, 0]
> lib/util_sock.c:write_socket(455)
> Apr 25 22:40:31 www smbd[4987]: write_socket: Error writing 4 bytes to
> socket 23: ERRNO = Connection reset by peer
> Apr 25 22:40:31 www smbd[4987]: [2006/04/25 22:40:31, 0]
> lib/util_sock.c:send_smb(647)
> Apr 25 22:40:31 www smbd[4987]: Error writing 4 bytes to client. -1.
> (Connection reset by peer)
> Apr 25 23:01:03 www crond(pam_unix)[4989]: session opened for user root
> by (uid=0)
> Apr 25 23:01:03 www crond(pam_unix)[4989]: session closed for user root
> Apr 25 23:13:37 www shutdown: shutting down for system halt
> Apr 25 23:13:37 www init: Switching to runlevel: 0
> Apr 26 08:36:38 www syslogd 1.4.1: restar

Last edited by LarryFrigginWachs; 04-29-2006 at 05:55 PM.
 
Old 05-02-2006, 05:36 AM   #6
pjcp64
Member
 
Registered: Dec 2002
Location: Omaha, NE
Distribution: Ubuntu Server and SuSE
Posts: 69

Rep: Reputation: 15
Larry,

I'm not an expert at reading Samba Logs, but when I successfully connect my logs look like this.

xp01 (x.x.x.x) connect to service ghm initially as user tharrison (uid=1002, gid=1001) (pid 31670)
[2006/05/02 04:27:00, 1] smbd/service.c:close_cnum(830)
xp01 (x.x.x.x) closed connection to service ghm

I'm wondering if all those log entries are simply "Windows Noise". Maybe somebody can validate that those log entries look particularly threatening.

However, as others have mentioned, you definitely need to firewall your Samba service. Here's mine. I've removed most of my VPN firewall information but I left the pertinent Samba rules. I've basically got two sets in there, one for OpenVPN and one for Hamachi. The two are slightly different ( I had to relax them a little to get Hamachi working ). I would try the OpenVPN section first. You will need to change the "192.168.99.1/24" to whatever is appropriate for your internal network ( 192.168.1.1/24 (?) ).

If this doesn't work, try modifying it to look more like the Hamachi section.

I'll point out that this firewall denies everything and each connection has to be explicitely allowed. I wouldn't simply through this into place since it'll probably "break" whatever else you have running. It's simply for demonstration.

You might also note that the script is setup as an /etc/init.d/ startup job. You can control it with a /etc/init.d/firewall start|stop|restart|status
*** Assuming you save it as /etc/init.d/firewall of course!

If your box reboots at the same time each day, look at your cron log.
It doesn't appear that your box crashed, but that it was given a shutdown command.

Other users: Please feel free to correct me if I've misspoken on anything here, I won't take offense! )

Hopes this helps.

Thom

#!/bin/bash
#^^^^^^^^-------------------------------------- Defines the shell. Never use csh!
#
#=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
# This is the location of the iptables command
IPTABLES="/sbin/iptables"
#---------------------------------------------- Specify any directories needed
PATH='/sbin:/usr/sbin:/bin:/usr/bin'
#=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
# Your script begins here.
#=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
case "$1" in
stop)
echo "Stopping Firewall."
# flush all of the iptables rules.
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD DROP
;;
status)
$IPTABLES -L
;;
restart|reload)
$0 stop
$0 start
;;
start)
echo "Starting Firewall."

################################################################
#Insert modules- should be done automatically if needed
dmesg -n 1 #Kill copyright display on module load
/sbin/modprobe ip_tables
/sbin/modprobe iptable_filter
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_conntrack_ftp
dmesg -n 6
#
## Flush everything, start from scratch
#
# flush all of the iptables rules.
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z
# originally tcp_syncookies and ip_dynaddr were 1
echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo 1 > /proc/sys/net/ipv4/ip_dynaddr
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

#---------- Reduce DoS'ing ability by reducing timeouts
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
echo 0 > /proc/sys/net/ipv4/tcp_sack

#---------- iptables defaults to these if no matches are found below.
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD DROP

##--------- Set basic rules

#----------- Above list ripped from http://www.linux-mag.com/2000-01/bestdefense_02.html

# --- reject invalid SYN,FIN combinations.

$IPTABLES -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
$IPTABLES -A FORWARD -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP

$IPTABLES -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
$IPTABLES -A FORWARD -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP

$IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
$IPTABLES -A FORWARD -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

$IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPTABLES -A FORWARD -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP


# --- allow replies coming in #=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
#Primary Rules Section =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
#=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
# Normal Section #
$IPTABLES -A INPUT -p tcp --dport 3022 -j ACCEPT #ssh
$IPTABLES -A INPUT -p udp --dport 3022 -j ACCEPT

# samba - openvpn
$IPTABLES -A INPUT -p udp -m udp -s 192.168.99.1/24 --dport 137 -j ACCEPT
$IPTABLES -A INPUT -p udp -m udp -s 192.168.99.1/24 --dport 138 -j ACCEPT
$IPTABLES -A INPUT -m state --state NEW -m tcp -p tcp -s 192.168.99.1/24 --dport 139 -j ACCEPT
$IPTABLES -A INPUT -m state --state NEW -m tcp -p tcp -s 192.168.99.1/24 --dport 445 -j ACCEPT

# samba - hamachi
$IPTABLES -A INPUT -p udp -m udp -s 5.1.2.3/24 --dport 137 -j ACCEPT
$IPTABLES -A INPUT -p udp -m udp -s 5.1.2.3/24 --dport 138 -j ACCEPT
$IPTABLES -A INPUT -p tcp -m tcp -s 5.1.2.3/24 --dport 139 -j ACCEPT
$IPTABLES -A INPUT -p tcp -m tcp -s 5.1.2.3/24 --dport 445 -j ACCEPT

#=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*)
echo "Useage: firewall (start|stop|restart)"
exit 1
esac

exit 0
 
Old 05-02-2006, 05:50 AM   #7
pjcp64
Member
 
Registered: Dec 2002
Location: Omaha, NE
Distribution: Ubuntu Server and SuSE
Posts: 69

Rep: Reputation: 15
Also, you should review security on the other "outward" facing services.

For instance,
Apache ==> mod_security is a huge plus.
ssh ==> modify /etc/init.d/sshd_config for security settings ( also change the port if possible )
ftp ==> Ugh! but if you have to use it, try to lock it down with something like vsftp. However, an ssh solution with something like the FileZilla or WinSCP3 GUIs would be far more secure.
telnet ==> Just say No! Try PuTTY as a Windows Client.

I agree that you should try to use GRC to scan your system.
You should also google for something like "after a hack" and to thoroughly determine whether there has been a compromise. If there has been, the best solution is to rebuild your system after backing it up, but I realize that isn't always possible.

I don't haunt these halls too frequently, so best of luck!

Thom
 
Old 05-02-2006, 07:48 AM   #8
LarryFrigginWachs
Member
 
Registered: Dec 2005
Posts: 31

Original Poster
Rep: Reputation: 15
pj- Thanks very much for the helpful input. Here is where I stand now:
1) I stopped Samba and damn near everything else (except for httpd). It doesnt appear that he got into anything else. At least the my logs are now clean. No more security flags. Also, the box has not frozen since then either (fingers crossed, hope it doesnt).
2) I will eventually have to add back ftp, samba etc, but I want to educate myself first and do it the right way.
3) Do you or anyone know- is it possibl/worthwhile to firewall a webserver? I mean, I don't understand how you could deny foreign IPs if you are trying to serve a public WWW site???? I have Firestarter installed- fooled around with it a bit yesterday, but every time I turn it on the website is, of course, inaccessible.
4) I agree that the logs often show network stuff like this, but if you could see the whole thing- it was scary- many many attempts by foreign ips to become root.

Thanks everyone.
 
Old 05-02-2006, 08:32 AM   #9
benjamin1254
LQ Newbie
 
Registered: Mar 2005
Location: somewhere in NW PA
Distribution: knoppix and slax (havent touched gentoo yet)
Posts: 12

Rep: Reputation: 0
lol im sorry i dont mean to sound crude... but isent the IP 192.***.***.*** pre reserved for localized machines? i dont see as its an outside sorse unless your running an unsecure wifi connection that people are peering through. That could be the case in your issue because when i was searching through your log file you had posted it dident seem like any other IP was aplicable to state that indeed it was an outside source. If i do sound ignorent its just because I took net essentials so i know some basics of networking.
 
Old 05-02-2006, 07:16 PM   #10
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
Quote:
Originally Posted by LarryFrigginWachs
is it possibl/worthwhile to firewall a webserver? I mean, I don't understand how you could deny foreign IPs if you are trying to serve a public WWW site????
yes, it's just a matter of configuring the firewall properly...

the firewall will make sure that people will only be able to connect to the things they should... practically speaking, people on the Internet will only be able to connect to your web server, while NOT being able to connect to anything else on your box... example (for a host-based firewall):
Code:
iptables -F INPUT

iptables -P INPUT DROP

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -p TCP -i $WAN_IFACE --dport 80 \
-m state --state NEW -j ACCEPT

iptables -A INPUT -p TCP -i $WAN_IFACE --dport 443 \
-m state --state NEW -j ACCEPT

iptables -A INPUT -p TCP -i $LAN_IFACE --dport 137:139 \
-m state --state NEW -j ACCEPT

iptables -A INPUT -p UDP -i $LAN_IFACE --dport 137:139 \
-m state --state NEW -j ACCEPT

iptables -A INPUT -p TCP -i $LAN_IFACE --dport 445 \
-m state --state NEW -j ACCEPT
as you can see with this example, packets coming into your external interface (represented by $WAN_IFACE) would only be accepted if they are going into your HTTP/HTTPS server... if someone were to try and connect to your samba (or anything else) from your WAN it wouldn't work... also, there are rules there allowing samba connections to the server as long as they come-in through your LAN interface...

Last edited by win32sux; 05-02-2006 at 07:21 PM.
 
Old 05-02-2006, 08:01 PM   #11
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 11,201
Blog Entries: 4

Rep: Reputation: 4123Reputation: 4123Reputation: 4123Reputation: 4123Reputation: 4123Reputation: 4123Reputation: 4123Reputation: 4123Reputation: 4123Reputation: 4123Reputation: 4123
Browsing through the log-entries that you've posted, I don't see anything that immediately screams to me "hacker!" What I do see are symptoms of a fairly constipated network. That is to say, very possibly a failing hub, or ground-faulted network cabling, or something else which .. yes .. could certainly be contributing to the freeze-ups.

So, before assuming that you've been hacked, bring someone in to do a thorough hardware diagnostic on your internal network and equipment. (They'll have the specialized test equipment needed to do it.) A hub can wink its lights merrily and still be busted!

Sure... it might well be that someone's hacked your machine. But let's try to objectively prove that, first. Unexplained symptoms that suddenly start-up out of nowhere could be a simple hardware fault. Keep that option open in your mind too... (It's reassuring, anyway.)
 
Old 05-03-2006, 06:38 AM   #12
pjcp64
Member
 
Registered: Dec 2002
Location: Omaha, NE
Distribution: Ubuntu Server and SuSE
Posts: 69

Rep: Reputation: 15
All good advise!

As far as Web Security goes. Apache has quite a number of robust security features.

The ones I implement are:

chroot - this "jails" the apache webserver into a subdirectory. This can get a bit complicated to maintain if you have a complex website, but I specifically opted for using nothing but static html so that my life would be easy. ( of course, some websites have to have executable code ). The problem is that if you use perl, php, java, etc... it has to exist in your jailed directory structure as well. That can make things more difficult to upgrade.

mod_security - this supports a lot of good security features, but my favorite is it's ability to prescan a URL for valid characters. For instance, I only allow: a-z A-Z 0-9 : / and _
This prevents many of the web-based hacks involving things like `rm -rf * in the URL.

The reason I went with the paranoid "static jailed" combination for my webpage is because I actually have data on that server that I wouldn't want compromised. If you need to run a full-blown webserver with all the bells and whistles, I'd seriously consider a dedicated server. These bells and whistles constitute a larger number of possible entry/failure points for your webserver and your data would remain on a separate system.

Good Luck.

Thom
 
Old 05-03-2006, 08:41 AM   #13
LarryFrigginWachs
Member
 
Registered: Dec 2005
Posts: 31

Original Poster
Rep: Reputation: 15
Thanks to all

Thanks to all who have taken time to respond!
I agree that on the face of it those samba logs could just reflect ordinary traffic, but the clincher for me was that the times in the log when all this stuff was going were times that NO ONE from my office was on the network. If you could see my samba file- there were hundreds of foreign ips that whois'd back to japan, taiwan, all kinds of hackerdoms.

Also, I agree that 192.168.x.x is LAN stuff, but it looks like he came in through the webserver and then samba'd around from there.


Lastly, what really makes me crazy is that I keep thinking, you know, for a newbie like me computer technology is hard enough on its own, without some jerk adding to it. Its like stealing from a homeless person, like y'know the guys got enough to deal with already.

Thanks again to you all.

Here is also a bit from my security log-




Invalid user guest from 218.1.65.233
Apr 27 21:47:36 localhost sshd[8263]: Failed password for invalid user
guest from 218.1.65.233 port 43803 ssh2
Apr 27 21:47:38 localhost sshd[8266]: Invalid user admin from 218.1.65.233
Apr 27 21:47:41 localhost sshd[8266]: Failed password for invalid user
admin from 218.1.65.233 port 43920 ssh2
Apr 27 21:47:43 localhost sshd[8268]: Invalid user admin from 218.1.65.233
Apr 27 21:47:45 localhost sshd[8268]: Failed password for invalid user
admin from 218.1.65.233 port 44032 ssh2
Apr 27 21:47:48 localhost sshd[8270]: Invalid user user from 218.1.65.233
Apr 27 21:47:50 localhost sshd[8270]: Failed password for invalid user
user from 218.1.65.233 port 44150 ssh2
Apr 27 21:47:54 localhost sshd[8272]: Failed password for root from
218.1.65.233 port 44272 ssh2
Apr 27 21:47:59 localhost sshd[8275]: Failed password for root from
218.1.65.233 port 44392 ssh2
Apr 27 21:48:03 localhost sshd[8277]: Failed password for root from
218.1.65.233 port 44509 ssh2
Apr 27 21:48:06 localhost sshd[8279]: Invalid user test from 218.1.65.233
Apr 27 21:48:08 localhost sshd[8279]: Failed password for invalid user
test from 218.1.65.233 port 44619 ssh2
Apr 28 11:27:12 localhost sshd[2557]: Server listening on :: port 22.
Apr 28 11:27:12 localhost sshd[2557]: error: Bind to port 22 on 0.0.0.0
failed: Address alr

Apr 29 15:38:53 localhost sshd[11313]: Did not receive identification
string from 66.221.91.152
Apr 29 15:39:02 localhost sshd[11315]: Did not receive identification
string from 66.221.91.152
Apr 29 18:30:48 localhost sshd[11961]: Did not receive identification
string from 221.254.183.42
Apr 29 18:31:10 localhost sshd[11964]: Invalid user staff from
221.254.183.42
Apr 29 18:31:18 localhost sshd[11964]: Failed password for invalid user
staff from 221.254.183.42 port 46101 ssh2
May 1 08:36:24 localhost sshd[2551]: Server listening on :: port 22.
May 1 08:36:24 localhost sshd[2551]: error: Bind to port 22 on 0.0.0.0
failed: Address already in use.

Apr 24 13:31:29 localhost sshd[14813]: Did not receive identification
string from 63.245.97.22
Apr 24 16:25:16 localhost sshd[16039]: reverse mapping checking
getaddrinfo for unused226.fibrewired.on.ca failed - POSSIBLE BREAKIN
ATTEMPT!
Apr 24 16:25:18 localhost sshd[16039]: Failed password for root from
66.207.101.226 port 41560 ssh2
Apr 24 16:25:19 localhost sshd[16042]: reverse mapping checking
getaddrinfo for unused226.fibrewired.on.ca failed - POSSIBLE BREAKIN
ATTEMPT!
Apr 24 16:25:21 localhost sshd[16042]: Failed password for root from
66.207.101.226 port 41842 ssh2
Apr 24 16:25:21 localhost sshd[16044]: reverse mapping checking
getaddrinfo for unused226.fibrewired.on.ca failed - POSSIBLE BREAKIN
ATTEMPT!
Apr 24 16:25:24 localhost sshd[16044]: Failed password for root from
66.207.101.226 port 42129 ssh2
Apr 24 16:25:27 localhost sshd[16046]: reverse mapping checking
getaddrinfo for unused226.fibrewired.on.ca failed - POSSIBLE BREAKIN
ATTEMPT!
 
Old 05-04-2006, 08:43 PM   #14
jschiwal
LQ Guru
 
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733

Rep: Reputation: 683Reputation: 683Reputation: 683Reputation: 683Reputation: 683Reputation: 683
Quote:
Apr 27 21:48:03 localhost sshd[8277]: Failed password for root from
218.1.65.233 port 44509 ssh2
Apr 27 21:48:06 localhost sshd[8279]: Invalid user test from 218.1.65.233
You are being subjected to a brute force attack on your ssh service.

Who is allowed to use ssh? Add the users to the "AllowUsers" line in your /etc/ssh/sshd_config file. Also make sure to disable root login.

example:
Code:
PermitRootLogin no
AllowUsers  larryf
This will deny all users except for larryf. The system users will be locked out also. A common technique the hackers use is to try to log in as a system user such as mysql.
If you don't use ssh, disable or uninstall it.

Also, since you are offering a web service on the internet, consider installing a NAT router and forwarding port 80 to the web server.

Ideally, the web server would be between two nat routers in the DMZ and the samba server would be on a different machine inside the network.

Last edited by jschiwal; 05-04-2006 at 08:58 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
face to face, man to man dazzler Linux - General 1 07-27-2004 06:27 AM
New Face rinard General 11 01-11-2004 10:23 AM
face in rh installation dave bean Linux - General 3 10-27-2003 02:22 PM
How we face Longhorn? jin.liu General 28 10-25-2003 05:28 PM
face to face in Malaysia ... Penang thomassounness Linux - Newbie 3 06-29-2003 06:09 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 01:23 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration