|
|
| Jam One |
| Posted: Mar 14 2012, 05:37 PM |
 |
|
Advanced Member
Group: Members
Posts: 580
Member No.: 25518
Joined: 8-May 09
|
| QUOTE (rjisinspired @ Mar 14 2012, 12:39 PM) | | If anyone has any firewall recommendations I'm open to suggestions. ... |
Just a thought of the moment -- a hardware firewall.
That is, a router.
A Wi-Fi router with built-in firewall. |
|
| evropej |
| Posted: Mar 14 2012, 07:55 PM |
|
|
Advanced Member
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09
|
Get a good router such as wrt54gl and install the third party firmware to make it a super firewall. |
|
| dloneranger |
| Posted: Mar 14 2012, 08:33 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
Routers are good inbound firewalls, they hardly ever do outbound firewalling though, which is his issue
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| IanB |
| Posted: Mar 14 2012, 09:24 PM |
|
|
Avisynth Team Member
Group: Members
Posts: 121
Member No.: 22295
Joined: 23-October 07
|
Your PC is being probed from outside with connects to TCP port 23 (SYN packets).
According to the the TCP standard, if a host has no ready listeners (telnetd in this case) the kernel is supposed to send a RST packet to say Connection Refused. This is what your firewall is bitching about. If you were running the telnet service (telnetd) then the firewall should winge about telnetd answering the connect instead of the kernel (system).
Your firewall should be blocking all stray incoming connections, you probably have accidentally added a rule to allow this. Check your rules carefully.
Windows PC's should really not be directly connected to the internet. Get yourself a NAT firewall router. If you have one already check the config for Port Forwarding and make sure there are no NAT rules that you do not explicitly want. Never use the wild card rule, which forwards all unspecified connects to a default host. |
|
| evropej |
| Posted: Mar 14 2012, 09:26 PM |
|
|
Advanced Member
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09
|
PS most virus programs these days cannot be detected. Create a good image restore system such as Acronis. Do not fool yourself into thinking that any virus program will successfully detect a root kit which runs at the kernel level.
Backup your data, reinstall windows. Create an image for a blank install of windows. Install applications and settings all offline. Create backup image on a separate drive of a full installation. Once you are backed up with a blank and full image, then go online a patch windows. Do this all behind a nice firewall such as a router which will always be the first line of defense.
Microsoft declared over ten years ago that they cannot defend you from malicious software hence you need something other than software to protect yourself. I restore regularly, no need for virus scans or troubleshooting or headaches of any kind.
Be mindful of software firewalls since they only work for non root kit applications. Promiscuous access to hardware by root kits bypasses all software including the windows kernel. |
|
| phaeron |
| Posted: Mar 16 2012, 09:02 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
What kind of firewall throws up outbound connection alerts for a RST sent by the kernel for an unbound port? That seems like a pretty useless notification.
|
|
| IanB |
| Posted: Mar 16 2012, 10:10 PM |
|
|
Avisynth Team Member
Group: Members
Posts: 121
Member No.: 22295
Joined: 23-October 07
|
| QUOTE (phaeron @ Mar 17 2012, 08:02 AM) | | What kind of firewall throws up outbound connection alerts for a RST sent by the kernel for an unbound port? That seems like a pretty useless notification. |
Generally ones that have an issue with the tcp state associated with the packet in question.
Poor firewalls don't implement tcp state tracking at all, so you need both an in rule and an out rule for a full TCP connection.
Good firewalls that do implement tcp state tracking including the target process identification, would reject out bound packets that do not match the original rule profile, i.e. must be the telnetd process.
In this case the in bound packet should have been caught because telnetd was not the recipient. So I suspect the first case here, i.e. in rule only, out rule missing.
In this case the notification is useful because it is alerting that something is in error. But generally, yes I agree we have lameness breeding even more lameness.
|
|
| rjisinspired |
| Posted: Mar 17 2012, 06:28 AM |
|
|
Advanced Member
Group: Members
Posts: 1256
Member No.: 20008
Joined: 12-October 06
|
Thanks for the input and suggestions guys.
I am thinking of getting a router some time down the line. Telnet was set for blocking both ways with the zone "(*) any" chosen in Filseclab. Plus Telnet had been disabled when I reinstalled the OS late last year.
I replaced my firewall two nights ago from Filseclab to Privatefirewall. Priivatefirewall acts sort of like Zone Alarm without the bloat. I have not had any issues nor any pop ups so far.
One thing that this new firewall didn't do was block port 135, the other one did. I had to use DCOMbobulator to close down that port. Port 139 still remains open, as it did with Filseclab. Shields Up still shows 139 being opened. I did try to disable Netbios through control panel but part of the internet didn't work anymore, web server for example. Nobody could see nor download my files so I had to re-enable Netbios.
In Win 98 I was able to fully disable all of that stuff but XP seems to be a different beast when it comes to that.
Things now are running much better now, all is quiet, lol. |
|
