IRC Logs

Network: freenode Channel: #iptables

	Enter your search terms Submit search form
	Web www.irclog.org

[11:26]<hggc>hmm i've been using it for over a year now with stock-kernel-iptables
[11:26]<rrffnn>uhm 3
[11:27]<rrffnn>wait a second a spell error
[11:27]<hggc>i'm getting a lot of relevant info
[11:28]<rrffnn>yes, i forgot an "h"
[11:28]<hggc>ah i see
[11:28]<hggc>anyway i figured this would be much more lightweight than ebtables
[11:29]<hggc>So this lets me do stuff like count the numbers of connections etc.
[11:30]<rrffnn>you might want to use the ipt_recent module to detect portscans
[11:30]<hggc>What i need is the 'best' way to trigger a response like an email-alert or shutting down a virtual server automaticaly if it starts behaving badly
[11:31]<hggc>so i was wondering will this iptables solution be the fastest (as oposed to sniffing / analysing) and should i use ulog or log and what tools are good to do the stuff i want
[11:33]<rrffnn>Henk: as far as portscans are concerned, do you want to detect outgoing or incoming portscans?
[11:35]<rrffnn>because detecting incoming portscans is not that hard, but also closing all ports on an incoming portscan can be used for denial-of-service attacks easily
[11:36]<svzdczz>Henk: have you had a look at snort? altho flase alerts and tweaking it is a pain IMO
[11:37]<hggc>callee, the problem i'm currently having to solve is that of a cracker signing up with us under false credentials (he seems to be very good at getting them) and using our services to scan/ crack en hack his way around the net. So i want to make our services less attractive to him by making it impossible to scan ranges of ips on the net for vulnerabilities (currently ssh) But ofcourse while i do this it would be nice to get the most out of it ('pr
[11:37]<hggc>o-active network protection of your server to detect and stop hackers') should work wuite nice for out marketing department ;)
[11:39]<svzdczz>thats a arse around approach, stop treating the problem symptomatically, fix the issue where his point of entry is, the accounts he seems to have easy access to, are you sure he's not internal, systems guys even?
[11:40]<hggc>callee, hmm seems to me that on an incomming portscan one should never close ports, just block the offending ip.
[11:40]<svzdczz>you can keep doing this, forcing him to gain higher priveleges and take it from there, but youre missing the point again
[11:40]<rrffnn>Strykar: on the other hand: the "hacker" doesnt seem to be very professional, otherwise he'd use (parts) of his own hijacked botnet
[11:40]<rrffnn>Henk: ever heard of ip-spoofing?
[11:41]<hggc>Strykar, we offer a free trial period. and although we do our best to validate trial applicants this guy seems to be to good at getting personal data about people to stop.
[11:41]<svzdczz>callee: is that your opinion of him from one sentence youve heard of him?
[11:41]<rrffnn>Strykar: well, the really good guys in that bussines have access to a botnet, which is much more secure
[11:42]<rrffnn>also distributed attacks are more easy to disguise
[11:42]<hggc>callee, hmm ok the point about ip-spoofing and denial of service it correct but easy to solve. that is not the point here.
[11:43]<svzdczz>callee: the better guys in the business are beyond botnets and such script kiddie behavior, altho i lean towards your opinion of he's not a professional, but i prefer to be safe than sorry
[11:43]<hggc>and the hacker is not a very good one no. it's just a script kiddy
[11:43]<rrffnn>Henk: back to the ip-spoofing part: immagine me not wanting you to access the ssh server you logon to work and your company uses a stupid portscanning counteractor that blocks ips from hosts that scanned ports. so all i need to do is spoof my ip as yours and "scan" the host you want to log on to
[11:44]<rrffnn>Strykar: i am not talking about a guy creating a botnet, with simply viruses, but a net of zombies of hacked boxes with good bandwidth...
[11:45]<rrffnn>at universities for example
[11:45]<svzdczz>i figured that was your meaning
[11:45]<hggc>but he takes his time covering his tracks and he seems to be very good at getting personal info on pleople. he has valid name/address/phone/bank-account data etc. So there is no way of knowing if a person signing up with us is a valid trial applicant / possible customer. or this script kiddy
[11:45]<svzdczz>Henk: denial-of-service is easy to solve? you have a buddy at your ISP who understands the steps needed to stop such an attack?
[11:46]<svzdczz>try it on the phone when you are under one, from a huge botnet :)
[11:47]<rrffnn>Henk: what about a verification phonecall? phonecalls are much easier to track later :)
[11:47]<hggc>Strykar, this is not some 'home' connection
[11:48]<hggc>callee, yea phone verification is indeed something we are implementing
[11:49]<hggc>callee, I'm not so dumb to have my own ip's blocked by some badly implemented anti-portscanning tool. That is not the point here
[11:49]<svzdczz>Henk: i dont think you should re-read the effects of a distributed denial of service attack, and is this guys is getting access to other people bank records, that is something i'd worry about, i wouldnt pass him off as a script kiddy
[11:49]<svzdczz>s/dont/do s/is/if
[11:50]<rrffnn>Strykar: well, you can easily google bank accounts these days, because people are so stupid and naive
[11:51]<svzdczz>callee: and those are all the details these guys need for a signup? thats a flaw in their authentication process right there
[11:51]<rrffnn>ebay.tld is also a nice way to get thousands of valid address information from every nation worldwide :)
[11:51]<hggc>Strykar, the problem is not ddos ( lets hope it stays that way) the problem is that this guy is using my datacenterconnection and my VPS services to scan en hack others. I just want him to loose interest by not enbling him to sscan from my network
[11:51]<rrffnn>Strykar: as i said, a verification phonecall would be the easiest way to make it less attractive
[11:52]<svzdczz>Henk: and i'm telling you that you're treating a headache as too much sun when you should really go to the doc and get the tumor out of your head
[11:53]<svzdczz>fix the root problem not the issues that crop up because of it
[11:54]<hggc>we are working on the verification system. But still a customer can get hacked for real and abused... I'd like to have multiple places to stop hackers you know
[11:55]<hggc>I know that a network filter is not *ALL* i need. that is totaly not the question. But i do believe this is #iptables and not #phoneveification
[11:56]<svzdczz>Henk: we're trying to help the entire problem instead of a patch job, how did you find out this guy is port scaninng from your network
[12:00]<hggc>Strykar, I know you are trying to help, but the discussion was getting out of hand with the ddos, botnet and phoneverification discusions etc. I'm the networkblock owner so I get complaints from sysadmins withing hours after the guy starts scanning. I do have privacy issues so i cannot snoop around on customers all the time. And with hundreds of servers running it's not feasable anyway
[12:00]<hggc>so i want to automate detection as much as possible
[12:02]<hggc>Phone/credential verification is not my personal concern. Thats the guys over at sales that are telling me they are unable to filter this guy out of the 'good' ones
[12:03]<svzdczz>Henk: is thats is the current solution you want, i would suggest installing snort and configuring it with snort-inline to drop traffic that looks like a port scan, again, not very reliable, and will need some tweaking from you, and might disrupt legit traffic
[12:03]<svzdczz>Henk: you need to explain to sales that it's easier said than done, l33t powerpoint presentations usually get them to listen to me
[12:07]<rrffnn>Henk: another thing you can do is put salt in the wound and filter all spoofed sender ips :)
[12:07]<rrffnn>meaning only allow sender ips that the client actually has
[12:08]<rrffnn>that will not make the server useless to him, but it will disrupt stealth-scans etc
[12:08]<rrffnn>and many kind of attacks require spoofing sender ip
[12:10]<svzdczz>in fact, do this right now
[12:11]<rrffnn>however there are legitimate applications that use ip spoofing :)
[12:11]<rrffnn>i am currently implementing one *fg*
[12:12]<hggc>callee, he is not spoofing. I have anti spoofing rules in place
[12:13]<hggc>i can control exactly what ip a vhost can bind/use
[12:13]<rrffnn>Henk: thats not the point
[12:14]<rrffnn>a packet generator can also create packets with a sender ip not from any interface you have
[12:15]<hggc>hmm yes i know. and the 'host' server does not allow packets to be forwarded from a virtual server if i have not explicitly allowed that ip for that customer
[12:15]<rrffnn>ah ok
[12:16]<hggc>so if you generate a spoofed packet with a false sender IP its dropped before it enters the bridge
[12:16]<rrffnn>remember me to not rent one of your vservers :)
[12:17]<rrffnn>because i am currently implementing some kind of anonymous instant messenger using packet spoofing
[12:18]<rrffnn>it's really easy to establish a connection between 2 hosts where both hosts spoof their senders address
[12:19]<hggc>and how does that make you anonymous? the other end still needs to know where to send
[12:21]<rrffnn>imagine you have 2 hosts: both knowing each other (you need to know real ip/dns and the persons gpg-key)
[12:21]<hggc>uhu
[12:22]<rrffnn>so host1 and host2 want to connect to each other: host1 spoofs his sender-address and includes his real address in the data-field of the packet (encrypted with gpg)
[12:22]<rrffnn>so host2 decrypts the data field and knows where to answer and from there on does the same
[12:23]<svzdczz>hows it anon to say the sysadmin of both the boxes
[12:23]<rrffnn>if you do it right, host1 and host2 talk to a lot of "other" people never really involved but never to each other
[12:23]<rrffnn>Strykar: well the concept is that host1 and host2 belong to you.
[12:24]<rrffnn>i recently got the idea when i got to know that german intelligence illegally was sniffing on journalists
[12:25]<rrffnn>also would be a nice-to have application to make logging on provider side useless :)
[12:26]<rrffnn>the very same concept may even be used to make external analysis on a p2p-net like freenode a lot more painful
[12:26]<rrffnn>uhm freenet not freenode
[12:26]<rrffnn>however i'd not recommend using gpg in that case but whatever encryption is used, doesnt matter at all
[12:28]<hggc>callee, but how is that anonimising? If I put up a tap to 'sniff' you. i'd still know where you are sending, So i'd know the other party involved in the chat. Even though packets that are part of the conversation might apear to be comming from all over the world it will not be hard to figure this out.
[12:30]<rrffnn>Henk: this method is used to make external analysis of the communication virtually impossible
[12:30]<rrffnn>nothing more
[12:31]<rrffnn>internal communication cannot be anonymised, for example someone could crack your box and install a sniffer on the very same machine.
[12:31]<rrffnn>however imagine not 2 but 100000 using that little program: no where to do any social networking...
[12:31]<rrffnn>because noone talks to anyone :)
[12:33]<hggc>callee, but fundamentaly spooing the sender adresses in a bidirectional socket tcp conversation adds no anonimity at all.
[12:35]<rrffnn>Henk: the most effective way is anonymizing something like freenet that way
[12:35]<hggc>callee, may i remind you that the kind of sniffing/logging done by 'inteligence' services is done on an ethernet level?
[12:37]<rrffnn>well, internet is ip only, so where is your ethernet level at all?
[12:38]<hggc>taps are placed by your ISP
[12:38]<rrffnn>Henk: well, but how do you know where to look
[12:38]<hggc>or by US in our datacenter right next to your servers switch

Back to #iptables
Or go to some related logs:
#gentoo
#css
#suse
#gentoo
#python